Debate in the JavaScript community over the syntax of proposed types – The New Stack

If a proposal unveiled this week catches on, JavaScript developers will soon have something many of them have been asking for a long time: a type system, of some kind at least.
A blog post by TypeScript Senior Program Manager Daniel Rosenwasser provides background and reasoning behind the type syntax proposal in JavaScript. He writes that “if we pull this all off, we have the chance to deliver one of the most impactful improvements to the world of JavaScript.”
Feel free to read the proposal (it’s quite readable), but for those of us who want the TL; DR, here it is: if the proposition is accepted in the language, it will be valid JavaScript: pic.twitter.com/hHkjFLQP34
— Gil Tayar (@giltayar) March 10, 2022
The proposal, which shares authors from Microsoft, Bloomberg, Igalia and a number of other sources, suggests that JavaScript developers should be able to “add type annotations to their JavaScript code, allowing those annotations to be verified by a external type checker”. to JavaScript” and then be ignored at runtime.
“Because this new syntax would not change the way surrounding code executes, it would effectively act as comments,” Rosenwasser wrote in his blog post, later adding that “JavaScript could create a set of syntax for types that the engines would ignore entirely, but what tools like TypeScript, Flow and others might use. This allows us to retain the things you love about TypeScript – its type checking and editing experience – while removing the need for a building stage in development.
this is absolutely huge – the biggest thing to happen to javascript in a long time. may this proposal sail swiftly in calm waters https://t.co/67qOJ8qtbc
—Rich Harris (@Rich_Harris) March 9, 2022
Until now, types were relegated to TypeScript in part because this build step could also be used to compile code for different browsers. However, with the advent of continuously updated evergreen browsers, the authors of the proposal write that they “anticipate that developers will have less need for lower-level compiling” and thus, “for many TypeScript users , the only step needed between writing the code and running it will be to clear the type annotations.
A remarkable part of the proposal spells out exactly what is not being offered:
“Our team is not proposing to put TypeScript’s type checking in every browser and JavaScript runtime – nor are we proposing a new type checker to put in the browser. We believe this would cause problems for JavaScript users and of TypeScript due to a range of issues, such as runtime performance, compatibility issues with existing TypeScript code, and the risk of stopping innovation in the type-checking space.
Similarly, several TypeScript features that generate code, such as enumerations, namespaces, and parameter properties, are explicitly excluded “because they have runtime semantics, generating JavaScript code rather than just be deleted and ignored”.
As you’d expect, the potential addition of types to JavaScript — even ones that are completely optional — isn’t something that absolutely everyone agrees on.
This is a very bad thing for JavaScript.
Here’s why 🧵 https://t.co/TytQZYWhO7
— Jess Telford (@JessTelford) March 10, 2022
For many detractors, the argument is that adding types as comments will unnecessarily complicate the code visually and make it harder for new developers. They also argue that, lest the code suffer bloat, an extra step will be required to remove this code anyway. Others still argue that there is a reason why TypeScript is TypeScript, and not JavaScript, but they may be forgetting that this proposition intentionally excludes a number of TypeScript features.
“This proposal is a balancing act: trying to be as compatible with TypeScript as possible while allowing other type systems, and not impeding JavaScript’s syntax evolution too much,” the proposal proposes. on this point.
I’ve had a chance to chew on that a bit and my view is more nuanced now.
As with many decisions in technology, this proposal is a trade-off and the weight that different people place on various factors will fluctuate.
My thoughts: 🧵
(fasten your seatbelt, it’s long) https://t.co/YqqszuHr0t
— Alex Reardon 🇺🇦💔 (@alexandereardon) March 10, 2022
As the authors of the proposal note, the proposal itself is presented as a “straw proposal” and, as such, intended to generate precisely this type of lively discussion. So far, it looks like there’s a lot of debate going on, alongside some pretty robust enthusiasm for the advent of type functionality coming to a JavaScript near you.
This week in programming
- List of Summer of Code Drops mentors from Google: For those of you who are considering applying for Google Summer of Code (GSoC) 2022, the list of mentoring organizations has been revealed. It adds 32 new organizations, bringing the total to 203 open source projects. Organizations include a variety of foundations – the Linux Foundation, Cloud Native Computing Foundation, Eclipse Foundation, Python Software Foundation, to name a few – and open source projects like TensorFlow, GitLab, Jenkins, Dart , Ruby, Julia and many more. The GSoC takes place every summer (northern hemisphere), coaching developers on how to contribute to open source software. Applications open Monday, April 4 and close Tuesday, April 19.
- The dramatic fallout from DHH continues: Last week we covered how Ruby on Rails creator DHH and RailsConf parted ways after the RailsConf team asked him to share the keynote scene, and this week the spinoff went continued, while Rails core team member Kasper Timm Hansen was rather abrupt. left the core team. Hansen had signaled his displeasure with the situation a week earlier, when he tweeted that he preferred not to be mentioned in DHH blog posts, and soon after issued the pull request which simply stated “I’m leaving the Rails core and not interested in being part of the old .” There was a lot of fanfare when Kasper joined the core of Rails and, if the replies to his tweets and pull requests are any indication, the eleventh most productive Rails contributor seems to be missed by the community as a whole.
- Embedded software development comes to VS Code: Following a similar launch for Visual Studio 2022, Microsoft released the Embedded Tools extension for Visual Studio Code, which according to the extension’s description “provides a registry viewer for CMSIS-SVD files and an RTOS data viewer with support for Azure RTOS and FreeRTOS. The extension, used alongside new vcpkg artifact functionality that helps acquire built-in tool dependencies, allows developers to quickly boot an integrated development machine and get started. With the addition of this extension, VS Code now offers developers all the usual features, including code navigation, IntelliSense, building, deploying, debugging, and new diagnostic capabilities around device registers and views real-time operating system (RTOS) objects.
With JavaScript you can save a few minutes by not declaring types!
(Warning: ⚠️ You’ll probably waste all those “saved” minutes debugging runtime errors) https://t.co/qFi5H9aOe1
— Cory House (@housecor) January 8, 2022