If you had a superpower to make a single change to JavaScript – what would it be?
In a Nutshell
JavaScript's backward compatibility requirement severely restricts language evolution, making meaningful breaking changes impossible without fundamentally changing what JavaScript is. Most developers now write TypeScript rather than JavaScript, but integrating TypeScript directly into browsers faces significant performance barriers due to expensive parsing costs. The speaker sees no compelling value in native TypeScript support since build tools are already required anyway, and alternative type hinting systems would be too different from TypeScript to be worthwhile.
These notes were generated by AI and may contain inaccuracies.
JavaScript is fundamentally an evolution of the same thing that has existed since its inception. The speaker has written websites before CSS existed and remembers when JavaScript started to become a thing. This gives JavaScript a certain vintage that matches the speaker's experience in internet years.
JavaScript has maintained the same fundamental functionality for decades, which has enabled everything written in JavaScript over the last decades to continue working in browsers and wherever it runs. However, this creates a pretty huge burden. The principle of "don't break the web" is a fundamental driving principle of how the language evolves, and it is very restricting in what it allows to be done with the language.
If the speaker could make one change, it would be figuring out a way to do breaking changes into JavaScript in a way that feels comfortable. Getting rid of the restriction of maintaining backward compatibility would be really interesting. However, removing this restriction might be too much of a good thing solution, as JavaScript would no longer really be JavaScript and could become something else entirely.
Most people writing JavaScript these days are probably actually writing TypeScript. Even when the JavaScript being written could theoretically be running directly in a browser or environment, it often isn't, particularly when talking about content going on the web.
In server-side solutions like Node.js, Deno, and other systems where content is loaded from disk, there is less of a performance penalty in requiring many different files in a module tree or having content that is directly the thing written be the thing running. For the web in browsers, which is what runs the front end, there needs to be consideration of what's going on over the wire and optimizations where hardware or systems the client is running on are not controlled.
The active discussion has been about allowing TypeScript content to be executable directly in a browser. One big blocker is that parsing TypeScript is more expensive than parsing JavaScript. If TypeScript content were allowed in JavaScript, browsers would need to do more work to figure out what JavaScript they are supposed to be executing. Even if they can completely continue to ignore the type content, they still need to figure out where the type content is so they can ignore it.
It hasn't even been suggested to support all TypeScript within JavaScript, but more like a subset of TypeScript. Developers would still need to write TypeScript that runs through some processor to ensure it can run wherever intended. Even if in many cases the processor would say the code is completely fine and can let it through as is, there would still need to be a tool in between.
If a tool is needed anyway, why not just remove the types at the build stage where the cost of type parsing and processing can be moved to build-time concern in an environment where clients are not impacted? The speaker doesn't buy the value proposition that incorporating TypeScript into JavaScript at this level brings.
Other parts could be considered, such as theoretically designing a type hinting system into JavaScript that would be different from existing TypeScript, Flow types, and other similar type hinting systems. This could be designed in a way that would be really easy for a runtime implementation to ignore the type content, potentially allowing typing in JavaScript with very low or negligible cost to parsing files. However, it wouldn't be TypeScript.
In the current world where many people are already using TypeScript to write JavaScript, it is normal to expect that running code through a tool is required to make things work in the browser. This makes it very difficult to rationalize making such fundamental changes to JavaScript, which would bring a cost to many places where JavaScript is used without necessarily bringing that much benefit over the systems already being dealt with.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
