Some context
First of all, don't misunderstand me, TYPES ARE GREAT. I use Typescript everyday at work and the goal of this post isn't to question the benefits of a type system. Because types give context, save us from stupid mistake and allow us to avoid performance issues by avoiding most of the automatic type inference performed by js interpreter during JIT compilation and run-time. I think that anybody should use a typing system while building javascript if he ever think to share it or to maintain it in the long run.
But as much as I appreciate the benefits of Typescript as a type system (even if several of my coworkers use so much any that in most places of the app it doesn't bring any benefit at all compare to pure javascript). I'm skeptical about Typescript as a compiler. All the following argument and reflexion concern Typescript as a compiler and a superset of javascript instead of a type system enhancing javascript.
It add a lot of complexity for minimal benefit
While using typescript you need to configure it and it's not simple. The options are not clear at all and documentation is obscure. As an example, ask yourself what are the differences between target and module options.
Ok, so target is straightforward spoil: not really it's your target environment...
But wait ?!? What exactly is ES2017 ? And ES2018 ?
Let's take a look at ES2017 as an example:
- Object.values/Object.entries;
- String padding;
- Object.getOwnPropertyDescriptors;
- Trailing commas in function parameter lists and calls;
- And Async functions.
Ok, Great. But which navigator are supporting this exact set of features ? Other question, did you knew that ES2017 was this set of feature without checking the can i use link ? I didn't.
So using the target options you have to know which version of ECMAscript the feature you want is from. Then you have to check if your target browser support this feature or (if the feature is polyfillable) write the code anyway and deal with the bloated code. If you check the can i use link you should also have noticed that even if all this list of features are part of ES2017. It doesn't mean anything for the browser version. Because web browser implement ecmascript features independently. If you were using Babel you could use @babel/preset-env and using browserslist target exactly the browser you want with meaningfull query (Nota: you should still be carreful about production bloat but you can be more serine knowing that at least the code you're shipping to the user is useful)
There is also the fact that the compiler options include options about minification. Which could be explain by the fact that typescript goal is to handle completely the bundling process. But it's not the case. In most case you still need to add a real module bundler to you build chain to be able to make something real with typescript.
Finally there is the fact that the typecript compiler have some constraint. For example if you want to use dynamic import you must use module: "esnext" which you can't if targeting ES2015 even if you bundler (webpack or parcel) support it. Which means you can't split your code while targeting legacy browser...
Typescript isn't really a superset of javascript anymore
There are some differences between pure javascript and typescript. For example between @decorators in typescript and what is currently being normalized in ECMAScript. Which will probably lead to some difference at run-time when using them once they are implemented natively by browser.
In addition of that it is possible to write today valid code which would be parsed differently by the typescript and the javascript parser which will lead to different run-time execution. I know, I know, it's really unlikely that you ever encounter any usecase like this one. But it doesn't stop the reality of this.
Use JSDoc instead
As I said before, I still think we should type our code. In fact it's really easy to do it even without typescript. We just have to write JSDoc declaration in plain javascript file.
We can then use typescript to type check them with the --CheckJs option.
You can also set VS Code (and probably most of the text editor and IDE in the wild) to show type checking on JS file by enabling Check JS in the parameters.
A big advantage to use JSDoc instead of typescript is that you write javascript which remove any need for a compilation step. You can still use babel if you want but you can also be happy with Javascript.
Some ressource about JSDoc:
Now, I'm not asking you to ditch typescript. If you're happy with it, stick with it. I'm just wondering why everyone jumped in the typescript train when for the most part I see more constraint than benefit compared to a some regular types included in comments.
PS: I didn't talk about tslint vs eslint because everyone agree on the superiority of typescript. Since I talked about browserify, I must also talk about one of my favorite plugin for eslint which is eslint-plugin-compat
PPS: English is not my native language so don't hesitate to correct anything. I used a corrector but its probably not perfect.
Top comments (25)
First of all. Thanks for the argumented and detailed answer :)
I'm also using typescript every day at work.
For the first point about how typescript handle its target I see your point. I still prefer the way browserslist handle it. But ok.
This is a false statement. Typescript is absolutely a strict syntactic superset of javascript. If you disagree, please point to javascript that the typescript compiler can't understand.
I invite you to read the medium article I linked. It is possible to write code which will be parsed, compiled and changed by typescript even if it was valid javascript at the beggining. It's a specific case which probably nobody won't ever encounter in the real world. But it's there and that's it !
As for decorators, they are currently a stage 2 proposal, thus they aren't valid javascript. In typescript, decorators are an experimental feature, in which the documentation explicitly notes, "Decorators are an experimental feature that may change in future releases."
Ok so, you admit that in that case typescript isn't really a fully specified language :D. It is for everything but the decorators ;) In addition of what whenever you upgrade the typescript compiler you can encounter bugs and regression. Upgrading can (and will due to Murphy's law) break your code. which mean that the specification can change.
Use JSDoc instead.
Why?
Because the one thing you're using typescript for types are perfectly handled by simple comments. KISS principle.
"A big advantage to use JSDoc instead of typescript is that you write javascript which remove any need for a compilation step."
I'm confused. In early sections of your post you've pointed to many javascript features that aren't supported in all browsers.
What I want is to have control over the code that is shipped to the user. Either using features which will be transpiled and knowing what the output will look like or not using them because the output doesn't meet my quality criteria (Avoid class when targeting legacy browser for example).
I don't want to use all the latest features. I want to use some good features which benefits me and the user. I want to be able to focus on recent browser while maintaining compatibility with IE (if I need).
In this case JSDoc types are just not advanced enough compared to typescript.
That is a false assumption ;) Once again some people have explained it far better than me. JSDoc is perfectly able to type javascript.
As for the tooling. Yes typescript tooling is a little better. Because typescript is more used than JSDoc. My interogation are about why is that the case when for the same result typescript introduce a lot more complexity ?
Typescript is easy to learn, so onboarding new developers is not cost prohibitive.
If javascript is a subset of typescript and typescript is easy to learn. Javascript must be easier to learn ^^.
Typescript can be safe. If an entire application is strongly typed and the types at the application boundaries are validated, then typescript can reduce the application's potential bugs to programmer errors only.
Agree TYPES ARE GREAT We should use them
Existing applications can be migrated slowly to typescript.
It's even simplier to migrate them to JSDoc, it's just writting comments.
Typescript is a popular language. Last year 80% of programmers would like to use or learn typescript.
And ?!? Again I'm asking why !
If people want only types. JSDoc can provide them. Typescript is more complexe for really small benefit.
If people want mostly compilation benefits and extra features. Babel is better.
If they want both they can combine JSDoc and babel. Instead if they want the compilation power of babel they combine it with typescript. Which is strange because both of them are compiler even if you use one only for striping types (which by the way can lead you to make typescript manipulate invalid typescript code).
I don't like the fact that typescript is an hybrid thing between a type system and a bundler. It's not KISS.
That's it simple word for a simple thing :D
For the second example:
For the third one:
Yes it's more verbose, I know
For the first one, my brain broke while trying to find a use case for it ^^. Types starting by an action verb are a strange concept.
I got your point, yes real typescript is certainly more powerfull that basic JSDoc but does everyone need it ? I'm pretty sure that most of the time I don't.
It can, if you use typescript ^^.
My point is and have always been : You don't need to write typescript to have is benefits. The typescript parser/compiler understand JSDoc well enough. The overhead introduce by writing something else than pure javascript does not worth it (or so I think).
I don't understand why typescript is more than just a type checker. Yes I know you can use Babel and typescript together. But then when using non-typescript feature in .ts files, linters go crazy and unreliable.
I'm not saying that typescript is bad. It's just overengineered (and a little schizophrenic). If feel the same about using a full framework to implement a simple login page. You can but I'm missing the interest.
Ok so apparently t is Foo is not JSDoc compatible (if we need to use JSDoc cli). But vs code understand it right.
So you probably won this point too ;) but rewriting your function to avoid using type predicate is easy
1 reason for Typescript is application wide intellisense.
Well... that's a reason for either JSDoc or TypeScript. It's certainly not a differentiator!
It is to me Rob. I prefer typescript...
And property type safety in the IDE without compiling as you immediately type.
Fair enough, preference is a valid argument all things being equal.
So that exists with both systems, and this is my argument... if it's just preference then that's cool... I can understand that, but then the overall question of how productive a team will be using a tool that is only picked because of preference will come up.
Preference makes sense when we are only choosing a tool on the basis of superficial qualities like the colour for instance (blue hammer vs red hammer), but if the tool is fundamentally different (and demonstrably and objectively less productive) then it becomes a whole other discussion.
Your views are skewed to your world view of Javascript only. Totally ok but not true for Typescript only people.
Typescript can be written in Javascript only, which I have to do sometimes when using Javascript libs that don't have def files. So I'm not against Javascript, I use it every day. I still prefer Typescript and my job requires it.
I get where you are coming from but it's not true I'm applying a skewed / biased view to this. To me this is a cost / benefit calculation. I'm looking purely at objective facts (happy to have any of these reasonably disputed):
1) TypeScript code takes longer to code than a JSDoc comment (because IDEs auto-generate JSDoc)
2) TypeScript adds additional compile time to projects - sometimes quite significant additional time
3) TypeScript requires additional modules / third-party toolsets and setup
4) TypeScript achieves nothing that cannot be done via JSDoc and a correctly setup linting and pre-commit system (except maybe the currently non-standard things like decorator support which if you really wanted to you could use babel to achieve)
5) TypeScript doesn't play well with the existing eco-system when def files are not present
6) TypeScript has to compile to JavaScript to run on your target environment
7) TypeScript is yet-another thing that JS developers have to learn and keep up to date with
On the other hand:
1) JSDoc code can be auto-generated from inference by IDEs making it very quick to write what is missing by filling in the blanks the IDE has left for you - therefore converting an existing codebase to typed code requires zero changes to the actual code you have written - the risk of converting is nil.
2) JSDoc does not compile, the code you write is the code you are executing and all that compile time from TS is removed - additionally JSDoc encourages documenting your code and you can generate documentation from it automatically - see isogenicengine.com/docs-reference.... for an example of documentation that was completely generated from JS code I wrote. I literally did not have to create any of that HTML, it was all autogenerated.
3) JSDoc is natively supported by almost every IDE. No additional software is required to get type checking in your IDE.
4) JSDoc does everything that TypeScript does, has been around for years before TypeScript even existed and for most developers who aren't coming to JS as new devs, JSDoc has been a defacto standard
5) JSDoc adoption among libraries in the eco-system is vastly superior to TypeScript adoption, it's far more likely you can see library code types via JSDoc than there being a def file for TS
6) If you have to compile TS to JS, why not just write JS. Since the tools to do what you want already exist, the devs that know JS vastly outnumber the devs that know TS, hiring is easier and integrating with existing teams is easier.
7) KISS principal
The cost / benefit is overly weighted in favour of JSDoc that TS seems so untenable by comparison.
I'm not trying to change your mind about your preference, it's personal and it's your right...
This is the part that I'm arguing against, and I realise this is likely out of your control, but at some point in the future if someone making that decision happens across this discussion, at a bare minimum they will ask questions and realise there are alternatives before committing to a solution.
Choosing TS means infusing it throughout your codebase. Changing later is painful and requires precision since modifying code is dangerous. Choosing JSDoc ties you in to nothing and changing your mind later requires no functional code changes.
I realise this was a hefty speech but can you see what I'm getting at here? I'm not espousing zealotry, I'm endorsing simplicity and choice over complexity and lock-in.
"Complexity and lock-in?" How can this possibly be true when Typescript can run in JavaScript only mode.
On lost time: I can't tell you how much time I've lost on poor javascript practices, e.g. the worst being declaring the same object in multiple places with keyname spelling errors, with values not expected like numeric over string. Most of all almost all javascript code I have maintained in the past (written by other people) was the most convoluted monolithic code I have ever seen. No separation of concerns, nothing DRY, no SOLID principals. The interesting thing is that I can get into the minds of what they were thinking when they created it. I can't tell you how undisciplined most are... Monolithic code is technical debt in a major way from day one.
BTW software studies all show that up to 80% of all software cost is in maintenance and often done by people who've never seen the code before. You can't possibly be factoring in the cost of maintaining monolithic Javascript code. It's the stuff Migrations to new Architecture is required, you know like the AngularJS rewrite which blew everyone out of the water. When software architecture is abandoned the cost to recoup is in the billions.
From code bases I've seen, most Javascript only people haven't a clue on good architectural practices, its code-and-go as fast as possible. Who cares about software principals, the simple most being DRY.
One other note, if Typescript is so costly why did Google adopt it saying it's a much better model for Organize Modules on large projects. This translates to easier to maintain.
You sir, well done.
You are completely correct. JSDoc is significantly less overhead, compile-free, easier to read, easier to write, easier to understand, easier to migrate one way or the other, is fully supported in all IDEs and has been for years before TypeScript even existed.
There is literally nothing TypeScript can do that JSDoc cannot do except some extra language functionality like decorators.
The reason TypeScript is being widely adopted is for 2 main reasons:
1) Hype and the fear of being left behind
2) Most developers who think TypeScript is amazing don't know JSDoc exists when they go on their learning stint with TS and by the time they find out JSDoc does exist, it's now alien compared to the thing they just taught themselves to use.
TypeScript like every other compile-to-js thing is a TOOL. The reason TypeScript sucks as a tool is because it gets in the way of productivity, adds expensive time consuming extra code and compilation steps / time and is less readable and less fun.
It also reduces speed across the ground significantly, reduces the flexibility of your code to adapt to developmental changes as the project progresses and significantly increases the "noise / support code" to "actual functional code" ratio in your files.
JSDoc on the other hand is unobtrusive, works everywhere without installing anything other than the IDE, has been around FOR YEARS, is very easy to read and write (including most of the IDEs being able to WRITE IT FOR YOU 90% of the way), can operate at dev time and compile time (yes, it is possible to do this, even without installing TypeScript by the way), and if you really wanted to use it at runtime it would be fairly simple to write a JS to AST then AST to JS that reads JSDoc and does runtime checking for you... but that seems like overkill when a simple data schema validation approach would solve that final runtime issue for user inputs and API / data over the wire which you HAVE TO DO ANYWAY when you have user or third party input.
JSDoc has all the benefit of an easy to use and implement tool without modifying anything at the language level. It is beautiful in its simplicity and ease of use.
TypeScript tries to solve a problem that was solved years ago, and TypeScript does it in a much more intrusive and less elegant way than the existing solution.
If you disagree with any of this, please state clearly how you refute these points above. Since almost everything I have written above is factual I can't see why anyone would want to continue to advocate for a language that is subjectively horrible and objectively less productive as a developer to use.
Typescript is a must have in future projects, i know, some devs doesn't like having types, but that is a pro instead of a cons, they really need to give a chance using TS.
Yeah, but no... Until someone prove me wrong and explain me what the real interest for using typescript over babel and types (plain JSdoc or even flow). I think the best way to use typescript is by not using it. No *.ts and no compilation. So basically no typescript.
Flow is the buggiest tool I've ever used. Types work one day - bump one single version of a single package and all goes to hell. Imported types usually appear as
any. JSDoc is simply not powerful enough and not intuitive to write, and it doesn't provide you with compile type checking. Most devs who come from typed languages, such as myself, find it more natural to define the types directly with the variables or arguments rather than having to write 10 lines of comments just to get IntelliSense for a function.Also, Typescript support for React and Redux has gotten so good lately, anyone not using it on a new project must be insane. Automatic detection of which props come from the store and which do not? Consider me sold.
Thats why i said Typescript its a must have in a JavaScript project, having a typed codefeels natural and you can avoid doing things like giving a value a boolean and then a number type.
Trust me, every Javascript dev has passed from that problem, i wish i had typescript in my earlier dev days.
You know that there is a shortcut to write Multilines comment ! Double press on * then enter and tada you have your JSDoc comment with the list of arguments and the first type prefocused to be written.
It's even faster than to write ts types ;)
As someone who started coding with Python, then C, C++, Java for 4 years, and finally Javascript in recent few months, Typescript is hell of a pain to read for me right now. I always question myself: Why do I have to have all these extra logic and complicated stuff just to make the error go away?
JSDoc over Typescript? You crazy? 😂🤣
Yes I am ;)
But you, you're disrespectful so I'll stick with craziness.
By now, this question is invalid... Why?
There's no convincing either side as to what's better. The bottom line is that we all will have to use whatever the company had picked.
Sidebar: I'd recommend against linking your profile here on your resume.
As the founder and CEO of a software development house I can assure you that linking to this article will in no way hurt their chances of getting a job in the future. It shows an intellectual interest in justifying new things rather than jumping on hype trains without thinking through the rationality.
To suggest that being anti-TypeScript would reduce your hireability is to think that everyone must agree with you in order to work together, and that would be a pretty bloody boring place to work I would imagine.
I hire independent thinkers who are not afraid to speak their mind and ask questions. Imagine what the inverse of that kind of person would be and ask yourself what kind of value they would bring to your organisation or team... yikes.
Well, yeah, the job description is to question things, learn things, and change things. I wasn't speaking to the Socratic notes so much - but the arguments (against something new to OP) are riddled with comments that hint at less-than-complete understanding of the platforms (eg: the confusion over targets, modules, etc). That, and the main heading is "it's so complicated".
Together, it paints a picture of someone who a) subscribes to "we do it this way because we've always done it this way" and b) just plain doesn't want to leave their comfort zone.
It would be different if the arguments had stronger foundation, and that's the nature of questioning: Argue what's in front of you, but do so objectively, not emotionally.
My favorite part of interviewing is when I ask "why did you do it that way?" Almost always, that's the deciding moment.
You used k8s for that, great! But why?
Some would say "cause it's cool" and others say "because it enhanced our SLA while at the same time condensing our resource usage and end-of-month bottom-line".
I take the second person in all cases, regardless of what I'd personally do. It shows deliberate, educated consideration of the platform and the spec.