DEV Community

loading...

The reasons I don't use Typescript

jfbrennan profile image Jordan Brennan Updated on ・5 min read

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.

In a short amount of time I was drawn to front-end work and became proficient in JavaScript and really fell in love with the language. It was relatively easy to master, which enabled me to focus more on the user and quality and to work much faster than with Java. When Node.js came out I was thrilled because if it proved itself in large-scale production environments, then I could use JavaScript across the stack.

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).
My first impression with Typescript was, "Wow, this feels less like an improved version of JavaScript and more like a weird version of Java."

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:

Non-standard

Maybe it's a phase, but I really have little interest anymore in the JavaScript fashion trends. I find it all to be too big, too fussy, too much in the way, and too non-revolutionary to justify the cost. If it can't be linked to and run natively in the browser I have a lot less interest. Typescript is no exception here and more than CoffeeScript ever did it's fragmenting open source.

On the other hand, I do want to learn new features of the web platform, including JavaScript. Efforts should be going here, not to fragmentation. I want to write real JavaScript, minify, and deploy. Anything that complicates that process - no matter how popular - has to demonstrate a net increase in value. Like, game-changing value.

And I don't think I'm alone here. JavaScript's fault-tolerant loosely-typed behavior is not a problem that needs solving, or it's not a big enough source of issues to justify writing non-standard, non-executable, pipeline-dependent source code. If Typescript features make their way into ECMAScript, I'll definitely use some of it once the runtimes have native support.

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

JavaScript does have types and strict type checking and I've found it's quite easy and sufficient to leverage them when I need to, but I don't often need to.

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 /foo url instead of /bar url, or foo storage key instead of bar key
  • I goofed and used the wrong method, like filter() when I should have map()ed
  • Algorithms

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.

Yes, of course you can throw more Typescript solutions at Typescript problems, and eventually pile on enough pseudo-code to make your JavaScript bullet-proof (we hope 🙏) or you can embrace the fault-tolerant nature of the web and wisely use JavaScript's strict type enforcement when actually necessary.

I enjoy the benefits of not having Typescript

Despite the herd mentality that forms around some technologies, Typescript is not 100% bliss. For example, can you share or copy some Typescript, paste, and execute? No. You only have that freedom with JavaScript. Can you debug your source code? No. What you see in dev tools is Chrome's best attempt at unraveling the mess and presenting you with something kind of close to source. You can debug JavaScript at any time, with any tool, and even if it's minified you can usually make sense of it pretty quickly (and the path back to unminified source is direct and results in real debuggable code).

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-ignore and 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.

UPDATE:

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!

Some commenters however, came in full of emotion and started right in with the accusations, criticisms, and condemnation. Someone implied I ought to stick to my "mom's blog". Another said my career is dead because I don't like TypeScript. Hey, I will take the bait and defend myself, but unsurprisingly none will actually articulate any of their criticisms of the points I make above. One commenter continues to insist their swift judgement of me "misinforming" readers about JavaScript's abilities is true - How much evidence do you need to see that yes, JavaScript does have many tools for the strict checking of types and the correctness of data and saying as much is not misinformation?

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.

UPDATE 2:

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
Enter fullscreen mode Exit fullscreen mode

Who is sadistic enough to want to move JavaScript in this direction?

Discussion (163)

Collapse
sharpninja profile image
The Sharp Ninja • Edited

It is here that I first learned to appreciate, but also hate strict typing.

Explain, please. I need to understand your hatred of strict typing.

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.

Explain, please. TypeScript is only strict about its own code. You can feed it or consume it with whatever you want.

JavaScript does have types and strict type checking

Yes, it has types, but definitely there's no strict type checking. There is no compiler to be strict, unless you want to say the JIT compiler, which doesn't do any strict type checking and will attempt all kinds of type casting gymnastics to run code that should never have been committed to source control.

Despite the herd mentality that forms around some technologies, Typescript is not 100% bliss. For example, can you share or copy some Typescript, paste, and execute?

VSCode with the Code Runner extension will do this. Visual Studio 2019 will do this. Deno will do this.

Edit: Debug Your Tests in TypeScript with Visual Studio Code.

No. You only have that freedom with JavaScript.

Wrong. See previous comment.

Can you debug your source code? No. What you see in dev tools is Chrome's best attempt at unraveling the mess and presenting you with something kind of close to source.

Wrong, the supplied .map file generated by TypeScript is fully understood and used by the Chrome debugger as well as the debugger in VS Code.

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.

This is not a typescript problem at all. This is a lack of documentation, or not following the documentation. If the service serves X, and you expect Y, that is not the problem of the languages involved, but a problem in communication between humans.

And blindly allowing invalid data because there's no validation is not a justification for using JavaScript, it is justification for finding a senior dev that understands that data hygeine is the most important "feature" of any application.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

In order:

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 any. Second, 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.

JavaScript does have strict type checking and many other tools for ensuring correctness (I've listed those in one of my comments below). Perhaps I should have said JavaScript provides an operator for strict type checking, but it's so common that I didn't bother to be explicit. As for the gymnastics, I am honestly blown away by the number of people who mock JavaScript for desperately trying to handle an imperfect line of code. For the hundredth time: What would all of you want the browser to do in these situations? Crash and BSOD your web app? Be the first critic who answers that question - I'm dying to know what your alternative is!

Well of course with the right tools and setup you can paste and execute TS. With the right tools and setup you can paste and execute C#, Java, Ruby, Rust, Python, Swift. The point is JavaScript, and not TypeScript, can be shared with anyone and everyone and run by any JS runtime with zero prerequisites. Freedom baby, yeah!

Yes, with the right tools and setup you can debug TS source code. Again, the point I was making is JavaScript, and not TypeScript, can be debugged without first doing work to make it so.

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.

Toning it down doesn't mean "blindly allowing invalid data" (the data wasn't even invalid in this case, their code just incorrectly assumed it was). Using the tools JavaScript provides for strict enforcement when needed and being wise enough to know when to back off since trying to type the world will eventually bite you, as it did this team, is how I like to build.

Collapse
peb7268 profile image
Paul Barrick

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.

Collapse
jfbrennan profile image
Jordan Brennan Author

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.

Collapse
sharpninja profile image
The Sharp Ninja

You still have explained why you hate type checking so much.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

Ninja I gotta say I’m flattered that you’re keeping tabs on who I have and haven’t responded to

Thread Thread
sharpninja profile image
The Sharp Ninja

It's about facts and accountability. Computer science is built on facts. When people gain a voice and dismiss facts without evidence then it must be challenged. So what facts are you bringing to the table to prove the things that are driving hate in you?

Thread Thread
jfbrennan profile image
Jordan Brennan Author

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.

Thread Thread
sharpninja profile image
The Sharp Ninja

According to Hanenberg, S., Kleinschmager, S., Robbes, R. et al. in An empirical study on the impact of static typing on software maintainability. (2014):

This paper describes an experiment that tests whether static type systems improve the maintainability of software systems, in terms of understanding undocumented code, fixing type errors, and fixing semantic errors. The results show rigorous empirical evidence that static types are indeed beneficial to these activities, except when fixing semantic errors.

Just took a few seconds on Google Scholar to find that. The evidence for static typing is very, very strong. All you've offered so far is an irrational dislike/hate based on something you haven't quantified. Front End code is not special. It is code, and should be treated the same as backend code with the same rigor and attention to detail.

Thread Thread
sharpninja profile image
The Sharp Ninja

I'm just going to leave this right here.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

Thanks for sharing. You are right, I am wrong. I will private message you for permission before expressing my opinions/annoyances next time.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

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 fetch it. 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.

Thread Thread
sharpninja profile image
The Sharp Ninja

gRPC-Web is the official package for browsers, and yes, Browsers cannot do everything that HTTP/2 requires, but browsers are not the only consumer of services. Your position seems to stem from the idea that the browser is the end-all, be-all of application development which is a very flawed position to take.

Thread Thread
sharpninja profile image
The Sharp Ninja

I have been thinking all day about how to respond to this comment. Yes, I fully understand your sarcasm. I want you to understand that my issue is not with you, my issue is with the mentality that it's ok to abuse resources that don't belong to you. When someone visits your website, our installs your app, you have a great responsibility to treat their device with care and respect. That means using safe coding techniques in code that is properly tested and that performs well without consuming large amounts of resources. Unfortunately, packaging a web page in Electron or Cordova is the opposite of all of these things. Single Page Apps that consume over a gig of RAM and constantly ping advertising trackers is the opposite of these things. Most sites exist for the purpose of making money for someone, and most consumers are OK with that, but they also deserve to be treated well while providing them a service. Using insufficiently tested or under-engineered solutions may get to the Minimally Viable Product sooner, but it shows an absolute disregard for the visitors you want to be monetizing on recurring basis. So how do you do this correctly? Well, you use the proven facts that are freely available on the Internet to learn about programming languages, not just syntax but how they work and why the successful ones do what they do. Just because phones and laptops are capable of running a dynamically typed scripting language at a tolerable speed today doesn't mean that monopolizing their system to run a single app is a very wise approach to designing software. Now, if you want to foot the bill to run a massive Python or Node containerized backend in the cloud, then you are only hurting your own wallet. But when you push code to other people's systems then your bad code hurts their wallet.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

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.

Thread Thread
peerreynders profile image
peerreynders

A Large-Scale Study of Programming Languages and Code Quality in Github (2017):

we report that language design does have a significant, but modest effect on software quality. Most notably, it does appear that disallowing type confusion is modestly better than allowing it, and among functional languages, static typing is also somewhat better than dynamic typing. We also find that functional languages are somewhat better than procedural languages. It is worth noting that these modest effects arising from language design are overwhelmingly dominated by the process factors such as project size, team size, and commit size. However, we caution the reader that even these modest effects might quite possibly be due to other, intangible process factors, for example, the preference of certain personality types for functional, static languages that disallow type confusion.

What a lot of qualifiers bordering on establishing "plausible deniability". And intangible process factors tend to include things like:

  • Code inspection is up to 20 times more efficient than testing.
  • A study of large programs found that every hour spent on inspections avoided an average of 33 hours of maintenance.

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.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

That’s pretty interesting, thanks.

Collapse
okikio profile image
Okiki

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.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

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).

Thread Thread
okikio profile image
Okiki

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.

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited

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:

.font-semibold {
  font-weight: 500;
}

.text-upper {
  text-tranform: uppercase;
}

.pad-all-sm {
  padding: var(--size-sm);
}
Enter fullscreen mode Exit fullscreen mode

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:

:root {
  --color-green: #somethinggreen;
  --color-orange: #somethingorange;
  --color-success: var(--color-green);
  --color-warn: var(--color-orange);

  --font-primary-family: 'Comic Sans';

  --size-xs: 2px;
  --size-sm: 6px;
  --size-md: 12px;
}
Enter fullscreen mode Exit fullscreen mode

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-alert {
  display: block;
  padding: var(--size-sm);
  color: white;
}

ok-alert[type=success] {
  background-color: var(--color-success);
}

ok-alert[type=warn] {
  background-color: var(--color-warn);
}
Enter fullscreen mode Exit fullscreen mode

I used 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 alert because 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:

BEM or similar
<div class="alert alert--success">Success!</div>

Tailwind
<div class="block p-4 text-white bg-green-600">Success!</div>

TAC
<ok-alert type="success">Success!</ok-alert>
Enter fullscreen mode Exit fullscreen mode

NOTE: <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:

ok-alert {
  transition: opacity 0ms 4s linear, height 0ms 4s linear; 
}

ok-alert[autodismiss] {
  opacity: 0;
  height: 0;
}
Enter fullscreen mode Exit fullscreen mode

Ah, no JS needed so no Custom Element yet, but now let's add the option for autodismiss to 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:

customElements.define('ok-alert', class extends HTMLElement {
  // Code 
  // Code
  // Code
})
Enter fullscreen mode Exit fullscreen mode

And voila! we have just introduced JavaScript-enabled abilities into an existing component without any breaking changes or shifting paradigms that would cause our devs to have to refactor their use of <ok-alert>.

This is where BEM and other reach their limitations. They are CSS only and introducing any JavaScript-enabled abilities to a component requires a dependency like React, Vue, jQuery, or something homegrown. Numerous reasons why that's a big problem that I'm skipping over. Also, they cannot use Custom Elements because those methodologies are class-based, whereas custom tags and attributes are intentionally used to prepare for this situation.

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.

Thread Thread
okikio profile image
Okiki

Nice, I'll try that out some time 👍

Collapse
flaviomh profile image
FlavioMH

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.

Collapse
jfbrennan profile image
Jordan Brennan Author

"we discovered by the time that it was the right choice" in what ways?

Collapse
flaviomh profile image
FlavioMH

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 ;-)

Thread Thread
jfbrennan profile image
Jordan Brennan Author

Ah, sounds like it helped with the Redux stuff. I can def see that.

Thread Thread
flaviomh profile image
FlavioMH

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 :-)

Thread Thread
jfbrennan profile image
Jordan Brennan Author

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.

Collapse
peerreynders profile image
peerreynders • Edited

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:

  1. Given the weak guarantees - poor return on investment.

    • I have to author code that isn't runnable in a modern browser like Chrome or Firefox without a build step - TypeScript is not ECMAScript.
    • Even though I have to compile code I don't get soundness (... talk about a false sense of security).
    • Given some type of extinction level event - like Microsoft deciding that TypeScript is a waste of their effort and Google deciding it's not worth picking up the slack, there's tons of marooned code that can only be maintained by editing output files (not happy times) - while ECMAScript marches on happily,
  2. A missed opportunity.

    • So I have to compile but I can't have soundness despite the fact that OCaml has been around since 1996 (and Haskell since 1990) which even served as the basis for F# at Microsoft Research since 2005 because ??? Right - partial typing of JavaScript - way to (not) commit (Types are like the Weather, Type Systems are like Weathermen).

That said there is a sweet spot for TypeScript where the downsides can be mitigated - but

  • it's not easy,
  • nor convenient,
  • nor likely to achieve mass adoption.

It's hinted at in this statement:

TypeScript is designed to be a JavaScript super linter, it uses type system to give your better editing experience, it has seamless interop with JavaScript, at the same time, it inherits all JavaScript gotchas.

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:

Moved some of my smaller libs to JSDoc TS; thoroughly recommend it. Among other things, the resulting code is generally smaller than transpiled code. Building, testing etc all become much less finicky. And .d.ts files are still generated from source code.

  • TypeScript is no longer on the critical path - just run it occasionally to ensure that the code makes sense from the type perspective.
  • If TypeScript goes defunct no big deal as the actual code is just plain ECMAScript.

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.ts files - 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).

Collapse
sqlrob profile image
Robert Myers

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.

Collapse
macsikora profile image
Maciej Sikora

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.

Collapse
jfbrennan profile image
Jordan Brennan Author

I don't remember the details - conditional, discriminate, idk - but the code at runtime was too strict. Custom types made it so. The result was a production bug that would not have occurred if some basic JS was used because the missing property in the response was never actually referenced further along in the execution path. Perhaps they weren't following best-practices or maybe they did everything right, my point was JavaScript and the rest of the web platform technologies are lenient and forgiving and imo that's a good thing.

Thread Thread
sharpninja profile image
The Sharp Ninja

It wouldn't have happened if the service had been integration tested prior to deployment.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

Ah, you’re right. We didn’t integ test

Thread Thread
macsikora profile image
Maciej Sikora

The thing is that TS does not create your code logic. TS types does not affect the runtime, don't generate code (outside enum), it only affects developers and in this situation I believe they felt fake safety. Therefore as I have stated it is not possible it was purely TS fault, the issue was they thought smth is different than it really was.

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited

It does in the form of polyfills and the like if you’re using things not yet supported by the browsers you’re targeting. But that’s not what happened.

They had built out a whole bunch of custom types because typing the world is better(?) and although one of these type’s had passed compilation the code at runtime was too strict. An object from the API was missing an optional property that their custom type expected and... production bug. The rest of the code path didn’t even need this property, but their code was wound up so “correct” that it couldn’t handle something outside their perfectly typed world.

Had they skipped TS and all the frivolous types and just went with a clean fetch, processed the data, and moved on, there would have been no bug.

Thread Thread
seveneye profile image
seveneye

"my point was JavaScript and the rest of the web platform technologies are lenient and forgiving and imo that's a good thing."

omg, it just spawns a lot of little spiders crawling underneath. If it's just you and the project, go ahead. but if its a team, i would'nt know which is required and optional. omg again.

Thread Thread
macsikora profile image
Maciej Sikora

Sorry Jordan. But what you are saying has no sense.

Thread Thread
sqlrob profile image
Robert Myers

The response to "there was a validation bug" should never be "therefore validation is bad"

You fix the validation and if necessary, fix the documentation that led to the incorrect validation. This was just incomplete definition or misinterpretation made manifest, not anything to do with Typescript or strict typing.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

Validation is not bad. That's why I wrote in my post that "JavaScript does have types and strict type checking and I've found it's quite easy and sufficient to leverage them when I need to."

What is bad is over-engineering in hopes of mastering the universe with stricter and stricter code. This is not conducive to the fault-tolerant nature of the web. Reality came along and didn't match this team's preconceived idea of how the world should look to the app and so the app crashed. TS did not help, in fact it was what led to the issue. I don't seem to be the only who has noticed this either.

jfbrennan profile image
Jordan Brennan Author • Edited

@seveneye Yeah, but TS can only exterminate some of those little spiders, so of course a "lenient and forgiving" web platform is a good thing, even if TS compiled. (Huh, "it compiled" twice in one day)

Unless you are suggesting the browser BSOD-ing your app would be better?

Thread Thread
seveneye profile image
seveneye

junior devs would have so much fun on maintaining large projects with so much leniency...

senior devs: the horror.

Collapse
stereoplegic profile image
Mike Bybee

My first impression with Typescript was, "Wow, this feels less like an improved version of JavaScript and more like a weird version of Java."

You weren't wrong.

Also:

  • TS is implemented to the detriment of junior JS devs still trying to learn the what and why of loosely, dynamically typed JS.
  • TS creates a false sense of security around "type safety" which becomes irrelevant as soon as you transpile (to loosely, dynamically typed JS) and run.
  • TS isn't nearly as beneficial to organization of complex projects as its proponents claim (and, in fact, is often detrimental).
Collapse
jfbrennan profile image
Jordan Brennan Author

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.

Collapse
jfbrennan profile image
Jordan Brennan Author

Based on my experience with projects that used JavaScript (web apps with various tech stacks and architectures, shared libraries, services, design systems) I never saw 1000s of bugs caused by type errors. Managing teams and keeping tabs on our quality I also never saw type errors being a significant issue in front-end projects. In fact, type errors have been so uncommon in my experience that it's one of a few reasons I don't find TS worth the effort.

Collapse
jonosellier profile image
jonosellier

I'm not entirely sure why you hate TypeScript so much as all JavaScript is valid TypeScript. I will admit some exceptions apply with common JavaScript like document.querySelector('a.link').style.color throwing an error but this is actually just JavaScript bullshitery that we have all gotten away with since querySelector does not actually return an HTMLElement, it returns an Element but most of the time, we can get away with this kind of jank. The correct way to assert that the element returned is an HTMLElement is simply using as HTMLElement. It's clear to the compiler, other developers, and yourself that you are not manipulating an SVGElement which will have different props.

Can you provide me some code you had to tell TypeScript it was wrong about? If it's a type issue, assert the intended type with as.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

I wouldn't say I hate TS, I'm just not a fan for the reasons I shared and other minor points. I do kind of hate Java though!

The last thing I remember telling TS it was wrong about was an object I added to window that contained some core data bootstrapped from the server. I like to avoid extra API calls on page load when it's possible to grab that same data cached server-side, bootstrap it, and then read that into my app when it initializes. TS was complaining and so I ts-ignore'd. Shortly after that I removed TS from the codebase and moved on with life. The only prod bug since has been a goofed up sorting algo, which of course TS would not have helped with.

Collapse
jonosellier profile image
jonosellier • Edited

Okay that's fair that TypeScript would throw an error, however. I am not saying that you were wrong to ts-ignore but that is never the right* way to do something. In TS, you can extend an object by doing the following:

interface Window {
  prop: any
} 
Enter fullscreen mode Exit fullscreen mode

EDIT:

  • Right as in the way TS intended, there is no objective right way to write something in general.
Thread Thread
jfbrennan profile image
Jordan Brennan Author

True enough, but that’s also an example of my “TypeScript begets TypeScript” complaint.

Thread Thread
jonosellier profile image
jonosellier

The whole point is type-safety which means you have to be explicit. That being said, I fully understand the frustration that you can't just drop in some TS while leaving other parts as just JS. Thanks for taking the time to explain your views, it's always interesting to hear why people make the choices they make, even if I do not fully agree with them (but I develop Angular for a living so I am well-acquainted with TS and have learned to love it).

Collapse
borobudur01 profile image
borobudur01

"I'm not entirely sure why you hate TypeScript so much as all JavaScript is valid TypeScript",.. "The correct way is"..., "Can you provide me some code you had to tell TypeScript it was wrong"...
You really can't see the point of this article.

Collapse
jonosellier profile image
jonosellier

Addressing "You really can't see the point of this article":

I definitely can, he chooses to not use TypeScript and made some examples that seemed like a simple fix based on what he said. I'd go on and explain the reason why tonnes of people choose it over JS but we already know them. Whether or not he chooses to fully embrace typescript is fine but it comes down to a personal choice and like/dislike. Every issue he mentioned can be easily solved with more TS (Which he does not want to write, because personal choice), eg:

The issue where an optional prop was not being passed to the application but the application thought it existed: The fix? Slap a ? on optional props and use ?. to access them with some fallback. In JS the outcome would be the same (assuming babel) except they wouldn't have relied on the type checking to do their dirty work and they might have caught it earlier. Or they might not have... But it's not fair to say TS caused this when the object was improperly defined.

Addressing "The correct way is..." snark

"This hammer is useless"
I make this in jest, relax
If you're unaware of how you can elegantly solve an issue (trivially too, IMO) then the language will feel janky.

Addressing "Can you provide me some code you had to tell TypeScript it was wrong"

Genuine curiosity. I was expecting a language bug or some edge case I would keep an eye out for as a developer. It's just as important to know what something can't do well as it is to know what it can do well.

Collapse
tlingit profile image
Tom Pittman

Having read the thread, I'd say the core problem appears to be bias, not actual Typescript shortcomings — especially since the bias is propped up by misinformation.

Building quality software is a team sport. One of the main things that makes software successful is a well functioning team.

Among other things, teams can help us recalibrate when we are off — consequently, if a teammate has a mindset that resists correction, it can drag down the whole culture of a team.

To be good at our jobs, it's not enough to be right; we have to behave right.

BTW, computer science is NOT like "any other scientific discipline". CS is about understanding and operating in an environment entirely created by mankind — which makes it very unlike biology, chemistry, geology, botany, etc.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

So if I understood you correctly then someone who doesn’t prefer to use TS is “misinformed”, unsuccessful, not a team player, “resists correction”, ruins the culture, and is misbehaving. I’m sorry, I’ll behave and use TS like a good boy I promise.

I don’t enjoy TS. I don’t find a huge amount of value in it, but I’m sure some projects benefit. This is not a “misinformed” opinion or bad behavior 😂

Collapse
tlingit profile image
Tom Pittman • Edited

No, you don't understand me correctly.

As has been discussed, your article misrepresents both Javascript and Typescript.

For example, Javascript does NOT have "strict type checking" as you wrote. And contrary to what you wrote, you CAN debug Typescript source code. And VS Code DOES let you share and copy, paste and execute Typescript. Etc.

That's not "a difference of opinion", Jordan, that is misinformation.

It's TOTALLY fine if you don't prefer Typescript, but it's less fine to misrepresent Typescript to others to support your bias.

Moreover the tone of your post (and comments) is condescending, sarcastic, and mocks people for not agreeing with you. That behavior is truly unhealthy to productive teams — not your opinion on Typescript.

For instance, you mock Typescript users for their "herd mentality" and accuse them of following "fashion trends" (your words).

It is demeaning to dismiss the research and results others put into the decision of using Typescript as if they just mindlessly followed the crowd, and you don't.

After all, Javascript itself is among the most popular languages in use today. It could be argued that "100% pure Javascript" devs are all following the crowd — but that's not true, is it?

The reality is there are real reasons for the technology stacks we choose. And in almost every case, real research and thought went into those decisions.

And more than once in the comments you've resorted to belittling people, like saying you will be sure to ask "The Sharp Ninja" for permission in private messages before posting further comments.

And telling me "I’ll behave and use TS like a good boy I promise."

None of that is necessary, Jordan — and it certainly doesn't make you somehow appear more right in your position.

Thanks for listening.

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited

I wrote a short opinion about TS.

Then, unlike most commenters, you didn't share your detracting or supporting thoughts or ideas, but instead you criticized, insulted, and condemned mine like the other two guys.

So I restated your condemnation and also couldn't help but laugh at how you accused me of "misbehaving" for not getting on the TS train.

You didn't like having your extreme take mirrored back at you so you further criticize, insult, and condemn. 🤯

As for JavaScript, do the following tools not provide a developer with the ability to ensure an extremely high level of correctness, including strict type checking, and all at runtime?

  • typeof (so again, JS does in fact have strict type checking for primitives, although somewhat flawed, hence the rest of this list)
  • instanceof
  • const
  • Object.freeze()
  • ===
  • hasOwnProperty
  • prototype.toString().call()
  • Array.isArray()
  • Number.isInteger()
  • Number.isNaN() or isNaN()
  • Object.is()

Those tools are ready to go when you need them and in my experience they have been sufficient.

And yes you are right, with the right setup you can debug, share, copy/paste, and execute TypeScript. With the right IDE and setup you can do anything. With the right setup. But not everyone has all of this ready to go with all the types they'll need for any random bit of TS they might come across and everything configured just so. For JavaScript there is none of that. Any JS can be shared with anyone and it's good to go, no batteries required. That's the point I was making and unless I've lost my mind that's true, is it not?

Thread Thread
tlingit profile image
Tom Pittman

Again, I'm 100% fine with you preferring Javascript over Typescript. All I have done was point out where your "opinion" was actually misinformation, and show where you're not treating others too well. Everything else is distortion. Cheers.

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited

How do you not see that you came along, rushed to judgement, threw out criticisms, and still haven’t actually explained anything but simply claimed that I am spreading misinformation. And then, ironically, accused me of being rude to those like you who came along with nothing more than shallow accusations of “Heresy!” and Jordan’s just an ignorant and reckless dev who should stick to creating his mommy’s blog? You’re defending that behavior while telling me it’s misbehaving to resist TS lol

Is this all an elaborate prank? Am I being punked rn?

Collapse
odedshr profile image
Oded Sharon

Like anything else, typescript can be misused. It would the equivalent to complain that microwaves are likely to explode and can get the same result as traditional cooking. Assuming you don't want to eat cold food for the rest of your life, microwaves can save you time when the quality of the meal isn't too-critical. Typescript done right can save you from type-errors. that's it; and that's should be time-saving enough to be valuable.

Collapse
jfbrennan profile image
Jordan Brennan Author

Understood. I just don’t find type errors to be common, definitely not common enough to justify the cost of TS. But some projects probably benefit a little, so I can see that. Some devs probably feel more comfortable knowing they’ve typed all the things like “real” languages.

Collapse
peb7268 profile image
Paul Barrick

Beautifully said

Collapse
mrwormhole profile image
Talha Altınel

This post == Me.
I love your opinions and just to let you know you are not alone.

Am i working on an enterprise frontend? No, good i will never use typescript. Am i working on an enterprise backend? No, good i will never use java.

Collapse
jfbrennan profile image
Jordan Brennan Author

Thanks, I’m glad you see them for what they are

Collapse
davidimoore profile image
David Moore

post === Me :)

Collapse
andreidascalu profile image
Andrei Dascalu

You say "fault tolerant" but I don't think it means what you think it means. JS is by no means fault tolerant. Fault tolerant means that a system continues to operate as intended in the face of faults (foreseen or unforeseen).
JS is not fault tolerant, it's great at ignoring potential faults and hiding their true source even while they manifest.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

Thank you for yet another condescending oh you’re just ignorant and misguided comment.

Maybe “fault tolerant” is the wrong way to describe it. Or maybe people are reading way too much into that and are just too literal. Or maybe I’m not the one who is misinformed but it’s actually all those who are so high on their horse they can’t see it themselves. Idk.

What I do know, because I can read and I’ve built an app or two is that the web platform, as I referred to it in my post, is in fact purposefully designed to be fault tolerant. HTTP will try it’s best to complete, will it not? HTML doesn’t blow up because someone missed a closing tag, does it? Will an unsupported CSS property cause an older browser to fail to calculate the rest of the rules? Does giving JavaScript null or undefined instead of false cause the runtime to throw? As weird as many think this is, does giving JavaScript '1' + 1 result in an error?
Ok, so yes JavaScript and the whole web platform are resilient and forgiving of things that a more strict and less fault-tolerant system would permit. The fault-tolerantishness of the web platform is a good thing.

Now, I hate having to state the obvious because I know the critics already know this and are just not willing to calm down and be reasonable for whatever reason, so here it is: of course we should not recklessly expect the web platform to fix all our lazy mistakes, but not using TS does not imply such carelessness. In fact, I would suggest those who use JS are writing more cautious and robust code because there’s no illusion of runtime safety. We know what needs to be checked and how to check it and we know when being too strict will potentially bite us. TS devs know all this too because they know what they’re writing is woefully insufficient.

Collapse
andreidascalu profile image
Andrei Dascalu

Language is important because if you insist on using words under your own definition then it's really no point in having a conversation.

But it's funny to describe that behaviour as fault tolerant. So you admit that's faulty but it's ok because the interpreter doesn't throw and error and continues to run by making a set of assumptions about intended use of data in a situation that's obviously nonsensical in a way that's inocuous enough in 50% of cases while in can cause rippled inconsistencies in others.
If you think that's ok, great.

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited

If not "fault-tolerant", then what words would you have used to describe the behavior of browsers when they encounter an imperfection in code, yet continue to function? I even double-checked the definition to make sure I wasn't nuts, and no surprise here that fault-tolerant is indeed applicable.

I think the hang up is that there's a spectrum of leniency across the web platform that's hard to capture in one or two words and so in comes a bunch of rushed assumptions that someone who acknowledges and even appreciates this leniency - me - is reckless and lazy and misguided and misinformed and all the other nonsense people have been dumping here.

Thread Thread
celkamada profile image
Cassandra Cruz

Unwanted behavior? I don't think anyone wants to see "Undefined is not a function" be the top error in their frontend logs.

If your code is imperfect, then you ideally want the disconnect between what you think should happen and what is actually happening to be surfaced as fast as possible. Static type checking at compile time is a good first step, and Typescript is popular because it is a good enough tool for that analysis. There are plenty of other alternatives (Google uses JSDoc on all JS code, which gets typechecked by the Closure Compiler), and plenty of other defenses (tests, runtime checking, error handling and logging, etc), but when you have revenue reliant on your code it should be as bulletproof as you can make it while still delivering value to users.

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited

Hey, I think you're talking about the other side of the same coin.

When an imperfection does find its way to prod - after you verified, after code review, after unit tests, after integration tests, after e2e tests, even after it compiled (there's that joke again!) - what would you prefer web platform technologies do? I'm blown away by so many commenters who drive by, roll down their window, and yell "Fault-tolerance sux!" and then speed off when asked why. I'm beginning to think there are some people in the world who believe Windows' Blue Screen of Death was an appropriate UX...

Thread Thread
celkamada profile image
Cassandra Cruz

Hey, I think you're talking about the other side of the same coin.

No, I don't think I am.

Silently continuing with a type error in your code is not "fault tolerance". At some point, you will either write manual type checks everywhere something is used, or write a type signature, or deal with unwanted behavior related to it.

7 of the top 10 errors in code are type errors (rollbar.com/blog/top-10-javascript...), and I would rather prevent those. Typescript lets me do that in an ergonomic way,, even if the type system is not robust enough to help me write a proof about my code.

what would you prefer web platform technologies do?

Throw an error, like almost every other language in existence. I would rather have a typo in a reference throw instead of having it silently resolve to undefined.

You seem to be conflating uncaught errors (The windows BSOD) with caught errors (all the other stuff in your Windows logs). I agree that uncaught errors usually lead to bad UX, but I also think it's disingenuous to conflate the two when we have robust tools for error handling available.

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited

The property of continuing to function - silently or not - with any kind of error in a system is fault tolerance. (I'm going to write another post about this because I think there's a lot to share on this topic alone...unless I'm being pranked by people who know exactly what I mean, idk anymore lol).

The article you linked to details the top 10 browser errors as captured by Rollbar. Is that not proof that browsers errors are actually not silent? Also, that article says several of those 10 errors are really the same error, just reported differently by browsers. And none of those 10 can be completely avoided with TS, many cases would still require a runtime check.

I don't mean to conflate the two, I don't know the details behind BSOD other than if something went wrong in a program Windows would just completely give up and die. My point is that after I have written the necessary runtime checks (which are still required even with TS) and test coverage, I am glad I can trust the browser to not completely blow up in the hands of my users if an error slips through (that's any kind of error btw: JS, CSS, HTML). This is a good thing for users and browsers should continue to behave this way even if it's theoretically incorrect according to some strict principles of computer science.

And thanks for the comment btw

Collapse
nssimeonov profile image
Templar++

Keep coding cowboy style, build a bigger system and enjoy the "fun" you will have trying to find problems, that TypeScript could easily told you months ago. But hey, who am I to tell you what to do. Go ahead hit your head into the wall, and come back 15 years later (when you get my age and experience) to tell us your story.

Collapse
jfbrennan profile image
Jordan Brennan Author

Yeehaw! But seriously I'm not sure how many times it has to be said: TS for some projects has value. And it definitely makes some developers more comfortable and productive (seems to be a lot of devs who come from C# or similar backgrounds).

And the last 100 times I've hit my head on the wall was not due to a failure to statically type check my code, it's usually one of those other issues I listed in my post.

Collapse
nssimeonov profile image
Templar++

Maybe you will take a look at this article from an infinitely smarter person than me: bytes.grubhub.com/optimizing-for-t...

To quote: TypeScript carried us through it all, and remains an integral part of our application. I’m continually impressed by how much it aids in understanding and refactoring code... Not only is this easier for humans to understand, but static analysis tools, such as the TS typechecker, linter, and IDEs offer better insights to offer on our codebase

Thread Thread
jfbrennan profile image
Jordan Brennan Author

Good article. I can see why TS would be helpful in an Angular-to-Preact migration. Really cool to see they chose Preact, they wouldn't have achieved the same perf gains had they gone React!

Thread Thread
nssimeonov profile image
Templar++

The reason to choose Preact (initially) was to incrementally move away from Angular. Going for React would mean a complete re-do of the entire website and trust me - it's not a one-week job (nor a one-month job)

Collapse
bcowley1220 profile image
Brendan Cowley

"Strict is not good for the web."

Thanks for the article. Maybe one-day people will stop fussing at each other and finally admit that the majority of this is preference. Apparently the type zealots are already in full force, I might as well say that most of us don't have the problems either in volume or complexity that the giant companies do...Because really at the end of the day, most of us are just making crud apps when you really boil it down.

One of the more poignant things I'll say on this is the fact that no developer is the same. Chastising and belittling others because they don't have your preferred method of development is childish and disgusting. That mentality is how you kill the passion and drive for development in others. "I don't give a shit if your brain works in a more functional fashion... You're going to write typescript because I say it's better."

Collapse
jfbrennan profile image
Jordan Brennan Author

Yeah the dogma gets old quick, especially with the unwillingness to acknowledge there’s more than “mom’s blog” that thrives without TS

Collapse
bcowley1220 profile image
Brendan Cowley

I might as well throw a grenade in the mix since people already have seen completely lost their shit. a lot of the need for tight script would evaporate if companies would actually implement SOPs and well-rounded quality managers that are just focusing on managing teams. I come from 20 years and culinary before Dev, and I can confidently tell you Dev and tech in general have more leadership issues than I've ever experienced in culinary.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

Ouch. That’s saying a lot because the managers in restaurants I worked for were straight animals haha! You must have worked at a French restaurant!

Collapse
bbbryan14 profile image
bryan

I dig the article. I'm also very much on the fence on TS. I have done large projects with and without.

My biggest qualms:

  1. false sense of type protection - you still need to write run time checks because it's really plain JS at the end of day
  2. type assertion != type casting, people need to stop saying type assertion, because TS does not have any run time support
  3. people like to use class when they should use interface/type instead -> see this less and less often though
  4. working with React could get annoying, especially with React.FC . I've been bitten by a bug mentioned in that article before.
  5. useless when libraries don't have index.d -> DefinitelyTyped is great but I've ran into libraries without (looking at you Box, you are a paid service and want open source community to maintain your types? COME ON!!!)
  6. more linting rules to follow
  7. for a properly build a project, you need other tools in the JS ecosystem. tsc only transpiles, but if you want to copy assets over to have a pristine build directory, you will need other things -> not much of an issue on backend, but front end more config unless you're using CRA

Biggest benefit I've seen:

  1. amazing with redux, benefit grows exponentially when your application state keeps on growing
  2. refactor is easier
  3. great to be able to type props in React, makes components clearer (instead of using runtime PropTypes)
  4. brings import/export syntax to Node -> now it's not much a benefit but 2 years ago this was huge.

So yeah, I'm on the fence and I go with the flow. If it's greenfield, I'd have a weak preference against it on the frontend. With that said, server code is hard to imagine without TS now.

Collapse
jfbrennan profile image
Jordan Brennan Author

Every developer needs type safety? That depends if every project needs type safety? Some projects do need it, others benefit a little from it, and some don't benefit at all.

Collapse
isaachagoel profile image
Isaac Hagoel

Lol. I saw the title of this post and I thought "here is a guy looking for trouble". Typescript is a religion at this point in time, which makes you my friend, a heretic.

Collapse
jfbrennan profile image
Jordan Brennan Author

Ha! I am a little surprised by the reaction tbh. I figured this religious war was long ago abandoned and we could all now freely share our various beliefs without fear of condemnation and accusations of witchcraft. I’m not even a denier of TS either, I just find it less interesting and less valuable than other tenets of the faith.

Collapse
isaachagoel profile image
Isaac Hagoel

I think the key insight, at least for me, was that although typescript is being marketed as a superset of javascript (which technically is true), the space of typescript programs is a subset of the space of javascript programs and that's a much more important relationship between the two.

In other words, typescript is less flexible than javascript. This is by design (not a criticism), because it wants to prevent potential type errors.

Many devs in many situations don't need the extra power javascript provides for the type of applications they write (mostly semi-dynamic forms, let's face it) and can benefit from having (a pretty limited - let's face it) type checking for their code.
Like any other tool, it all boils down to tradeoffs and context.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

tradeoffs and context

Collapse
jessekphillips profile image
Jesse Phillips • Edited

I'm mostly said not only with the post but its replies. Some context for my comment first.

  • Not a frontend developer
  • QA for frontend and backend
  • Huge type system fan, never want to code without it
  • very limited experience in both Typescript and Javascript

My response is too long, so I created an article for a part of it.

I think the anecdote is similar to the expecting optional data issue you had. However, based on comments made I think you have misplaced the involvement of Typescript in this issue.

If Typescript is purely static analysis, then it is not inserting runtime type guards, things you do find in static typed languages when casts are involved. Instead you found developers who coded to expect an optional parameter. This is not specific to Typescript or static typing. Though Typescript may have involvement due to that "soundness" fallacy others mention. Programmers coming out of a dynamic world could reasonably expect guarantees from types which aren't there (null is still a huge pain in many static typed language).

While I'm very happy with what I've seen of Typescript, I would suggest keeping a eye out for where you actually hit type errors, I don't just mean in production. Did it happen while debugging? During code review? Were you working with string data? Was it a misuse of == or === was it from + on strings instead of numbers. Was it just that voice which says "always use ===".

I'm not saying Typescript solves all the type errors you will see. But if you start actually looking for all that mental training you put yourself through to correctly avoid type errors, I think you'll find that it might not be worth putting others through it. Then again, you can't really appreciate type errors until you hit them frequently enough that you appreciate not thinking about it.

Collapse
swizzard profile image
sam

it seems like a lot of people dislike "static types" because they've only experienced bad static typing systems. having learned haskell before getting into ts, i'm constantly frustrated by how both more verbose and less expressive ts's type system is. idk who thought the problem with js is that it's not enough like c++, but i'd like to have a word with them.

the other, bigger problem is that the entire type system is built on a foundation of dynamically-typed sand--coffeescript had the same issue, as has and will every other "superset"-type compiles-to-js language. elm-/purescript-/rescript-style constrained interop feels like more of a hassle, but if you're gonna do static typing, you might as well go all the way, otherwise you're just typing to help your ide.

Collapse
jackmellis profile image
Jack

By far the biggest plus of typescript is intellisense and editor hints. I cant fathom how I ever used to write code, constantly having to switch files to check what parameters I need to pass where. I resisted typescript/flow for the longest time but now I work 10x faster because of it.
Also it kinda sounds like your beef is actually just with any sort of build process...

Collapse
jfbrennan profile image
Jordan Brennan Author

Good point, I’ve found my IDE gets me pretty much all the intellisense I could ask for even for non-TS files. You’re right that I really don’t like the addition build process!

Collapse
pawelperek profile image
Pawel

What do you mean with this update 2? You can't replace String with &'static str, because &'static str is encoded somewhere in program memory, and String is on the heap. You can't just overwrite the assembly code at runtime. This isn't the issue of the static types, but low levelness of Rust. I can assure you that you won't encounter such a problems with higher level static typed languages such as Kotlin or Swift and definitely JS and TS aren't going in this direction.

Collapse
pawelperek profile image
Pawel

I wouldn't even call it an "issue", it's just a language design. Rust gives an low-level language performance with high-level language "feel" and safety, but you have to know at least basics of the language, because otherwise it's very easy to shoot oneself in the foot.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

Right, not an actual issue, definitely by design and that is my point. The system I'm working on produces the value I need as a String and warp's expect function requires a &'static str. The use case was so incredibly basic (compared two strings), yet I'm genuinely trapped by the language. Wasted hours on this and we ultimately had to scrap the clean one-liner that warp offered and hack in 10 lines of code to work around the inflexibility. Some of my experiences with TypeScript have been just as annoying and wasteful and for no value. If I want stringent rules applied, I prefer to explicitly ask for them as needed.

Thread Thread
pawelperek profile image
Pawel

I do agree that they are kind of the similar in the way that they are both caused by inflexibility, but comparing those 2 is unfair. You have to follow a few rules in Rust that you wouldn't do in any other language, but in exchange you get powerful static analysis of the program performed by the compiler that can give you 10x speedup compared to the same code written in JS. It is supposed to be a successor of C, so sometimes you have a shenanigans like this in your codebase. It isn't worthless TS unsound type checking, that might be even wrong in runtime, sacrificing the beauty of JS simplicity along the way.

However that seems very weird to me that in warp library they got &'static str types. To me it looks like they want to know exactly the value of the string at the compile time, especially that String would allow you to use both static and dynamic strings. I don't have as much experience in Rust as I do in JS/TS and I never used warp but it seems that it's either you are misusing this function or library creator make a mistake

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited

From the docs docs.rs/warp/0.3.1/warp/filters/he...

pub fn exact(
    name: &'static str, 
    value: &'static str
) -> impl Filter<Extract = (), Error = Rejection> + Copy
Enter fullscreen mode Exit fullscreen mode

I think it was a bad choice. Too limiting for a use case that won't always be able to meet this level of strictness.

Collapse
coreybutler profile image
Corey Butler

I see the same kinds of issues you see. I spend my time building solutions to those types of problems. I figured I'd share a few of those.

AuthN tends to differ from project to project, but AuthZ felt repetitive. I created github.com/coreybutler/iam to deal with it. It's AuthN-agnostic and serves as an AuthZ query engine of sorts.

Not sure which type of events you're referring to, but I tend to deal with alot of event oriented architectures. I created a library based on an event emitter (github.com/ngnjs/ngn). There are Codepen examples linked at the end. The most relevant is codepen.io/coreybutler/pen/ExKwdmY. There's actually a networking library in this suite that gracefully handles alot of API errors (and prevents many from happening in the first place). The lib has a few thousand unit tests and runs in our client's production environments.

I'm working on networking/environment management tools too, but they're commercial.

As for TS, it has its place for some people/teams. I'm not one of them, but I can see how it would benefit some folks. As a non-TS user, I still appreciate the role it plays in moving the web forward. When a rare concensus is reached about a language detail, it's a decent indicator there would be public support of an ECMAScript proposal for such a feature... kind if like partisan politics coming together on a bill.

Anyhow, thanks for sharing your experience.

Collapse
nibtime profile image
nibtime • Edited

I think whether TypeScript is useful or not is very much dependent on the style of programming.

I have sort of a typeful fp-ish style of programming, where I think about the shapes of data that would make up a solution and encode that in a type model. I really have no clue what I'm actually doing most of the time, so I need some directions at least. Then I see what possibly could be done with those shapes and start building and composing functions around it and try to make it interactive with React. I continue this cycle until I think I am done.

Type checks are really valuable to me if they tell me that I am doing something wrong in terms of a requirement/solution to a specific problem (make illegal state unrepresentable). I care about this aid and good dev experience, not about rigid type-safety with strict enforcement at runtime. That's my reason for using TypeScript. I am just making web apps, not missile guidance systems (if you do, TypeScript and JavaScript are probably not the best options - but I bet that somebody somewhere even used JavaScript for that :-))

If I hadn't this particular way of programming and would just randomly annotate JavaScript with TypeScript types and it felt like a chore: I would probably think that TypeScript is utterly pointless. But it accommodates my style quite well, so I enjoy using TypeScript.

If somebody doesn't like it and doesn't find it useful I am sure that there are good reasons for that. I can see that almost every argument against using TypeScript in this article and the comments is valid in some way and so are the arguments for using TypeScript.

I think people are just very different and have unique ways of making sense of the world and that reflects in preferences of technology and especially programming languages. That's ultimately probably the reason why there is almost (I've never actually seen one, I just optimistically assume there has to be at least one) no respectful conversation about programming languages on the entire internet. There's always this "Why is that idiot unable to see that XY, what I use, is better" between the lines - surely augmented with technical details and a paper reference drop here and there. And sometimes, when somebody really means business about demonstrating his intellectual superiority, it's just a downright insult. I wonder if there has been a single time where somebody actually went: "oh my god, what an idiot I have been all these years, thank you for the enlightenment" and then changed his opinion. It's just so pointless :-).

I wish everybody would think about programming languages more like cuisines. There can be many good ones side by side without the necessity that all others suck.

Collapse
aminnairi profile image
Amin • Edited

In the end, I've seen typescript used by people more as an intellisense tool than a real added value for catching bugs earlier.

Those bugs are mainly type errors because on large projects this can be very hard to catch.

I do not think that typescript is a solution but more a patch or at best a temporary solution because the real problem is that people that write javascript are too lazy to do type checking at runtime because ain't nobody got time for that apparently.

Write your library in typescript publish it to npm and you'll still have some people that are using vim with no intellisense and just node. For me this makes no sense other than catching up with the large javascript user base.

A real added value from typescript would have been to add those infamous runtime type checking for us at least for scalar types. This would have been the killer feature and I would have used typescript all the way but in the end, typescript is just javascript with types. So this is still javascript with its many problems and people are even less willing to do runtime type checking than before because they are biased by this wonderful type system don't get me wrong this is very well done probably one if the best of you ask me.

What I'm trying to say here is that either typescript has not been strict enough like preventing the use of javascript and forcing people to use typescript only (and not using node modules written in cjs with ugly typedefs patch) or typescript has not matured enough to see the real problem and should add type guard at runtime.

#unpopularopinion #sueme

Collapse
jfbrennan profile image
Jordan Brennan Author

Can’t argue with that. I really like your point about why TS doesn’t at least produce runtime checks for “free”

Collapse
yohanchoidev profile image
YC John

Poor you. But your article was somehow controversial. The topic was a kind of religion between programmers. For FP programmers, typescript may be another obstacle although some people love type with fp. But one thing I'm sure is that every approach has its own cost, therefore good engineer should be discreet on choosing their tools.

Collapse
jfbrennan profile image
Jordan Brennan Author

It’s my cross to bear 😂

Collapse
jfbrennan profile image
Jordan Brennan Author

I'm pretty sure there's more than 1 reason people hold back from adopting TS. For example, you're commenting on a post where I listed five reasons. Other reasons might include time, resources, priorities, team readiness, open source considerations, lack of interest, cooler technologies to adopt, they use Flow or JSDoc, and more.

Collapse
exabyt3 profile image
Nabeel Parkar

All valid points. I can see why you are against using Typescript. But I feel that even with these issues, Typescript gives more than it takes. Not having to go through docs to find out what a method does and having the IDE tell me is something that Javascript on its own doesn't give most of the time.

But still thank you for this post. I'll keep using TS but you've highlighted a few things and it'll make me more vigilant when writing my next program. Who knows... Maybe some day I'll come back to JS

Collapse
jfbrennan profile image
Jordan Brennan Author

Yeah the convenience in the IDE can be a benefit for sure. I think a good way to summarize someone’s choice is just as you said: “Gives more than it takes” or “Takes more than it gives”. It can go either way depending on a lot of factors.

Collapse
exabyt3 profile image
Nabeel Parkar

I think it all depends on your past experience. I believe IDE choice, language choice and tooling choice among others are subjective. I try to remember that when reading something I may not completely agree with.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

The IDE reason is less beneficial for me because WebStorm is really good even without TS. The other thing for me is when I can choose my stack I go vanilla as much as possible with only those dependencies I need. So, not to say I’ve mastered anything, but I do usually have very familiar APIs at my fingertips. I like the simple stuff that you can actually commit to memory or leverages the standards you already know (one reason why I like Vue and Riot so much).

Collapse
anthonyjoeseph profile image
Anthony G • Edited

I really like this article! I think it's clearly written and I love the focus on feelings and lived experience.

I'm not sure I have much to say that hasn't already been said, but I do want to try my hand at defending TS here. My angle is this - I don't think of TS as the latest fad, I think of it as the latest culmination of about a century of research into the lambda calculus (which predates Turing), the ML/Hindley-Milner family of type systems, Category Theory and Informatics.

The tldr is that types allow you to prove important and surprising things with mathematical certainty. The Elm language promises zero runtime exceptions. There's an operating system that has been mathematically proven to be secure. In fact with the calculus of constructions you can even certify mathematical proofs (which is, to me, completely magical) - here's a paper documenting a proof of the four-color theorem using Coq.

I (dubiously) claim that Typescript is so significant b/c it brings this research to the mainstream. It may not have dependent types, or native higher-kinded types (though you can still use HKTs), but it is a powerful type system. It's even influenced the design of Scala 3. The exciting thing, though, is its tremendous adoption rate - npm claims 50%.

I'm sure you're aware of the commonly stated benefits - referential transparency, fewer/no runtime errors, self-documentation, self-testing, consistency, etc. Those are some practical reasons to learn it, but I recommend it because, as Phil Wadler says, the lambda calculus is multiversal. If nothing else, TS is beautiful!

Collapse
jfbrennan profile image
Jordan Brennan Author

I wouldn’t call my list of reasons feelings, more like first and second-hand observations.

Thanks for the good comment, lots of interesting details

Collapse
buildmotion profile image
Matt Vaughn

Good luck with your Typeless applications and career. I've seen enough chaos Object literals to last a lifetime. I've seen your lack of use and appreciation for design patterns - which by the way have been around longer than we've been programming.

My best suggestion to you and any others who are Typeless...is stay at your current job forever and maintain that irreplaceable beast you call software so that us other devs don't have to come in later to fix it.

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited

Questioning people's careers because they aren't excited about TypeScript. That's a new one.

Design patterns are great, so how on earth did you conclude he doesn't like TS, so he must also not follow design patterns?

This is turning into a comedy!
🍿

Collapse
valeriavg profile image
Valeria • Edited

I can absolutely relate to how you feel about TypeScript. I had the absolute same opinion about it just about half a year ago. After all who in the sane mind would agree to extra boilerplate that doesn't even do anything in the runtime?! Oh and let's not forget that in nodejs it adds totally unnecessary compilation step.
But when I actually gave TypeScript a chance I learned to value this tool a lot.

First of all, it's really easy to navigate in large codebase with it. You always know what arguments functions have, what they return and therefore can rely on autocomplete, which speeds development significantly.

The second feature is that TypeScript can be used as a standalone bundler. Take a look at fuse-box for instance, which is based on TS compiler. It's rough on the edges but it does bundle things super fast because it does not need to traverse AST several times.

With that said, TypeScript is just a tool to ease the development, if it doesn't work for you, you don't need to use it. But do give it a real chance: set noImplicitAny: false and give it a try on a pet project. It actually guesses a lot of types on its own nowadays, so there's not much boilerplate.

Cheers!

Forem Open with the Forem app