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

If a proposal unveiled this week gets its way, JavaScript developers will soon have something many of them have long been request for a typing systemat least somehow.

A blog post by the Senior TypeScript Program Manager Daniel Rosenwasser sets out the background and reasoning for the proposed type syntax 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.”

the proposalwhich shares authors from Microsoft, Bloomberg, Igalia and a number of other sourcessuggests that JavaScript developers should be able to “add type annotations to their JavaScript code, allowing those annotations to be checked by a type checker external to JavaScript” and then 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.

Until now, types were relegated to TypeScript in part because this build step could also be used to compile code for the various browsers. With the advent of continuous update evergreen browsershowever, 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 necessary step between writing code and running it will be to erase 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, namespacesand parameter propertiesare explicitly excluded “because they have runtime semantics, generating JavaScript code rather than simply being dropped 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.

For many detractors, the argument is that adding types as comments will unnecessarily complicate the code visually and make it more difficult 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.

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, there seems to be a lot of debate, alongside a rather 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 Google Summer of Code (GSoC) 2022the list of mentoring organizations revealed. It adds 32 new organizations, bringing the total to 203 open source projects. the 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 stage, and this week the fallout went continued, as a member of the core Rails team. Kasper Timm Hansen rather abruptly 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 he posted the pull request which simply stated “I’m leaving the Rails core and not interested in being oldies.” There was a fair amount of fanfare when Kasper has joined the Rails core and, if the replies to his tweets and pull requests are any indication, the eleventh most productive Rails contributor it looks like he will be missed by the community as a whole.
  • Embedded software development comes to VS Code: following a similar launch for Visual Studio 2022, Microsoft has published the Built-in Tools extension for Visual Studio Code, which according to the description of the extension “provides a registry viewer for CMSIS-SVD files and an RTOS data viewer with support for Azure RTOS and FreeRTOS.” The extension, used alongside the new vcpkg artifact capabilities which helps in acquiring embedded tool dependencies, allows developers to quickly start an embedded 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.

Sam D. Gomez