Hi my name is Ryan, and this is my first post on dev.to. I regularly write for medium.com but I wanted to give dev.to a try. I'm a big enthusiast of reactive libraries and front-end JavaScript performance. I'm the author of Solid.js one of the top-performing libraries on JS Frameworks Benchmark. But today I want to write about something else.
I've been using TypeScript now for about a year. Hardly enough time to come to a conclusion about it, but I've wanted to write this article for months. Pushing it off each time hoping that it would finally click. I also decided that I might not be the best judge as being a library writer I was sort of thrust right over the deep end. So I wanted to give people of different experience levels and programming backgrounds I trusted an unbiased chance at it. So not only did I convert all my open-source libraries to TypeScript, but 6 months later I asked the developers at the startup I work at if they would like to use TypeScript on a rewrite of our core application. They had a varied interest in learning it, but they were all open to it. Now that several more months have passed, I finally feel that I'm at a point I can say something. So let's dig in.
TypeScript is an Art, Not a Science
I've been programming for about 25 years now. I've used dozens of typed languages over the years. But TypeScript was a first in that it was trying to put types on top of a dynamic language. This in itself seems like it would be an incredible feat. But then again dynamically typed languages did so a few decades ago. At one point getting rid of the types was actually seen as progress.
When you start with simple examples it all seems familiar enough. You add a few annotations and marvel at how it won't let you assign a string to a number. You make sure your functions have clear parameters and return types and you start feeling like you are getting it. And then you hit a place where you need to pass in different objects. Your first thought is loosening up the definition but then you see an example with generics and realize TypeScript uses generics way more liberally than you are used to with C++ or Java. Even cooler, their type can often be inferred which means you don't even need to annotate and everything magically works.
That is until you add a few extra levels on to, and you start coming across the inconsistencies, or the places where types can't be inferred. The other day I was helping my lead dev work through some typings on factory function that produces hooks that return CSS in JS generated classes that are a result of the style definition passed into the factory and props passed into the hook. He had something very basic and couldn't quite figure out why his types weren't working. So I sat down and started using generics to assign multiple values and creating wrappers to project types for return values. Someone how after a couple of tries I got it working for the most part. I admit I felt pretty good about myself, but the developer looked bewildered. You see he thought he was finally getting TypeScript and he had no idea what I had just done. So I spent the next half an hour explaining it. In the end, he got it, but he still didn't feel any better about it as he would have never thought about it that way. And truthfully I was in the same boat months earlier.
You've heard the saying that programming is art? Developers choose how to model their problems and have their own stylistic approach. Everyone's code is different. I remember when I was a young developer I'd try to find the most clever way to solve a problem and feel so proud before a senior developer tore a hole in it and asked why I just didn't do the simplest thing. Over time my code got more directed and less frivolous. TypeScript has so many tools to do seemingly similar things since JavaScript has so much potential, that you might easily take a tact that can't get you 100% of the way there. It's very difficult to know what the right way is unless you've experienced it. But since it is impossible to safely type all things in JavaScript you don't even know if what you are trying to do is possible or if you are just thinking about the issue wrong.
This leads to a very strange scenario that the more complex the issue even when you go for help, communicating the intent of the code is as important as the function. When talking about possible solutions it isn't unlike people looking at modern art trying to critique the intent and the emotion of a toilet paper roll nailed to a wall. You can spend hours perfecting an elegant solution to your types without shipping any new workable code. It makes you feel really good and clever when you get it right. It is metaprogramming to the highest degree. It gets even more awkward when you are trying to use a 3rd party library who is more concerned about spending several months getting it right than getting something out that works (while in meanwhile the current types are effectively broken).
As I alluded to previously, programming itself has these characteristics, but it's super strange when your tools do too. That level of uncertainty, that need to solve a puzzle with your tools completely on the side of the programming problem you are solving is the kind of thing that I can see developers liking given their personality as problem solvers, but when it comes down to things like efficiency and productivity it is excess. Every time I use TypeScript and I realize that I remember being that young and unexperienced programmer just doing a lot of unnecessary stuff.
TypeScript focuses on Ceremony
I often wonder how many people who rave about TypeScript have ever really used JavaScript. I used CoffeeScript for 5 years almost exclusively and only returned to ES6 for the last couple of years. I wouldn't recommend people move over to CoffeeScript today except perhaps to appreciate some of its qualities briefly. CoffeeScript in some ways is the absolute opposite of TypeScript exemplifying the other characteristics of JavaScript. Forget types. You don't even declare variables for the most part. If you read the way these people talk about JavaScript I can only imagine what they'd think of CoffeeScript.
Would it surprise you that CoffeeScript increased productivity over JavaScript for our team? This was a different time and I'm not sure it would do as much now. But let me paint the picture. Writing CoffeeScript is a lot like writing pseudocode. So after you plan out how you are going to approach your programming task, you tend to just throw stuff up. Need a new variable just start using it. Getting an idea up was incredibly fast. The syntax being terse was nice as something that would be 80 lines in JavaScript would be about 30 lines in CoffeeScript. Sure you'd run it realize it didn't quite work since you missed a null check. And you'd add a ? (optional chaining operator). Then you realize your logic was wrong in the 2nd loop. So you need to do a refactor.
What I've witnessed with TypeScript is that 30 line CoffeeScript file is now 150 lines. I can't see the whole thing in my IDE window anymore without scrolling. At about the same time the CoffeeScript developer is starting the refactor the TypeScript developer has just reconciled all the types and is about to run their code for the first time. Type annotation doesn't take much time unless you need to look up Types you don't know (seriously for the browser MDN is such a lifesaver here), but the tendency here is to ensure everything matches that it all works out the first time you run it. Sure the TypeScript developer never has that run where the browser spits out Cannot read 'name' of undefined but by the time they are realizing their logic is wrong in the 2nd loop our first developer is already testing the refactor.
Many JavaScript developers are very used to just throwing stuff against a wall and see if it sticks sort of development. They rapidly test ideas without the code being perfect. This just wasn't a luxury afforded compiled languages. If you are going to wait a couple of minutes you better make sure your code works before you hit build. To me, it isn't that different from the difference between waterfall and agile methodologies. We know that some larger companies can still have some issues being as agile and I feel the argument for TypeScript is sort of similar. Now don't get me wrong. The CoffeeScript probably produced more bugs, but trying something can often reveal when your assumptions are wrong quicker. Waste less time perfecting something you aren't going to use anyway.
TypeScript is Noisy
As in it has a higher noise to signal ratio. Less of the code you are looking at is functional. I've already talked about more code being required but this goes beyond initial development. I know this is perhaps more opinion based but when Dan Abramov (React Core Team) recently tweeted that when he looks at someone else's code the Types actually get in the way of him seeing the code, I realized I wasn't alone. Type information can be noise when you are just trying to see the flow. Truthfully this is less of an issue compared to the last as it doesn't change how you approach coding. But it is something. We can filter out the annotations pretty readily but simply function declarations going from one line to 5 lines starts you on a path where you are always looking at less.
TypeScript is a Subset of JavaScript
I can't impress this one enough. Technically is a superset from a feature support perspective. However, people use it so they have compile-time type checking so once that becomes a requirement for you there are just things you can't do with TypeScript. I hit this right away when writing Solid.js. It uses JSX in a completely different way than React, it has a lot of functional patterns like currying, and functions that support paths and dynamic arguments. Not to mention at its core it is incredibly tuned for performance so I was unwilling to change what the underlying JavaScript compiled to. I kid you not, within 3 weeks I ran into over a dozen unsolved TypeScript issues with open tickets and reported 2 more myself. I have received a lot of help from the TypeScript community and have no ill will towards the people working on it and supporting it. But when for the solutions that are solvable the best options are: change your API or add another function call to get the compiler to work the way you want, I was understandably very uncooperative.
Ultimately I settled on not having custom bindings with $ prefixes in the JSX attributes, using JSX namespaces, and introducing intrinsic elements with special characters (all things supported by the JSX spec). I introduced another syntax against my better judgement to avoid paths. I just think is vital to understand that there are a ton of patterns you'd do with JavaScript that cannot be made type-safe and many more that would require an expert to determine if it is.
Obviously, as a lower-level library writer, I hit these right away, but I've even seen these affect application developers. They've had to change the way they would approach an interopt layer since it wasn't as TypeScript friendly. Similarly hitting weird TypeScript only idiosyncrasies when using 3rd party libraries. Pretend you haven't sold your soul to TypeScript and read this guide for Material UI. Why would I ever sign up for this?
Conclusion
If you treat TypeScript as a language in its own right, with albeit a smaller feature set than JavaScript, you will do just fine. If you treat TypeScript as JavaScript with types you will be disappointed. The thing is despite how terrible of an experience I or those around with me have had we are sticking with it. As a library writer it makes a lot of sense since there are many people that want it. It hasn't meant any compromise thus far that I wasn't willing to make so I'm committed to supporting it. I know somewhere in my head by doing so I'm limiting my creativity. Some of my more interesting ideas don't work with TypeScript so taking this position might compromise my motivation to look into them. But Solid.js, as it is today, is already very impressive.
On my team, it was split. The backend developers did not have a hard time with TypeScript and their solution scaled with their knowledge as they've found better ways to structure their project. However, on the frontend, it has been nearly a disaster. TypeScript has basically dictated other technology choices. Where we've been like use TypeScript or use this library. So far we've sided with TypeScript because of the promise of what it brings. In hindsight, I would have never introduced it there but I feel like we are starting to get over the hump so the time invested is worth seeing it through. It's just ironic that many of the advertised benefits I believe are actually detrimental.
TypeScript doesn't improve productivity or readability. It doesn't particularly improve on modern JavaScript feature set. If anything it restricts what you can do. But it isn't all negative. It pushes developers to document code. It sets a contract when dealing with 3rd party APIs. However, the biggest win I think is it makes developers more comfortable. It inspires developer confidence which is something we can all get behind even if the language itself might be the worst mess of compromise I've witnessed in my 25 years of programming.
TypeScript might not be the language we need, but it is the language we deserve for now.
Latest comments (82)
I loved this:
TypeScript is backed by M$. This is all you must know. M$ created the hype around it. M$ supports it. Tell me how about all M$ languages it created? All of them are silently dying. The same will be with TypeScript.
Hi Vladas Saulis! 👋
Welcome to the dev.to community! We're thrilled to have you here and appreciate your engagement with articles. It's great to see active participation from new users!
We would love to hear more from you about your field of expertise, whether it's JavaScript, C, or any other area you're passionate about. Our community is diverse, and we value a wide range of technical discussions and insights.
By sharing your knowledge, you can contribute to the growth and learning of fellow developers. Whether it's tutorials, code samples, or even thought-provoking discussions, your contributions will be greatly appreciated.
If you have any questions or need assistance in creating content, don't hesitate to reach out. We're here to support you on your journey of connecting with like-minded developers.
Looking forward to seeing your valuable contributions!
Happy coding! 🚀
"At one point getting rid of the types was actually seen as progress." - And it will be seen so again. Typing / not typing is really just a preference, not a good or bad thing - people worked without types for so long, they started to see them as a good thing again because they started to have all the problems that typing took care of for you. Now that everyone is using type annotations again, people are noticing what a PITA they can be in many other use cases. The circle never ends.
I'm just waiting for all the "cool kids" to notice how easy it was to compose objects dynamically in old code... and start trying to do that again. Imagine - you can create an object, put data on it, and send it back and forth between applications, without having to worry if the object was a string or a number? And those applications just work, because they are smart enough to detect the difference between a string and a number and don't require the developer to spell this out up front? Wow, such a language must be amazing! ... and we can introduce a new concept called magic methods, which automatically check for and assign properties on objects ... no need to write getters or setters every time you add a new property! This will happen. Just wait. The developers whose careers / reputations are ruined by hardliners who insist that only typed languages are good languages? Those are good engineers you will never get back. The human consequences are the only permanent ones.
I know this is an old article, but then again, it must have aged well enough for you to include it in your 2-year digest, so here are my 2 cents:
Cent 1: Libs vs Apps
I might have misread, but the experience you describe seems to be mostly as a lib author. Libs, IMHO, are different from apps in that any library worth its salt usually has much more users than it has developers, most of the bugs are very likely to be reported, and maybe even have a PR submitted for. "Given enough eyeballs, all bugs are shallow". Plus you usually have a test suite in place, so adding more tests is usually a low-friction endeavor.
Apps, on the other side, have a lot of code that isn't reused at all, and might even be called very rarery, so it can have a lot of edge cases that might break unknowingly to anybody. Also, people reporting bugs are either QA engineers, or users, so on average, bug reports have less technical details. Sure, tests might help, but I've worked in 4 shops so far, and 3 of them had very little to no tests for the client code (the fourth one has some, but not that many either). All 4 used statically typed languages though (TypeScript or ReasonML/ReScript). Whatever you can say about noisiness of TS annotations, tests seem to be more work to maintain.
And one thing apps have in spades is business logic. Types are good for domain modelling, making illegal states irrepresentable, etc. Do libs need this kind of help with modelling? I don't have a lot of experience with libs (the only lib I've published is very type-oriented: it mostly consists of API), but I have a suspicion that really good libs (or at least FE frameworks) mostly try to create simple abstractions for a lot of technical complexity. And for that kind of problems, static types in implementation can be more hindrance than help, as you have obviously noticed.
Also, I know I don't have enough experience with tests, but. One highly touted benefit of static types is ease of refactoring, and I'm not sure how the same would work with tests. You change a function signature in TS, and the type checker screams at you until you fix all the call sites. Nice and easy. (You'd have to be more careful in TS than in a language with no nullable types, but that's a minor detail.) How to get that kind of safety with tests? I bet you need a lot of coverage (probably with integration/end-to-end tests) to approach this kind of safety net. And sure, I know types won't catch everything that tests will, but again, types are cheaper.
Where I'm going with this? My point is that when authoring a lib, you probably give more thought to design upfront. And you don't refactor as willingly. So ease of refactoring, on the cheap or otherwise, isn't in high demand. And when do refactor, you have a lot of test coverage anyway, so tests are a sunk cost. With apps, the process is usually much more agile, and both ease of refactoring and maintenance cost are very important, so it's no wonder types are used everywhere, but tests are not.
Cent 2: Interface vs Implementation
I know some people think you're not
manperson enough when you bail out of the type system, but I think it strongly depends on whether it's interface or implementation, and I'd argue that for the latter, type safety is not as useful and doesn't matter as much. The more useful approach could be to write sane types for the interfaces, maybe write tests to make sure it works as expected—and then use whatever number ofas anyand@ts-ignoreas you need to make it work. (In a language like ReScript, which is not a "gradually typed language" like TS, you're still free to combine static types and raw JS like this:let add: (int, int) => int = %raw(`function (a, b) { return a + b }`).)But when it comes to interfaces, I'm with Jared Forsyth who said: "If it’s hard to type check, it’s probably hard to understand." Communicating the intent of your abstractions is probably as important as solving the problems your abstractions abstract away. So if some howto is hard to express with types, maybe it's to hard to explain at all? Sure, there are exceptions: e.g., defining targets in Stimulus is easy to grok while impossible to type check, but I'm not sure it's something to aspire to.
Conversely, if someone has to use hacks while consuming some statically typed APIs, then either the APIs are bad (or at least a bad fit for the world of static types), or your own types are convoluted, or, on a rare occasion, it's a bad case of impedance match between the API and the problem at hand. Maybe those rare occasions happen often enough with libs where you have to optimize a lot, but again, that's not much of a problem with your typical business logic code.
I do agree with the overriding App vs Lib thing. In the article I was dealing this on 3 fronts, as a library author, then as Development Manager on frontend and backend of a Preact/GraphQL project. I will say the backend experience with TS was great. It felt easy and just worked. There were some poor types at first but it was never an obstacle.
On the client-side, it was much more painful. Part of it was just library mismatches and trying to pull of Preact Compat cleanly. And weirdness around libraries designed without TS in mind. All that being said it is a lot easier to sort of just make it work as necessary and take the value where you can. We stayed on TS for the project and the developers seemed relatively happy with it except when they got stuck.
I think I found it much more annoying in a prototyping sort of sense. Sometimes developers would be stuck, and I found it easiest to lay out the logic in simple code. With CoffeeScript my psuedo code would basically execute. We were past that with JS anyway but TS felt like the opposite end of the spectrum. In one sense it's probably better anyway. The old 10x developer leaving behind 10x the number of bugs. But my former development manager was like that and I had continued the tradition. In my career I've never seen any teams deliver that fast before or again. I'm not going to say it isn't without tradeoffs, but I find it interesting when looking at it as a matter of points along a scale. Not simply better/worse.
As a lib author, most of my friction came around functional programming APIs with paths and partial applications, and JSX. Solid uses a custom JSX compilation and typescript definitely has tied my hands more than a few times. I hit about 5 issues within my first week that have been taking years to resolve. They have addressed 2 out of the 5 in the last 2 years. Honestly I think those factors made things particularly awkward. I wouldn't expect most libraries to even hit these sort of things.
That was a great read! Thank you. Not many people have the guts to write that they don't like TS too much because it's a HOT topic and everyone attacks them with the benefits that TS offers while no one is against those benefits. 😄
In general, programming goes back and forth in terms of "the best way to write an app". I don't want to expand on this but one example is going from OOP to Functional programming (FP) and vise-versa or SPA vs SSR. Again I see that I can elaborate on the statements above but I don't want to waste time explaining something that it's not my point.
My point is that people who come from languages like Java love TS and it makes sense because they are used to that paradigm of coding. I came to JS from Java and after some time of using it, I felt in love with JS for the "dynamic behaviour" it offers. I feel more powerful doing things with JS and I never returned to Java. Also I am now a big fun of FP and almost never use OOP. So I think there is some "truthness" on "People who go with TS don't really know how to write good JS"
However we are humans and we can't always rely on people writing good JS and the truth is that even if you are experienced enough with JS, TS does a better job on handling large codebases. I use Webstorm and the IDE offers autocompletion for JS even though it's not great. Is it true if someone says: "We write TS in order to make the IDE happy so it can help us prevent humans syntax errors or remind us we wrote a wrong code" ? I don't think it's 100% true because with TS you get errors on compilation not only inside IDE.
But let's be honest. TS offers some great benefits over pureJS and anyone benefits from them. So it's a fact that TS offers a great experience in letting you know that you did something wrong that you, as a human, could easily code it wrong with pureJS.
But let's be honest again. TS code it's not clean and there is so many examples out there that showcase TS code vs the same code in JS and of course JS wins all the time. You might argue that reading TS code can be easier because you know the typings. For example for function that receives a
personargument, in TS you know exactly that the argument is an object with known properties. And you are right.There in no doubt TS benefits are great but having to write TS code is something that I don't personally love. So I have to leave with coding in a way I don't love for the benefits I need. I think everyone agree that it would be amazing if you could write JS code and have TS benefits. Maybe people coming from Java would not love that either though (kidding.. or am I?).
JS is a very dynamic language. And TS limits the "dynamic" behaviour of JS in order to do its job.
YES.
YES.
Conclusion: I am not against TS because I think everyone loves the benefits but I am against TS because I think everyone loves writing JS more than writing TS.
NO.
The last couple of days I have been experimenting with JSdoc + TS type checking and pure JS code. And it works amazingly + offers the benefit of explaining your code not only typing it + write docs out of it. Not sure if that's really better than just using TS but currently it seems so.
I also have the option to type only the things I need to. For code that I am sure how it will behave I don't have to write typings. Even though that might seems a bad practice since you should type anything, right now I think it's an advantage. But still early to have an opinion.
Final conclusion: In order to make your code behave the way it should to and be more confident about your code and also using JS, I highly recommend this stack:
I will write an article about this stack when I experiment a bit more with it. Hopefully it will be within this year.
This is by far the most relatable comments I can read about typescript on the internet.
As a nodeJS developer who modularazing the codebase, do functional programming with dependency injection. do my unit test properly. write component tests and e2e tests. I just cannot relate the pain points of javascript that many says over and over again.
There's some inferiority situation happening in javascript community and they think the dynamic character is (always) a language problem...
Yes I've never had an issue writing stuff people think is controversial as I have no particular issue with defending myself and find with my ideas for Frontend Dev I need to often anyway.
In general, I think your observations are dead on. I'm not really sure what the solution is. I do think it's interesting when Vue exports different types for end-developer rather than what they use in the codebase. It makes sense but it suggests this divide is a real one anyway. Which is insane from the perspective of a true typed language and a nod to how artistic this whole endeavor is.
I haven't found JSDOC particularly pleasant anyway because for some reason it feels like more work, but that also acknowledges the fact that you weren't forced into that work when you were just iterating on the idea.
Since writing this article I've had the opportunity to continue to maintain other TS libraries including a whole platform built on top Babel (and custom Babel parser types) Honestly it is a bit of a mess sometimes and we sit there cursing TypeScript but yet we stick at it. I think as library authors it is just part of the thing.
Applications are different as you say, strict state management, robust testing etc all cover the basis. They should be there anyway even with TS. I feel it is likely in that environment the extra work is something you'd need to invest in one way or the other regardless so maybe TS isn't that bad. Like I've seen the move to TS + Prettier instead of ESLint in some cases. That is a simplification in a sense. It's also where it is least necessary.
As a library author, you can write in TS or write your definitions and call it a day. I'm starting to think that the latter might have been the better move for most libraries. It just is awkward how TS bug fixes and upgrades tend to break Semver in ways we don't want to embrace as a library author. It just adds ultimately to the unpleasantness to all those downstream.
Interesting read. I read this article along with Eric Elliot's article, You May Not Need Typescript. I think you might find a few articles as a follow up to this one interesting:
medium.com/javascript-scene/you-mi...
medium.com/javascript-scene/the-sh...
labs.ig.com/static-typing-promise
I agree with the sentiments of this article and often feel like Typescript is an attempt to make JS more like C#. I also got this impression after having read an article on Blazor and it's promises to appeal more to the C# developers who are not fond of the frontend. It seems to me the biggest appeal to Typescript has been the auto completion from the ecosytem inside IDE's like VS Code. However, I wonder how much of the same effect can be achieved by JsDoc or perhaps something similar in the future. I once saw a presentation emphasizing to never bet against Javascript, only time will tell if this is true or not. Just my personal opinions.
"However, on the frontend, it has been nearly a disaster. "
I agree, the absolute mess I have seen people make with typescript is almost unprecedented. Its power is part of the problem. Its inherently high SNR is another.
I think you are right that it's mostly front end developers because I don't think a lot of them have had to develop some of the formal disciplines other types of developers have (not a rule just a general observation as I remember sifting through pages of mostly unnecessary thousand line files)
It feels like it's not particularly well curated with regards to style choices but I feel that is becoming normal in programming.
More and more people with very little aesthetic understanding are getting into programming. It's just a numbers game. You throw more people in and the people with a relatively rare aesthetic understanding will become more and more marginalised and the majorities influence more pervasive.
It seems like a trend to often happily trade legibility for terseness. Simplicity for often unnecessary complexity.
I cannot wait for the trend to fall back to the other side because it is getting absurd.
I'm concurrently building a backed service in TypeScript and clientside in Svelte.
I didn't bother including TS in the clientside for the non-component files.
I find it extremely helpful, doubly so with RxJS (on the backend), where it has surprisingly good inference.
That is despite the fact that are bugs/rough edges in the typedefs though, for example when you use multicast as one of the adapters in pipe.
It obviously is a subset of JS, and that is partially the point.
You mention type inference (where you mention generics), but I must say it is actually very poor at the moment.
Oh wow, that's an
Array<never>? Good to know.With minimal effort and minimal extra code -you can use typescript to drastically improve readability and maintainability of your projects. Some of the problems you pointed out can be bypassed with a one-off any
Some comments may only be visible to logged-in visitors. Sign in to view all comments.