The last days of my type checker for JavaScript

bk496 | 74 points

For starters, I think the author should take this all as a resounding success. I'm sure they learned a lot - technical and othewise - from the project, and that's always worth it. I don't believe the only two options are massive viral hit or failure.

But I don't think I agree with the authors conclusions that there's less interest in type safety or strict type checking. I suspect the author finds Typescript too leanient (there's plenty of ways to trigger Typescript's unsoundness) for their liking, but I do think there is an overall trend to use Typescript to design and build more reliable software.

madeofpalk | 11 days ago

It takes a lots of wisdom, humility and a pragmatic vision for a man to confess that an important enterprise he devised and worked on is not worth to continue investing on.

Do not forget you learned a lot along the path. That's something no one can take away from you.

begueradj | 11 days ago

There's something bittersweet about doing something well, and then eventually having something else take over from it. You had that feeling of doing it really well and being successful, but you don't need to keep pouring energy into it now and can work on other things with a clear head.

wccrawford | 11 days ago

I feel like in the longer term we'll eventually get, via WASM or otherwise, another language that we're allowed to use in the browser, which can be properly type-safe from the beginning.

pjc50 | 11 days ago

> The idea of strict type-checking for JavaScript is less popular than in 2019.

I’d be shocked to find this to be true. Back then I’d always wonder, “are there typings for this library?” Now I don’t have to.

Waterluvian | 11 days ago

Here is another tool in the same vein that people might find interesting: https://gitlab.com/dejawu/ectype

joshstrange | 11 days ago

This project, along with TernJS, really inspired me to dig into the wild world of type inferencing of JavaScript with minimal annotation. TypeScript, or even JS with JSDoc comes with learning overhead. Pure JavaScript projects often cannot be easily typed in TypeScript's way without major refactoring, and sometimes a lightweight editor plugin suffices to provide enough insight for ease of development. There is no one-size-fit-all solution, and I wonder how far can something like context-aware autocompletion can go without TypeScript.

qbane | 11 days ago

> I see other opportunities to increase the language diversity on the web (further in the article)

I'm unconvinced this would be a good thing.

philipwhiuk | 11 days ago

Thanks for your hard work on making JS safer. You were working on exactly what I am missing most, sane error-handling. I hope TS picks up where you left off at some point.

I was also happy to see the shout-out to Ben's Ezno. I'd recommend people start sponsoring that kind of work, it has the potential to make our JS life much saner.

gr__or | 11 days ago

Good post. It's important to realize when a project isn't worthwhile continuing. It's also important to realize that so-called technical criteria are only one dimension along which usage decisions are made. Technically inferior technology often wins out for other reasons (e.g. Windows vs OS/2 etc.)

noelwelsh | 11 days ago

I have been working with node for a couple of years now, not my choice but it isn’t tragic. This team uses TypeScript,

I honestly don’t get the problem TypeScript is trying to solve. JavaScript has lots of wacky problems but its main advantage to me was the loosy goosy approach to types. I was a smalltalk programmer back in the 1990s and it felt pretty comfortable if very primitive in the way of tools.

Typescript just seems unnecessary. Not sure why nobody built something like reentrent exceptions or cool stuff like that, instead they built a stupid jail that down compiles to unreadable sludge.

Now I find out there were competing jails. What a strange ecosystem.

smackeyacky | 11 days ago