Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
To be fair in this situation it can, effectively, be any 😅
The return type would be the return type of the last function called and the type to pass to the next function would be the output type of the one before, but I honestly don't know how to express that in the TS type system nor if its possible. 🤯
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
These situations always keep me thinking about why I am using TS in the first place. You will end up spending so much time figuring out the types in these tricky situations, which is NOT a business problem to work on in the first place. That's why I would love to revert back to JS, anytime.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Because the absence of types (nor TS nor JSDoc+TS Pragma ) leads sooner or later to non-expected paths that can break the app in runtime, which is a business problem that will rain as sh*t over the dev team (Imagine you spent 200k on a marketing campaign and the app crashes avoiding the conversion that could eventually amortize the costs plus benefits).
Are the types necessary in every single App? No, they aren't.
Still it's recommended to have them in most apps. On the other hand, JSDoc + TS Pragma (remember that JSDoc alone does nothing but printing an informative text, you need TS Pragma to get type checks on dev time) is better than nothing, but TS has much more features than that.
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
Because the absence of types (nor TS nor JSDoc+TS Pragma ) leads sooner or later to non-expected paths that can break the app in runtime, which is a business problem that will rain as sh*t over the dev team
Yep. Although the absence of types may not be considered a major problem by some, me included, I believe that not following best practices is what ultimately causes more issues in web development. By adhering to established conventions and standards, we can avoid many of the potential problems that can occur without these guidelines. In addition, following best practices often leads to code that is easier to read and understand, which can save time and frustration for all parties involved.
But, the thing is that major business issues, even though I don't have data but from what I have experienced, are not necessarily caused by the absence of types. I think there is a correlation between the two. But, the relation is not causation. The absence of types doesn't necessarily lead to rain as sh*t over the dev team. Know what I am saying?
Are the types necessary in every single App? No, they aren't.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Of course not, the main issue is not having tests.
Key in the discussion here being that coding in TypeScript is faster than vanilla JS + JSDoc + TS Pragma, you may never seen it this way but look:
/** Sums two numbers */constsumTwoNumbers=(n1:number,n2:number)=>n1+n2;
As well as more reliable.
To get a similar reliability with JSDoc you need to ensure JSDoc is added and maintained through automatisms in the linter and run this step in the PR's pipeline, at least (i.e. ESLint plugin JSDoc) and it takes more to configure than what it takes to configure TS most of the time.
Keep in mind that using JSDoc and TSPragma you are just using one little piece of TS, which is about type definition and type reports (and it doesn't even cover it entirely).
If you just need those features, then add TS and just use those features 😂
Do you dislike interfaces? Fine, don't use them, if you are working in FP instead OOP, interfaces doesn't even make sense (in FP all functions are interfaces).
It is not mandatory to use everything from TS so don't stress it so hard 😁
Nice to meet you, ma fren 🫡. Sorry, I ain't DEVing that much ✍️ , primarily due to the nature of maintaining Open Source projects 👷, while also gigging 💰. Anyways, stay humble like a bumblebee 🐝.
Thanks for sharing such a neat concept. Also, +1 on using JSDoc (Get the TS code outta my face. Kidding, keep it.).
😂
To be fair in this situation it can, effectively, be
any😅The return type would be the return type of the last function called and the type to pass to the next function would be the output type of the one before, but I honestly don't know how to express that in the TS type system nor if its possible. 🤯
These situations always keep me thinking about why I am using TS in the first place. You will end up spending so much time figuring out the types in these tricky situations, which is NOT a business problem to work on in the first place. That's why I would love to revert back to JS, anytime.
Because the absence of types (nor
TSnorJSDoc+TS Pragma) leads sooner or later to non-expected paths that can break the app in runtime, which is a business problem that will rain as sh*t over the dev team (Imagine you spent 200k on a marketing campaign and the app crashes avoiding the conversion that could eventually amortize the costs plus benefits).Are the types necessary in every single App? No, they aren't.
Still it's recommended to have them in most apps. On the other hand, JSDoc + TS Pragma (remember that JSDoc alone does nothing but printing an informative text, you need TS Pragma to get type checks on dev time) is better than nothing, but TS has much more features than that.
Yep. Although the absence of types may not be considered a major problem by some, me included, I believe that not following best practices is what ultimately causes more issues in web development. By adhering to established conventions and standards, we can avoid many of the potential problems that can occur without these guidelines. In addition, following best practices often leads to code that is easier to read and understand, which can save time and frustration for all parties involved.
But, the thing is that major business issues, even though I don't have data but from what I have experienced, are not necessarily caused by the absence of types. I think there is a correlation between the two. But, the relation is not causation. The absence of types doesn't necessarily lead to rain as sh*t over the dev team. Know what I am saying?
Agree.
Of course not, the main issue is not having tests.
Key in the discussion here being that coding in
TypeScriptis faster thanvanilla JS + JSDoc + TS Pragma, you may never seen it this way but look:As well as more reliable.
To get a similar reliability with JSDoc you need to ensure JSDoc is added and maintained through automatisms in the linter and run this step in the PR's pipeline, at least (i.e. ESLint plugin JSDoc) and it takes more to configure than what it takes to configure TS most of the time.
Keep in mind that using JSDoc and TSPragma you are just using one little piece of TS, which is about type definition and type reports (and it doesn't even cover it entirely).
If you just need those features, then add TS and just use those features 😂
Do you dislike interfaces? Fine, don't use them, if you are working in FP instead OOP, interfaces doesn't even make sense (in FP all functions are interfaces).
It is not mandatory to use everything from TS so don't stress it so hard 😁
💯