You have 1 article left to read this month before you need to register a free LeadDev.com account.
Estimated reading time: 4 minutes
Ask most developers what their favourite programming language is, and JavaScript isn’t likely to be near the top.
As far back as six years ago, Scott Hanselman, vice president of developer community at Microsoft, was saying “JavaScript is not the language we deserve but it is the language we have.” Hanselman told LeadDev that it’s an assessment he stands by today.
The most recent Stack Overflow survey suggests that while 62% of devs use JavaScript, just 58% say they admire it, compared to 82% of Rust users, or 68% with Python.
Now there are efforts to change the narrative. During a meeting of the committee that oversees JavaScript’s specification globally, a group led by Google staff software engineer Shu-yu Guo proposed splitting JavaScript in two, supported by developers from Mozilla, Apple, Moddable, and Sony.
The core version, which the proposal calls JSO, would be implemented by runtime engines, while another variant – called JSSugar – would include more features that require third-party compiling tools to run.
The principle is to try and leave the core JavaScript (or JSO) alone in an effort to reduce complexity and lower the risk of something going wrong. This way, more experimental feature development can happen through tooling and not the core. “Complexity belongs at the edges. Foundational tech ought to be simple,” as the presentation put it.
The engineers proposing this new path forward see it as a pragmatic way of solving issues around reliability and bloat, while keeping the option available for those who want to add elements.
Industry reaction
Not everyone is convinced. Developer LD Hasson is opposed to the idea because it puts more power in the hands of tooling providers like Typescript, Babel, React, and Npm. “The moment the tooling ecosystem blossomed is the moment JS complexity went out of hand,” he wrote on X. “There has to be a tool-less vanilla JS that is competent to address the challenges of app development today.”
Compared to another language like CSS, JavaScript hasn’t split out its core language features and libraries, creating some of the issues developers face today. “I think JavaScript did not do a good job in separating the two,” Hasson told LeadDev.
The reliance on third-party tools also has open source developer Pierre Joye feeling worried. Such a move is “the opposite direction” of what he would like to see from JavaScript, he shared on X. Instead, he wants “a very fast, stable, core standardize[d] language, [and] single runtime standard.”
It’s also a reversal of direction that Joel Moss, a UK-based developer, wouldn’t appreciate. “It’s a step backwards, and more work,” he says.
In recent years the JavaScript community has managed to veer away from needing a build or compilation step. In this new mode, developers would be required to figure out which of the third-party tools would enable everything to work, rather than the language itself just… working, Moss believes.
Changing course?
“I think it’s Google saying, ‘We don’t want to deal with this because it’s more work,’” Moss explains. He believes putting the lion’s share of the work on developers by requiring them to find, then deploy, a build tool, is misguided. “It’s the browser that runs the code at the end of the day,” he says. Google did not immediately respond to a request to comment.
Moss doesn’t blame Google for wanting to implement the change. One of the challenges with JavaScript is that it occupies an odd position of being the only language that’s evergreen. “Any new feature, no matter how big or small, in 99% of cases can’t revert,” he says. JavaScript has to be able to support the websites built 20 or 30 years ago as readily as they can today – which admittedly causes issues. “That’s one of its strengths, but also one of its weaknesses.”
For better or worse, JavaScript has long been valued for its ability to be all things to all people. This gives the developer community a lot of freedom to shape it to their needs, but also creates complexity and stability issues for the browser makers that rely on it most heavily.
Yet it’s a burden that big tech companies can shoulder better than the developer community who would be expected to do so under the proposed plans, according to Moss. Don’t expect this debate to be settled quickly.
