I am working as a web developer for nearly 20 years. I care a lot about simple and maintainable code that is fun to work with, good documentation and clean APIs.
I was strongly against TS not too much time ago. I hated it. It made me feel incapable of expressing my thoughts in code anymore. It prevented my from using JS as I was used to. My code worked stable most of the time and JSdoc helped a lot in adding types to functions and variables.
When i started using TS, I was constantly fighting the compiler which spit out long and complicated error messages.
Those days are gone now. I fought my way through and came to piece with TSC. I use it every day now and would not start any JS project without additional TS guidance.
About your post:
JSdoc is good and fine but it has its limits. I am much in favor for adding descriptive comments on top of functions but the type descriptions just dont cut it. The TS syntax is extremely more expressive.
I also have the feeling you are missing a lot of what TS can give. You mention for example that TS interfaces are only good for OOP. Thats wrong. You use interfaces to describe objects and their properties - and objects are passed around in JS all day. In fact interfaces are my most used feature of all.
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
my scope for the last year has been React and NextJS (plus few Node) so prop-types work best than adding TS interfaces as prop-types are checking in runtime plus it lets you define clearly which props are required, which ones are optional and in case they are optional, it makes you add a default.
In Node I usually use Joi which covers the same need.
I am working as a web developer for nearly 20 years. I care a lot about simple and maintainable code that is fun to work with, good documentation and clean APIs.
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
You can combine the JSDoc approach with PropTypes.
Remember that TS interfaces and Prop Types are not covering the same need.
Prop Types offer runtime checking while TS does not plus it lets you define optional and required props and enforces you to add a default for those which are optional 😀
I am working as a web developer for nearly 20 years. I care a lot about simple and maintainable code that is fun to work with, good documentation and clean APIs.
Runtime checking is absolutely unnecessary - except at the point where foreign data enters your system. So static type checks are better since they do not unnecessarily clog your runtime execution.
About optional and defaults: thats perfectly possible and I used it in my example. title is optional and has a default.
I am working as a web developer for nearly 20 years. I care a lot about simple and maintainable code that is fun to work with, good documentation and clean APIs.
Oh and by the way: as far as I know, the runtime checks of prop-types only work in development mode and is removed from production builds - so you get the sameas with TS.
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
In my current specific use case there is a headless CMS that manages both the structure and the data to show on it.
It's better to not remove them and fallback to a controlled error if it suits instead.
Removing them is something that you need to actively config, not something that works like that out of the box.
On the default thingy, we can receive relatively big chunks of data thus It's less invasive or more maintainable to get defaults defined in prop-types instead on the component definition.
It's all about the use-case like always :)
On the other hand, by all means this post is about having different options, not an allusion to fight between two tech stacks. You can use whatever you want, but you should use whatever your project needs.
A possible TL;DR would be "Is better to use TS, but just use the amount of TS you really need" 🤷🏻♀️😂
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I was strongly against TS not too much time ago. I hated it. It made me feel incapable of expressing my thoughts in code anymore. It prevented my from using JS as I was used to. My code worked stable most of the time and JSdoc helped a lot in adding types to functions and variables.
When i started using TS, I was constantly fighting the compiler which spit out long and complicated error messages.
Those days are gone now. I fought my way through and came to piece with TSC. I use it every day now and would not start any JS project without additional TS guidance.
About your post:
JSdoc is good and fine but it has its limits. I am much in favor for adding descriptive comments on top of functions but the type descriptions just dont cut it. The TS syntax is extremely more expressive.
I also have the feeling you are missing a lot of what TS can give. You mention for example that TS interfaces are only good for OOP. Thats wrong. You use interfaces to describe objects and their properties - and objects are passed around in JS all day. In fact interfaces are my most used feature of all.
Totally agree,
my scope for the last year has been React and NextJS (plus few Node) so prop-types work best than adding TS interfaces as prop-types are checking in runtime plus it lets you define clearly which props are required, which ones are optional and in case they are optional, it makes you add a default.
In Node I usually use Joi which covers the same need.
About JSDoc limits... I don't think it really has many, check this out typescriptlang.org/docs/handbook/j...
I am working in a similar environment (nextJS frontend for a huge news portal in germany).
We are not using prop types at all in favor of: typescript interfaces! :D
Ususally, a component looks like this:
You can combine the JSDoc approach with PropTypes.
Remember that TS interfaces and Prop Types are not covering the same need.
Prop Types offer runtime checking while TS does not plus it lets you define optional and required props and enforces you to add a default for those which are optional 😀
Runtime checking is absolutely unnecessary - except at the point where foreign data enters your system. So static type checks are better since they do not unnecessarily clog your runtime execution.
About optional and defaults: thats perfectly possible and I used it in my example.
titleis optional and has a default.Oh and by the way: as far as I know, the runtime checks of prop-types only work in development mode and is removed from production builds - so you get the sameas with TS.
In my current specific use case there is a headless CMS that manages both the structure and the data to show on it.
It's better to not remove them and fallback to a controlled error if it suits instead.
Removing them is something that you need to actively config, not something that works like that out of the box.
On the default thingy, we can receive relatively big chunks of data thus It's less invasive or more maintainable to get defaults defined in prop-types instead on the component definition.
It's all about the use-case like always :)
On the other hand, by all means this post is about having different options, not an allusion to fight between two tech stacks. You can use whatever you want, but you should use whatever your project needs.
A possible TL;DR would be "Is better to use TS, but just use the amount of TS you really need" 🤷🏻♀️😂