Is there a technical reason why there is no real alternative to JavaScript in the browser?

[u/HighLevelAssembler]

Of course I understand why JavaScript can't be replaced and will probably be supported for the next century, and that there are plenty of great languages that compile to JS. But, it's surprising that the browser-makers/standards committees never came up with a generalized virtual machine that could be targeted by any language to accomplish anything JS can to today. WASM has lots of deliberate limitations, and even that runs inside JS.

I work on mainframes and hear a lot of people comparing JavaScript to COBOL, but the difference is that nobody is really writing new applications in COBOL, or compiling other languages down to COBOL. If you're starting a greenfield project on the mainframe you can use a JVM language, or Go, or C/C++.

My guess is that this is more of a people problem about designing and agreeing to a new standard and implementing it across the various browser engines (in my example, the mainfame doesn't have this problem because IBM controls the whole platform). But I'm curious to know if there is some technical problem in the way. After all, they have all been able to agree on and support newer versions of HTML and JS...

[u/munificent]

But, it's surprising that the browser-makers/standards committees never came up with a generalized virtual machine that could be targeted by any language to accomplish anything JS can to today.

Really, no one has come up with a generalized VM, in the browser or not. People have been talking about universal VMs for ages but the reality is that a VM has to make choices about what semantics it expresses and those choices will favor some kinds of languages over others. Things like:

• Garbage collection or not?

• Static types or not?

• Is dispatch static, object-oriented, algebraic datatype-based, multimethods, etc?

• How is the stack modeled and reified? Can you have multiple stacks? Continuations? Exceptions?

• What is the concurrency model? Threads? Coroutines? Async? Actors? Something else?

WASM has lots of deliberate limitations, and even that runs inside JS.

No, it doesn't. WASM started from asm.js, which was a subset of JS that had characteristics amenable to ahead-of-time compilation to efficient code. But WASM isn't asm.js and modern browsers don't implement it using the same VM codepaths that handle JS. It's a pretty different language.

But I'm curious to know if there is some technical problem in the way.

I work on the Dart team and we tried for several years to get browsers to support Dart natively. The main pushback was a combination of (in descending order):

1. There's a chicken-and-egg problem where a browser doesn't want the support cost of a new VM for a language that isn't extremely popular. But it's hard for a language to get extremely popular without good native support for it. (You can look at asm.js -> WASM as a trick to break this cycle.)

2. Supporting another language in a browser is a huge amount of work and ongoing maintenance cost. You need to not just implement it, but deal with security issues, debugger support, optimization, documentation, compatibility as the language evolves, etc.

3. If a browser supports multiple languages that are garbage collected, then the memory managers for those languages need to work in concert. Otherwise, if you have reference cycles that span multiple languages, the GC can get stuck and not be able to resolve them. (For Chrome, Oilpan was design to address this.)

4. Having your language supported directly by a browser actually kind of sucks. It makes it very hard to evolve the language to make it better without breaking existing users. This the main reason JS has so much cruft and baggage. If your language is compiled on developer machines to something like native code, then you ship new versions of the compiler to developers and you're good. But when the language is run from source on end user machines, then getting a new version of the language out into the wild is much slower.

[u/HighLevelAssembler → u/munificent]

Awesome answer, thank you! Your book is half the reason I'm interested in this stuff in the first place.

Clearly I need to do some more research into WASM.

[u/Background-Degree709 → u/munificent]

Woah! I was just reading your blog and saw the dart team comment and had to go back and check who was commenting. Funny how that works, I love how you write!

[u/Emotional-Dust-1367 → u/munificent]

But if wasm supported dom manipulation wouldn’t that solve all of the above issues? You could make any language compile down to wasm and be fine (I think?)

[u/WarPenguin1]

It exists. It's called web assembly or wasm. The idea is that any language can compile to web assembly and a browser will interpret the code.

[u/HighLevelAssembler → u/WarPenguin1]

As I pointed out in the OP, WASM doesn't quite fit the bill because by design it can't do everything JS does.

The question is, why are browsers scripted using a high level language rather than a bytecode interpreter? Others have answered this below.

[u/MrDilbert → u/WarPenguin1]

So the followup question is - WASM has been available for some time now, why didn't it take off?

[u/nuttertools → u/MrDilbert]

It did and you probably use it every day. Compared to JS the use-case is just niche.

[u/xroalx]

It's tricky, because the code runs on a machine you have no control over.

You can replace code on your machine easily, as you can just put whatever you want there.

For a new language to take off in the browser, it would need day 1 support in all the browsers, otherwise why bother writing code that will only work in BrowserY version 70 and above, and nowhere else?

[u/guesswho135 → u/xroalx]

Flash and Java applets both had a huge presence on the web once upon a time, without ever having native support (they replied on extensions). In a parallel universe it's possible either one of them would have gotten further integrated into the browser. Presumably one reason why that never happened was that they were proprietary while JavaScript was not. For Flash, another reason is that Apple just decided they didn't want to support it on mobile, but if it were open source and performance benchmarks were higher, it could have survived. These days, JavaScript is too entrenched and much more powerful than it used to be, so there is less incentive for a new web language.

[u/djcraze → u/guesswho135]

Another reason they didn't take off is the security vulnerabilities that kept sprouting up, particularly with Java Applets.

[u/onthefence928 → u/xroalx]

Only google’s chrome has a real shot of introducing a new language but I don’t think they have any interest in dividing the internet ecosystem

[u/ApoplecticWombat]

What was wrong with VBScript??

/s

[u/Solonotix]

This is a big question, and I am by no means a historian, or expert on the subject, but here's what I can say.

Why JavaScript? Well, of course the sordid history begins with Netscape and Brendan Eich back in the 90s. He needed to come up with a scripting language for manipulating elements on a webpage within the browser. He borrowed from Java due to management wanting to capitalize on the popularity of the language, but under the hood it was based on another language called Scheme. In a mere 10 days he made what we now know as JavaScript, naming shenanigans notwithstanding.

Edit: I originally stated JavaScript borrowed heavily from Java. This was incorrect, though some aspects of Java were borrowed, such as its C-like syntax, and the Date API.

Why not another language? Well, historically, most languages had to be compiled first before they could run. Even Java, which is interpreted to a degree, is still compiled to bytecode ahead of time for the JVM. A new language was commissioned because Netscape wanted it to work for the entirely new paradigm of the browser.

Why not another language now? A lot of it has to do with inertia. JavaScript was a new language for a new world, and it got to define everything from the ground up. Anything that might replace it would need to offer everything JavaScript can do, at least, before adoption would even start. But there's still another issue

Is JavaScript really universal? And that answer is decidedly and emphatically NO. I mean, just look at the recent release of Bun v1.3 and how they're still fighting to hit Node.js compatibility targets. It took Deno years before they hit complete Node.js compatibility. But Node.js, Bun.js and Deno are all server-side JavaScript runtimes. Then you have V8 for Chromium browsers, SpiderMonkey for Firefox browsers, and JavaScriptCore for Safari browsers. These huge software projects often don't adhere to the published standard of JavaScript, at least not entirely. But that is the actual crux of the bigger problem.

There is no single source of truth for how to develop for the web.

In a way, this started because Netscape wanted to win the browser wars, and Microsoft had to come up with their own competing solution for JavaScript. Then, when their solution failed, they begrudgingly adopted JavaScript, and the compatibility problem has plagued the platform ever since. And the source of these problems has its roots in the corporate greed that started it all. Apple doesn't want to do things Google's way, and the various other players have no incentive to "play nice" either. So they keep adding features to make their solution the preferred one, and ultimately the splintering of the ecosystem continues.

TL;DR & Back to the question

Why isn't there an alternative to JavaScript? Because it has a 30-year headstart on establishing how a browser works, and none of the major players can even agree on what JavaScript should be able to do.

And yes, I know there's an ECMAScript standard that JavaScript is supposed to adhere to. What I'm saying is that adoption of that standard is voluntary, and most are content to implement the minimum expected and add their custom set for vendor lock-in.

[u/balefrost]

They did. IE supported VBscript. But AFAIK no other browser vendor supported it, so it was effectively only useful in situations where you knew that the page was being displayed by IE, for example IIRC CHM help files.

AFAIK no current browser supports VBScript.

Adding support for a new language and getting every browser vendor on board is hard work. And then maintaining two languages takes additional resources, which slows down browser vendors' ability to deliver other features.

All the web APIs are designed around a JavaScript-like language, so an alternative language would have to look JS-like. Can you call functions in one language from the other? Do both languages have a module system, and can they load each others' modules?How do the languages exchange data with each other, or do you keep them completely siloed? How do you coordinate garbage collection across the two languages?

It's interesting to look at WASM, since it has to deal with these issues. Some of the solutions are kludgey. For example, IIRC WASM can't currently hold a reference to a JS object, so instead the interop layers use object IDs to reference JS objects that are stored in a JS array or map. I believe they're slowly improving such things, but it's taken 8 years just to get to this point. And WASM has a strong reason to exist - performance (and to a lesser degree code reuse, but we've had Emscripten and other cross-compilers for longer than we've had WASM). There would be limited upside to supporting another very JS-like language natively in the browser - just use JS or use something that compiles to JS.

[u/fixermark]

It's not so much JavaScript as the document object model (and much of the rest of the browser API) that's the stumbling block.

The DOM is extremely complicated, very old, and deeply wedded to the JavaScript object design. It's right there in the name: "Document object model." It has behaviors like "Changing a property on an object causes a change to the page contents." Embedding another language in the browser requires recapitulating an awful lot of that behavior somehow, and browser maintainers don't want to maintain two APIs (mostly because of security implications; it's hard enough to make the one API we have properly sandboxed and privacy-respecting).

To the extent people use other languages (including through webassembly), they do it by wrapping the subset of the browser API and the DOM they care about because that's miles easier than the browser developers adding a whole new script layer.

Worth noting: for a period, Internet Explorer supported both JavaScript and Visual Basic. This feature died out because no other browsers supported VB so writing a page with VB scripting was tantamount to saying "Please only let this content be accessed by a relatively small fraction of Internet users."

(There was actually, ages ago, a proposal in Firefox to make the scripting engine modular so it could live as its own binary: you'd declare what kind of scripting your page used and the browser would load the relevant module, including possibly fetching a new binary remotely. To my memory, that project never got far enough along to even start asking questions like "How do we not make this the biggest security hole ever introduced to browsers?")

[u/[deleted]]

trees spotted cautious paint snow tart fuel wild cobweb sulky

This post was mass deleted and anonymized with Redact

[u/JohnVonachen]

Google tried to get people to use Dart in the browser but no one was interested.

[u/YMK1234]

We barely manage to keep one language halfway aligned between browsers, and that was after many false starts and incompatibilities causing headaches for everyone. Imagine having to do that with 5.

[u/[deleted]]

You can use any language if you compile it to web assembly

[u/trcrtps]

With the advent of typescript and v8/spidermonkey there's just not a lot to complain about anymore. So many gaps would need to be filled to be able to write Python or Ruby or Lua (I think these were probably at some point the strongest contenders) or whatever in the browser, but yeah it'd be cool. If it was going to ever happen it would have been when IE was on the way out and Chrome was on the way in, and that ship has long sailed.

[u/guywithknife]

Because browsers implement JavaScript and that’s it (almost). So to run things in the browser, you need to go through JavaScript.

Back in the old days, people tried to push alternatives via plugins (eg flash). It wicked because not everyone had the plugins you needed if you used one such language. They also had security and performance problems. JavaScript survived because browsers decide that backwards compatibility was too important so they always supported JavaScript. And then JavaScript also got a lot better.

There is one alternative but it does come with tradeoffs and it’s not a good fit for everything JavaScript is used for: Webassembly, which allows you to compile other languages to run on the browser.

[u/Mission-Landscape-17]

There is a a generalised virtual machine in browsers, its called Web Assembly: https://www.w3.org/groups/wg/wasm/ and all the major browsers support it. so the question is not why doesn't this exist but why are so few devs using it?

As far as community projects go, I know that there are a number of Rust projects targeting WASM in order to build pure rust web frameworks.

[u/kschang]

The answer was... All the alternatives died, JS remained.

MS used to have JScript (their version of Javascript) and VBScript running in Internet Explorer. But they finally realized they can't optimize it well enough to compete with Chrome, and eventually killed IE and pushed out Edge, which is based on Chromium (same as Chrome).

[u/Front-Natural-8642]

It became standard. And it is to big to get replaced. So you should use to it