There's like a fight or something like that about JS vs TS and I always like to go against TS in TS posts and against JS in JS posts. This way I ge...
For further actions, you may consider blocking this person and/or reporting abuse
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.
At least if we are about the question "should I learn JS or TS?", I would say, that it makes more sense to start with JS in case this did not happen yet, because TS just extends it. Regarding the usage, as you ask with this article, I guess TS should be preferred, if possible. Requirements can be fundamental knowledge about JS and having additional experience with TS.
There is still the option to switch from a JS project to a TS project, especially if you have well written code (but I do not have much experience to verify this at the moment). If this is not the case I would also doubt, that TS necessarily makes everything "magically" better. You still need to code carefully.
I completely agree with that. It has been a mantra on the community that TS makes your code better but it simply can't be true.
Experience, practice and having enough time is what makes a better code and a better coder. I've seen with my two functional eyes big messes using different languages, frameworks and so and I've seen beautiful code in some of them (including vanilla JS).
Yes it simply can be true. Because you can write the most horrible crap in JS and there's no compiler that will ever complain to you.
So in both JavaScript and TypeScript (and whatever language you can think off) you can:
And much more, (I repeat, with both JS and TS, in fact you can do the same in almost every language) but to you, it's the environments fault (language, IDE, compiler/transpiler/bundler...).
Most of this things can be enforced using ESLint, there's no way typescript will make you suddenly write good code. Practice, experience and a style guide will do.
Cheers
Yes if you want to write unclean code, you can do so in any language. In Javascript however (and other code cowboy languages) you can write crappy code that will produce unexpected run time errors, that become an absolute nightmare to debug. This is something you cannot do in type safe languages.
Discussing principles of clean code as an argument in favor or against Javascript or Typescript is pointless, because clean code principles are language independent. Although there are differences in clean code principles between languages that are strictly OOP and languages that are strictly functional.
Man, really...
Both ways to use TS in the post helps you in dev time.
If you want runtime protected code in both JS and TS need to control the errors in runtime explicitly (i.e. try-catch,
somethingExists && somethingExists.doSomething()and so on).TS will not magically help you in runtime and I'm sure you already know it.
There is no "JS vs TypeScript". The real question is: Do you NEED TypeScript? I don’t think you need to use it every project.
We are not using TS in a big client application (Svelte + JSDoc + d.ts, more than 400 files), and it's ok.
More: youtu.be/xLDVfBUgD8U
Do TypeScript without TypeScript - Simone Sanfratello / NearForm
I'll check it out, thank you! :)
Are you manually writing that d.ts file instead? If so, it would seem it would be easier to just write in TS to begin with and let it generate the d.ts for you.
Good question here! While d.ts serves the purpose of documenting CommonJS modules (
module.exports), JSDoc aims to document JS code and can be used to provide type information in JavaScript files which, along with TS pragma (// @ts-check) will make VSCode to use TS to automatically search for type notations and type checks whenever you document a function, variable etc. With that notation, Including ES6 modulesexport.Leaving that alone, JSDoc + TS Pragma is a safely approach (first step) to migrate a JS project into TS or, if you don't want to add TS as dependency into your project or your team has zero or near-zero experience with TS, you can use this to provide type notations plus type checks without actually coding in TS, just by documenting your code which is always good.
I have no disagreements with using JSDoc. I find it incredibly useful.
Manually managing a d.ts, however, I'm not sure about.
There's the potential of getting those types completely incorrect if manually managing that file separately.
I'd think that if the aim is to use d.ts without TypeScript, surely someone has written some sort of parser which could generate them from JSDoc itself.
At that point, I'd just recommend using TypeScript, however.
No no, that's nothing related with
d.ts. It's just that writing JSDoc this way (check TS doc around JS Doc I linked before) and adding// @ts-checkat the top of your JS files, VSCode will type check your variables, functions/methods and so on using TS behind the scenes.Try it out quickly on a single JS file if you're curious so it will be more clear probably 😁
Lots of good resources in the comments 🥰
TypeScript was the best thing to happen to Javascript. It had features many years before Javascript Integrated them.
TypeScript is still years ahead of Javascript IMO.
Sure it has! The key point is to discern whether you need those features or not on a given use-case.
I'm currently testing some differences with an end-to-end javascript app (Node JS + React) to see if I can find specific use-cases that can bring a real competitive difference between both approaches mentioned on the post :)
So we understood that we need TS (I guess) the question you need to answer when starting a project is "How are we going to use TS on this project"?
Thoughts?
ts-check + JSDoc !== Typescript
You lose all the power that Typescript offers like generics and type intersections and to do anything but the most basic stuff, you have to deep dive into JSDoc and learn a whole new language. Then when you have it all set up, some jackass comes in and forgets to update a JSDoc after changing a function and your code just falls apart like a house of cards.
// @ts-checkis from TypeScript pragma, it makes VSCode use TS to validate your code (to explain it on a simplified way).Didn't read the post, did you? You can enforce it with the ESLint plugin JSDoc.
By the way:
On the other hand you're right with Generics, you cannot use them with this approach as far as I know.
Last but not least, it's somewhat worrying that you consider JSDoc (The standard way to document JS and TS code) a whole new language 😅
Yes lets discuss what you consider a language. JSdoc has a learning curve. Its worrying that you would try to deny that or didnt get that point.
Do you have shares in JSDoc or something? Because you keep bring it up in nearly every post you make.
Hey, I'm just showing that since some days ago. Since when documenting your code is bad? I agree in each pros/cons of a given tech that's something you really need to practice.
We can agree that TS is good, but you seem stubborn on TS being "the only way to go" for any reason.
If you want type safe JavaScript (which is the case if your team is bigger than 1 person), typescript is the only logical way to go yes.
That's the key point. Using TS on a way or another 😆
No, your way is a work-around to not use actual TS, but JSDoc with ts-check instead, which is not the same thing (which we've already established), you need to learn how to write proper JSDoc and you cannot use some convenience features that TS has, like generic types or type intersection features.
Thankfully, atleast you agree that type safety is important. You're convinced your way is better and you dismiss any arguments in favor of using just TS (which is nothing more than vanilla JS + type safety) it does not look like we're ever going to resolve that.
Gosh are you like a fanboy or something?
Each project has it's needs. There are tones of JS projects, is the most used programming language in the entire planet. TypeScript was released in 2012, it's been almost 10 years by now, but do you really know it's market share?
If you're about to create a npm package you probably will add TS or d.ts at least to bring extra-compatibility, that's a thing.
On the other hand, I'm gonna show you a real life metric:
Job offers naming JavaScript in the European Union (remote filter On):
Job offers naming TypeScript in the European Union (remote filter On):
That's a huuuge difference of 43.275 (~5.5 times more in favor of JS).
Let's look at United States (remote filter On):
The diference is even bigger here, 153.011 (~7 times more in favor of JS).
Even that, you are suggesting learners to learn TS without learning JS first and stupid things like that.
What will you say? that companies using TS don't use LinkedIn? 😆 They suddenly hate microsoft so they decided to not using it's platform but keep working with TS? C'mon.
Do you really think that all those companies will suddenly migrate to TS for any reason? Are you that kind of utopic people that tries to change the world while refusing to learn how it actually works?
I can in fact get type intersection with this workaround and I do not need generic types most of the time or in 99% of my projects (either be personal or professional). Again, if you want this features, add TS and go ahead.
There are tones of posts telling people how good TS is since it has been released, still the amount of projects using it is low in comparison with projects that are not using it.
If I reach 3k people, they share this and they begin documenting their code and using some few features like type-checking in dev time, Welcome! We'll probably face better projects in a future.
Having people to know this one, the one that @patoi suggested or any other intermediate option is firstly a fact -because they exists- and secondly can be convenient for many.
It's ok if you don't share this feeling or preference but at least you can make the effort to understand it.
Would you recommend a beginner/hobbyist developer learn TS from the start?
TS is an addition to JS so if you're at the beginning of the road I'll suggest to learn JS beforehand. The same way I'll suggest to learn JS before jumping into React i.e.
Learn Typescript from the beginning, because it means you also learned Javascript. Typescript is only a superset of Javascript. If you can write Typescript code, you can also write Javascript code.
TS is a good addition to JS, but there's no tech to rule them all. There are few disadvantajes on using it:
We need to be honest about what we use. Knowing the good and the bad things of what we use helps us improving our work, fanboying something usually tends to a blid-following which is usually not good.
The first 2 are true for JSdoc as well, with the disadvantage that JSdoc does not enforce type safety. If people forget to update it, your code will fail in runtime.
Compilation time (in milliseconds) is a very small price to pay for actual type safety. It saves me many hours of trying to debug a JavaScript runtime error.
1- I'm not saying that TS is bad in any piece of this texts.
2- JSDoc is PART of JavaScript, hence of TypeScript.
3- No, you can't have outdated docs with TS-Pragma, it will take care of that plus you can use ESLint JSDoc plugin just like you do in any project.
TypeScript was a great way to slowly add types to existing legacy projects, and it's decent for small apps, but it breaks down in speed when you hit 100k lines of code with 40 devs. One person drops in a 'ts-ignore' comment or a
as unknown as stringand it starts to not be worth the effort.I've made the switch over to ReScript and it's a much better alternative for writing strongly typed code that compiles to JavaScript.
rescript-lang.org/
Is this a "pros + cons", because I think, the cons are missing? TypeScript, while great in many ways, also has its dark side, or at the very least, a learning curve with some rough edges (and for some reason, it is barely ever even brought up).
In short: Would you address this question? - "What did you find most frustrating about TypeScript, especially after you already used it for a while?"
This would be a different question. The post is more about letting people know that there are two different ways in which you can use TS in your project.
Type-checking, documentation and type inference in Dev Time is a valuable bunch of things to have, there's no doubt on that (I guess).
Being able to get those things while working with JavaScript just by adding TS Pragma and documenting your code (which is something you should want as well in your projects by default) suits for many projects.
If I'm going to create a big service in Node RE I'll probably add TS as dependency, but I'm not adding it in frontend React or Next JS applications because this other way to get type checking in dev time suits better IMHO.
This is just my personal preference without context and I myself can review my preferences in a future.
Knowing both ways to use this, you can choose whichever suits best for your projects.
I'm currently hands on two different projects using this second option, both are usign Next JS as framework but with two different approaches.
In the first one we depend on a headless CMS so the requests goes through Next -> gateway -> microservice -> CMS to get the page structure and data to pre-render it (SSR) with React, so the Node JS part in Next is just a middleware. (The GW and the micros are built with Java Spring).
The second one has it's own services inside Next JS Node part, connected directly to a database using Sequelize as ORM and Joi for validations.
If we need to migrate to TS for any reason (it doesn't look like to me) we can do it easily as we already defined types and so on.
I can extend more the architecture explanation but with the information provided you can see that the project with the CMS does not fit well for TS (we can receive whatever structure from the CMS and we should then define all the input types which is kinda annoying when client wants the things ASAP) so we can just use types for our inner components and ignore them in the dynamic factory that loads components dynamically to just check the identifier of each, or in other words, apply responsibility delegation.
The most frustrating part about Typescript is that you cant write the bad code anymore that you used to write in Javascript :P
😆 😆 😆
Sure you can, just like in any language!