What’s Next for JavaScript: New Features to Look Forward to
When you look at the new features going into JavaScript each year through the ECMAScript standards process, it might not always seem that the language is making major changes. A lot of improvements are what TC39 co-chair and head of Bloomberg’s JavaScript Infrastructure and Tooling team Rob Palmer calls “paving the cowpath” — by building something you could already do with a tool or a framework into the language — or syntactic sugar, to make it easier to use an existing feature without making mistakes.
“We see this iteration of tools, frameworks [and] patterns, and over time, we in the standards world start to pick out where the convergence has happened and we try to pave that cowpath, which has the effect of decreasing the complexity in the application stack. So the size of your Node modules directory decreases, because more of that functionality is provided by the language itself.”
Taken with major developments like adding native async in 2017, those incremental features add up, Vercel’s TC39 delegate Justin Ridgewell told the New Stack. “Over a span of years, they add up to a lot of new APIs with new functionality that we’re adding very quickly and then while the smaller things are being added, we’re working on massive features.”
“These massive features, they don’t land every year: maybe every two years, maybe every three years. But when they do get added they really advance the language forward.”
Some significant new features, like Temporal, are almost ready for adoption; and others are in development to arrive in the next few years. We’ve picked some of the most interesting here, as well as asking people involved in building the JavaScript standards to explain how the language is progressing, and what it might make sense for JavaScript standardisation to tackle next.
Types That Don’t Turn JavaScript into TypeScript
TypeScript was developed to make JavaScript developers more productive, rather than to replace JavaScript, but it’s also been a source of improvements to the language. Currently, you use TypeScript to make types explicit in your code while you’re writing it — but then you remove them when your code runs.
Still some way off, the stage 1 Type Annotations proposal for including type information in JavaScript code but having them treated as comments by JavaScript engines is important, because it converges TypeScript and JavaScript for consistency in a way that keeps them aligned, but also makes it clear that they’re working at different layers.
Developers can use first class syntax for types, whether that’s TypeScript or Flow syntax with long JSDoc comment blocks, and know that their code is still compatible with JavaScript engines and JavaScript tooling — avoiding the complexity of needing a build step to erase the types before their code will run, Palmer pointed out.
“There’s huge value just in having static types that only exist during development and are fully erased during runtime,” he explained. Some of that value is obvious: “The fact that you can provide type checking and can tell you when you’ve made a mistake, and you’ve dereferenced a property that doesn’t exist: that’s great. But above and beyond that, the type information also powers a number of quality of life improvements for the developer, like the ability to refactor things — such as renaming variables and properties, all at once just automatically in the IDE, as well as code navigation.”
“If you’re working with a lot of different code that you didn’t write, then it helps to have the type view of it,” suggested Daniel Ehrenberg, vice president of Ecma (parent organization of TC39) and a software engineer working on JavaScript developer experience at Bloomberg.
And again, given how contentious static typing has been in the JavaScript community despite continuing demand from the community (it’s been the top missing feature in the State of JavaScript survey for three years in a row), it’s a testament to the standards process that this approach would bring a hugely useful feature to the language without affecting the simplicity that attracts many users in the first place.
Simplifying Localization with Smarter Message Formats
Localizing websites (and web apps) is more complicated than just swapping out the message strings in the user interface, because if you want those messages to make sense and be grammatically correct, you can’t just swap in words without thinking about how numbers, ordinals (like first and second), dates, plurals and other constructions are handled in different languages.
There are libraries to help with this, like FormatJS, but it’s more work for developers and translators in JavaScript than in other languages like Java and C, where there are built-in capabilities for translating and formatting strings with international Unicode components like ICU4J and ICU4.
“Plurals are really difficult,” Igalia’s Romulo Cintra tells us. “All the grammatical concepts, inflections and depending on gender number, and then different placeholders can vary in different languages; [handling] this complexity normally relies on those libraries, but also requires tons and tons of data.”
In fact, browsers already use those components for internationalization, and for building APIs like date time format and relative time format. So why not bring similar options to the web and have built-in options for JavaScript developers that include that linguistic expertise — after all, it’s the language so many interfaces are written in.
Intl MessageFormat is another stage 1 TC39 proposal, in conjunction with the Unicode Consortium’s Message Format Working Group, for templated strings that include internationalization and localization logic, with a built-in engine in JavaScript for filling in those templates correctly in different languages.
The work to bring internationalization APIs to the web is so comprehensive that it triggered a major update to the 20-year-old ICU message format API. “It only relies on strings, it’s very rigid, not modular — so why not solve the problem from the root and start a new standard on Unicode,” Cintra wondered. That became MessageFormat 2.0 (MF 2.0 for short) which is designed to be a common ground, handling internationalization for software and the web alike, and it underpins Intl MessageFormat, which he views as the most needed international API to help the web reach the next billion users.
“It’s closing the cycle of providing a more accessible web at the level of localization and personalization.”
“To me as a non-native English speaker,” said Cintra, “it’s extremely important as the web grows and everybody has access [to it], having something like this, that puts in our hands the capability of making more accessible all the software we write, is fantastic!”
Currently, a lot of localization relies on mostly proprietary specifications for custom message formats that have to be parsed at runtime. Mozilla uses its Fluent tool to translate all its interfaces: Bloomberg has an internal tool as well, Igalia’s Ujjwal Sharma told us. “Everybody is trying to tackle this problem through custom tooling that does different things.” While Intl MessageFormat will let organizations who are already doing internationalization build on a common standard, with all the usual advantages of open collaboration, Sharma hopes it will also help smaller organizations that don’t yet have a process for translating sites.
Beyond simply translating text strings, MF 2.0 will include metadata and comments that can be used to mark up everything from the tone of the writing — whether it’s formal or informal — to hints for speech synthesis that will be useful for smart speakers like Siri and Alexa as well as screen readers. That could also remove a bottleneck: “A lot of the innovation in speech and interfaces is happening on the client side,” Sharma noted, but the amount of data has made that impractical for localization: “Intl MessageFormat could enable us to do a lot more client-side”.
Localization is a multimillion-dollar industry so balancing compatibility with the necessary improvements is something of a balancing act. “Providing an easy-to-use intuitive API that can still somehow work with all the legacy effort is a challenging task,” Sharma noted. “But I think if we can do it well, then we can really change some things around how people think about websites.”
A Language for Translating Languages
The MF 2.0 spec defines what you can think of as a simple programming language with name binding (“let” declarations) and pattern matching (selectors), explained Igalia’s Tim Chevalier, who is working on the ICU implementation. He suggested thinking of it as “a domain-specific language for writing translatable messages” that can draw on what we know about writing compilers and interpreters.
“Hopefully, the developer experience using MF 2.0 will be less like writing cryptic strings of characters and more like programming in a special-purpose language embedded within their general-purpose language of choice, such as JavaScript.” He compares that to going from hard-coded query strings for working with databases to SQL.
“There was no reliable way to write programs that manipulated the query strings themselves in order to generate variations on a given query, because there was no knowledge about the query language embedded into the general-purpose languages like C++, Java and JavaScript. Modern language tools provide richer ways to construct queries than just writing a string and passing it as an argument to a function.” MF 2.0 promises a similar developer experience.
It’s extensible: developers get an interface to create new abstractions of their own in JavaScript (or other languages) to deliver formatting functions. The spec is also intended to make it easy to write higher-level translation tools that can provide a friendlier user interface to make it easier for translators to work with messages, without having to be programmers themselves.
The ICU work on MF 2.0 is still at an early stage, with a technical preview; initially, that’s only ICU4J but it’s being ported to ICU4C, which is the language used for most JavaScript engines. The TC39 proposal relies on MF 2.0, but “as soon as there is a stable version of Message Format 2 implemented, I think that things on the TC39 side will go smoothly,” Cintra predicted. A stable release will also allow browsers to start implementing the API to see how it works in the wild.
If you want to try this out, FormatJS has early support for the initial IntlMessageFormat proposal and there’s an experimental polyfill under development. Because the polyfill is based on tools that are already widely used for internationalizing React and other applications, it will give developers experience with the new syntax required.
Milestones, but Still Plenty to Do
JavaScript will continue to evolve slowly, Palmer suggested. “Some argue that things should shift faster so that we can get feedback and recognize the importance and iterate; our style in TC39 tends to be more conservative.”
Removing something from the web platform, if it turns out to have been designed the wrong way and needs changing — like the first implementation of web components — has an extremely high cost. Polyfills and tool-based implementations of features that are candidates to become part of the standard allow for the faster feedback cycle that helps protect web compatibility, without making developers wait for all the steps of the formal process.
“I do think it makes sense for JavaScript to be developed conservatively.”
“We have many implementations; we have a lot of usage,” Ehrenberg said. “Other platforms can be these more experimental environments, and we can be the more conservative implementation environment.”
Following that pattern, he said JavaScript now contains natively many of the features that developers used to have to turn to tools for (and some proposals, like iterator helpers, are inspired by other languages).
“When you look at class fields, including private fields and decorators, but also small things like hashbang grammar, and then hopefully soon our type annotations proposal and on-going modules work, they kind of complete the pantheon of things people are doing through tools, that we want to bring into the language,” said Ehrenberg. “CSS is at a similar point, where they’re also bringing in many features that were done through tools into the core language, like nesting — the classic example — or scoping, or layers and variables.”
But standardization also helps minimize the configuration involved in creating your project, by giving developers a clear default for how to set things up; and that inspires new ideas for what JavaScript could come to include. One area that particularly interests Ehrenberg for future consideration: core components for reactive user interfaces, like signals and cells, could perhaps become part of the language; that’s something developers rely on frontend frameworks for today.
That would follow what he calls the same “incremental shared path of discovery” that JavaScript is known for, with experimentation turning into a new baseline for core features that then get built into the language. There’s plenty of scope for the evolution of the language yet, he maintained.
“I think we’re nowhere near yet running out of things to do that are inspired in that direction.”
