At my first few programming jobs I worked on Java projects. It is here that I first learned to appreciate, but also hate strict typing.
Fast-forward and Angular 2.0 dropped which was exclusively Typescript. A bold move at the time! I had heard about TS prior to that, but ignored it because it came out of Microsoft (Sorry MS! I really had no patience with anything MS back in those days, but things have since improved in Redmond).
Time went on and Typescript became popular. In fact, it's so popular that some people are simply using it because it seems "everyone uses it". I revisited Typescript (a couple times!) in hopes of being more mentally prepared for the Javaness and seeing past initial hurdles and finding its real value. I was underwhelmed. Here's why I'm not a fan:
Typescript begets Typescript
I know technologies can be misused, but I've seen a lot of Typescript written just to comply with the other Typescript that was written. You might be thinking, "Duh! That's the whole point!" and I know that, but what it means in practice is unless your custom types are truly something special (much of what I've seen are meaningless wrappers around the primitives), then those custom types beget more mostly meaningless Typescript code, which renders the exercise pointless.
Not the kind of issues I see
The issues I most often need to deal with can't be solved with Typescript:
- Network and environment-related issues
- API call failures
- AuthN, AuthZ stuff
- CSS not rendering the way I expected
- Events not behaving the way I expected
- Copy/pasted the wrong value, like
/foourl instead of
foostorage key instead of
- I goofed and used the wrong method, like
filter()when I should have
I would love to see some good data on non-Typescript projects and their percentage of production issues that would have been prevented with Typescript. Please share if you have a resource.
Also, my IDE is smart enough to do what Typescript enables in regards to intellisense, so there's no benefit there.
Strict is not good for the web
I remember one of my teams was investigating a production issue and eventually found the root cause was their custom type. Yes, a production issue caused by Typescript, not prevented by it.
Their code expected an object that came back from one of our APIs to have everything dictated by the type. Well, the API sent back the object without an optional property and the resulting code from Typescript crashed because heaven forbid the object didn't have all the properties Typescript thought it should have even though the object did have all the properties needed by the application.
I enjoy the benefits of not having Typescript
Other benefits you get are:
- less configuration (I've wasted hours doing this for Typescript)
- less false errors ("Sorry Typescript, but it is you who are wrong, not my code. Here, have another
@ts-ignoreand be quiet.")
- faster builds
- less compatibility issues when using 3rd-party stuff
- smaller payloads
So, is Typescript bad. No.
Is it a must-have that provides tons of value. No.
Should everyone Typescript because [current year]. No.
Should you use it? If you have found a genuine need, yes.
I did not realize religious wars were still a thing in front-end development. I thought the community grew out of that a few years ago and it seems most have. Many commenters have graciously shared constructive comments, like @flaviomh, who I learned something from. Some comments are in support of my reasons, and some disagreed with my reasons without implying I'm a moron. All of it is appreciated!
So, if you're gonna comment PLEASE contribute to the discussion in a constructive way. If I'm wrong about a point, avoid implying things and just articulate your constructive thoughts and it will be reciprocated by myself and others.
Been working in Rust lately. At least in the context of web endpoints, it is borderline comical to work with.
Spent an entire afternoon trying to compare two "strings". Yes, compare two strings! And that was with the help of several people who are familiar with the language. Try it yourself:
/// See https://docs.rs/warp/0.3.1/warp/filters/header/fn.exact.html .and(warp::header::exact_ignore_case("Authorization", secret_string)) // <-- Good luck converting your String to a &'static str
It's been two years since I wrote this. In that time I've spent more time with TS and I'm compelled to come back here to humbly acknowledge that I was...right. Right as hell too! TypeScript is 100% useless overhead that serves only one purpose: scratch an itch for neurotic developers.
Top comments (220)
With all due respect these points are silly. Ts allows you to use next generation js features and makes the cross compatible with with browsers that haven't caught up yet.
Typing is another layer on top. Albeit the main layer, and css rendered not the way you expect? Why even mention that in the context of ts?
That's like saying I don't use sass bc I like to write clean modern css. Anything you can do in js you can do in TS, that doesn't work the other way around.
How long did it take all browsers to get the class keyword after it was proposed? Let and const support? Why code like the 90's when you can learn next gen and only be as strict as you want.
It's not like you're forced to type everything.
Babel also "allows you to use next generation js features and makes the cross compatible with with browsers that haven't caught up yet." TS offers me nothing in this regard. But I don't user either.
Yes you're right, TS is another layer on top. I'm looking to remove layers that don't offer "game-changing value".
I mentioned CSS along with several other issues in the context of "Not the kind of issues I see", i.e. TS can't help me with these more common needs. I just don't find type-checking to be a big issue worth writing non-standard code and further complicating my pipeline for, but I am sure some projects do benefit from a little TS.
I stopped using SASS and LESS a couple years ago. 100% pure CSS source with PostCSS and CSS Optimize in my pipeline for a little magic. I will never ever use SASS or LESS again. They're awful and that's just not how I approach CSS anymore.
I don't know how long it took, but Babel came out in 2014, so that's like 20 years from the 90's.
I have to disagree with you here on Babel. Babel is an horrendous slow mess of a system that barely accomplishes the goal its set out to do while requiring you to install multiple packages for no good reason. For a recent project I wanted to compile my code to support Older browsers (which in this case is IE as its very difficult to find older versions of Firefox and Chrome), when I used Babel for some odd reason it kept placing a
require("regenarator...")in random parts of my code, which I couldn't get rid of, so, just as an experiment I switched to typescript turned off type checking and told it to polyfill for es5 and it worked, what's even worse is it was faster than Babel. BTW I use esbuild for compiling typescript to es6 js, and then use typescript for compiling the es6 js to a separate es5 legacy js file.
When it comes to Sass I just don't get the hate. Postcss is cool and all but the power of sass is just hard to ignore in my opinion, postcss is what I use for production builds for prefixing, minifying and purging unused css, but postcss tools just don't have the power and community support that sass has. I've been testing out tailwindcss recently (tailwind use postcss) I find that overall performance can be boosted by using your own custom solution for utility classes and then writing custom css for complex styles.
Oh we agree that Babel is slow and messy! It may not have been obvious, but I said don't use Babel. My point was to clarify that for 5+ years Babel has enabled use of "next generation js features" and makes your code compatible across browsers, so TS is not unique in that regard.
I used to like Less and SASS, but I have completely changed my approach to CSS and no longer use those. I do something I'm reluctantly calling the TAC methodology (I keep explaining it and people seem to like it so I'm gonna "formalize" it and do a little post about it).
Oh it seems I misunderstood, thanks. Also, I would like to here more about your new methodology, I'm currently looking for new methods to design sites quickly and efficiently, and thus far using sass enables both, and then using postcss optimizes for production, so, I'd like to here more on your methodology.
I hate to give you something unfinished and I'm not sure what your needs are, but if you can access this you're welcome to have a read dev.to/jfbrennan/the-custom-tag-at...
The idea is pretty simple:
BEM/OOCSS/SMACSS and utility-only approaches like Tailwind are not wrong, but their limits can be overcome with an approach that embraces and leverages web standards.
This methodology follows HTML's lead and uses Custom Elements in a progressive enhancement sort of way. Here's the basic approach:
1) Generic styles should be implemented as utility classes (Tailwind got this right). Depending on project size and type, you may have 20-30 or 150+ utility classes. For example:
2) Design tokens (color values, typefaces, sizes, etc.) should be implemented as CSS Custom Properties (no SASS/SCSS/LESS variables because we must embrace and leverage web standards and also we'll need JS access). Token examples:
3) UI components start life as custom HTML tags. The custom tag must be prefixed and have a short but meaningful name. For example, an alert component where we want to apply some basic styles based on the type of the alert message would NOT be implemented with classes and modifier classes or a bunch of random utility classes (oh Tailwind you dirty dog!). Instead we would do something like this (super basic styles for brevity):
ok-for the mandatory prefix (stole that from your username btw), but the prefix itself is arbitrary (there's more that needs to be said about that, but skipping for now). The component's name is
alertbecause that's its semantic name.
The component's variations - the type of alert message we're displaying - is also semantic so we give them good names too using an attribute NOT a class. To summarize: component => tag, component's variations => attributes. Reasons reasons reasons...fast-forward and let's compare where we're at:
<ok-alert>is a CSS-only component at this point just like the others.
4) Evolve to Custom Element when a component's features require it. For example, let's add a feature to alert where it disappears after 4 seconds:
Ah, no JS needed so no Custom Element yet, but now let's add the option for
autodismissto have a custom value, like
autodismiss="7", that dismisses after the given seconds and not the default 4. We would now evolve this component to a Custom Element:
Well at this point I'm just rewriting what I linked to above, so you can learn more there if you're interested!
I've also built a design system following this methodology. It's based on what I learned from using 3rd-party design systems and building a couple design systems at large companies. Here's the docs: m-docs.org. It's not perfect yet, but maybe 80% there.
Nice, I'll try that out some time 👍
I wonder why you stopped using SCSS? It does help a lot, as for me. Little story?
Used to use SCSS and LESS.
Today I don't build anything without a design system, which means my apps have so little custom CSS that there's just no need for a preprocessor. There's just a few lines of CSS here and there scoped inside their respective components.
As for the design system, the one I use (see github.com/jfbrennan/m-) follows a methodology called Tag Attributes then Classes or TAC. TAC structures things in such a way that there's just no real need for a preprocessor. Could I save a few lines of source code with SCSS? Probably, but it's hardly worth bringing in a dependency and writing non-standard code for. I do use PostCSS though. PostCSS means I can write vanilla CSS and still have things like vendor prefixes taken care of for me.
With all due respect, comments such as "Ts allows you to use next generation js features" ... as if the JS universe somehow prevents one from using any JS features ... is the sort of nonsense that exposes the indoctrination of the TS cult. This is why I can't take the TS cult seriously.
You're commenting on this like my ancient comment is still relevant. Things move super quick in the dev world. With the adoption of next generation js features this is less of a thing.
Could I ask which next gen features are available in TS that are not in JS. I am curious because babel and react offer the same things as far as I am away.
Article written and explained very well.
It reminds me of myself about 3 years ago, when I absolutely didn't want to take the Typescript road with React & Redux in my new business venture.
I kept repeating: "it's just a useless additional layer"
Fortunately (yes, I wrote just like that: fortunately) I was quite forced to use it, and we discovered by the time that it was the right choice.
I appreciate very much the way this article is written, because it is a common thought that we should always keep in mind:
Should everyone UseATechnology because [current year]. No.
Should you use it? If you have found a genuine need, yes.
"we discovered by the time that it was the right choice" in what ways?
I was a quite good JS developer when I firstly saw TS. In my head the first thought was: "No, another superset! I don't want it...finally it's just a helper, not a very language. I can work with plain JS the same".
The problem is that I just worked with small projects...then, about 4-5 years ago, I started to work hard on bigger projects, especially using React&Redux.
When we started with TS I was always keeping in my mind the same thought, but through the time I got a very good help (also with junior or low experience developers in my team) in writing code, for example on type-checking errors, very useful when you have to work with a structure like ours where we have hundred of middlewares, reducers and actions (Redux section) with different organized "types".
And yes, even if it is all writable in simple JS, and maybe I was able to write all in simple JS, I loved the way we cleared out the code, just defining different objects type shape.
But, of course, this is only my opinion ;-)
Ah, sounds like it helped with the Redux stuff. I can def see that.
Mainly yes, it helped a lot by Redux stuff and, of course, by React one, because we used Ract with TS.
But trust me, there is a great benefit also on all contexts where we didn't have React or Redux.
We built up an UtilityManager module, or a custom ConsoleLogger one, or a custom LocalStorage one: as I already said I was able to do all without TS, but just looking at those types on the UI now make me a good feeling from the point of view of clear code.
A suggestion: just try to use it in small-medium project on your own, not because "TS is the fashion", but for training. Look at TS site, because there are a lot of things that we don't use and they can be useful for you. After that, if you still think that TS will not be helpful for you, that's it :-)
I have used TS, which is how I got my opinion of it.
I generally don’t find strict typing in front-end development to be very relevant or valuable, I don’t like the hassle of writing non-standard code and needing a compiler setup (same reason I didn’t stick with CoffeeScript).
I’m sure there’s some projects that benefit and the code really is better, but from my experience that’s only a small amount of projects.
I really appreciate your references to CoffeeScript here. I think the community is quick to forget that this isn't the first time this has been attempted. Sadly it appears that TS is being too widely adopted to ignore (like I did with CoffeeScript). Won't stop me from agreeing with you. I would go one farther and argue that it was a mistake to bring the class keyword into ES6 too. Prototypes allow you to do class-like things in JS, but they allow you to get polymorphism and more out of patterns that you don't find in Java or C# books.
Sure a lot of what prototypes can do outside of faking classes has been explored, but it seems that as groupthink leads us to fall on tooling in the development world the creativity is slowly seeping out of the web. I think a clear symptom of this is the visual bootstrapping of websites over the last 10 years where every site now looks like the bootstrap starter site. When bootstrap came along, it was not exactly the norm to have these banded layouts with large type etc. It was a look that you saw on the web, but not all sites were designed this way. Today nearly every site is designed this way (even if it isn't using bootstrap). Similar to the design stagnation, I feel that development is largely in stagnation (especially around large projects in the corporate space).
?before the colon.
Thanks for pointing out the class keyword, etc, history too. TS does seem like the same thing; adding something to JS or on top of it which doesn’t add any new features but mainly a way to organize your code.
I agree with all Jordan has said, and would like to confirm that TS can make it hard to add jr and even mid devs from a mainly JS background to a project. Not great when all you want is some linting.
I’ve been coding for 20 years, and was very happy that web software and JS community seems to be heading toward readability and speed.
Colleagues and I have the opinion that the main misuse boils down to this: something like angular or react gets popular, an effort starts to make it look like C or Python. I feel like doing that misses the point of JS.
There’s also the impact of companies having a harder time hiring when adding that requirement.
Interesting, could I ask please what benefits you saw using over react "native" as it were?
You should drop Redux, The reason you found TS helpful is only an illusion because Redux really sucks.
Computer science, like any other scientific discipline, has only theories with varying degrees of supporting evidence. Sometimes the evidence is strong enough that we accept a theory as fact. Sometimes those facts are blown apart by new scientific discoveries and sometimes the facts remain while a new side of the same coin is revealed by other good theories.
Science is not and never should be dogmatic, bad things happen when that’s the case.
Am I claiming to have made a new discovery? No. But is strict typing a scientific fact? No. Not at all. That’s not even the right way to discuss these topics. Software engineering, unlike computer science, is not concerned with facts. It’s about applying tools and techniques and balancing their trade-offs. I’m sure you know this.
Here I’m merely expressing my opinion that I don’t like strict type systems, at least in the context of front-end development, because I don’t find the trade-offs to clearly favor strict types. For some projects, yes.
You weren't wrong.
Yeah I agree. There's value, but there's cost. I have not experienced TS in an environment where the tradeoffs favor TS in a big enough way, so I don't bother.
On the other hand validation the data I receive in a method call is another matter. Like really check if the property exists, if it is a string of Latin characters etc. -- but TS will not do that.
I think for newbies it is misleading that TS uses things as "string" or "array" and makes it look like it validates the data passed to functions from outside sources. TS Does not do that.
Reason for TypeScript's popularity: VS Code support (JetBrains Webstorm US$59.00 for the first year (individual use) is still too much of an impediment). Without VS Code I doubt very much that TypeScript would have a lot of traction outside of the Angular and MS Visual Studio ecosystems. It's not about static typing at all.
I like types.
I don't care for class-based object-orientation masquerading as a "type system."
My assessment of TypeScript on a high level:
Given the weak guarantees - poor return on investment.
A missed opportunity.
That said there is a sweet spot for TypeScript where the downsides can be mitigated - but
It's hinted at in this statement:
i.e. not TypeScript the compiler/programming language but TypeScript the static analysis tool (like Erlang's dialyzer and Elixir's dialyxir).
Preact has been using it for over a year in this capacity and other teams are following suit:
The downside is that currently not all of TypeScript's capabilities translate cleanly into JSDoc TS - some are plain awkward, while others might be impossible.
The other issue is that in my experience you have to be quite competent in TypeScript to make "JSDoc TS" work. There really is no "I want to learn just enough JSDoc TS" - you've got to go through TypeScript first. That means you'll likely have to successfully navigate the trap of "the TypeScript Developer Experience" in an IDE - which really is a more comfortable place to be in.
In a perfect world there wouldn't be TypeScript, JSDoc TS and TSDoc. There would just be TSDoc which can pull in types from
*.d.tsfiles - or generate them - (with everything TypeScript is capable of) for static analysis (and unconstrained by what JSDoc wants to do). But the simple truth is that version of TypeScript would have never been as popular as the one we have today (there is no correlation between popularity and quality).
My explanation is to give equal weight to my first word ("appreciate") as you've given my last word ("but also hate"). Contradictions are sometimes unavoidable. I understand and appreciate some cases for strict type enforcement, but I also find it to be fussy and annoying and of little value in a lot of cases. That's not an extreme opinion, so that doesn't need anymore explanation.
This guy dev.to/bytebodger/tossing-typescri... has a detailed example on this point if you want a better answer. I have seen some TS, wrote some TS, and read about TS code that amounts to nothing much at all. First and foremost is the use of
unknown. Third would be custom types that aren't much more than a wrapper on a primitive. They're like semantic types with no real purpose.
I don't recall the exact details of a bug one of my teams had about three years ago, but I do know the code they wrote was TypeScript and the types they put together were trying to be too correct and something unknown came along and caused their super strict code to fail. Had the code just trusted the API (the product's own API that they can trust) and carried on with what needed to be done without first trying to unnecessarily check every t was crossed and i dotted in the shape of the data, there would have been no bug.
Great comments. Don't worry about the religious typescript worshippers. Just another cargo cult. TS is great but not for all projects and people. And great products can be built with and without TS.
Electron, Cordova, bloated SPAs and ads - I don't like any of those either or the sloppy "hey it works" mentality behind them.
But not finding huge value in strict typing for front-end projects isn't relevant to hacked together apps. In fact, I've seen many bloated garbage projects doing all the right things, including using TS, which can in some cases add to the bloat. I'm of the opinion that removing pretty much all of it is best until something really really proves it needs to be there and no TS does not automatically need to be there.
A Large-Scale Study of Programming Languages and Code Quality in Github (2017):
What a lot of qualifiers bordering on establishing "plausible deniability". And intangible process factors tend to include things like:
And as Matthias Felleisen is fond of saying: No Soundness, no business.
So while TypeScript, C# and Java (et al.) are technically statically typed, they aren't sound and therefore fail to live up to the promise of static typing.
That’s pretty interesting, thanks.
Thanks for sharing. You are right, I am wrong. I will private message you for permission before expressing my opinions/annoyances next time.
Btw gRPC doesn’t work with browsers, so I’m not sure how you’re flat-out dismissing REST as “the worst possible choice to implement any API” and then bringing up gRPC as a solution. Find a gRPC service and then try to
fetchit. You cannot. It requires one of several currently non-ideal solutions to be put in place, one of those solutions is a simple JSON proxy.
Old post and may have been said already (I didn't read all 198 comments surprisingly). JS vs TS is not an argument really because so many in things in JS are hard to describe in TS like middleware. JS's ability to be untyped is the strength that gave rise to these patterns. When you attempt this in TS you get crazy madness like
<t extends z, any, any, any>really doesn't help the dev anymore in that case.
However fundamentally, pretty large complex apps have been built in JS before TS. So JS never blocked anyone. These apps worked because they were well "tested". At the end of the day if your aren't testing your code TS doesn't offer that much advantage. If you are then your tests will reveal the errors anyway!
Not to mention that any external interfaces are not "checked" by typescript. Validation is a big deal, to have to type cast my external interface to only then have to manually check the incoming data is pointless. This is where typescript fails over truly compiled languages. Dynamic typing should be used in interpreted languages and static typing should be used in compiled languages. Anything else is a trade off.
This is really coming down to how your IDE behaves more than whether JS vs TS is a thing. If your IDE experience is the problem then you can just JSDOC typescript comments and you get well documented code, IDE understanding of your types, autogen JS documentation and you can use raw JS all in one... Now that's appealing... Which is just to say it's JS with IDE typescript hints... Everything else was already JS.
I know, thank me later...
Yup yup and more yup!
JSDoc gives you the dev benefits with zero dependencies and build overhead and external data sources (which virtually every web app is fully dependent upon) means you better be writing runtime safe code because TS cannot and will not save you.
Could you explain the crash you had in more detail? I don't understand how that would happen. I didn't think Typescript did any type checking at run time, so I don't see how that happened.
I think his point is wrongly stated. As I understand the type assumption was wrong what means developers felt fake safety. It means that they believed type defines the data which will come. But of course such error will happen with/without typescript. You need to have some assumptions for the data you work with, TS just makes this assumption explicit and visible.
So the error was coused by wrong communication/assumption.
Thank you! it is so refreshing to read this! I've been coding front end for 10+ years and delivered dozens of projects for millions of users that have generated millions in revenue. Some of them still standing today. True innovation for me was html5 and web apis. Without those we could not do many of the things we do today. If you take out react, vue, angular, typescript, etc. as ugly as it sounds, we could have still built the same things with jQuery or vanillajs. These are all tools and helpers that make us work better in teams which makes sense, but have normalised the developer. I get "cancelled" every time I bring out this topic and fellow colleagues get all religious about it to the point in which this is actually affecting new job processes. Have any of you encountered this? how have you dealt with it? It is making me hate development lately and it sucks. I miss those times where developers could change the world and be creative, think outside of the box.
Ninja I gotta say I’m flattered that you’re keeping tabs on who I have and haven’t responded to
Some comments may only be visible to logged-in visitors. Sign in to view all comments.