8 ms·

The last days of my type checker for JavaScript

74 points by bk496 2y ago

philipwhiuk 2y 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.
wccrawford 2y 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.
- dmurray 2y ago
  I don't think the author completely feels this way. He feels Typescript is the VHS to his Betamax: the approach that won out despite being technically inferior. > unfortunately, I see that nowadays, TypeScript won. The idea of strict type-checking for JavaScript is less popular than in 2019. > [Typescript's types] give people a fantastic tool to cover existed code with types but doesn’t force to re-design it to make it safer.
  - meandmycode 2y ago
    By 2019, typescript was for some time dominant over flow and had won the js ecosystem, so either the author was naive to this or isn't quite portraying the story well.. I think it should be fine for the author to say they had personal preference over something like flow and so you developed tools to their own preference
    - thiht 2y ago
      Yeah in 2019 Typescript was already the clear winner, no contest
joshstrange 2y ago
Here is another tool in the same vein that people might find interesting: https://gitlab.com/dejawu/ectype https://gitlab.com/dejawu/ectype
noelwelsh 2y 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.)
pjc50 2y 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.
- couchand 2y ago
  That time is now. I've been shipping Rust code to browsers for years...
  - berkes 2y ago
    Rust is still the only language with decent tooling and an ecosystem to compile to WASM. Many other languages haven't passed the PoC stage. Several are ready, and doable (C#, Go?) but hardly as easy and common as with rust. At least that was the state when I looked six months ago. It's a fast moving area. So, yes, that time is now. But the only practical option is rust. Which may be enough, idk.
    - pjc50 2y ago
      C# Blazor certainly exists and works, although it feels really clunky. Only suitable for a true application, not for integrating with web pages. It's almost the inheritor of the Java "applet" and the HotJava browser.
    - randomdata 2y ago
      > Many other languages haven't passed the PoC stage. Wouldn't it be more accurate to say that WASM hasn't passed the PoC stage? There are quite a few languages that have great WASM support, to the extent WASM allows, but have to bring all kids of workarounds to deal with the shortcomings of WASM as it sits. An especially challenging problem as it relates to browser use with those workarounds is that they bloat the artifact size. Few are willing to subject users to multi-megabyte downloads. Work is being done on WASM to address those shortcomings, but hands are pretty much tied until that arrives. Until then, the "lower level" and heavily constrained languages will be left to stand alone.
  - 2y ago
begueradj 2y 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.
Waterluvian 2y 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.
- __s 2y ago
  By that I think he meant to differentiate Hegel from TypeScript as Hegel being strict, as opposed to TypeScript being what is often described as gradually typed
  - Waterluvian 2y ago
    Oh that makes more sense.
- deleted 2y ago
  [deleted]
- nevon 2y ago
  The keyword being "strict". Typescript is more popular than ever, but soundness is not a design goal.
smackeyacky 2y 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.
- verelo 2y ago
  This is so my experience. Also when you can just declare something as “any” and effectively say f it to the entire concept they’re trying to enforce…what’s the point? From time to time human nature takes over and you use any, and the disease has started the spread. If i wanted loose types, i wouldn’t have used typescript. So “pick a side” is all i can ever think when i work with ts.
  - seper8 2y ago
    You know you can do loose types in C# and many other "strongly typed" languages too?
  - vundercind 2y ago
    “Any” is incredibly useful. It lets you transition JS code to TS without having to do the whole thing at once. It lets you work with libraries written in JavaScript without having to immediately find or write types for them. The language would be nearly unusable in the real world without it, and that’d have been even more true in its early days.
  - tom_ 2y ago
    You need a getout clause sometimes, and it's useful to have one. (You should prefer "unknown", though, which requires you to cast the value on each use, over "any", which treats the value as being of all possible types. You can configure eslint to moan at you if you use "any": https://typescript-eslint.io/rules/no-explicit-any/ https://typescript-eslint.io/rules/no-explicit-any/)
madeofpalk 2y ago
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.
qbane 2y 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.
- wyriwyg 2y ago
  IMHO type checking for dynamically typed languages should be done by the IDE instead of messing up the language itself. Fortunately at some point there will be an addon for your favorite IDE that does the type checking without touching your code. Microsoft could have developed such a rigorous type check addon for VSCode, but (unfortunately) instead they went for Typescript, no clue why they preferred to do the latter, maybe another throw to dominate the no1 browser language?
  - pjc50 2y ago
    I don't understand this point of view: types are part of the code? Perhaps one could eliminate 90% of the need to write them down with aggressive use of Hindley-Milner, but in many places they're a deliberate choice.
    - randomdata 2y ago
      The discussion taking place is about type checking plain Javascript. The comment you replied to questions why Microsoft didn't go down that road, something they ended up doing eventually anyway, instead of introducing a new language.
  - qbane 2y ago
    JavaScript is inherently untyped. Either the programmer tries to be very careful to make it type safe, or someone invents a programming language that can only compile to a sound subset of it. TS heads for the latter way. But things quickly go out of control when you introduce dependencies, and even a dependency without interface file can pollute your codebase with "any". I do not think TS would be mainstream if there were not many packages on npm that had included a type definition. On the other hand, a type checker/inferencer that "does less things" like Jedi has proved great success in Python community.
gr__or 2y 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.

74 points by bk496 2y 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.

wccrawford 2y 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.

dmurray 2y ago
I don't think the author completely feels this way. He feels Typescript is the VHS to his Betamax: the approach that won out despite being technically inferior. > unfortunately, I see that nowadays, TypeScript won. The idea of strict type-checking for JavaScript is less popular than in 2019. > [Typescript's types] give people a fantastic tool to cover existed code with types but doesn’t force to re-design it to make it safer.
- meandmycode 2y ago
  By 2019, typescript was for some time dominant over flow and had won the js ecosystem, so either the author was naive to this or isn't quite portraying the story well.. I think it should be fine for the author to say they had personal preference over something like flow and so you developed tools to their own preference
  - thiht 2y ago
    Yeah in 2019 Typescript was already the clear winner, no contest

joshstrange 2y ago

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

noelwelsh 2y 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.)

pjc50 2y 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.

couchand 2y ago
That time is now. I've been shipping Rust code to browsers for years...
- berkes 2y ago
  Rust is still the only language with decent tooling and an ecosystem to compile to WASM. Many other languages haven't passed the PoC stage. Several are ready, and doable (C#, Go?) but hardly as easy and common as with rust. At least that was the state when I looked six months ago. It's a fast moving area. So, yes, that time is now. But the only practical option is rust. Which may be enough, idk.
  - pjc50 2y ago
    C# Blazor certainly exists and works, although it feels really clunky. Only suitable for a true application, not for integrating with web pages. It's almost the inheritor of the Java "applet" and the HotJava browser.
  - randomdata 2y ago
    > Many other languages haven't passed the PoC stage. Wouldn't it be more accurate to say that WASM hasn't passed the PoC stage? There are quite a few languages that have great WASM support, to the extent WASM allows, but have to bring all kids of workarounds to deal with the shortcomings of WASM as it sits. An especially challenging problem as it relates to browser use with those workarounds is that they bloat the artifact size. Few are willing to subject users to multi-megabyte downloads. Work is being done on WASM to address those shortcomings, but hands are pretty much tied until that arrives. Until then, the "lower level" and heavily constrained languages will be left to stand alone.
- 2y ago

begueradj 2y 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.

Waterluvian 2y 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.

__s 2y ago
By that I think he meant to differentiate Hegel from TypeScript as Hegel being strict, as opposed to TypeScript being what is often described as gradually typed
- Waterluvian 2y ago
  Oh that makes more sense.
deleted 2y ago
[deleted]
nevon 2y ago
The keyword being "strict". Typescript is more popular than ever, but soundness is not a design goal.

smackeyacky 2y 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.

verelo 2y ago
This is so my experience. Also when you can just declare something as “any” and effectively say f it to the entire concept they’re trying to enforce…what’s the point? From time to time human nature takes over and you use any, and the disease has started the spread. If i wanted loose types, i wouldn’t have used typescript. So “pick a side” is all i can ever think when i work with ts.
- seper8 2y ago
  You know you can do loose types in C# and many other "strongly typed" languages too?
- vundercind 2y ago
  “Any” is incredibly useful. It lets you transition JS code to TS without having to do the whole thing at once. It lets you work with libraries written in JavaScript without having to immediately find or write types for them. The language would be nearly unusable in the real world without it, and that’d have been even more true in its early days.
- tom_ 2y ago
  You need a getout clause sometimes, and it's useful to have one. (You should prefer "unknown", though, which requires you to cast the value on each use, over "any", which treats the value as being of all possible types. You can configure eslint to moan at you if you use "any": https://typescript-eslint.io/rules/no-explicit-any/ https://typescript-eslint.io/rules/no-explicit-any/)

madeofpalk 2y ago

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.

qbane 2y 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.

wyriwyg 2y ago
IMHO type checking for dynamically typed languages should be done by the IDE instead of messing up the language itself. Fortunately at some point there will be an addon for your favorite IDE that does the type checking without touching your code. Microsoft could have developed such a rigorous type check addon for VSCode, but (unfortunately) instead they went for Typescript, no clue why they preferred to do the latter, maybe another throw to dominate the no1 browser language?
- pjc50 2y ago
  I don't understand this point of view: types are part of the code? Perhaps one could eliminate 90% of the need to write them down with aggressive use of Hindley-Milner, but in many places they're a deliberate choice.
  - randomdata 2y ago
    The discussion taking place is about type checking plain Javascript. The comment you replied to questions why Microsoft didn't go down that road, something they ended up doing eventually anyway, instead of introducing a new language.
- qbane 2y ago
  JavaScript is inherently untyped. Either the programmer tries to be very careful to make it type safe, or someone invents a programming language that can only compile to a sound subset of it. TS heads for the latter way. But things quickly go out of control when you introduce dependencies, and even a dependency without interface file can pollute your codebase with "any". I do not think TS would be mainstream if there were not many packages on npm that had included a type definition. On the other hand, a type checker/inferencer that "does less things" like Jedi has proved great success in Python community.

gr__or 2y 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.