Typed JavaScript? For real? The “type annotations” proposal and what it’s all about by Gil Tayar

A major earthquake has hit TC39, the JavaScript standards committee. A proposal for adding type annotations to JavaScript has just landed in the committee, and has been approved for Stage 1.
What is this proposal all about? How did it come to be? What is the motivation behind it? What are its pros and cons? Why are some people excited about it, some wary, some angry, and some afraid? As one of the writers of this proposal, I will delve into the details of the proposal, and try to answer all the questions above.
jsconfbp.com/speakers/gil-tayar
About Gil
30 years of experience have not dulled the fascination Gil Tayar has with software development. His passion is distributed systems and figuring out how to scale development to big teams. Extreme modularity and testing are the main tools in his toolbelt, using them to combat the code spaghetti monster at companies like Wix, Applitools, and at his current job as software architect at Roundforest.
In his private life, he is a dad to two lovely kids (and a cat), an avid reader of Science Fiction, (he counts Samuel Delany, Robert Silverberg, and Robert Heinlein as favorites) and a passionate film buff. (Stanley Kubrick, Lars Von Trier, David Cronenberg, anybody?)
Unfortunately for him, he hasn’t answered the big question of his life-what’s better, static or dynamic languages? But he’s working on it.

[@FabioSpampinato]

I wish he addressed the obvious concerns here, that those types are just syntax sugar for inline block comments basically, like /* number */, they just do nothing, people wanting static types added to the language shouldn't be treated as if they are in favor of this proposal, static types do something, these do nothing, they are comments that get ignored by the engine entirely. Also I would have liked to see some numbers on what percentage of people use JSX/Vue/Svelte on the frontend, if you use those this proposal is pretty much entirely useless for you, _even_ during development, because you'll need your code to be transformed anyway. On the server side it seems to me that with the advent of Deno and even more modern engines like Bun this isn't even a problem to begin with, like reducing tooling can be solved without complicating the spec and the language one bit and without constraining out future choices one bit. Regarding the benefits during development I also wish he addressed how modern tooling like esbuild and Vite work pretty much in real time and Vite especially is really trivial to set-up, like I don't even see much room for improvement there, there are even more modern tools like Bun that claim to trim even more of the overhead if the problem you have with esbuild or Vite is performance. And as the speaker says you are going to want to use tooling for production _anyway_, so where's the simplification, on the contrary, using the same tool for both dev and prod seems easier to me than not using tooling during development but transforming your code with some tooling during production. One silly example: do you really want to F5 all the time or do you want the thing to auto-refresh during development? That seems a strong benefit of wanting dev tooling _already_, and it's far from the only one.

[@kvirajs]

How come for people using JSX this is useless? Wouldn't it help during development where we can identify the errors earlier before we execute it? Yes, ofcourse our code will be transformed and all those will be ignored which is the same how ts behaves... So how come this doesn't add advantage or its not useful?

[@FabioSpampinato]

​@@kvirajs What they call "types" here are really just another form of comments, you could add these comments to JS, but you'd still need TypeScript to do anything useful with them, i.e. you'll see no improvement if you are using JSX: - Today you need TS to type-check your code, and you will need it just the same if this proposal ships. - Today you need tooling to compile your code, because it contains JSX, and you will need it just the same if this proposal ships. That's the confusion that I was referring to, they seem to be playing with people somewhat, yes the proposal received a lot of excitement when it was first announced, but yes also people still don't understand that this is a syntax for comments that don't do anything by themselves and that won't do anything when the JS engine will execute your code either.

[@nodidog]

@@FabioSpampinato Why will you still need typescript to type-check code? He explicitly states that language servers will be able to pick up the types. This IDE feedback is one of the main advantages for TS, to have it built into JS would seem to be a fairly significant and positive change.

[@FabioSpampinato]

​@@nodidog The IDE/LSP still uses TS under the hood. By the way if deleting "typescript" as a dependency and relying on the IDE for your type checking sounds desirable to you you can just have that working today. This proposal has no impact on that whatsoever.

[@marcellerusu]

actually for svelte this will still be a benefit, if we can get rid of even 1 part of the transpilation process, its still a win IMO. Svelte in general isn't as bought-in on typescript as other communities, afaik Rich still prefers types in js comments, while TS is possible, I've found build issues in setting up ts that isn't ideal. If type annotations are just part of the language, we don't need to have 2 separate sets of build pipelines that need to work with 2 languages. It decreases the complexity of our build tools, even if we still have them, which is a huge win IMO.

[@leemack4562]

proof that not every idea is a good idea

[@jskndeol]

Yes, Please do it.

[@mpcref]

Still thinks it's a stupid idea. Browsers can easily just implement a "dev mode" in which they will accept this type syntax or any other syntax extensions for that matter. That way it doesn't even need to be a standard! It's just extra parser overhead if it gets added to the language spec.

[@MihilRanathunga1990]

Started the video as a sceptic and ended it as an believer. Awesome presentation.

[@TomNook.]

Sure, sounds good

[@hajinhajinkim]

omg, if this lands on js :o

[@mwangochilabi5366]

I don't see the reason for this??

[@Ronenlahat]

Python already has this kind of type hints since 3.5, with PEP 484 I like the opposite, the fewer type annotations as possible, but type strictness (like ReScript). I hope this doesn’t encourage type annotations everywhere, but seems like a good and versatile direction

[@edgeeffect]

I don't know for sure but I think PHP did type hints before Python... And this is worth mentioning because it's probably the only time PHP will ever do anything BEFORE anyone else.

[@barbourc]

💥

[@TayambaMwanza]

Make it so

[@richardjecooke8036]

Years :(

[@supernova82]

I think the problem is, that the developers who started with some statically-typed language, can't grasp how JavaScript's dynamic type system works. So instead of understanding how it works, the solution is just to add types to JavaScript. The same things with the classes, it was not needed but probably added for the same reason. Whatever the reason is, they are turning JavaScript into Java. I am sure that most of the community is using types because it is required by the job not because they had any opinion about types. You can't just change the JavaScript because of some people are using some tool. JavaScript's tooling system changes very fast. Besides, why not change the CSS to add SASS functionality? Why not change HTML to use the most common templating engine? By the way, you can definitely create React apps without the tooling. If you just want to work with standard JS and CSS.

[@parlor3115]

No, It's definitely not about devs coming from staticly-typed languages, it's about the collective experience of every JS dev. Static typing speeds up development as you won't need to wait until your code runs to spot bugs like misspelled property names or treating a string as an array.

[@hanzlaahabib]

@@parlor3115 👍

[@alerya100]

ABsolutely true, man!!!

[@raianmr2843]

Funny how people who only know one language (JS in this case) are reacting to this as though it's the end of the world. Trying to come up with fictitious cons of this proposal, insulting the people involved, and so on. These stooges are a gift that just keeps on giving.

[@softwarelivre2389]

Types are good if you can either optimize performance ahead-of-time or if you can ensure type correctness in order to prevent type bugs. This proposal solves none of those.

[@edgeeffect]

I think this proposal sucks and I've used 20 different high level languages over the 40 years that I've been programming.

[@DanielMelogpi]

Typescript is a hell lot better. It actually helps when you do yourself a disfavor and pass wrong types down the pipe. This is just fancy comments

[@parlor3115]

The runtime ignores but IDE like VS Code won't and will squiggly spam you until you fix all the errors.

[@hanzlaahabib]

You haven't heard it correctly, JS will treat them as comment but Type compilers will bug you down if you do something wrong, basically its same TS experience with no extra tooling

[@alerya100]

Typescript is the same as Javascript which makes you type more.

[@trustmebro19]

So with this proposal, browsers and node ought to support this syntax, right? Then one would argue that browsers and node can start supporting typescript syntax! The syntax that millions of developers are familiar with I didn't like this proposal

[@grumpylibrarian]

I am surprised that browsers don't already. Might be a hatred of Microsoft thing. Node module loader hooks and web server engines could be configured to compile TS->JS on demand, even cache the results, so a DIY solution is at least possible.

[@softwarelivre2389]

@@grumpylibrarian that's why Deno exists.

[@grumpylibrarian]

@@softwarelivre2389 I agree, that is why Deno exists. But it doesn't mean Deno is going to do the job. I love the concept, but the ecosystem isn't there yet.

[@softwarelivre2389]

@@grumpylibrarian well, at the moment it has everything I need for my projects. A while ago I would agree, the WebCryptoAPIs weren't there yet, but now they are, and I don't think I miss anything. What do you feel is lacking for your workflow?

[@grumpylibrarian]

@@softwarelivre2389 Even if everything I personally need is there now, which I don't think is the case, that wouldn't hold for everyone. There are some libraries that would do the same job but in very different ways, so a fresh project might be worth examining Deno, but converting an existing one would be too much trouble. XMLDOM is an example of a horrible little package that's still the least-awful choice in the Node ecosystem, because it actually makes a ws3-compliant graph. Deno XML packages seems to be along the same line as the not-even-as-good-as-XMLDOM packages from Node, trying to convert to "simplified" nonstandard object formats. I see discussions for DOMParser and XMLSerializer that have gone nowhere. Deno has deno_dom, of which its self-description of "fairly usable for basic HTML manipulation needs" is slightly terrifying. Perhaps it would be no worse than XMLDOM, but that would require a bit of testing. XPath seems worse. I see a package that binds to XPath from libxml2, which is simply inadequate. I need pure JS/TS solutions and portability, as these run on multiple machines / multiple OSs with the same source, and compilation is not an option. I have shoved some processing through Electron just to get chromium's native DOM / Xpath processing. These REALLY should have been native in Deno and not left to third party hacks. There are SSH and Websocket packages that might do the trick if I learned them. They might even be better than the mscdex/ssh2 or theturtle32/WebSocket-Node modules. Similar for socksv5 and Postgres modules.

[@carlinjacob520]

Horrible idea, we already have JSDOC comments that are easier and clearer. JS has more then enough ways to structure a function, adding more variation to the mix will make learning and keeping things uniform exponentially harder

[@softwarelivre2389]

True. Types are good if you can either optimize performance ahead-of-time or if you can ensure type correctness in order to prevent type bugs. This proposal solves none of those, and seems to only add complexity instead.