I'd argue that other languages did this (or something similar) to great success, most notably Java.
That is, the Hotspot VM was such a phenomenal engine that lots of other languages sprung up to take advantage of that: Closure, Scala, Kotlin, etc.: https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with the Java language itself, syntactic changes happen much more frequently than VM-level bytecode changes.
With an interpreted language like JavaScript, the dividing line is a little grayer, because the shippable code isn't bytecode, it's still just text. But it still seems to make sense to me to target a a "core", directly interpretable language, and then let all the syntactic sugar be precompiled down to that (especially since most JS devs have a compilation step now anyway). Heck, we basically already did this with asm.js, the precursor to WebAssembly.
It seems to me that wasm should just support the web/browser API instead of the current trampoline business; this way, JS build tooling can emit wasm files, which is similar to the example you use.
asm.js came about because it was a very optimizable subset of JavaScript, then it was superseded by WebAssembly, then the proposal in TFA is basically asking for asm.js back, but perhaps the better answer is to make WebAssembly fully support all of what JS could originally do.
This is perhaps why as I get older I sometimes feel like I want to get out of software development and become a goose farmer like that dude on LinkedIn - lots of times feels more like spiraling in circles than actually advancing.
I think it’s much harder to make big leaps as a community with languages and other - relative to the technology stack as a whole - lower level concerns.
Look at the stronghold grip of C/C++ and how long it’s taken Rust to gain a meaningful foothold in those realms for example.
Google wanted to flat replace JS once already, that was the entire origin of Dart. They only pivoted to the cross platform mobile framework as its primary target after it failed to gain traction as a standard
PNaCL was essentially "let's shove LLVM into every browser and make it a mandatory part of the web", which somehow seems even worse than "let's shove the JVM into every browser and make it a mandatory part of web"
Given Google's power a decade later, with Safari left as the only non-Chrome clone with market relevance, it hardly makes a difference.
Additionally we already have LLVM all over the place, alongside JVM and CLR, it is the most deployed compiler infrastructure with contributions at the same level as the Linux kernel.
They wanted to implement a typing system first so they could transfer complex types with a strict contract first, as large parts of DOM management would benefit enormously from that, and it would be far better to design an API around. This system has been stuck in different iterations for years.
Because it's already solved from day one and people keep repeating that it's a problem anyways.
Anything you can do in JavaScript, including access to the DOM, can be put into a JavaScript function. You can import that function into a WebAssembly Module, and you can use WebAssembly Memory to transfer large or complicated data as an efficient side channel. It all works.
Could you link an ergonomic example? I have cemented in my memory that DOM access in WebAssembly is not trivial and I suspect others too.
This is what StackOverflow tells me (2020):
> Unfortunately, the DOM can only be accessed within the browser's main JavaScript thread. Service Workers, Web Workers, and Web Assembly modules would not have DOM access. The closest manipulation you'll get from WASM is to manipulate state objects that are passed to and rendered by the main thread with state-based UI components like Preact/React.
> JSON serialization is most often used to pass state with postMessage() or Broadcast Channels. Bitpacking or binary objects could be used with Transferrable ArrayBuffers for more performant messages that avoid the JSON serialization/deserialization overhead.
This feels like "we can have DOM access at home" meme.
Web Workers can't directly access the DOM in JavaScript either. This is not a WebAssembly problem. If you want a Web Worker to manipulate your document, you're going to post events back and forth to the main thread, and Web Assembly could call imported functions to do that too.
I don't even know what he's on about with Preact/React...
Save the following as "ergonomic.html" and you'll see that WebAssembly is manipulating the DOM.
That `easy(arg)` function could do much more elaborate things, and you could pass lots of data in and out using the memory export.
I'd like to believe a simple standalone example like this would be enough to get people to shutup about the DOM thing, but I know better. It'll be the same people who think you need to link with all of SDL in an Emscripten project in order to draw a line on a canvas.
> This feels like "we can have DOM access at home" meme.
And I'm sure somebody (maybe you) will try to move the goal posts and claim some other meme applies.
> I don't even know what he's on about with Preact/React...
Around 10 years ago, I was having lunch in a food court and overheard "Luckily I don't have to use javascript, just jquery".
Around 5 years ago, a co-worker admitted he still had issues distinguishing what functionality was python and what came from Django (web framework), despite having used them both daily for years. He thought it was because he learned both at the same time.
I wouldn't be surprised if this was more of the same, and just getting worse as we pile more and more abstractions on top.
Thanks for confirming that WebAssembly still cannot manipulate DOM in 2024.
It can only call custom javascript functions that manipulate DOM AND I need to write some arcane function signature language for every DOM manipulating function I want to call.
I'll give another 4 years and see if they fixed this.
Thanks for your simple concrete examples and explanations!
You can lead a horse to water, but you can't make it drink. Funny how he touts his ignorance of WebAssembly by describing the WebAssembly Text Format that he does not recognize for what it obviously is as "some arcane function signature language". ;)
So arcane that it's just a standard s-expression syntax that you can manipulate and process and generate in any Lisp-like language (like Racket, mentioned below)!
If you'd like to see some beautifully hand written WebAssembly Text Format code that implements a Forth compiler/interpreter that uses dynamic linking to dynamically compile and run the Forth words it interactively compiles, and also uses Racket as a macro pre-processor, check out WAForth:
DonHopkins on Jan 13, 2023 | parent | context | favorite | on: What the hell is Forth? (2019)
This is a great article! I love his description of Forth as "a weird backwards lisp with no parentheses".
Reading the source code of "WAForth" (Forth for WebAssembly) really helped me learn about how WebAssembly works deep down, from the ground up.
It demonstrates the first step of what the article says about bootstrapping a Forth system, and it has some beautiful hand written WebAssembly code implementing the primitives and even the compiler and JavaScript interop plumbing. We discussed the possibility of developing a metacompiler in the reddit discussion.
I posted this stuff about WAForth and a link to a reddit discussion with its author in the hn discussion of "Ten influential programming languages (2020)":
It's a lovingly crafted and hand written in well commented WebAssembly code, using Racket as a WebAssembly macro pre-processor.
I learned so much about WebAssembly by reading this and the supporting JavaScript plumbing.
The amazing thing is that the FORTH compiler dynamically compiles FORTH words into WebAssembly byte codes, and creates lots of tiny little WebAssembly modules dynamically that can call each other, by calling back to JavaScript to dynamically create and link modules, which it links together in the same memory and symbol address space on the fly! A real eye opener to me that it was possible to do that kind of stuff with dynamically generated WebAssembly code! It has many exciting and useful applications in other languages than FORTH, too.
Lots more discussion and links in the reddit article.
If you can't be bothered to install VS Code, you can have a look at a standalone version of the example notebook (in a 26kB self-contained page).
And if you're planning to go to FOSDEM 2023, come say hi: I'll be giving a talk there on WebAssembly and Forth in the Declarative and Minimalistic Computing devroom.
DonHopkins:
I really love your tour-de-force design and implementation of WAForth, and I have learned a lot about WebAssembly by reading it. Never before have I seen such beautiful meticulously hand written and commented WebAssembly code.
Especially the compiler and runtime plumbing you've implemented that dynamically assembles bytecode and creates WebAssembly modules for every FORTH word definition, by calling back to JavaScript code that pulls the binary bytecode of compiled FORTH words out of memory and creates a new module with it pointing to the same function table and memory.
WebAssembly is a well designed open standard that's taking over the world in a good way, and it also runs efficiently not just in most browsers and mobile smartphones and pads, but also on the desktop, servers, cloud edge nodes, and embedded devices. And those are perfect target environments for FORTH!
What you've done with FORTH and WebAssembly is original, brilliant, audacious, and eye-opening!
I'd read the WebAssembly spec before, and used and studied the Unity3D WebAssembly runtime and compiler to integrate Unity3D with JavaScript, and I also studied the AssemblyScript subset of TypeScript targeting WebAssembly and its runtime, and also Aaron Turner's awesome wasmboy WebAssembly GameBoy emulator .
I first saw your project a few years ago and linked to it in this Hacker News discussion about Thoughts on Forth Programming because I thought it was cool, but it's come a long way in three years, and I'm glad I finally took the time to read some of your code, which was well worth the investment of time.
Until reading your code, I didn't grasp that it was possible to integrate WebAssembly with JavaScript like that, and use it to dynamically generate code the way you have!
Also, the way you used Racket as a macro assembler for WebAssembly was a practical and beautiful solution to the difficult problem of writing maintainable WebAssembly code by hand.
Even for people not planning on using FORTH, WAForth is an enlightening and useful example for learning about WebAssembly and its runtime, and a solid proof of concept that it's possible to dynamically generate and run WebAssembly code on the fly, and integrate a whole bunch of tiny little WebAssembly modules together.
Playing with and reading through your well commented code has really helped me understand WebAssembly and TypeScript and the surface between them at a much deeper level. Thank you for implementing and sharing it, and continuing to improve it too!
remco:
Wow, thanks a lot, I really appreciate that! It makes me very happy that I was able to get someone to learn something about WebAssembly by reading the source code, which is exactly what I was going for.
[More links and discussion of WAForth, WebAssembly, and Forth Metacompilers:]
> Thanks for your simple concrete examples and explanations!
I'm glad someone liked it :-)
> I love his description of Forth as "a weird backwards lisp with no parentheses"
I've been interested in that duality between Forth and Lisp before, but my progression always seems to following this path:
- Since Forth is just Lisp done backwards and without parens, and since it's not hard to write an sexpr parser, I might as well do Lisp to check the arity on function calls.
- But in addition to arity errors, I'd really like the compiler to catch my type errors too.
- And since I've never seen an attractive syntax for Lisp with types, I might as well have a real grammar...
And then I've talked myself out of Forth and Lisp! Oh well.
They’re already moving it that way, it’s not like it isn’t without complexities and such either. WASM isn’t the silver bullet everyone seems to cling to.
I feel like the WASM fervor has more to do with the fact people don’t enjoy using Frontend tools or JavaScript etc. vs looking at the actual utility tradeoffs
You're two library functions away from having it easy:
Copy from JavaScript to WebAssembly:
Use TextEncoder to convert a JS String to Uint8Array
Copy the bytes from the Uint8Array to WemAssembly.Memory
Copy from WebAssembly to JavaScript:
Copy the bytes from WebAssembly.Memory into a Uint8Array
Use TextDecoder to convert from Uint8Array to JS String
JS Strings are pretty much always going to be "rope data structures". Trying to provide anything other than copy-in and copy-out is going to expose implementation details that are complicated as fuck and not portable between browsers.
"the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call"
I guess the more elegant and universal stringref proposal is DEAD now !?
We don’t yet have consensus on this proposal in the Wasm standardization group, and we may never reach there, although I think it’s still possible. As I understand them, the objections are two-fold:
WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8).
The requirement to support fast WTF-16 code unit access will mean that we are effectively standardizing JavaScript strings.
I really like stringref and hope the detractors can be convinced of its usefulness. Dealing with strings is not fun right now.
And dealing with strings isn't fun in many other languages or runtimes or OSes.
e.g.1. C# "Strings in .NET are stored using UTF-16 encoding. UTF-8 is the standard for Web protocols and other important libraries. Beginning in C# 11, you can add the u8 suffix to a string literal to specify UTF-8 encoding. UTF-8 literals are stored as ReadOnlySpan<byte> objects" - https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
e.g.2. Erlang/BEAM/Elixir: "The Erlang string type is implemented as a single-linked-list of unicode code points. That is, if we write “Hello” in the language, this is represented as [$H, $e, $l, $l, $o]". The overhead of this representation is massive. Each Cons-cell use 8 bytes for the code point and 8 bytes for the pointer to the next value. This means that the 5-byte ASCII-representation of “Hello” is 5*16 = 80 bytes in the Erlang representation." - https://medium.com/@jlouis666/erlang-string-handling-7588daa...
> The Erlang string type is implemented as a single-linked-list
This refers just to Erlang's string() type, not BEAM strings in general; it's just a bad default. If you're not using binaries, you're doing it wrong, and that's exactly why Elixir's strings are UTF-8 binaries.
Thank you for the links. To the extent I understood it from a quick reading, it all looks like stuff you could get with the existing import/export mechanisms. I would choose (modified) UTF-8, but I understand why UCS16 is always going to be around.
I agree about keeping wasm bytecode cleaner. The core plus simd stuff is such a great generalization of the ARM and X86 CPUs we mostly use. The idea of gunking it all up with DOM related stuff is distasteful.
It supports nearly arbitrary imports of anything you want. How much more flexibility do you need? You could provide an `eval` function to run arbitrary code with a small amount of effort.
Is the problem that Emscripten and/or Rust haven't laid it all out on a platter?
- a bytecode "language" that roughly corresponds to Javascript semantics, and that is what the engines interpret (and JIT compile)
- browsers still include a compiler to compile JS sourcecode to the bytecode. Possibly wasm could work, although it would need a lot more functionality, like native support for GC, and DOM access, etc.
- browsers include a disassmbler/decompiler to improve debugging the bytecode
Then simple sites, and development can use plain JS source, but for higher performance you can just deploy the pre-compiled bytecode.
I am certain this would mainly add problems while not improving performance as websites would just add more stuff on top until it's again on a barely tolerable level, for both the user and the developer who know probably has to manage yet another super simple, blazingly fast tool to keep everything running.
The problem is within that gray area. For enjoyers of vanilla js, like myself, I'd hate it if "core" js got so small that I now started to require a compiler for my ES6 code. If I was in charge I'd say "fine, but the core must be at least as large as ES6" and I'd reserve the right to tweak browser native modules in minor ways (for example, it would be nice to support a SPA syntax where you could export/import modules from within the same page without either a) hacking the global object or b) generating unnecessary resources).
1) JavaScript, the original assembly language of the internet, does not need new language features.
2) JavaScript, the front-end web development language is a fractal of infinitely many sub-languages that transpile back to ES5.
The proposal, as I read it, is: Let's stop adding front-end web features to the assembly language; it doesn't get easier, better or faster if we change the underlying, slowly adopting and hard-to-optimize foundation.
When you want a new language feature, add it to the fractal part that transpiles back to the part well-supported and highly optimized in existing runtimes. The only loss is that you need to transpile, so your build pipeline becomes non-trivial. But it's either "code assembly" or "get a modern build tool".
This isn’t really true on a practical level any more. ES6 support is very widespread (97% of all web users according to caniuse.) That even includes module import syntax!
There are still some new language features that need to be transpiled, but most projects do not need to worry about transpiling cost/let/arrow functions/etc.
I mean even newer features like nullish coalescing and optional chaining are at 93-94% support.
At the end of the day, I would say tools like babel for transpiling are less and less important. Yes, you still use a bundler because the web has a lot of runtime constraints other native applications don’t have (gotta ship a tiny bundle so the page loads fast), but it’s better for the language features to be implemented in the VM and not just faked with more JS.
> 3% of people is a lot of people to cut off if your JavaScript is essential
These are probably the 3% that won’t affect your business much. They’re more likely to be on older hardware and also have less discretionary income. Or browsing on really weird hardware that is also unlikely to lead to a sale.
People with "less discretionary income" still deserve to access the web in a way that isn't broken. This might come as a surprise nowadays, but the web can be useful for more than just selling things.
Did they solve GC and DOM access ? It's been years since it was "just about to happen" and I stopped paying attention in the meantime. But if it had that I agree - it would be ideal if JS was a legacy thing and a saner WASM first class language got to replace it.
Keep the single threaded event loop approach but kill the JS semantics.
Wasm GC is shipped in stable releases of all major browsers except for Safari but that will be changing shortly if it hasn't already (my info is a few weeks old.) The important thing to note about Wasm is that all important functionality, such as access to I/O and the DOM, have to arrive in the form of host imports to a Wasm module. With this in mind, thanks to Wasm GC it is possible to do web UIs from Wasm by importing the relevant bits of the DOM API that the module needs. Projects like Hoot (Scheme) and Kotlin port are already demoing such things.
> Projects like Hoot (Scheme) and Kotlin port are already demoing such things.
And Scala.js has shipped it. [1] Although technically experimental, it has no known bugs and it has full support of things like manipulating DOM objects from Scala.js-on-Wasm code.
The problem is that they promised that the WasmGC would include the much desired access to JavaScript objects but now this crucial aspect is no longer part of it and postponed again.
Actually I don't want DOM access and GC for wasm. At least not yet. It overcomplicates a lot and I simply cannot imagine that a GC can be one-size-fits-all languages.
I want fixed-size buffer-backed structs for JS. Basically a DataView as a C struct. This would massively benefit interop and solve some shortcomings of DataView.
There was a proposal for a binary AST for JS several years ago [1]. Why not just use that as JS0? It's separate and can offer new possibilities as well.
good point. in a sense webassembly is that minimal very performant language. let javascript and typescript compile to webassembly, and you essentially got what is being proposed here
All imports have to come from the host, which in the case of the web means they have to be expressed as JavaScript. Behind the scenes they could be optimized, though, and I've heard that JS/Wasm engines maybe already be doing this with well-known imports (think Math.sin).
Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most.
Providing access to an already proven DOM would be the better solution.
> And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application.
The download isn't much different to a typical website. That Flutter demo in wasm is 2 megabytes.
Uno Platform's WebAssembly implementation uses the DOM rather than drawing to canvas: https://platform.uno/
Uno's philosophy is to use platform native controls. The benefit is that you get platform native characteristics, the cost is it will never be exactly the same in each browser and platform.
What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?
So throwing out literally 99% of what makes the web actually portable and useful?
A random drawn rectangle is not a UI, it’s not accessible, not inspectable, not part of the de facto OS native toolkit.
If all we wanted is a random cross-platform canvas element to draw onto from a vm, it could be solved in a weekend. There are million examples of that.
Can you give an example of anything anywhere that manipulates the DOM without using JavaScript? Because it seems to me that pretty much every web application is currently using the javascript host, and the well written ones are pretty snappy.
this is going beyond my level of experience, but i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM, which is slower. how much slower, i don't know. i also don't know how old that discussion is where i learned about this. so maybe it improved since. that would be good news.
did you mean there are snappy webapplications running in WASM? if you have any examples, i'd be curiuos to learn more.
> i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM
That doesn't have to be true.
Eventually WASM will get direct access to the full browser API, without going through JavaScript.
The browser exposes a browser API to the JavaScript VM it hosts, so things like the DOM are available.
Those things aren't available in other JavaScript VMs, like Node. (There's no DOM to interact with.)
And they're not yet available in the WASM VM in the browser, either.
The reason is that the WASM APIs/ABIs have not stabilised. It takes time to make right, but there is progress.
Eventually WASM will get direct access to the full browser API, without going through JavaScript.
well, that is what i am waiting for. my point is that it's not the case yet, while the gp seemed to suggest that it's not needed because access through the host is available
A fundamental aspect of the Wasm capability security model is that all access to the outside world (I/O) is controlled via imports. Direct access to the entire browser API doesn't make sense in this context.
> [...] go through the javascript host, which is slow
And now you admit:
> this is going beyond my level of experience [...]
> how much slower, i don't know
I guess people just repeat what they hear without questioning or understanding it, and then it becomes dogma.
> did you mean there are snappy webapplications running in WASM?
No. I meant that all existing web apps go through the "javascript host", using JavaScript. So if any of them are fast enough, and some certainly are, the problem isn't the "javascript host".
The DOM itself is very slow, much slower than Javascript, so you're not going to be seeing any great performance increase if WASM can access the DOM directly.
I also have to wonder if people are excited about replacing Javascript, why they would want to have HTML/CSS/DOM on top of WASM. A different front-end UI tech could be much better than slow, old DOM.
I commented this elsewhere, but the funny thing is that asm.js was the precursor to WebAssembly, and this proposal is essentially asking for asm.js back again.
Yes and no, there is a significant bundle size problem with wasm which is hard to fix.
I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications.
What's more likely is that all of this will probably be eclipsed by LLM and virtual assistants - which could be controlled by native apps with a dynamically generated GUI or voice.
I think APIs exposing data and executing functions will fundamentally change what we think the web is.
Not that please. The flutter example took 20 seconds to load and the scroll is super choppy.
It’s unfortunate there isn’t a more native “app like” UI toolkit. Especially on mobile, web apps generally are bad and a lot of the reason is trying to shoehorn an app experience onto the dom.
It loads fast for me in Firefox, MS Edge, and Chrome. It's a 2 megabyte transfer and runs quickly.
If you're using Safari it's true that Safari's WebAssembly implementation is behind the other browsers. But that's a Safari problem more than a WebAssembly problem.
Throwing out the baby with the bath water? There are millions of standardized APIs available in the browser that would be probably impossible to recreate in anything else due to failing consensus.
Assembly is not a language runtime. Even if you had WebAssembly as the core, you'd still need to compile JavaScript to WebAssembly, manage the GC, etc which all would still suffer from the performance implications mentioned in the article.
Also... do you really think its wise to rewrite v8 to target WebAssembly?
Amazon has been migrating its Prime Video app from JavaScript to WebAssembly. They're compiling Rust to WebAssembly and they've seen increased performance and lower memory usage:
Still spreading your JS hate from thread to thread I see.
> WebAssembly enables you to use any language. And when you can use any language, why would you use JavaScript?
In which context? I'm doing Kotlin/Java/Rust/C++ for a day job and I'd rather die than use any of those instead of JS for my hobby/exploratory projects.
The amount of bullshit I have to deal with in those languages from tooling to languages themselves is astonishing.
Well this person is not the only one who thinks js (and web stuff in general) is terrible. I mostly dislike the pace of crapification; I comment almost daily on repositories asking why they made that breaking change with zero benefits for the user. Usually 'we are cleaning up' or so; there are npms that really need never be changed that are changing weekly just because 'keep them fresh'. That kind of misery is just weird and frankly depressing; update something one week after writing and plop, it breaks. For No Reason as no improvements were made, just breakage for the sake of upping the date on github and npm (the most terrible I find the VC backed open source ones; I guess they have to update all the time for the sake of the VCs looking in even though no updates are required). I use lisp, c++ and go libraries that haven't been updated in 10 years; guess what; they work and work well and stable for another decade because they really never need anything new and people are not vying for update kudos or whatever.
But you can use vanilla js you say? Yes it is true, but I find js very terrible and I want to write things in common lisp, or, if need be, Go. Neither of these require any bullshit with tooling or anything hard. You can learn enough Go in a few hours to be productive (like C) and llms are super at it (unlike js/ts where they produce things that had breaking updates 40 times since the llm knowledge cut off for no reason at all). With vugu framework you don't need to touch js either. Common lisp is also not hard to learn, bit harder but even better tooling and you don't need to know all of it to write nice stuff; there is the clog framework which is basically all you need to get going as it is an ide, web dev environment and you get away with writing almost no js.
Then you add capability to hide the browser chrome and build close to native user experience and we will have truly looped the loop. Think about that: the browser as an intermediation ensuring resources are properly shared and each application is shielded from the others. Everything that’s old is new again. /s
On a serious note I don’t see the point in turning browsers into an OS on top of the OS. I know it’s some kind of Google wet dream so they can suck up even more data than they already do but still. If you want to ship applications, just do that. The sandboxing should be done at the OS level where it belongs.
I was in your camp, but we truly lost. Almost everyone I know literally ONLY uses a browser for everything. On mobile some things force you app use, but if that weren't the case, people would use it from a browser. Games in browsers, movies, email, anything. So it makes sense to only open a browser in an OS; it is basically what users do anyway.
> Regarding BigInt, the presentation states that “use cases never materialized.”
Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend).
Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one, e.g. in the browser console. Develop the language instead of tons of incompatible tools.
That part caught my attention too. It reminds me of the discussion to remove complex numbers from Go. Funny enough, compiler writers can't even imagine why you would want BigInt or Complex, because those aren't useful for writing compilers.
The problem with Google compiler developers is that they will do a search of the google3 repository, find no uses (because Google doesn’t do any advanced math, for example) and declare the language feature to be useless.
Which is ironic because I use Google Sheets a lot and occasionally run into problems when it doesn't support BigInt calculations. Sheets is the best excuse Google has for keeping BigInt support in the language.
one contributor to the pike programming language when asked why he took the effort to optimize syntactic sugar responded: so that pike users can write simple code and still have it run blazingly fast.
in pike, bigint and int are integrated in such a way that the transition is automatic. there is no overflow but as long as the values fit in an int, that is used internally to keep the code fast.
Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats.
This is where you say something about "exact" vs "inexact" as though that will hand wave it away.
> This is where you say something about "exact" vs "inexact" as though that will hand wave it away.
I'm not familiar with this debate, but how is that a hand wave? The article describes a reasonable-sounding way to extend the tower with a second dimension of precision. Following those rules, you would never just convert between bigint and float, but an expression involving both would output a float.
You gotta read between the lines with the commenter above. Their name is a reference to "Smug Lisp Weeny", and they're part of the religion (cult) that thinks everything in Lisp (usually Common Lisp) is perfect. He couldn't care less about Pike, except as an excuse to be smug about Lisp.
Besides his nick, was he smug? He just noted that Lisp(likes) solve this problem for some version of 'solve' with the numerical tower. The implementations don't (usually; I am not aware of any) mix exact and inexact as that would be foolish obviously.
I used LPC a long time ago on an LP Mud, so Pike has always had a fond spot in the back of my mind, even if I don't use it now.
However, that works for int and bigint, but Number (double precision) can represent numbers that BigInt can not, and BigInt can represent numbers which Number can not. There isn't a graceful way to automatically promote/degrade one to the other in all cases, and a silent conversion will do the wrong thing in many cases.
heh, yeah, that's where i started too. i don't know how or even if LPC did it, but in pike the transition really is seamless. give it a try. as a naive user i can't even tell the difference (you can see it though if you compare typeof(1) vs typeof(20000000000000000000) (i hope that number is big enough))
This stood out to me as well. Proper decimal type would be my #1 missing language feature, seconded by a standardized runtime implementation of the same.
Sounds like the presenters are assuming that everyone must be using JS in the same way they are. As someone who prefers to work in VanillaJS, I'm already frustrated by all the language changes being forced upon me.
So maybe I agree with them that fewer changes should be made, but for completely different reasons.
I'd rather them work on API improvements so that web apps get closer to parity with native apps. All this other talk is pointless while web apps remain second class IMO
What do you mean forced upon you? There is no requirement for you to use new features. If you do, it’s because you or your team thinks it’s more convenient — and it really is! map, filter, arrow functions, scope improvements with const/let, etc. are major language improvements. So is null coalescing and optional chaining. You don’t have to use them, but they do make JS more straightforward to work with.
As a dabbler in JS, it jumps out to me that a lot of tools are trying to force ESM, despite the fact that they lack many essential features that other module systems have.
I think the proposal is actually good for people like you.
You can choose to just work with the core and maybe a minimal sugar library. Which will probably be faster and don't include "all the language features that were forced upon you".
This is also a result of the detachment of TC39 and the developer community. Just how many JS developers are participating TC39? I can recall multiple TC39 proposals that didn't even consult opinions from authors of notable open-source stakeholder libraries, and went straight into stage 3.
And btw, the TypeScript tooling scene is far from being able to get standardized. TypeScript is basically a Microsoft thing, and we don't see a single non-official TypeScript tool can do type-checking. And there's no plan to port the official tools to a faster language like Rust. And the tsc is not designed for doing tranditional compiler optimizations. The TypeScript team made it clear that the goal of tsc is to only produce idiomatic JavaScript.
Imagine Google not having the resources to maintain their V8 engine after the hiring downturn, and telling us they want to change JavaScript because their V8 engine has become challenging to maintain.
A proposal rooted in attempts to improve the language would be one thing. This appears to be about Google struggling with technical competencies and not having the budget to do the right thing.
“A Google engineer presented … 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.“
“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.”
Maybe try something besides c++ for V8 if you are having security issues?
The apathy towards proper tail calls in V8 leads me to distrust Google’s language proposals. But now that abdication appears to possibly have been a canary? Perhaps even prior to the pandemic they couldn’t keep up with maintaining the V8 C++ codebase, and that’s why PTCs got skipped?
Are there debuggers that can single step over the transpiled bits so that it feels like the methods are implemented natively? Otherwise, it becomes a mess.
With the right debugging tools, transpiled alternatives to JavaScript are easier to debug than vanilla ES5.
For example: TypeScript's sourceMap [1], Elm's time-travelling debugger [2], Vue.js DevTools [3], just to name a few I've tried. Especially well-typed languages tend to behave well at run-time once they pass type-checking. Or rather, I have not made enough front-end code to discover transpiler bugs.
Because debugging better languages affords you more context and more tooling.
Elm's debugger lets you step forwards and backwards in the application's state.
TypeScript's type system lets you catch bugs before you run the code.
Vue.js's DevTools extend the browser's with a component-based overview, so you can interactively see what's going on at a high level of abstraction. (I'm sure something similar exists for most frameworks similar to Vue.js, and possibly even frameworks made in vanilla ES5, I'm just picking one I've tried.)
I started with your position (vanilla js 4ever!) and after being dragged into the world of transpilation via typescript/eslint/prettier/webpack/babel/etc I do agree that it’s at least as easy. Not sure about “easier” but my debugging needs are not exotic. The painful part is initially setting up the toolchain.
You wouldn’t see much difference as a user of those tools. And if you’re writing vanilla JS, you’d have less features creeping in over time. So it seems like you would benefit from this kind of change.
Who cares? If backwards compatability is maintained then this fails to have any impact on my experience as a developer. It sounds like the VM maintainers are busy making their own lives hell. Not my problem.
I do. Maybe if someone programs in one language it's okay for them to keep up with language changes, but if you have to constantly juggle multiple languages it becomes a real chore to stay up to date with every one of them.
I use the language. The existence of new language features has not forced me to adopt them. The standard library for browsers is a different story but it is always going to be.
Thankfully.. both maintain reasonable backwards compatability where security is not otherwise implicated.
Fuck, no. Everyone's free to make better tooling, but don't standardize it. There's no point. It'll only lead to further fragmentation. Libraries and frameworks will be split between plain JS and whatever this new version will be called. Just freeze the language and be done.
Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself? i.e. if implementing them directly as new language features doesn't make sense, then preprocess them away before executing the scripts. You could even do this for past features that made it into ECMAScript but haven't turned out to be useful, instead of ossifying a specific moment in time's tooling.
> Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself?
I think if it was that simple, it would be done that way already (maybe it is, for some features). Two big arguments for doing the "desugaring" offline are the (1) speed, and (2) security of the browser. Those two things also conflict somewhat if addressed on the client, since faster but more complex compiler code increases the surface area for potential exploits.
But if you do this compile step offline, you don't need to worry about compromising the performance or security of the browser.
Why wouldn't you take the complexity and performance hit involved once at buildtime rather than offloading it to the client at runtime?
If you read the original slides from the proposers, they're presenting a framing where there is an inherent tension between "serving the user" and "helping the developer". They argue that there is too much of the latter, and that a formalized splitting should push more to the former.
From an end-user perspective, it definitely makes more sense that the js doesn't have to be transformed locally before it can interpreted. I think your suggestion is not compatible with the motivations of the proposal.
If there’s still going to be a standard JSSugar, yes, seems like it should be desugared in the runtime. On the other hand, if we want to make it easier to fragment the high-level language into incompatible sugared versions, this seems like the way to go. (Hard to believe that would be the TC’s goal.)
> features to be implemented as a desugaring step in the runtime itself
The problem is distributing the runtime(s). By having developers transpile to a small core, anyone can freely invent new language features without waiting for the rest of the internet to download support for them.
The problem expressed is fundamentally correct, but the proposed solution is a band-aid, which is worse than not solving the problem at all. The fix provides a long term change with short term benefits. Reliance on tooling will continue to make code instances are the progressively larger and slower until we arrive at this problem again. At some point JavaScript must become a professional language written by adults, people capable of self-organization and measurement, and not be the subject of fashion by people who aren't qualified to program in the first place.
If the goal really is higher performance and lower complexity the most desirable solution is to create a new language with forced simplicity directly in the image of JavaScript, where simple means less and not easy, and transition to that new language slowly over time. Yes, I understand Google went down this road in the past with Dart, but Dart solved for all the wrong problems and thus was dead on arrival. Instead the idea is to take something that works well and shave off all the bullshit reducing it down to the smallest possible thing.
Forced simplicity means absolutely ignoring all vanity/stylistic concerns and instead only focusing on fewer ways of doing things. As an example consider a language that requires strong typing like TypeScript and thus thereby eliminates type coercion. Another example is operators that have a single purpose (not overloaded), single character, and no redundant operators.
Will there be a lot of crying about vanity bullshit... yes, absolutely. Just ignore it because, you cannot reasonably expect to drive above 120mph on a child's tricycle. If people wish to offer their own stylistic considerations they should include performance metrics and explanations how their suggestions reduce quantity of operations without unnecessary abstraction.
No word about Actionscript 3 (ECMAScript 4) here? It compiled to the ActionScript Virtual Machine 2 as bytecode. Everybody was happy. And then, Steve Jobs came around the corner and damned it with a single magical curse. Too bad.
I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't understand why it needed to be reinvented from scratch and why it needs to be so limited. We could already be writing web code in Rust, Java, C#, Python, and heck even Haskell, if we had just done that. I know that I'm skipping over the engineering effort required to make this happen but I get a sense that the engineering effort is not the stumbling block. I want to know the details of what is.
My guess is that none of those bytecode VMs were designed with the explicit goal of running untrusted code at global scale in a rock-solid sandbox.
If anything, I expect those existing VMs to slowly be replaced by WebAssembly due to how crucial and complicated that very specific sandbox requirement is - and how useful that is once you have it working reliably.
Personally I never want to run untrusted code on any of my computers outside of a robust sandbox. I look forward to a future where every application I might install runs in a sandbox that I can trust.
"Secure Java" is something I recall hearing decades ago. No idea if it still exists.
The more important thing to consider, however, is the fact that CLR, JVM, etc. provide internal memory safety whereas Wasm runtimes don't.
e.g. a C program that goes sufficiently out of bounds on an array is guaranteed to segfault in the C runtime, but that runtime error does not necessarily occur on a wasm target. That is to say, the program in the sandbox can have totally strange runtime behavior -- still, defined behavior according to wasm -- although the program has undefined behavior in the source language. In the case of JVM languages, this can't really happen.
SecurityManager? Java's current direction (using the word "integrity" rather than "security", but seems relevant) looks interesting to me https://news.ycombinator.com/item?id=41520246
> As told in JavaScript: The First Twenty Years, Brenden Eich joined Netscape in April 1995.
> [..]
> However, Eich didn’t think he’d have to write a new language from scratch. There were existing options available — such as the research language, Scheme, or a Unix-based language like Perl or Python. So when he joined, Eich “was expecting to implement Scheme in the browser.” But the increasingly fractious politics of the software companies of the day (it was, basically, everyone against Microsoft) soon saw the project take a more creative turn.
> On 23 May 1995, Sun Microsystems launched a new programming language into the world: Java. As part of the launch, Netscape announced that it would license Java for use in the browser. This was all well and good, but Java didn’t really fit the bill for the web. Java is a general-purpose programming language that promised Write Once, Run Anywhere (WORA) functionality, but it was too complicated for web designers and other non-programmers to use. So Netscape decided it needed a scripting language, which was a trendy term at the time for a smaller, easier to learn programming language.
There's a whole lot more interesting stuff but I think that part directly answers most of what you're wondering.
They were.
Lots of reasons why it turned out how it turned out. Basically a local minimum in the gradient descent.
Computers were much slower is one reason. JVM wasn't open source at the time is another. NIH is another 100 reasons.
They had to build a verifier that attempts to ensure the bytecode isn't doing anything bad. That proved to be fairly difficult, and comes at a considerable cost.
But it's not as if security concerns are specific to the Web. Look at the vulnerabilities found in CPUs over the last decade or so. Security is necessary no matter what the delivery medium, so I don't see why this is a rationale for reinventing the wheel.
I mostly don’t mind JavaScript only thing for me is number data type and no int. The other part that is annoying is lack of standard library so we get left-pad crap.
A core requirement of WebAssembly was that (ignoring I/O for the moment and considering only the computational core) you should be able to run arbitrary existing code on it, and the effort involved in getting it working should be comparable to porting to a new architecture, not to a new programming language. What this particularly meant, in practice, was that it needed to be a good compilation target for C and C++, since most code is written either in those languages or in interpreted languages whose interpreters are written in those languages. (It also needs to support languages that's not true of, like Go, Rust, and Swift, but once you've got C and C++, those languages don't pose major additional conceptual difficulties.)
The JVM and CLR are poor compilation targets for C and C++, because those languages weren't designed to target those runtimes and those runtimes weren't designed to run those languages. (C++/CLI isn't C++.) It's possible to get something working, and a few people have tried, but you run into a lot of impedance mismatches and compatibility issues. I think you would see people run into a lot more problems trying to get their code running on the JVM or CLR than they in fact run into trying to get it running on WebAssembly. (Though I think the CLR is less bad about this than the JVM.)
As for the idea of using LLVM bitcode as an interchange format, we don't have to guess how that would have gone, because it was actually tried! Google implemented this in Chrome and called it PNaCl, and some sites and extensions relied on it for a while. They ultimately withdrew it in favor of WebAssembly. I don't understand all the reasons why it failed, but I think part of the problem is that it ran into a bunch of "the spec is whatever LLVM happens to do" type issues that were real problems for would-be toolchain authors and made the other browser vendors (including Apple, LLVM's de facto primary corporate sponsor) reluctant to support it. WebAssembly has a relatively short and simple standard that you can actually read; writing a WebAssembly interpreter is an undergraduate exercise, though of course writing a highly performant one is much more work.
Also, as far as I can tell, LLVM hasn't at all been optimized to death for the use case of runtime code generation, where the speed of the compiler is about as important as that of the generated code. The biggest dynamic language I know that uses LLVM is Julia, which is a decently big deal, but the overwhelming majority of LLVM usage is for ahead-of-time compilation of languages like C, C++, Swift, and Rust.
On a bigger-picture note, I'm not sure I at all understand why adopting an existing bytecode language would have made things easier. Yes, it would have been much easier to reuse existing Java code if the JVM had been adopted, or to reuse existing C# code if the CLR had been adopted, but those options are mutually exclusive; the goal was something that would work at least okay for all the languages. Python doesn't have a stable bytecode format, and Rust and Haskell compile to LLVM bitcode (which LLVM has no problem lowering to WebAssembly since WebAssembly was designed to make that straightforward), so I don't see how those languages are in any way disadvantaged by the choice of WebAssembly as the target bytecode language instead of some alternative.
Or are your concerns about I/O? That's a bigger can of worms, and you'd need to explain how you imagine this would work, but the short version is that reusing the interfaces that existing OSes provided would not have worked well, because the browser has a different (and in many ways better) security model.
This is not true. CIL could be an excellent compilation target for C++ and was quite literally made with that in mind. C# was inspired as much by C++ as it was by Java. And CLR back then was made with consideration of C++/CLI, which exists even today. You can't effectively express C++ code with JVM bytecode, you absolutely can with CIL. You can even express most of Rust's generics with CIL nowadays, retaining monomorphization, save for zero-sized structs and other edge cases.
What disqualifies "the JVM" (usually referring to HotSpot implementations) from being considered open source? Are you talking about OpenJ9 or something else?
NIH and CIL is probably an ultra-overkill for browser-based scenarios. It implements a complex type system with all sorts of high-level features that significantly complicate the runtime/compiler. It makes it drastically easier to target but not to write an implementation.
I'm not a huge fan of WASM but it's easy to see that the authors would clearly not want to leave control in the hands of Microsoft or Oracle (and as a result all of us are hostages to Google instead because of evil that is Chromium).
Java is as open-source as it gets (it’s reference implementation, OpenJDK, has the same license as the linux kernel)
And it was used by some browsers, there was just no consensus between different vendors due to politics. The problem largely solved itself by.. only one vendor remaining, chromium.
Hell yes. I've been advocating for this for years. From an engine-implementer perspective, full-fledged JavaScript is just too hard to make both fast and secure.
One of the examples given makes sense, since Symbol.specie messes with prototypical inheritance and is likely hard to secure as a result because that touches so much of JS as a whole.
BigInt failing to materialize I think has more to do with ergonomics around it, they’re a bit unwieldy and there aren’t able to be used with the built in Math object functions.
They also have zero JSON support out of the box which is a huge miss.
Honestly it should have been roadmapped to replace the built in Number type
Can't replace Number with BigInt as BigInt is orders of magnitude slower on certain operations. Try to do bitwise operations with BigInt, you'll see what I mean.
absolutely - one for the great minds to play with while running in great circles and one that passes https://jslint.com and is allowed to be on the internet.
I think I understand the argument but this sounds like it would make things worse. The argument that new features almost always make the language worse doesn’t hold true from my perspective as a developer. (I could imagine the perspective of a language implementor being very different.)
I like that JavaScript now has modules/imports, destructuring, Proxies, async/await, etc. These were all new features at one point, But yeah, why did Symbol.species get in? Seems like it’s to enable some odd subclassing pattern? I’m an anti-OOP zealot, so my hot take would be that maybe OOP subclassing is unnecessarily complex already, so stuff like that shouldn’t make it in. We got the OOP syntactic sugar, which is enough. Stop there.
How much of the extra complexity is from stuff like that that is rarely used? Maybe we just need to be a lot more conservative about what makes it in, but stopping changes and forcing everything into more tooling complexity is not the direction I’d like to go in. We need to reduce tooling, not increase it.
I'm a little annoyed that they said Bigint uses cases never materialized. I've used it several times and it isn't something that's easy to transpile. A bigint class has bad ergonomics and there's no way the perf can be equivalent.
It's a good idea, but a better idea would be to make the browser a virtual machine running wasm. HTML, SVG and everything else could be implemented in wasm, and loaded from the cloud as needed.
> It's a good idea, but a better idea would be to make the browser a virtual machine running wasm. HTML, SVG and everything else could be implemented in wasm, and loaded from the cloud as needed.
So now a huge swaths of use cases are going to be killed by this change. E.g. AdBlock, NewPipe and yt-dlp - how is that better? All of them (expect maybe AdBlock) rely on parsing incoming JS from YouTube which will be rendered obsolete by WebAssembly blob.
WASM is slower than running JavaScript on V8 in almost all scenarios and will likely continue to be for a very long time. Also, many of us don’t want a compile step.
While I don't want any compile step either (js should stay), I'm actually confused by your statement.. are there any benchmarks? Are you saying that for example v86 would run faster without wasm?
I think that would probably fall outside the norm. My information might be outdated, but I was under the impression that JavaScript usually wins in most algorithm benchmarks because the JIT is so good.
The US government needs to fast track breaking up Google asap. Chrome needs to be torn from their festering lich hands, so that the web can be free of their self serving, and frankly bad, proposals.
Out of curiosity, which of the fragments of Google would you expect to take ownership over that codebase?
I had always imagined that if the DoJ took any action it would be to cleave the ad business away from Google. Although if they went so far as to take action against GCP I bet Amazon, Amazon Marketplace, and AWS would start to get sweaty palms
All this championing Javascript as a single language for front and back end work, now to be split for different use cases. Hopefully this is how Javascript dies if that is the route Google pushes it.
There is already too much exhaustion around switching frameworks and paradigms in the JS world, but I guess everyone likes getting jerked around by corpos and evangelists these days.
I’m really tired of this discourse. The JavaScript ecosystem is the lingua franca of the web. Furthermore, while a segment of the programming community has sat around complaining, JavaScript has gotten really good and continues to improve every passing year. Incremental progress is the key to making progress, not giant paradigm shifts.
We’ve run React for almost a decade now and the only major parts we’ve swapped have been react build with Vite. Angular has been even more stable since the switch to TS. As far as the frontend frameworks themselves changing massively, that’s a different story, but it’s not like C# didn’t go from Windows .Net to Core/Framework to cross platform .Net, and so on for different language frameworks.
On the Backend there are very few issues, outside of FFI only being in unstable for Deno I suppose, but you could frankly be running the same old Express API you did a decade ago and be perfectly fine.
If you’re burnt out on changes and keeping up with things I think the issue is mostly a “you” issue. You don’t have to chase down the latest hypes or fads. In fact I think you almost never should.
I’m not chasing down hypes and fads, the new product person who wants to make a splash by rewriting the core app does.
This is an incredibly disingenuous response. You maybe like the world this way. It doesn’t mean there isn’t room for change or improvement away from Javascript.
> What's wrong with VanillaJS?
Absolutely nothing, we all love it, and we also love things built upon that foundation, like TypeScript. But it's optional, and that's a good thing that some people miss to recognize. Therefore, they seek more standardization that 'should be enforced' by your Big Brand's top used product (ie. browser).
My point is that "framework fatigue" is a self-inflicted problem. Nobody forces you to use flavor of the week, VanillaJS and bog standard HTML/CSS are always there for you.
Work in a publicly traded company where people are moving things around for promotions sake. Then you’ll see how forced you are to use the latest flavor of the week. People absolutely do force you.
It’s not just the flavor of the week frameworks, it’s libraries and best practices. Want to work with dates? Do you use moment? Nope that’s deprecated, what do you use? Which moment successor? How do you write react? Classes or functions? You can’t use hooks with classes, so you better update to functions. On and on you run into a decision tree because of the shifting target of javascript. It causes a lot of churn to be migrating and updating to new systems, especially when the new hire can’t help because they don’t understand prototypal inheritance.
I don't understand the problem? If v8 wants to split into frontend (sugar, transpiled) and backend language (es5 + few things probably; runtime engine proper), they can just do it, no?
If this happened then JavaScript would be split into 20+ languages, one for each popular compiler. There would be nothing stopping a tool maker from adding their favorite language features even if no other compiler ever adopted them. That would be a disaster.
In many ways this has already started happening. TS has enums, Svelte has runes, React has jsx. None of these features exist in JS, they are all compile-time syntax sugar.
While it is admittedly confusing to have all these different flavors of JS, I don’t think this proposal is actually as radical as it seems.
Outside of browsers this is already how it works. Nothing is stopping LLVM versus GCC from adding their favorite language features, but it's not a disaster.
> 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.
After watching it evolve for many years my conclusion is either politics or it being run by the wrong people who think they literally need to invent the whole world (in component model) before they can give us basic string objects. No, wasm string objects were an independent feature in experimental Chrome for a while but they got removed again. Wasm structs are beautiful without the component model but useless because they can't be read or written in JS.
"ECMA TC39", not "Emca TC39". Also, looks like a bad markup link for TC39. Also note that it's either "co-authored by Mozilla, Apple, Moddable and Sony" or "authored by Guo along with others from Mozilla, Apple, Moddable and Sony", but directly related to that statement, that makes this "not a Google proposal" but clearly an "industry proposal" if it has Mozilla and Apple buy-in.
Also, "the proposed solution is not to backtrack on existing features" makes very little sense. If you're going to split something into core and "compiles down to core", then a LOT of features can be moved out of core because they're just (definitely worth keeping, but not necessary in core if that split were made) convenience APIs.
> 1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.
No, it won't be faster, if you only optimize a lesser language. If you have higher level code running your optimizer can do more than if it only has a low level version.
No, it won't be more secure. Js0 might be more secure, but if we sites all run any of dozens of different tools those tools are going to be creating the vulnerabilities. It's shifting where security issues occur, and creating more of them.
I'm terrified this could happen. JS has gotten so much better over time. We are so close to being able to not need transpilers. This sounds like such an absurd cop out for browsers to say, meh, we just don't want to do the work to implement. Being so close & then saying, sorry, you must use big toolchains to develop for the web is a monstrously bad future.
I'd argue that other languages did this (or something similar) to great success, most notably Java.
That is, the Hotspot VM was such a phenomenal engine that lots of other languages sprung up to take advantage of that: Closure, Scala, Kotlin, etc.: https://en.m.wikipedia.org/wiki/List_of_JVM_languages . Even with the Java language itself, syntactic changes happen much more frequently than VM-level bytecode changes.
With an interpreted language like JavaScript, the dividing line is a little grayer, because the shippable code isn't bytecode, it's still just text. But it still seems to make sense to me to target a a "core", directly interpretable language, and then let all the syntactic sugar be precompiled down to that (especially since most JS devs have a compilation step now anyway). Heck, we basically already did this with asm.js, the precursor to WebAssembly.
It seems to me that wasm should just support the web/browser API instead of the current trampoline business; this way, JS build tooling can emit wasm files, which is similar to the example you use.
What's old is new again :)
asm.js came about because it was a very optimizable subset of JavaScript, then it was superseded by WebAssembly, then the proposal in TFA is basically asking for asm.js back, but perhaps the better answer is to make WebAssembly fully support all of what JS could originally do.
This is perhaps why as I get older I sometimes feel like I want to get out of software development and become a goose farmer like that dude on LinkedIn - lots of times feels more like spiraling in circles than actually advancing.
I think it’s much harder to make big leaps as a community with languages and other - relative to the technology stack as a whole - lower level concerns.
Look at the stronghold grip of C/C++ and how long it’s taken Rust to gain a meaningful foothold in those realms for example.
Google wanted to flat replace JS once already, that was the entire origin of Dart. They only pivoted to the cross platform mobile framework as its primary target after it failed to gain traction as a standard
Actually in regards to Dart it is a more subtle.
Dartium was cancelled and AdWords team, having just migrated from GWT to AngularDart, saved the Dart team.
Eventually many left the team.
Somewhere at Google, Flutter started and when they decided to replace JavaScript on their original design, they decided to reach out to the Dart team.
So Dart got a new purpose in life, being Flutter's language.
In this process it was rebooted from dynamic language, into a static type one, having JIT and AOT toolchains.
How long Flutter, and by association Dart, remain relevant remains to be seen.
Dart is a better designed language in many regards.
asm.js came about because Mozzilla refused to adopt PNaCL, which is kind of ironic given the existing Firefox market share a decade later.
PNaCL was essentially "let's shove LLVM into every browser and make it a mandatory part of the web", which somehow seems even worse than "let's shove the JVM into every browser and make it a mandatory part of web"
Given Google's power a decade later, with Safari left as the only non-Chrome clone with market relevance, it hardly makes a difference.
Additionally we already have LLVM all over the place, alongside JVM and CLR, it is the most deployed compiler infrastructure with contributions at the same level as the Linux kernel.
>"let's shove the JVM into every browser and make it a mandatory part of web"
Javagator / Jazilla!
https://www.cnet.com/tech/tech-industry/javagator-down-not-o...
I’ve been hearing about access to DOM APIs from WASM for years now. Does anyone know why this is such a difficult problem?
They wanted to implement a typing system first so they could transfer complex types with a strict contract first, as large parts of DOM management would benefit enormously from that, and it would be far better to design an API around. This system has been stuck in different iterations for years.
The current active proposal for it is the Component Model: https://component-model.bytecodealliance.org/design/why-comp....
Because it's already solved from day one and people keep repeating that it's a problem anyways.
Anything you can do in JavaScript, including access to the DOM, can be put into a JavaScript function. You can import that function into a WebAssembly Module, and you can use WebAssembly Memory to transfer large or complicated data as an efficient side channel. It all works.
Could you link an ergonomic example? I have cemented in my memory that DOM access in WebAssembly is not trivial and I suspect others too.
This is what StackOverflow tells me (2020):
> Unfortunately, the DOM can only be accessed within the browser's main JavaScript thread. Service Workers, Web Workers, and Web Assembly modules would not have DOM access. The closest manipulation you'll get from WASM is to manipulate state objects that are passed to and rendered by the main thread with state-based UI components like Preact/React.
> JSON serialization is most often used to pass state with postMessage() or Broadcast Channels. Bitpacking or binary objects could be used with Transferrable ArrayBuffers for more performant messages that avoid the JSON serialization/deserialization overhead.
This feels like "we can have DOM access at home" meme.
> This is what StackOverflow tells me (2020)
Web Workers can't directly access the DOM in JavaScript either. This is not a WebAssembly problem. If you want a Web Worker to manipulate your document, you're going to post events back and forth to the main thread, and Web Assembly could call imported functions to do that too.
I don't even know what he's on about with Preact/React...
Save the following as "ergonomic.html" and you'll see that WebAssembly is manipulating the DOM.
That `easy(arg)` function could do much more elaborate things, and you could pass lots of data in and out using the memory export.I'd like to believe a simple standalone example like this would be enough to get people to shutup about the DOM thing, but I know better. It'll be the same people who think you need to link with all of SDL in an Emscripten project in order to draw a line on a canvas.
> This feels like "we can have DOM access at home" meme.
And I'm sure somebody (maybe you) will try to move the goal posts and claim some other meme applies.
> I don't even know what he's on about with Preact/React...
Around 10 years ago, I was having lunch in a food court and overheard "Luckily I don't have to use javascript, just jquery".
Around 5 years ago, a co-worker admitted he still had issues distinguishing what functionality was python and what came from Django (web framework), despite having used them both daily for years. He thought it was because he learned both at the same time.
I wouldn't be surprised if this was more of the same, and just getting worse as we pile more and more abstractions on top.
Is this sarcasm I might be missing?
Thanks for confirming that WebAssembly still cannot manipulate DOM in 2024.
It can only call custom javascript functions that manipulate DOM AND I need to write some arcane function signature language for every DOM manipulating function I want to call.
I'll give another 4 years and see if they fixed this.
> I need to write some arcane function signature language for every DOM manipulating function
You really don't know that you can create WebAssembly in other languages?!? I used WAT to keep the example short, but that's clearly lost on you.
> I'll give another 4 years and see if they fixed this.
In that time, there are lot of things you could be learning. Embracing ignorance and belligerence isn't like to serve you well in the long term.
Thanks for your simple concrete examples and explanations!
You can lead a horse to water, but you can't make it drink. Funny how he touts his ignorance of WebAssembly by describing the WebAssembly Text Format that he does not recognize for what it obviously is as "some arcane function signature language". ;)
So arcane that it's just a standard s-expression syntax that you can manipulate and process and generate in any Lisp-like language (like Racket, mentioned below)!
If you'd like to see some beautifully hand written WebAssembly Text Format code that implements a Forth compiler/interpreter that uses dynamic linking to dynamically compile and run the Forth words it interactively compiles, and also uses Racket as a macro pre-processor, check out WAForth:
https://news.ycombinator.com/item?id=34374057
DonHopkins on Jan 13, 2023 | parent | context | favorite | on: What the hell is Forth? (2019)
This is a great article! I love his description of Forth as "a weird backwards lisp with no parentheses". Reading the source code of "WAForth" (Forth for WebAssembly) really helped me learn about how WebAssembly works deep down, from the ground up.
It demonstrates the first step of what the article says about bootstrapping a Forth system, and it has some beautiful hand written WebAssembly code implementing the primitives and even the compiler and JavaScript interop plumbing. We discussed the possibility of developing a metacompiler in the reddit discussion.
I posted this stuff about WAForth and a link to a reddit discussion with its author in the hn discussion of "Ten influential programming languages (2020)":
https://news.ycombinator.com/item?id=34056735
Yes, I agree FORTH should be probably be on the list, at least if the list was a few languages longer, for as influential as it's been.
WAForth for WebAssembly is beautiful and modern!
https://github.com/remko/waforth
It's a lovingly crafted and hand written in well commented WebAssembly code, using Racket as a WebAssembly macro pre-processor.
I learned so much about WebAssembly by reading this and the supporting JavaScript plumbing.
The amazing thing is that the FORTH compiler dynamically compiles FORTH words into WebAssembly byte codes, and creates lots of tiny little WebAssembly modules dynamically that can call each other, by calling back to JavaScript to dynamically create and link modules, which it links together in the same memory and symbol address space on the fly! A real eye opener to me that it was possible to do that kind of stuff with dynamically generated WebAssembly code! It has many exciting and useful applications in other languages than FORTH, too.
Lots more discussion and links in the reddit article.
But here's the beef, jump right in:
https://github.com/remko/waforth/blob/master/src/waforth.wat
Reddit /r/Forth discussion of WAForth:
https://www.reddit.com/r/Forth/comments/zmb4eb/waforth_wasmb...
remko:
Author here
If you can't be bothered to install VS Code, you can have a look at a standalone version of the example notebook (in a 26kB self-contained page).
And if you're planning to go to FOSDEM 2023, come say hi: I'll be giving a talk there on WebAssembly and Forth in the Declarative and Minimalistic Computing devroom.
DonHopkins:
I really love your tour-de-force design and implementation of WAForth, and I have learned a lot about WebAssembly by reading it. Never before have I seen such beautiful meticulously hand written and commented WebAssembly code.
Especially the compiler and runtime plumbing you've implemented that dynamically assembles bytecode and creates WebAssembly modules for every FORTH word definition, by calling back to JavaScript code that pulls the binary bytecode of compiled FORTH words out of memory and creates a new module with it pointing to the same function table and memory.
WebAssembly is a well designed open standard that's taking over the world in a good way, and it also runs efficiently not just in most browsers and mobile smartphones and pads, but also on the desktop, servers, cloud edge nodes, and embedded devices. And those are perfect target environments for FORTH!
What you've done with FORTH and WebAssembly is original, brilliant, audacious, and eye-opening!
I'd read the WebAssembly spec before, and used and studied the Unity3D WebAssembly runtime and compiler to integrate Unity3D with JavaScript, and I also studied the AssemblyScript subset of TypeScript targeting WebAssembly and its runtime, and also Aaron Turner's awesome wasmboy WebAssembly GameBoy emulator .
I first saw your project a few years ago and linked to it in this Hacker News discussion about Thoughts on Forth Programming because I thought it was cool, but it's come a long way in three years, and I'm glad I finally took the time to read some of your code, which was well worth the investment of time.
Until reading your code, I didn't grasp that it was possible to integrate WebAssembly with JavaScript like that, and use it to dynamically generate code the way you have!
Also, the way you used Racket as a macro assembler for WebAssembly was a practical and beautiful solution to the difficult problem of writing maintainable WebAssembly code by hand.
Even for people not planning on using FORTH, WAForth is an enlightening and useful example for learning about WebAssembly and its runtime, and a solid proof of concept that it's possible to dynamically generate and run WebAssembly code on the fly, and integrate a whole bunch of tiny little WebAssembly modules together.
Playing with and reading through your well commented code has really helped me understand WebAssembly and TypeScript and the surface between them at a much deeper level. Thank you for implementing and sharing it, and continuing to improve it too!
remco:
Wow, thanks a lot, I really appreciate that! It makes me very happy that I was able to get someone to learn something about WebAssembly by reading the source code, which is exactly what I was going for.
[More links and discussion of WAForth, WebAssembly, and Forth Metacompilers:]
https://www.reddit.com/r/Forth/comments/zmb4eb/waforth_wasmb...
DonHopkins on Jan 13, 2023 [–]
Here's the author's blog post about WAForth:
A Dynamic Forth Compiler for WebAssembly
https://el-tramo.be/blog/waforth/
> Thanks for your simple concrete examples and explanations!
I'm glad someone liked it :-)
> I love his description of Forth as "a weird backwards lisp with no parentheses"
I've been interested in that duality between Forth and Lisp before, but my progression always seems to following this path:
- Since Forth is just Lisp done backwards and without parens, and since it's not hard to write an sexpr parser, I might as well do Lisp to check the arity on function calls.
- But in addition to arity errors, I'd really like the compiler to catch my type errors too.
- And since I've never seen an attractive syntax for Lisp with types, I might as well have a real grammar...
And then I've talked myself out of Forth and Lisp! Oh well.
They’re already moving it that way, it’s not like it isn’t without complexities and such either. WASM isn’t the silver bullet everyone seems to cling to.
I feel like the WASM fervor has more to do with the fact people don’t enjoy using Frontend tools or JavaScript etc. vs looking at the actual utility tradeoffs
You're two library functions away from having it easy:
JS Strings are pretty much always going to be "rope data structures". Trying to provide anything other than copy-in and copy-out is going to expose implementation details that are complicated as fuck and not portable between browsers.From the new official WASM proposal:
https://github.com/WebAssembly/js-string-builtins/blob/main/...
"the overhead of importing glue code is prohibitive for primitives such as String, ArrayBuffer, RegExp, Map, and BigInt where the desired overhead of operations is a tight sequence of inline instructions, not an indirect function call"
I guess the more elegant and universal stringref proposal is DEAD now !?
https://github.com/WebAssembly/stringref/blob/main/proposals...
I don't really mind, as it keeps the wasm bytecode cleaner.
Quote from https://wingolog.org/archives/2023/10/19/requiem-for-a-strin...
I really like stringref and hope the detractors can be convinced of its usefulness. Dealing with strings is not fun right now.> Dealing with strings is not fun right now.
And dealing with strings isn't fun in many other languages or runtimes or OSes.
e.g.1. C# "Strings in .NET are stored using UTF-16 encoding. UTF-8 is the standard for Web protocols and other important libraries. Beginning in C# 11, you can add the u8 suffix to a string literal to specify UTF-8 encoding. UTF-8 literals are stored as ReadOnlySpan<byte> objects" - https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
e.g.2. Erlang/BEAM/Elixir: "The Erlang string type is implemented as a single-linked-list of unicode code points. That is, if we write “Hello” in the language, this is represented as [$H, $e, $l, $l, $o]". The overhead of this representation is massive. Each Cons-cell use 8 bytes for the code point and 8 bytes for the pointer to the next value. This means that the 5-byte ASCII-representation of “Hello” is 5*16 = 80 bytes in the Erlang representation." - https://medium.com/@jlouis666/erlang-string-handling-7588daa...
> The Erlang string type is implemented as a single-linked-list
This refers just to Erlang's string() type, not BEAM strings in general; it's just a bad default. If you're not using binaries, you're doing it wrong, and that's exactly why Elixir's strings are UTF-8 binaries.
Okay? Is this an argument in favor of doing nothing?
Thank you for the links. To the extent I understood it from a quick reading, it all looks like stuff you could get with the existing import/export mechanisms. I would choose (modified) UTF-8, but I understand why UCS16 is always going to be around.
I agree about keeping wasm bytecode cleaner. The core plus simd stuff is such a great generalization of the ARM and X86 CPUs we mostly use. The idea of gunking it all up with DOM related stuff is distasteful.
"trampoline business"?
It supports nearly arbitrary imports of anything you want. How much more flexibility do you need? You could provide an `eval` function to run arbitrary code with a small amount of effort.
Is the problem that Emscripten and/or Rust haven't laid it all out on a platter?
> because the shippable code isn't bytecode,
But what if it was?
What I would like to see is:
- a bytecode "language" that roughly corresponds to Javascript semantics, and that is what the engines interpret (and JIT compile)
- browsers still include a compiler to compile JS sourcecode to the bytecode. Possibly wasm could work, although it would need a lot more functionality, like native support for GC, and DOM access, etc.
- browsers include a disassmbler/decompiler to improve debugging the bytecode
Then simple sites, and development can use plain JS source, but for higher performance you can just deploy the pre-compiled bytecode.
I am certain this would mainly add problems while not improving performance as websites would just add more stuff on top until it's again on a barely tolerable level, for both the user and the developer who know probably has to manage yet another super simple, blazingly fast tool to keep everything running.
The BEAM VM (Erlang, Elixir) does this with what’s called "Core Erlang", used as lower-level targets before compiling to the BEAM primitives.
https://blog.stenmans.org/theBeamBook/#_compiler_pass_core_e...
The problem is within that gray area. For enjoyers of vanilla js, like myself, I'd hate it if "core" js got so small that I now started to require a compiler for my ES6 code. If I was in charge I'd say "fine, but the core must be at least as large as ES6" and I'd reserve the right to tweak browser native modules in minor ways (for example, it would be nice to support a SPA syntax where you could export/import modules from within the same page without either a) hacking the global object or b) generating unnecessary resources).
The vanilla js APIs are so atrocious that we got jquery.
JavaScript is two languages:
1) JavaScript, the original assembly language of the internet, does not need new language features.
2) JavaScript, the front-end web development language is a fractal of infinitely many sub-languages that transpile back to ES5.
The proposal, as I read it, is: Let's stop adding front-end web features to the assembly language; it doesn't get easier, better or faster if we change the underlying, slowly adopting and hard-to-optimize foundation.
When you want a new language feature, add it to the fractal part that transpiles back to the part well-supported and highly optimized in existing runtimes. The only loss is that you need to transpile, so your build pipeline becomes non-trivial. But it's either "code assembly" or "get a modern build tool".
This isn’t really true on a practical level any more. ES6 support is very widespread (97% of all web users according to caniuse.) That even includes module import syntax!
There are still some new language features that need to be transpiled, but most projects do not need to worry about transpiling cost/let/arrow functions/etc.
I mean even newer features like nullish coalescing and optional chaining are at 93-94% support.
At the end of the day, I would say tools like babel for transpiling are less and less important. Yes, you still use a bundler because the web has a lot of runtime constraints other native applications don’t have (gotta ship a tiny bundle so the page loads fast), but it’s better for the language features to be implemented in the VM and not just faked with more JS.
Interesting.
I did assess the ES6 coverage of ~97% a month ago.
I just evaluated that while it sounds high, 3% of people is a lot of people to cut off if your JavaScript is essential.
E.g. Firefox sits at ~2.7% browser market share. (Not incidentally the part that doesn't support ES6, but it's a demography the size of my own.)
> 3% of people is a lot of people to cut off if your JavaScript is essential
These are probably the 3% that won’t affect your business much. They’re more likely to be on older hardware and also have less discretionary income. Or browsing on really weird hardware that is also unlikely to lead to a sale.
I always assumed it was people browsing on work computers that they don't control.
People with "less discretionary income" still deserve to access the web in a way that isn't broken. This might come as a surprise nowadays, but the web can be useful for more than just selling things.
I have a $30 cell phone that runs the latest version of Chrome.
[dead]
Better to focus on WebAssembly instead. Bring every language to the web.
JavaScript for some scripting, any other language for bigger applications.
Did they solve GC and DOM access ? It's been years since it was "just about to happen" and I stopped paying attention in the meantime. But if it had that I agree - it would be ideal if JS was a legacy thing and a saner WASM first class language got to replace it.
Keep the single threaded event loop approach but kill the JS semantics.
Wasm GC is shipped in stable releases of all major browsers except for Safari but that will be changing shortly if it hasn't already (my info is a few weeks old.) The important thing to note about Wasm is that all important functionality, such as access to I/O and the DOM, have to arrive in the form of host imports to a Wasm module. With this in mind, thanks to Wasm GC it is possible to do web UIs from Wasm by importing the relevant bits of the DOM API that the module needs. Projects like Hoot (Scheme) and Kotlin port are already demoing such things.
> Projects like Hoot (Scheme) and Kotlin port are already demoing such things.
And Scala.js has shipped it. [1] Although technically experimental, it has no known bugs and it has full support of things like manipulating DOM objects from Scala.js-on-Wasm code.
[1] https://www.scala-js.org/news/2024/09/28/announcing-scalajs-...
Garbage collection is solved to the extent that host garbage collection is now available via WasmGC:
https://developer.chrome.com/blog/wasmgc/
https://v8.dev/blog/wasm-gc-porting
But languages like C# want more features in WasmGC:
https://github.com/dotnet/runtime/issues/94420
No direct DOM access yet. You still have to use JavaScript glue code to get at the DOM.
The problem is that they promised that the WasmGC would include the much desired access to JavaScript objects but now this crucial aspect is no longer part of it and postponed again.
Actually I don't want DOM access and GC for wasm. At least not yet. It overcomplicates a lot and I simply cannot imagine that a GC can be one-size-fits-all languages.
I want fixed-size buffer-backed structs for JS. Basically a DataView as a C struct. This would massively benefit interop and solve some shortcomings of DataView.
There was a proposal for a binary AST for JS several years ago [1]. Why not just use that as JS0? It's separate and can offer new possibilities as well.
[1]: https://github.com/tc39/proposal-binary-ast
good point. in a sense webassembly is that minimal very performant language. let javascript and typescript compile to webassembly, and you essentially got what is being proposed here
WebAssembly could replace JavaScript, the assembly language, once it has reached feature parity.
But there's still far to go. Large parts of the browser API are still not directly available in WASM.
I very much look forward to WASM reaching stability. It's very enjoyable to run Rust code in the browser.
What parts are not available?
WebAssembly can call arbitrary JavaScript through imports. You could literally provide an `eval` function if you were motivated to.
direct access to the DOM for example without having to go through the javascript host, which is slow and makes DOM intensive applications impractical
All imports have to come from the host, which in the case of the web means they have to be expressed as JavaScript. Behind the scenes they could be optimized, though, and I've heard that JS/Wasm engines maybe already be doing this with well-known imports (think Math.sin).
Or you can just draw to canvas to make the UI fast which is what Flutter does now:
https://flutterweb-wasm.web.app/
https://www.youtube.com/watch?v=Nkjc9r0WDNo
Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most.
Providing access to an already proven DOM would be the better solution.
> And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application.
The download isn't much different to a typical website. That Flutter demo in wasm is 2 megabytes.
Avalonia UI's WebAssembly uses canvas in C#: https://avaloniaui.net/
Uno Platform's WebAssembly implementation uses the DOM rather than drawing to canvas: https://platform.uno/
Uno's philosophy is to use platform native controls. The benefit is that you get platform native characteristics, the cost is it will never be exactly the same in each browser and platform.
What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?
What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?
So throwing out literally 99% of what makes the web actually portable and useful?
A random drawn rectangle is not a UI, it’s not accessible, not inspectable, not part of the de facto OS native toolkit.
If all we wanted is a random cross-platform canvas element to draw onto from a vm, it could be solved in a weekend. There are million examples of that.
Can you give an example of anything anywhere that manipulates the DOM without using JavaScript? Because it seems to me that pretty much every web application is currently using the javascript host, and the well written ones are pretty snappy.
this is going beyond my level of experience, but i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM, which is slower. how much slower, i don't know. i also don't know how old that discussion is where i learned about this. so maybe it improved since. that would be good news.
did you mean there are snappy webapplications running in WASM? if you have any examples, i'd be curiuos to learn more.
> i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM
That doesn't have to be true.
Eventually WASM will get direct access to the full browser API, without going through JavaScript.
The browser exposes a browser API to the JavaScript VM it hosts, so things like the DOM are available.
Those things aren't available in other JavaScript VMs, like Node. (There's no DOM to interact with.)
And they're not yet available in the WASM VM in the browser, either.
The reason is that the WASM APIs/ABIs have not stabilised. It takes time to make right, but there is progress.
That doesn't have to be true.
Eventually WASM will get direct access to the full browser API, without going through JavaScript.
well, that is what i am waiting for. my point is that it's not the case yet, while the gp seemed to suggest that it's not needed because access through the host is available
A fundamental aspect of the Wasm capability security model is that all access to the outside world (I/O) is controlled via imports. Direct access to the entire browser API doesn't make sense in this context.
Previously you said:
> [...] go through the javascript host, which is slow
And now you admit:
> this is going beyond my level of experience [...]
> how much slower, i don't know
I guess people just repeat what they hear without questioning or understanding it, and then it becomes dogma.
> did you mean there are snappy webapplications running in WASM?
No. I meant that all existing web apps go through the "javascript host", using JavaScript. So if any of them are fast enough, and some certainly are, the problem isn't the "javascript host".
you are not answering my question. most existing webapps are not running inside WASM.
i am only talking about webapps running inside WASM. are there any WASM based webapps that are as fast as pure js webapps?
> you are not answering my question
Lol, your question asked me what I meant. I told you what I meant.
> are there any WASM based webapps that are as fast as pure js webapps?
You can browse links from Google for examples and benchmarks. Maybe one of these will scratch your itch, but I won't vouch for any of them:
https://madewithwebassembly.com/
But really, JavaScript and WebAssembly are both very fast. I don't think speed is the reason to choose one or the other.
For me, I like WebAssembly because it lets me program in languages other than JavaScript. JavaScript makes me want to scratch my eyes out.
The DOM itself is very slow, much slower than Javascript, so you're not going to be seeing any great performance increase if WASM can access the DOM directly.
I also have to wonder if people are excited about replacing Javascript, why they would want to have HTML/CSS/DOM on top of WASM. A different front-end UI tech could be much better than slow, old DOM.
right, making those APIs accessible from WASM is something i am also waiting for.
So you want more rights for code that’s harder to read than obfuscated JS?
I commented this elsewhere, but the funny thing is that asm.js was the precursor to WebAssembly, and this proposal is essentially asking for asm.js back again.
Yes and no, there is a significant bundle size problem with wasm which is hard to fix.
I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications.
What's more likely is that all of this will probably be eclipsed by LLM and virtual assistants - which could be controlled by native apps with a dynamically generated GUI or voice.
I think APIs exposing data and executing functions will fundamentally change what we think the web is.
> I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications
Here you go. Do both native and wasm:
https://avaloniaui.net/
https://platform.uno/
https://flutter.dev/
Flutter example:
https://flutterweb-wasm.web.app/
Not that please. The flutter example took 20 seconds to load and the scroll is super choppy.
It’s unfortunate there isn’t a more native “app like” UI toolkit. Especially on mobile, web apps generally are bad and a lot of the reason is trying to shoehorn an app experience onto the dom.
It loads fast for me in Firefox, MS Edge, and Chrome. It's a 2 megabyte transfer and runs quickly.
If you're using Safari it's true that Safari's WebAssembly implementation is behind the other browsers. But that's a Safari problem more than a WebAssembly problem.
> I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications.
Go back to garbage "cross platform" UI toolkits and having to help users manage software dependencies on their machine? No thanks.
> I'd rather we just move to native cross platform applications and stop using a document browser to build interactive applications.
Cool stuff, let's kill web for good.
Throwing out the baby with the bath water? There are millions of standardized APIs available in the browser that would be probably impossible to recreate in anything else due to failing consensus.
Assembly is not a language runtime. Even if you had WebAssembly as the core, you'd still need to compile JavaScript to WebAssembly, manage the GC, etc which all would still suffer from the performance implications mentioned in the article.
Also... do you really think its wise to rewrite v8 to target WebAssembly?
It already supports WebAssembly. All browsers do.
Here's a demo of Dart and Flutter compiled to WebAssembly:
https://flutterweb-wasm.web.app/
WebAssembly enables you to use any language. And when you can use any language, why would you use JavaScript?
Google has started migrating parts of Google Sheets to WebAssembly. They're compiling Java to WebAssembly and seeing a 100% performance increase:
https://web.dev/case-studies/google-sheets-wasmgc
Amazon has been migrating its Prime Video app from JavaScript to WebAssembly. They're compiling Rust to WebAssembly and they've seen increased performance and lower memory usage:
https://www.amazon.science/blog/how-prime-video-updates-its-...
Still spreading your JS hate from thread to thread I see.
> WebAssembly enables you to use any language. And when you can use any language, why would you use JavaScript?
In which context? I'm doing Kotlin/Java/Rust/C++ for a day job and I'd rather die than use any of those instead of JS for my hobby/exploratory projects.
The amount of bullshit I have to deal with in those languages from tooling to languages themselves is astonishing.
Well this person is not the only one who thinks js (and web stuff in general) is terrible. I mostly dislike the pace of crapification; I comment almost daily on repositories asking why they made that breaking change with zero benefits for the user. Usually 'we are cleaning up' or so; there are npms that really need never be changed that are changing weekly just because 'keep them fresh'. That kind of misery is just weird and frankly depressing; update something one week after writing and plop, it breaks. For No Reason as no improvements were made, just breakage for the sake of upping the date on github and npm (the most terrible I find the VC backed open source ones; I guess they have to update all the time for the sake of the VCs looking in even though no updates are required). I use lisp, c++ and go libraries that haven't been updated in 10 years; guess what; they work and work well and stable for another decade because they really never need anything new and people are not vying for update kudos or whatever.
But you can use vanilla js you say? Yes it is true, but I find js very terrible and I want to write things in common lisp, or, if need be, Go. Neither of these require any bullshit with tooling or anything hard. You can learn enough Go in a few hours to be productive (like C) and llms are super at it (unlike js/ts where they produce things that had breaking updates 40 times since the llm knowledge cut off for no reason at all). With vugu framework you don't need to touch js either. Common lisp is also not hard to learn, bit harder but even better tooling and you don't need to know all of it to write nice stuff; there is the clog framework which is basically all you need to get going as it is an ide, web dev environment and you get away with writing almost no js.
Kotlin and Rust are modern languages that were designed much later and not so hastily, so they have less warts than JavaScript as a result.
Then you add capability to hide the browser chrome and build close to native user experience and we will have truly looped the loop. Think about that: the browser as an intermediation ensuring resources are properly shared and each application is shielded from the others. Everything that’s old is new again. /s
On a serious note I don’t see the point in turning browsers into an OS on top of the OS. I know it’s some kind of Google wet dream so they can suck up even more data than they already do but still. If you want to ship applications, just do that. The sandboxing should be done at the OS level where it belongs.
I was in your camp, but we truly lost. Almost everyone I know literally ONLY uses a browser for everything. On mobile some things force you app use, but if that weren't the case, people would use it from a browser. Games in browsers, movies, email, anything. So it makes sense to only open a browser in an OS; it is basically what users do anyway.
> Regarding BigInt, the presentation states that “use cases never materialized.”
Yet every language has either that or BigDecimal. Even if Google's frontend devs haven't found a use, there also exist JS devs outside of Google who certainly have found uses (though possibly more of them on the backend).
Similarly, not every developer has a compilation step in their JS work. And there are places where you can't have one, e.g. in the browser console. Develop the language instead of tons of incompatible tools.
That part caught my attention too. It reminds me of the discussion to remove complex numbers from Go. Funny enough, compiler writers can't even imagine why you would want BigInt or Complex, because those aren't useful for writing compilers.
The problem with Google compiler developers is that they will do a search of the google3 repository, find no uses (because Google doesn’t do any advanced math, for example) and declare the language feature to be useless.
Which is ironic because I use Google Sheets a lot and occasionally run into problems when it doesn't support BigInt calculations. Sheets is the best excuse Google has for keeping BigInt support in the language.
Excel does not support BigInt either, so Google has no reason to implement it in their cheap imitation.
That's a general problem: languages end up having features that are only useful for writing compilers, and vice versa.
one contributor to the pike programming language when asked why he took the effort to optimize syntactic sugar responded: so that pike users can write simple code and still have it run blazingly fast.
in pike, bigint and int are integrated in such a way that the transition is automatic. there is no overflow but as long as the values fit in an int, that is used internally to keep the code fast.
That's nice. The implementation of a numerical tower is common in Lisps: https://en.wikipedia.org/wiki/Numerical_tower
Nice or not, pretending that double precision floats and arbitrary precision integers can be stacked as a tower is foolish. There are floats that can't be represented as integers, and integers which can't be represented as floats.
This is where you say something about "exact" vs "inexact" as though that will hand wave it away.
> This is where you say something about "exact" vs "inexact" as though that will hand wave it away.
I'm not familiar with this debate, but how is that a hand wave? The article describes a reasonable-sounding way to extend the tower with a second dimension of precision. Following those rules, you would never just convert between bigint and float, but an expression involving both would output a float.
that's not what pike is doing though. int and float are still kept separate.
btw, i just checked, typeof() no longer shows the difference between int and bigint. it did in the past if i remember correctly
You gotta read between the lines with the commenter above. Their name is a reference to "Smug Lisp Weeny", and they're part of the religion (cult) that thinks everything in Lisp (usually Common Lisp) is perfect. He couldn't care less about Pike, except as an excuse to be smug about Lisp.
Besides his nick, was he smug? He just noted that Lisp(likes) solve this problem for some version of 'solve' with the numerical tower. The implementations don't (usually; I am not aware of any) mix exact and inexact as that would be foolish obviously.
> Besides his nick, was he smug?
Saying, "That's nice." is a cliche condescension. You're free to disagree, but I think his intent was clear.
Ah, I did not read that into it. But guess that might be what he was doing.
I used LPC a long time ago on an LP Mud, so Pike has always had a fond spot in the back of my mind, even if I don't use it now.
However, that works for int and bigint, but Number (double precision) can represent numbers that BigInt can not, and BigInt can represent numbers which Number can not. There isn't a graceful way to automatically promote/degrade one to the other in all cases, and a silent conversion will do the wrong thing in many cases.
heh, yeah, that's where i started too. i don't know how or even if LPC did it, but in pike the transition really is seamless. give it a try. as a naive user i can't even tell the difference (you can see it though if you compare typeof(1) vs typeof(20000000000000000000) (i hope that number is big enough))
This stood out to me as well. Proper decimal type would be my #1 missing language feature, seconded by a standardized runtime implementation of the same.
Yeah it was really concerning to hear someone from Google saying that BigInt doesn't have a use case. It is both used and important!
Would help if it worked with JSON by default.
I literally use BigInt on the backend every single day at work lol.
Sounds like the presenters are assuming that everyone must be using JS in the same way they are. As someone who prefers to work in VanillaJS, I'm already frustrated by all the language changes being forced upon me. So maybe I agree with them that fewer changes should be made, but for completely different reasons. I'd rather them work on API improvements so that web apps get closer to parity with native apps. All this other talk is pointless while web apps remain second class IMO
What do you mean forced upon you? There is no requirement for you to use new features. If you do, it’s because you or your team thinks it’s more convenient — and it really is! map, filter, arrow functions, scope improvements with const/let, etc. are major language improvements. So is null coalescing and optional chaining. You don’t have to use them, but they do make JS more straightforward to work with.
I think "forced upon" could also read as:
- at work they expect me to write code with the latest features
- my colleagues write code with the latest features and I have to review/extend/build upon using the same style
- the community, books, copilots, LLMs, libraries, tooling are "forcing" all that new stuff upon me
- etc.
As a dabbler in JS, it jumps out to me that a lot of tools are trying to force ESM, despite the fact that they lack many essential features that other module systems have.
I think the proposal is actually good for people like you.
You can choose to just work with the core and maybe a minimal sugar library. Which will probably be faster and don't include "all the language features that were forced upon you".
This is not what happened in C vs C++.
This is also a result of the detachment of TC39 and the developer community. Just how many JS developers are participating TC39? I can recall multiple TC39 proposals that didn't even consult opinions from authors of notable open-source stakeholder libraries, and went straight into stage 3.
And btw, the TypeScript tooling scene is far from being able to get standardized. TypeScript is basically a Microsoft thing, and we don't see a single non-official TypeScript tool can do type-checking. And there's no plan to port the official tools to a faster language like Rust. And the tsc is not designed for doing tranditional compiler optimizations. The TypeScript team made it clear that the goal of tsc is to only produce idiomatic JavaScript.
It should have been split into JS and Wasm. Instead they decided to make Wasm a second-class citizen without web API access.
The proposal was submitted here but didn't get much attention. Are there other threads?
Language Evolution: Problems, and What Can We Do About It? - https://news.ycombinator.com/item?id=41795190 - Oct 2024 (1 comment)
Proposal of JavaScript becoming a compiled language: JS0 and JSSugar - https://news.ycombinator.com/item?id=41764825 - Oct 2024 (2 comments)
https://news.ycombinator.com/item?id=41764825
Added. Thanks!
Imagine Google not having the resources to maintain their V8 engine after the hiring downturn, and telling us they want to change JavaScript because their V8 engine has become challenging to maintain.
A proposal rooted in attempts to improve the language would be one thing. This appears to be about Google struggling with technical competencies and not having the budget to do the right thing.
“A Google engineer presented … 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.“
“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.”
Maybe try something besides c++ for V8 if you are having security issues?
The apathy towards proper tail calls in V8 leads me to distrust Google’s language proposals. But now that abdication appears to possibly have been a canary? Perhaps even prior to the pandemic they couldn’t keep up with maintaining the V8 C++ codebase, and that’s why PTCs got skipped?
By the way, what happened to Golang and Dart?
I really don't like it as it is difficult to debug code when the code that runs isn't the code I wrote.
This is mostly a solved problem in regular compilers, and sourcemaps etc do currently exist for JS.
I agree that the tooling/UI around this could be better, but by focusing on this approach, things like Typescript get better as well.
Are there debuggers that can single step over the transpiled bits so that it feels like the methods are implemented natively? Otherwise, it becomes a mess.
I’m not sure if it exists, but it definitely seems doable (a regular debugger has to map instructions to lines of code).
If the browser starts treating JS as assembly, then there would probably be a greater onus for features like this.
> sourcemaps etc do currently exist for JS.
Are those being supplied with every website you use?
With the right debugging tools, transpiled alternatives to JavaScript are easier to debug than vanilla ES5.
For example: TypeScript's sourceMap [1], Elm's time-travelling debugger [2], Vue.js DevTools [3], just to name a few I've tried. Especially well-typed languages tend to behave well at run-time once they pass type-checking. Or rather, I have not made enough front-end code to discover transpiler bugs.
[1]: https://www.typescriptlang.org/tsconfig/#sourceMap [2]: https://elm-lang.org/news/time-travel-made-easy (2014 [3]: https://devtools.vuejs.org/
> transpiled alternatives to JavaScript are easier to debug than vanilla ES5
As easy, certainly. But how are they easier?
Because debugging better languages affords you more context and more tooling.
Elm's debugger lets you step forwards and backwards in the application's state.
TypeScript's type system lets you catch bugs before you run the code.
Vue.js's DevTools extend the browser's with a component-based overview, so you can interactively see what's going on at a high level of abstraction. (I'm sure something similar exists for most frameworks similar to Vue.js, and possibly even frameworks made in vanilla ES5, I'm just picking one I've tried.)
With vanilla ES5 you get interactive debugging.
> With the right debugging tools, transpiled alternatives to JavaScript are easier to debug than vanilla ES5.
So if I agree with GP then I just haven't found the right tooling yet?
I started with your position (vanilla js 4ever!) and after being dragged into the world of transpilation via typescript/eslint/prettier/webpack/babel/etc I do agree that it’s at least as easy. Not sure about “easier” but my debugging needs are not exotic. The painful part is initially setting up the toolchain.
If you're happy writing ES5, power to you.
No. Javascript should be split into 3 languages and html and css should be split into 20 languages.
Seriously frontend is already the most fragmented and fast changing area of web there is. Don’t split the language.
You wouldn’t see much difference as a user of those tools. And if you’re writing vanilla JS, you’d have less features creeping in over time. So it seems like you would benefit from this kind of change.
Yeah but if I change jobs or work on another project then I’d have to learn two standards.
> and fast changing area
Who cares? If backwards compatability is maintained then this fails to have any impact on my experience as a developer. It sounds like the VM maintainers are busy making their own lives hell. Not my problem.
> Who cares?
I do. Maybe if someone programs in one language it's okay for them to keep up with language changes, but if you have to constantly juggle multiple languages it becomes a real chore to stay up to date with every one of them.
I use the language. The existence of new language features has not forced me to adopt them. The standard library for browsers is a different story but it is always going to be.
Thankfully.. both maintain reasonable backwards compatability where security is not otherwise implicated.
You didn't read the article.
Fuck, no. Everyone's free to make better tooling, but don't standardize it. There's no point. It'll only lead to further fragmentation. Libraries and frameworks will be split between plain JS and whatever this new version will be called. Just freeze the language and be done.
Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself? i.e. if implementing them directly as new language features doesn't make sense, then preprocess them away before executing the scripts. You could even do this for past features that made it into ECMAScript but haven't turned out to be useful, instead of ossifying a specific moment in time's tooling.
> Wouldn't it make more sense for some of these features to be implemented as a desugaring step in the runtime itself?
I think if it was that simple, it would be done that way already (maybe it is, for some features). Two big arguments for doing the "desugaring" offline are the (1) speed, and (2) security of the browser. Those two things also conflict somewhat if addressed on the client, since faster but more complex compiler code increases the surface area for potential exploits.
But if you do this compile step offline, you don't need to worry about compromising the performance or security of the browser.
Why wouldn't you take the complexity and performance hit involved once at buildtime rather than offloading it to the client at runtime?
If you read the original slides from the proposers, they're presenting a framing where there is an inherent tension between "serving the user" and "helping the developer". They argue that there is too much of the latter, and that a formalized splitting should push more to the former.
From an end-user perspective, it definitely makes more sense that the js doesn't have to be transformed locally before it can interpreted. I think your suggestion is not compatible with the motivations of the proposal.
If it’s not implemented as a built-in feature of the browser, wouldn’t half the internet break if features were removed that people were counting on?
If there’s still going to be a standard JSSugar, yes, seems like it should be desugared in the runtime. On the other hand, if we want to make it easier to fragment the high-level language into incompatible sugared versions, this seems like the way to go. (Hard to believe that would be the TC’s goal.)
> features to be implemented as a desugaring step in the runtime itself
The problem is distributing the runtime(s). By having developers transpile to a small core, anyone can freely invent new language features without waiting for the rest of the internet to download support for them.
This is a very good at important point:
JS0 should be a subset of current JS
JS1 should be current JS
JsSugar should be current JS plus future features
I use bigint all the time. Not adopted? Its not true.
Sounds like WASM is their JS0 already?
The problem expressed is fundamentally correct, but the proposed solution is a band-aid, which is worse than not solving the problem at all. The fix provides a long term change with short term benefits. Reliance on tooling will continue to make code instances are the progressively larger and slower until we arrive at this problem again. At some point JavaScript must become a professional language written by adults, people capable of self-organization and measurement, and not be the subject of fashion by people who aren't qualified to program in the first place.
If performance and complexity really are the primary concerns then the language must stop pandering to children. We already know what high performance looks like. I wrote about it here: https://github.com/prettydiff/wisdom/blob/master/performance...
If the goal really is higher performance and lower complexity the most desirable solution is to create a new language with forced simplicity directly in the image of JavaScript, where simple means less and not easy, and transition to that new language slowly over time. Yes, I understand Google went down this road in the past with Dart, but Dart solved for all the wrong problems and thus was dead on arrival. Instead the idea is to take something that works well and shave off all the bullshit reducing it down to the smallest possible thing.
Forced simplicity means absolutely ignoring all vanity/stylistic concerns and instead only focusing on fewer ways of doing things. As an example consider a language that requires strong typing like TypeScript and thus thereby eliminates type coercion. Another example is operators that have a single purpose (not overloaded), single character, and no redundant operators.
Will there be a lot of crying about vanity bullshit... yes, absolutely. Just ignore it because, you cannot reasonably expect to drive above 120mph on a child's tricycle. If people wish to offer their own stylistic considerations they should include performance metrics and explanations how their suggestions reduce quantity of operations without unnecessary abstraction.
No word about Actionscript 3 (ECMAScript 4) here? It compiled to the ActionScript Virtual Machine 2 as bytecode. Everybody was happy. And then, Steve Jobs came around the corner and damned it with a single magical curse. Too bad.
I would like to see an in-depth treatise explaining why existing bytecode VMs (LLVM, JavaVM and Ecma CLR) were never seriously considered for the world of browsers. These VMs already exist for numerous platforms, have been optimized to death, already have plethoras of languages that compile to them, and beside JavaVM are open source (Ecma CLR exists in the Mono project). I've looked at WebAssembly and I don't understand why it needed to be reinvented from scratch and why it needs to be so limited. We could already be writing web code in Rust, Java, C#, Python, and heck even Haskell, if we had just done that. I know that I'm skipping over the engineering effort required to make this happen but I get a sense that the engineering effort is not the stumbling block. I want to know the details of what is.
My guess is that none of those bytecode VMs were designed with the explicit goal of running untrusted code at global scale in a rock-solid sandbox.
If anything, I expect those existing VMs to slowly be replaced by WebAssembly due to how crucial and complicated that very specific sandbox requirement is - and how useful that is once you have it working reliably.
Personally I never want to run untrusted code on any of my computers outside of a robust sandbox. I look forward to a future where every application I might install runs in a sandbox that I can trust.
"Secure Java" is something I recall hearing decades ago. No idea if it still exists.
The more important thing to consider, however, is the fact that CLR, JVM, etc. provide internal memory safety whereas Wasm runtimes don't.
e.g. a C program that goes sufficiently out of bounds on an array is guaranteed to segfault in the C runtime, but that runtime error does not necessarily occur on a wasm target. That is to say, the program in the sandbox can have totally strange runtime behavior -- still, defined behavior according to wasm -- although the program has undefined behavior in the source language. In the case of JVM languages, this can't really happen.
SecurityManager? Java's current direction (using the word "integrity" rather than "security", but seems relevant) looks interesting to me https://news.ycombinator.com/item?id=41520246
https://cybercultural.com/p/1995-the-birth-of-javascript/
> As told in JavaScript: The First Twenty Years, Brenden Eich joined Netscape in April 1995.
> [..]
> However, Eich didn’t think he’d have to write a new language from scratch. There were existing options available — such as the research language, Scheme, or a Unix-based language like Perl or Python. So when he joined, Eich “was expecting to implement Scheme in the browser.” But the increasingly fractious politics of the software companies of the day (it was, basically, everyone against Microsoft) soon saw the project take a more creative turn.
> On 23 May 1995, Sun Microsystems launched a new programming language into the world: Java. As part of the launch, Netscape announced that it would license Java for use in the browser. This was all well and good, but Java didn’t really fit the bill for the web. Java is a general-purpose programming language that promised Write Once, Run Anywhere (WORA) functionality, but it was too complicated for web designers and other non-programmers to use. So Netscape decided it needed a scripting language, which was a trendy term at the time for a smaller, easier to learn programming language.
There's a whole lot more interesting stuff but I think that part directly answers most of what you're wondering.
They were. Lots of reasons why it turned out how it turned out. Basically a local minimum in the gradient descent. Computers were much slower is one reason. JVM wasn't open source at the time is another. NIH is another 100 reasons.
None of them started out with web security in mind.
Look at the Java bytecode, and you'll see it features such things as a goto with an arbitrary offset: https://en.m.wikipedia.org/wiki/List_of_Java_bytecode_instru...
They had to build a verifier that attempts to ensure the bytecode isn't doing anything bad. That proved to be fairly difficult, and comes at a considerable cost.
But it's not as if security concerns are specific to the Web. Look at the vulnerabilities found in CPUs over the last decade or so. Security is necessary no matter what the delivery medium, so I don't see why this is a rationale for reinventing the wheel.
They genuinely spent years trying to make Java more secure for the web. That was entirely new effort.
And?
Perhaps reread your comment and mine, and you'll see there is a relationship between statements.
They both mention security. That's about it as far as I can tell.
I mostly don’t mind JavaScript only thing for me is number data type and no int. The other part that is annoying is lack of standard library so we get left-pad crap.
A core requirement of WebAssembly was that (ignoring I/O for the moment and considering only the computational core) you should be able to run arbitrary existing code on it, and the effort involved in getting it working should be comparable to porting to a new architecture, not to a new programming language. What this particularly meant, in practice, was that it needed to be a good compilation target for C and C++, since most code is written either in those languages or in interpreted languages whose interpreters are written in those languages. (It also needs to support languages that's not true of, like Go, Rust, and Swift, but once you've got C and C++, those languages don't pose major additional conceptual difficulties.)
The JVM and CLR are poor compilation targets for C and C++, because those languages weren't designed to target those runtimes and those runtimes weren't designed to run those languages. (C++/CLI isn't C++.) It's possible to get something working, and a few people have tried, but you run into a lot of impedance mismatches and compatibility issues. I think you would see people run into a lot more problems trying to get their code running on the JVM or CLR than they in fact run into trying to get it running on WebAssembly. (Though I think the CLR is less bad about this than the JVM.)
As for the idea of using LLVM bitcode as an interchange format, we don't have to guess how that would have gone, because it was actually tried! Google implemented this in Chrome and called it PNaCl, and some sites and extensions relied on it for a while. They ultimately withdrew it in favor of WebAssembly. I don't understand all the reasons why it failed, but I think part of the problem is that it ran into a bunch of "the spec is whatever LLVM happens to do" type issues that were real problems for would-be toolchain authors and made the other browser vendors (including Apple, LLVM's de facto primary corporate sponsor) reluctant to support it. WebAssembly has a relatively short and simple standard that you can actually read; writing a WebAssembly interpreter is an undergraduate exercise, though of course writing a highly performant one is much more work.
Also, as far as I can tell, LLVM hasn't at all been optimized to death for the use case of runtime code generation, where the speed of the compiler is about as important as that of the generated code. The biggest dynamic language I know that uses LLVM is Julia, which is a decently big deal, but the overwhelming majority of LLVM usage is for ahead-of-time compilation of languages like C, C++, Swift, and Rust.
On a bigger-picture note, I'm not sure I at all understand why adopting an existing bytecode language would have made things easier. Yes, it would have been much easier to reuse existing Java code if the JVM had been adopted, or to reuse existing C# code if the CLR had been adopted, but those options are mutually exclusive; the goal was something that would work at least okay for all the languages. Python doesn't have a stable bytecode format, and Rust and Haskell compile to LLVM bitcode (which LLVM has no problem lowering to WebAssembly since WebAssembly was designed to make that straightforward), so I don't see how those languages are in any way disadvantaged by the choice of WebAssembly as the target bytecode language instead of some alternative.
Or are your concerns about I/O? That's a bigger can of worms, and you'd need to explain how you imagine this would work, but the short version is that reusing the interfaces that existing OSes provided would not have worked well, because the browser has a different (and in many ways better) security model.
This is not true. CIL could be an excellent compilation target for C++ and was quite literally made with that in mind. C# was inspired as much by C++ as it was by Java. And CLR back then was made with consideration of C++/CLI, which exists even today. You can't effectively express C++ code with JVM bytecode, you absolutely can with CIL. You can even express most of Rust's generics with CIL nowadays, retaining monomorphization, save for zero-sized structs and other edge cases.
What disqualifies "the JVM" (usually referring to HotSpot implementations) from being considered open source? Are you talking about OpenJ9 or something else?
NIH and CIL is probably an ultra-overkill for browser-based scenarios. It implements a complex type system with all sorts of high-level features that significantly complicate the runtime/compiler. It makes it drastically easier to target but not to write an implementation.
I'm not a huge fan of WASM but it's easy to see that the authors would clearly not want to leave control in the hands of Microsoft or Oracle (and as a result all of us are hostages to Google instead because of evil that is Chromium).
https://ecma-international.org/publications-and-standards/st...
Java is as open-source as it gets (it’s reference implementation, OpenJDK, has the same license as the linux kernel)
And it was used by some browsers, there was just no consensus between different vendors due to politics. The problem largely solved itself by.. only one vendor remaining, chromium.
Hell yes. I've been advocating for this for years. From an engine-implementer perspective, full-fledged JavaScript is just too hard to make both fast and secure.
One of the examples given makes sense, since Symbol.specie messes with prototypical inheritance and is likely hard to secure as a result because that touches so much of JS as a whole.
BigInt failing to materialize I think has more to do with ergonomics around it, they’re a bit unwieldy and there aren’t able to be used with the built in Math object functions.
They also have zero JSON support out of the box which is a huge miss.
Honestly it should have been roadmapped to replace the built in Number type
Can't replace Number with BigInt as BigInt is orders of magnitude slower on certain operations. Try to do bitwise operations with BigInt, you'll see what I mean.
Hence roadmapped. You can’t today, certainly, it also can’t represent floating point numbers or be used with the Math object as noted.
But the idea is that it should have been proposed with a roadmap of what it would look like to have it eventually supplant Number
absolutely - one for the great minds to play with while running in great circles and one that passes https://jslint.com and is allowed to be on the internet.
I think I understand the argument but this sounds like it would make things worse. The argument that new features almost always make the language worse doesn’t hold true from my perspective as a developer. (I could imagine the perspective of a language implementor being very different.)
I like that JavaScript now has modules/imports, destructuring, Proxies, async/await, etc. These were all new features at one point, But yeah, why did Symbol.species get in? Seems like it’s to enable some odd subclassing pattern? I’m an anti-OOP zealot, so my hot take would be that maybe OOP subclassing is unnecessarily complex already, so stuff like that shouldn’t make it in. We got the OOP syntactic sugar, which is enough. Stop there.
How much of the extra complexity is from stuff like that that is rarely used? Maybe we just need to be a lot more conservative about what makes it in, but stopping changes and forcing everything into more tooling complexity is not the direction I’d like to go in. We need to reduce tooling, not increase it.
I'm a little annoyed that they said Bigint uses cases never materialized. I've used it several times and it isn't something that's easy to transpile. A bigint class has bad ergonomics and there's no way the perf can be equivalent.
It's a good idea, but a better idea would be to make the browser a virtual machine running wasm. HTML, SVG and everything else could be implemented in wasm, and loaded from the cloud as needed.
> It's a good idea, but a better idea would be to make the browser a virtual machine running wasm. HTML, SVG and everything else could be implemented in wasm, and loaded from the cloud as needed.
So now a huge swaths of use cases are going to be killed by this change. E.g. AdBlock, NewPipe and yt-dlp - how is that better? All of them (expect maybe AdBlock) rely on parsing incoming JS from YouTube which will be rendered obsolete by WebAssembly blob.
WASM is slower than running JavaScript on V8 in almost all scenarios and will likely continue to be for a very long time. Also, many of us don’t want a compile step.
No, wasm has higher performance and lower memory usage. Here are two practical, real world examples:
https://www.amazon.science/blog/how-prime-video-updates-its-...
https://web.dev/case-studies/google-sheets-wasmgc
That is a misconception; there is a cost of abstraction, although this cost may disappear if AI gets really smart.
While I don't want any compile step either (js should stay), I'm actually confused by your statement.. are there any benchmarks? Are you saying that for example v86 would run faster without wasm?
I think that would probably fall outside the norm. My information might be outdated, but I was under the impression that JavaScript usually wins in most algorithm benchmarks because the JIT is so good.
Split it into a thousand pieces and send each to separate, distant stars. Put three in a Phantom Zone.
The US government needs to fast track breaking up Google asap. Chrome needs to be torn from their festering lich hands, so that the web can be free of their self serving, and frankly bad, proposals.
Out of curiosity, which of the fragments of Google would you expect to take ownership over that codebase?
I had always imagined that if the DoJ took any action it would be to cleave the ad business away from Google. Although if they went so far as to take action against GCP I bet Amazon, Amazon Marketplace, and AWS would start to get sweaty palms
All this championing Javascript as a single language for front and back end work, now to be split for different use cases. Hopefully this is how Javascript dies if that is the route Google pushes it.
There is already too much exhaustion around switching frameworks and paradigms in the JS world, but I guess everyone likes getting jerked around by corpos and evangelists these days.
I’m really tired of this discourse. The JavaScript ecosystem is the lingua franca of the web. Furthermore, while a segment of the programming community has sat around complaining, JavaScript has gotten really good and continues to improve every passing year. Incremental progress is the key to making progress, not giant paradigm shifts.
Well drink a cup of java because it’s not going away.
We’ve run React for almost a decade now and the only major parts we’ve swapped have been react build with Vite. Angular has been even more stable since the switch to TS. As far as the frontend frameworks themselves changing massively, that’s a different story, but it’s not like C# didn’t go from Windows .Net to Core/Framework to cross platform .Net, and so on for different language frameworks.
On the Backend there are very few issues, outside of FFI only being in unstable for Deno I suppose, but you could frankly be running the same old Express API you did a decade ago and be perfectly fine.
If you’re burnt out on changes and keeping up with things I think the issue is mostly a “you” issue. You don’t have to chase down the latest hypes or fads. In fact I think you almost never should.
I’m not chasing down hypes and fads, the new product person who wants to make a splash by rewriting the core app does.
This is an incredibly disingenuous response. You maybe like the world this way. It doesn’t mean there isn’t room for change or improvement away from Javascript.
> There is already too much exhaustion around switching frameworks and paradigms in the JS world
What's wrong with VanillaJS?
> What's wrong with VanillaJS? Absolutely nothing, we all love it, and we also love things built upon that foundation, like TypeScript. But it's optional, and that's a good thing that some people miss to recognize. Therefore, they seek more standardization that 'should be enforced' by your Big Brand's top used product (ie. browser).
My point is that "framework fatigue" is a self-inflicted problem. Nobody forces you to use flavor of the week, VanillaJS and bog standard HTML/CSS are always there for you.
Work in a publicly traded company where people are moving things around for promotions sake. Then you’ll see how forced you are to use the latest flavor of the week. People absolutely do force you.
It’s not just the flavor of the week frameworks, it’s libraries and best practices. Want to work with dates? Do you use moment? Nope that’s deprecated, what do you use? Which moment successor? How do you write react? Classes or functions? You can’t use hooks with classes, so you better update to functions. On and on you run into a decision tree because of the shifting target of javascript. It causes a lot of churn to be migrating and updating to new systems, especially when the new hire can’t help because they don’t understand prototypal inheritance.
I don't understand the problem? If v8 wants to split into frontend (sugar, transpiled) and backend language (es5 + few things probably; runtime engine proper), they can just do it, no?
If this happened then JavaScript would be split into 20+ languages, one for each popular compiler. There would be nothing stopping a tool maker from adding their favorite language features even if no other compiler ever adopted them. That would be a disaster.
In many ways this has already started happening. TS has enums, Svelte has runes, React has jsx. None of these features exist in JS, they are all compile-time syntax sugar.
While it is admittedly confusing to have all these different flavors of JS, I don’t think this proposal is actually as radical as it seems.
Outside of browsers this is already how it works. Nothing is stopping LLVM versus GCC from adding their favorite language features, but it's not a disaster.
> Nothing is stopping LLVM versus GCC from adding their favorite language features, but it's not a disaster.
It is a disaster the moment you try to run same code on different platforms.
I hope not. I have a hard enough time trying to keep up with front end frameworks.
The same could be said for R and Tidyverse crowd. Honestly two entirely separate visions.
Can we clean up the TypeScript & JavaScript thing at the same time?
Add structs/value types, pattern matching and we can freeze the language until end of days.
> 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.
Hot take
Can anyone explain the layout and formatting of the slides?
In my opinion Typescript made a mistake staying in sync with the ECMA Script specs.
Why JS0 and not wasm? Why is wasm so damn limited?
I was thinking we should split JavaScript based on the 'good parts' vs 'bad parts' as opposed to 'new features' vs 'existing features'.
That said I also see the rationale for that. JS is already getting heavy and we should limit feature creep.
JavaScript developers yet again rediscover bytecode!
"ECMA TC39", not "Emca TC39". Also, looks like a bad markup link for TC39. Also note that it's either "co-authored by Mozilla, Apple, Moddable and Sony" or "authored by Guo along with others from Mozilla, Apple, Moddable and Sony", but directly related to that statement, that makes this "not a Google proposal" but clearly an "industry proposal" if it has Mozilla and Apple buy-in.
Also, "the proposed solution is not to backtrack on existing features" makes very little sense. If you're going to split something into core and "compiles down to core", then a LOT of features can be moved out of core because they're just (definitely worth keeping, but not necessary in core if that split were made) convenience APIs.
> ECMA not Ecma
Incorrect: https://ecma-international.org/about-ecma/history/
> 1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.
This sounds like a crock of shit.
No, it won't be faster, if you only optimize a lesser language. If you have higher level code running your optimizer can do more than if it only has a low level version.
No, it won't be more secure. Js0 might be more secure, but if we sites all run any of dozens of different tools those tools are going to be creating the vulnerabilities. It's shifting where security issues occur, and creating more of them.
I'm terrified this could happen. JS has gotten so much better over time. We are so close to being able to not need transpilers. This sounds like such an absurd cop out for browsers to say, meh, we just don't want to do the work to implement. Being so close & then saying, sorry, you must use big toolchains to develop for the web is a monstrously bad future.
JavaScript so wants to be Scheme. Can we just do Eich's original thing and put Scheme in the browser?
WebAssembly enables that: https://www.spritely.institute/hoot/
Heh thanks for dropping the link! The dream of the 90s is alive thanks to Wasm GC.
https://news.ycombinator.com/item?id=41936300
Thanks—that thread had two comments, which I've merged hither since the current thread is ongoing.