Skip to content
Search

DEV Community

Jordan Brennan
Jordan Brennan

Posted on • Updated on

 

The reasons I don't use Typescript

#javascript #typescript #webdev

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?

UPDATE 3:

It's been two years since I wrote this. In that time I've spent more time with TS and I'm compelled to come back here to humbly acknowledge that I was...right. Right as hell too! TypeScript is 100% useless overhead that serves only one purpose: scratch an itch for neurotic developers.

Top comments (220)

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 •

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 •

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 • • 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 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 • • Edited

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
 
odoocemodules profile image
odoo-ce-modules • • Edited

With all due respect, comments such as "Ts allows you to use next generation js features" ... as if the JS universe somehow prevents one from using any JS features ... is the sort of nonsense that exposes the indoctrination of the TS cult. This is why I can't take the TS cult seriously.

Collapse
 
peb7268 profile image
Paul Barrick •

You're commenting on this like my ancient comment is still relevant. Things move super quick in the dev world. With the adoption of next generation js features this is less of a thing.

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.

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 •

"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 •

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 •

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.

Thread Thread
 
pinkyshelac profile image
Lisa Ziegler •

Thanks for pointing out the class keyword, etc, history too. TS does seem like the same thing; adding something to JS or on top of it which doesn’t add any new features but mainly a way to organize your code.
I agree with all Jordan has said, and would like to confirm that TS can make it hard to add jr and even mid devs from a mainly JS background to a project. Not great when all you want is some linting.
I’ve been coding for 20 years, and was very happy that web software and JS community seems to be heading toward readability and speed.
Colleagues and I have the opinion that the main misuse boils down to this: something like angular or react gets popular, an effort starts to make it look like C or Python. I feel like doing that misses the point of JS.
There’s also the impact of companies having a harder time hiring when adding that requirement.

Collapse
 
hutber profile image
Jamie Hutber •

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

Collapse
 
louiszen profile image
Louiszen •

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

 
jfbrennan profile image
Jordan Brennan •

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

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
 
yavork profile image
Yavor Kirov •
  • On the "Strict is not good for the web". I think the issue here is that Typescript might have "documentation" of types it expects but documenting types is not exclusive to TS. You can document the data structure you expect with JSDoc and use plain JS objects.

On the other hand validation the data I receive in a method call is another matter. Like really check if the property exists, if it is a string of Latin characters etc. -- but TS will not do that.

I think for newbies it is misleading that TS uses things as "string" or "array" and makes it look like it validates the data passed to functions from outside sources. TS Does not do that.

  • On ts as a whole. I don't see the use of it. TS is basically C# trying to compile itself to JS. When I went for web development I wasn't looking to write C# in the web. I am still not looking to write C# in the web. I think that OOP languages enforce writing out types, class names etc. which is ultimately a waste of time. It does not reduce bugs. It's just what C# and Java fans are used to and makes them feel at home. However... it's only TS veneer over JS. JS is not C# under the hood. It will never be.
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
 
jfbrennan profile image
Jordan Brennan • • 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
 
kevinlbatchelor profile image
Hello Dave •

Great comments. Don't worry about the religious typescript worshippers. Just another cargo cult. TS is great but not for all projects and people. And great products can be built with and without TS.

 
jfbrennan profile image
Jordan Brennan •

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 •

That’s pretty interesting, thanks.

 
jfbrennan profile image
Jordan Brennan •

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 •

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.

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 •

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.

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 •

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
 
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
 
kpkeerthi profile image
Keerthi • • Edited

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.

 
jfbrennan profile image
Jordan Brennan •

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

View full discussion (220 comments)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

DEV Community

Need a better mental model for async/await?

Check out this classic DEV post on the subject.

⭐️🎀 JavaScript Visualized: Promises & Async/Await

async await

Read next

viktoriialurie profile image

Module Federation v7 featuring Delegate Modules

Viktoriia Lurie -

apppardana profile image

PERFECT ROADMAP FOR REACT DEVELOPER

Aditria Pardana -

cleancodestudio profile image

Chat GPT-4 Already Used In the Wild (Stripe, Duolingo, Khan Academy, etc...)

Clean Code Studio -

sameer_trimade profile image

Best Practices for Optimizing Frontend Performance

Sameer Trimade -