Ditching TypeScript for JavaScript

https://gomakethings.com/ditching-typescript-for-javascript/

by fintechie • 3 years ago

28 30 3 years ago

gomakethings.com

danpeddle• 3 years ago

I do wish we were in the timeline where we got a super powered jsdoc, instead of TS.

Something like that would be my guess for what’s next, once this current trend has run its course.

jrajav• 3 years ago

Typescript is one of the most popular languages in the world at this point and continuing to grow (see Stack Overflow developer survey for the last 3 years). It covers the majority of the mature ecosystem on npm by now. Characterizing it as a trend is beyond incorrect. For all intents and purposes, JS is now statically typed.

capableweb3• 3 years ago

TypeScript would have to become more popular than JavaScript for your last part to become true. And it's nowhere near of getting there (outside of SV/hip development world).

https://trends.google.com/trends/explore?q=%2Fm%2F0n50hxv,%2... (last 12 months worldwide)

Last datapoint: TypeScript - 10, JavaScript - 82

eyelidlessness• 3 years ago

We already have that! And it’s TypeScript. You can and probably do use 98% (made up number but close enough to reality I don’t need to quantify it) of the benefits of TS while authoring JS code if you bother annotating types in JSDoc.

You can also get the same type checking benefits outside of the editor (eg in CI) with very minimal tooling effort. That’s what Svelte is doing.

Granted I work on JS projects which embraced this from the opposite direction (gradual typing where nothing is enforced statically), and it’s strictly worse than just using the tools how they work best (you’d be hard pressed to make an incremental decision about anything without knowingly preserving bugs or increasing the incremental scope).

Anyway, the alternate timeline you seek already exists. It’s just so optional that you could easily miss it.

phyrex• 3 years ago

I think that’s literally Flow: https://flow.org/en/docs/types/comments/

sibeliuss2• 3 years ago

For small things, sure. Substantial things like apps, its like shooting yourself in the foot before you've ever begun, and good luck refactoring anything with any confidence short of covering your whole app in tests.

Also, I think the examples given in the article are circumstantially exceptional, if you read more closely into the why.

capableweb3• 3 years ago

refactoring anything with any confidence short of covering your whole app in tests

I don't have any confidence in refactor large swaths of code without widespread tests, with or without TypeScript. Types covers such a small area of where we (I) usually introduce bugs.

xupybd• 3 years ago

I've found in strongly typed systems if I lean heavily on the type system refactoring is a dream. I make the changes I want. Then follow the compiler errors. Most of the time it just works. Rarely does that introduce bugs. However if you use a Typed language without using the type system to enforce the design constraints then the type system just gets in your way. In that case refactoring is just as hard. It's very easy in Type Script to write code that might as well be written in a dynamic language. It often is.

erikpukinskis3• 3 years ago

That’s not my experience. I find in carefully typed projects I can do pretty large refactors with high confidence that once the types are correct again, a lot of tests will pass, and a lot of behavior will work.

It’s not that there aren’t bugs, but I have a high degree of confidence after fixing a small number of bugs that the overall system has a high degree of correctness.

There are several things that go into this

- good types

- good tests

- good interfaces between modules

All three I think give me a big jump in how quickly and confidently I can refactor.

sibeliuss2• 3 years ago

Tests are very important, don't get me wrong. What I mean is that it's trivial to refactor large _trivial_ things with types -- ie, big restructures, renames, clarifying things, etc -- where without it even small "large" things become dangerous and worksome.

samtho• 3 years ago

I have not been able to jump on the TS train. For the longest time, it has just not quite felt right. Adding layers upon layers of complexity for a static type system and some related syntactic sugar, all while guaranteeing that it remains a superset of JavaScript has left it in a similar position to C++. It’s fragility has left it with a house of cards-type feel with unending dependency trees and poor visibility into itself as a runtime.

erikpukinskis3• 3 years ago

It’s definitely possible to create very brittle types that feel like a house of cards.

I think the most common mistake people make is re-using types. Even if a type works in two places, you can’t guarantee that the semantics in those places will stay consistent.

Devs working in TypeScript often think that in order to keep things DRY you should reuse the same types all over a codebase. For me it’s the opposite: using a type in two places is a code smell. You’re not really leaning on the compiler if you’re re-using types. The compiler loves to take two types and tell you if they’re compatible. Sharing the same type across use cases is just not necessary.

I find keeping types as local to a function as possible helps a LOT with alleviating that “house of cards” feeling you’re describing.

It’s a real problem though.

pull_my_finger• 3 years ago

I would hate to make judgement after such a small piece of text, but your argument just doesn't make sense to me. Reusing types would suggest you're actually coding against a design. Why should the data have a different shape in two different places in your code? If you're working with the same data shouldn't its type have a single identity?

selfmodruntime2• 3 years ago

Incremental compile time when changing files in cli/js takes minutes. This is crushingly slow and painful to modify.

This is in my opinion the worst offender of TypeScript. TSC is insanely slow even in incremental mode for large code bases, and no alternative compiler exists. There are projects which can strip types and convert TS into JavaScript, but they do not check types.

Alternative implementations have been swatted down by TypeScript maintainers like Daniel Rosenwasser, with the leading argument being that the TS spec moves insanely fast and keeping two or more implementations up to spec would not be worth it due to the work it would require.

capableweb3• 3 years ago

Well, if there would be multiple TypeScript implementations available, especially ones that are faster, Microsoft would suddenly lose their moat they gathered by getting TypeScript to be wildly used.

Keeping the spec moving fast and breaking it with new updates servers multiple purposes, not only to make the language itself different, but to avoid competing implementations.

When I say "spec" I main the Microsoft TypeScript implementation, as they don't actually maintain any actual specification anymore.

The spec is now an "archived" artifact and we won't be tracking defects against it anymore. - https://github.com/Microsoft/TypeScript/issues/15711

selfmodruntime2• 3 years ago

Wow. That is pretty bad.

neodypsis• 3 years ago

Have you heard of ReScript?

Their website: https://rescript-lang.org/

dcgudeman• 3 years ago

I’ve been a developer for a decade now and never run into an issue where JavaScript’s loosely typed nature has created a problem for me.

yeah... ok

hyperhello2• 3 years ago

I think if you are so reliant on static type checking that you can’t live without it, well, there you go. But it doesn’t seem like it has to be more of a problem than an hundred other oopses you deal with like passing parameters in the wrong order.

Most of JS’s most public issues come from thinking every programming language is C++.

Clamchop• 3 years ago

Framing type checking as a crutch is a new one to me.

NoahKAndrews• 3 years ago

Statically typing your parameters prevents a lot of instances of passing them in in the wrong order. And if you make a habit of using a single statically typed options parameter instead of multiple parameters that have the same type, you can make passing parameters in the wrong order completely impossible in your codebase.

zamnos• 3 years ago

Wat

stbl219z8y• 3 years ago

Cannot disagree more. The author is either a Javascript savant or has never worked on a 100k LOC Javascript project.

I remember the days before Typescript, chasing down those “undefined” Javascript bugs. Not fun.

stolenmerch• 3 years ago

I could definitely see the benefit of TS on a giant, modern app with a big team. However, at my job I am a solo developer on literally dozens of smaller JS projects of varying age that I need to keep running essentially forever. Typescript is enough of a pain in my npm build process that I just ditched it long ago. The fewer dev dependencies the better for me personally.

graeber_28927• 3 years ago

I also work on small apps, and like it there. I needed a day to set up TS the way I wanted, and I don't use strict mode. This way I can have TS check the few places I feel it's most useful, and not bother with the rest.

I feel confident making small components, and functions. But I like adding types to form data and product objects, especially when decorating product objects. Otherwise I'm prone to get confused as to whether the props have been decorated already, or not, maybe check for it? TS just feels really smooth sometimes, but admittedly I am not using it in strict mode.

ctvo• 3 years ago

The developer experience is excellent with Typescript. It's so much nicer to get auto complete suggestions based on a type system rather than mostly heuristics in plain JS. Refactoring is breeze. I enjoy using TS. I enjoy basic correctness guarantees caught at transpile time.

Of course there's trade-offs, but the whole article is a list of unconvincing appeals to authority.

And then the author ends with:

Our tendency to just blinding reach for tools because it’s what Google or Facebook does often just makes things worse for both developers and the people who use what they build.

You spent 4 paragraphs giving examples of other people using plain JS as the reason we should be blindly switching back to plain JS. Svelte swapped back to JS for n reasons that aren't applicable to you or most people.

I help people learn vanilla JavaScript, and I believe there’s a simpler, more resilient way to make things for the web.
I create courses and ebooks, run online workshops, and host the Vanilla JS Podcast. My developer tips newsletter is read by over 14k developers each weekday.

Oh.

skimdesk• 3 years ago

For smaller applications, an acceptable middle ground is using the TS language server[0] and JSDoc[1] comments.

Writing

  // @ts-check
  /** @type {number} */
  let x;

works very well for example in VSCode. The JSDoc comments are not as convenient as Typescript, but otherwise the experience is almost the same. The language server correctly keeps track of the types for me.

[0] https://www.typescriptlang.org/docs/handbook/intro-to-js-ts.... [1]: https://jsdoc.app/

Ditching TypeScript for JavaScript

Related Stories