https://devclass.com/2024/10/22/should-javascript-be-split-into-two-languages-new-google-driven-proposal-divides-opinion/ Linkedin RSS Twitter Youtube * Newsletter * Archive * The Register * Blocks&Files * The Next Platform Search [ ] DevClassNewsPaperDeveloper News * Newsletter * Archive * The Register * Blocks&Files * The Next Platform * Newsletter * Archive * The Register * Blocks&Files * The Next Platform DevClassDevClassDeveloper News [ ]Search * Home * DevOps * Serverless * Containers * CI/CD * ML/AI Home Development Should JavaScript be split into two languages? New Google-driven proposal divides opinion * Development Should JavaScript be split into two languages? New Google-driven proposal divides opinion By Tim Anderson - October 22, 2024 Facebook Twitter WhatsApp Linkedin ReddIt Email Should JavaScript be split into two languages? New Google-driven proposal divides opinion A Google engineer presented a proposal to the official standardization committee that would split JavaScript into two languages, a core to be implemented by runtime engines and a more capable variant which depends on tools that compile it down to that core. The presentation was at a meeting of Emca TC39 earlier this month, TC39 [https://tc39.es] being the committee of Ecma International that evolves the JavaScript (officially ECMAScript) specifiation. Shu-yu Guo, a staff software engineer at Google who specializes in JITs, VMs, compilers and standardization, made the presentation, with slides that were co-authored by Guo along with others from Mozilla, Apple, Moddable and Sony. Moddable is a company which offers an open source SDK for embedded programming, including the XS JavaScript engine. The authors argue that new language features have a mostly negative impact on users. New features "almost always" worsen security, performance is "neutral to negatively impacted," stability is sometimes worse, and app features are only improved if developers use what is new. JavaScript VMs (virtual machines), they say, are "already very complex because of pressure to be fast," which compromises security, and "feels especially bad" when new features do not get adoption. They cite species, where the MDN web reference for JavaScript already reports that "engine implementers are investigating whether to remove this feature," and BigInt, for large numeric values. Regarding BigInt, the presentation states that "use cases never materialized." The foundational technology of JavaScript should be simple, according to the proposal, because security flaws and the "complexity cost" of the runtimes affects billions of uses, whereas the benefits are restricted to developers and applications that actually use that complexity to advantage. Despite the multiple organizations involved, the initiative seems to be driven by Google to some extent, and one of the slides contains a disclaimer that "this possible solution is Google's preferred solution, not necessarily other implementers'" [jssugar-1024x550]JavaScript developers primarily use compilers according to a new proposal - but some developers want to move away from this model The proposed solution is not to backtrack on existing features, including new ones where proposals are at a late stage, but to change the future approach to one where most new features are implemented in tooling rather than in the JavaScript engines. The language implemented by the engines is called "JS0" while the language implemented by the tooling is "JSSugar"; these names are used to enable discussion and not intended as final. The tooling idea is particularly appropriate for JavaScript since many developers actually code in TypeScript and rely on compilers such as Babel, Webpack or the TypeScript compiler to output JavaScript. From the developer perspective, JavaScript is JSSugar, but the runtime engines need only implement JS0. The implication is that there should be more standards compliance among tools. If adopted, the proposal would mean that future syntax features go into JSSugar, and only API and capability features go into JS0. Compliant engines would only need to support JS0. The burden would shift to tool implementers to support JSSugar, and a side-effect would be that tool implementers would need to be more involved in the standards process and perhaps form a new technical group. The proposal is already controversial. "Please don't grant official status to the current crop of JavaScript tooling ... many JavaScript developers, myself included, would like to rely less on these tools," said one. There is widespread agreement that prioritizing security, performance and stability is a good thing, but the notion of making JavaScript dependent on intermediate tooling is not popular. "RIP Vanilla JS" said another developer. 'Special privileges' for VS Code GitHub Copilot extension show Microsoft's advantage over competitor... Express.js team explain purpose of version 5.00, released after ten years to revive project ecosyste... AWS brings Finch container development to Linux, but it's not so easy to get started StackBlitz Bolt.new blurs boundaries between web development and skilled use of AI prompts VS Code migration to ECMAScript modules 'massively improves startup performance' - but extensions le... Google's Code Assist Enterprise can be trained on internal source code, is focused on Google service... Microsoft previews unified .NET API for AI, and delivers .NET 9 Release Candidate with go-live licen... Ruby on Rails 8.0 first beta release: A big bet on SQLite in production OpenAI previews major update to ChatGPT visual interface for writing and coding Python 3.13 delayed by 'drastic change' removal of incremental garbage collector Why Windows 11 24H2 is a big yawn for developers The SQLite team is preparing an efficient remote replication tool DevClassDevClassDeveloper News ABOUT US DevClass is the news and analysis site covering modern software development issues, from the team behind the Continuous Lifecycle, Serverless Computing and MCubed conferences Contact us: devclass@sitpub.com FOLLOW US Linkedin RSS Twitter Youtube (c) Situation Publishing, 2018-2024 * About * Contribute * Contact * Sales * Privacy * Cookies * Terms & Conditions * Do not sell my personal information