DEV Community

Jordan Brennan
Jordan Brennan

Posted on • Updated on

The reasons I don't use Typescript

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 (204)

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
okikio profile image
Okiki Ojo

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 Ojo

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 on

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 Ojo

Nice, I'll try that out some time 👍

Collapse
vovchisko profile image
Vladimir Ishenko

I wonder why you stopped using SCSS? It does help a lot, as for me. Little story?

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited on

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.

Collapse
Sloan, the sloth mascot
Comment deleted
Collapse
hutber profile image
Jamie Hutber

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.

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.

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.

Thread Thread
gibbitz profile image
Paul Fox

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

I have to commend you here for posting the web-component standards compliant TAC approach. It seems only borderline relevant, but I think it does a great service to pointing at what the real problems are in front end development that go outside of Javascript not being the language that people wish it was. I think it also points at testability as a problem in the frontend space. It's easy enough to unit test JS/TS as a single executable program in a single platform, but when you mix in the markup and styling you quickly fall into visual testing which is largely traceable. If half the effort put into typescript would go into detecting the causes of box model layout issues our lives would be much more improved than catching when I forgot that a member of an interface needed to be optional or I missed typing the ? before the colon.

Collapse
louiszen profile image
Louiszen

You should drop Redux, The reason you found TS helpful is only an illusion because Redux really sucks.

Collapse
hutber profile image
Jamie Hutber

Interesting, could I ask please what benefits you saw using over react "native" as it were?

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
peerreynders profile image
peerreynders • Edited on

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
jfbrennan profile image
Jordan Brennan Author • Edited on

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.

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.

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
jce profile image
Juan

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.

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
Pragmatic Maciej

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.

Collapse
hseritt profile image
Harlin Seritt • Edited on

I liked what you wrote. You don't have to defend any of it. Your points are all valid. There are some jackasses here who have solid positions they cannot give up or being too attached to them keeps them from allowing others to speak their beliefs. I personally like Typescript (to a point) but I also realize it doesn't really do anything for your "compiled" Javascript since js doesn't have any type checking at all anyways.

Collapse
hutber profile image
Jamie Hutber

I agree with almost every single thing you've written here. Having used TS now for 3 years in every professional job, because without TS you cannot find work.
I've come to the conclusion it is, so far on the projects I've used it in, a complete waste of time and has offered no safety or only been there to frustrate.

I look forward to when TS dies away like Coffee Script did!!

Collapse
kpkeerthi profile image
Keerthi • Edited on

I prefer to use pure JavaScript. But the IDEs are pretty dumb without types and there are amateur programmers in the team who could mess up the code pretty bad. Typescript offers reasonable help here.

I wish JavaScript did what Python did - break the compatibility and eliminate all the ugly parts. Life would have been much better.

Collapse
ashheskes profile image
Ash Heskes

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

Collapse
jfbrennan profile image
Jordan Brennan Author

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.

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

Collapse
_mikeusa profile image
Mike • Edited on

This post invited a multitude of opinions. As someone that originally learned programming with C and has been using Perl/JavaScript/Ruby for the past 15 years, when I saw TypeScript I thought why?

Years later, I still think "why?" I understand the error argument, but the mistakes it tries to prevent are mistakes I never make. Most of my mistakes are handled by tests, the others are exactly as you said soft errors.

Someone made a comment about how it improved their editor functionality. Suddenly, I had flashbacks to Emacs vs VIM. Those editors have lots of functionality. Part of the reason I left Emacs was because I found lighter-weight editors like SublimeText or Notepad weren't bogged down by so much functionality that if I used someone else's computer to help them, I wasn't handicapped.

This biggest argument that I didn't see you make was readability. TypeScript is becoming more popular; when browsing repos, many projects have efforts to slowly convert their code to TS. I'm sure they have their reasons, but I scanned their code and I thought it was a regression. Yes there are types, but there's also double the text. It wasn't as readable as elegantly sparse JavaScript.

Furthermore -- again, I'm not absolutely opposed to TS -- it seems to have shifted away from the essence of what a scripting language is. TypeScript seems to be turning a scripting language into a programming language, which is yet another religious argument, but it does. TypeScript seems more C/Java like. The fact it needs to be transpired before the JavaScript is interpreted even feels like a compilation step.

Anyhow, I'm sure I will eventually adopt TS at least for some projects because I'm a nerd/geek/dork that loves new things, but I don't know if I'll ever completely endorse it. The reason why I liked Node.js to begin with was for its isomorphic capability. I liked my development team having one main language they could specialize in to use in the front-end and back-end with the ability of reusing some code in both, like for form validations. Unlike JSX, adding a language like CoffeeScript or TypeScript on top of JavaScript recreates the challenge of knowing multiple languages, albeit a sub/superset, to accomplish one task. The ROI just isn't there on my sheet.

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 on

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 on

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
daemonburrito profile image
Scott M Drake

You're not wrong, IMHO. Sometimes I do wonder if I am just too old (or the youngest cohort too young) to know that dynamically typed, interpreted languages were an accomplishment in CS. Yes, TS fans wish to add legacy features to JS.

And, of course, you are correct that vanilla JS has types (almost goes without saying.)

This is another "get off my lawn" statement, but I would guess that few here remember the failed attempt at ECMAScript 4; your gut feeling of a "weird Java" is due to the reintroduction of features that killed that specification, that a very famous Microsoft language designer, who I shall not name, described like this: "Javascript is missing classes and interfaces." The end game of TS, I imagine, is to make it no longer a "superset" of JS, but to add features in a future ECMAScript spec, because, as you say, "everyone is already doing it."

You also raise a point that I forget to bring up because the well's been thoroughly poisoned by this point in a conversation about TS; that there is evidence that TS is a net creator of bugs, due to developers doing things like needlessly wrapping primitives that already have types. Why would you want to give up the ability to import other JS modules (with its beautiful static import system that circular imports doesn't even break) without a problem?

At the end of the day, I agree pretty much wholeheartedly with your conclusion, though, despite the missing history (and I'm avoiding the "confusing classes with types", "confusing type annotation with type-based programming", "confusing type annotation with types in compiled languages", etc. etc.). JS is great. It's so powerful and flexible that it supports classes with mere sugar. If you need TS, go for it. But TANSTAAFL, and for the cost you have Purescript, Sanctuary, and a million transpiled options if you really, really, want to explore what type-based programming can do.

(Or try an ML! You like types? You'll love Haskell! Heh.)

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
sdj2008 profile image
sdj2008

I thought I'm the only one who is not buying TypeScript.
Thanks for the great article.
In the past I developed many applications with C# and it was my main tool and because i didn't understand JavaScript i used to describe it to my colleagues as "anything goes" language because the rules seemed too relaxed.
Time went by and i had to work with JavaScript and now i love it because of that flexibility. What i enjoy -among many other features- is how i can create an object, add new properties, remove existing properties, iterate through the properties...etc.
It is so much freedom.
In regrad to typescript; I hit different types of bugs thought my work, none of them strong typing can help me with, they are usually network issues or handling unseen scenarios.
Throughout my 25 years of working in software development field i have seen many hyped up trends come and go, so I'm not going to invest my time in every one until I'm fully convinced that it is worth the time and effort to adopt it for my use

Collapse
berdichevskyivan profile image
berdichevskyivan

Oh good lord, it's great to know I'm not the only one on this boat (Having preference of JS over TS but absolutely nothing against TS and definitely recognize its utility). Thank you very much for your insight!

It is true this is akin to religious wars. People will make a completely wrong assesment of your skills and knowledge based on wether you use TS or not and that's just wrong and we need to evolve from that.

Collapse
Sloan, the sloth mascot
Comment deleted
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
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 on

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
wenq1 profile image
Wenqi Chen • Edited on

I see nothing in your comments but marketing tricks.

Of course when types are introduced into your "software", you will call it a "solution", as your aim has "always been to do deliver high quality solutions".

When you come across typeless codes, you call it a beast and become a beauty. I see. You never lose.

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 on

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 on

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 on

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 on

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
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 on

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 on

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 on

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 on

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
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
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
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
raghavmisra profile image
Raghav Misra

Honestly at this point I see so many pros and cons that fighting religiously over this is worthless (I love TypeScript with my heart and soul lmao and do disagree with your points, personally lol), because what's life without choices right? Really liked reading, and you do bring up very valid points. My only question was quite small, what did you mean by many of the typings you noticed being "meaningless wrappers around the primitives" Could you give an example?

Collapse
jfbrennan profile image
Jordan Brennan Author • Edited on

Yeah, pros and cons. I haven't found enough pros to outweigh the cons and JavaScript just keeps getting better (e.g. Optional Chaining) so the need for TS continues to dwindle. For my needs anyway...

Here's some examples I found in a few minutes that are practically worthless imo. There's just so little value here

export interface MDCSnackbarCloseEventDetail {
  reason?: string;
}

export interface ShowTooltipOptions {
  readonly hideFromScreenreader: boolean;
}

export interface MDCSelectEventDetail {
  value: string;
  index: number;
}

export interface MDCMenuItemEventDetail {
  index: number;
}

export enum CssClasses {
  PROCESSING = 'mdc-switch--processing',
  SELECTED = 'mdc-switch--selected',
  UNSELECTED = 'mdc-switch--unselected',
}

type WelcomeMessage = string;

type Keywords = Array<string>;

type User = {
  name: string;
  age: number;
}

const colors = ['red', 'orange', 'yellow'] as const;
export type Color = typeof colors[number];
Enter fullscreen mode Exit fullscreen mode
Collapse
raghavmisra profile image
Raghav Misra

hmm why are all of those bad?

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited on

I'm not saying they're bad as in that code is objectively bad code. I'm saying I've found that kind of TS to be of no real value (especially if you believe in the 30% TS tax) and I see a lot of TS like that. Some TS is more meaningful and useful than the above, but even still I don't think it's really worth the investment considering how much JavaScript already offers (see the long list of native ways to harden your js) and you still need to write explicit runtime checks for a lot of use cases and write unit tests and other types of tests.