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.
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.
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.
I thought the js DOM API was atrocious. But they copied it over with Java object hierarchy into Scala.js. Makes me want to give up on coding altogether.
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
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.
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.
You're joking, right? A 2mb bundle is *absolutely unacceptable*. People complain about React which is less than 100kb minified and gzipped. This website doesn't even include any images or anything...
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?
I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options:
A) Get your hands dirty and write what you want. Once.
B) Chant along with the mob who doesn't even understand what they're asking for.
C) Wait several years for some super complicated solution to be designed by committee.
I wouldn't even want direct access to the DOM if we had it today. The DOM as an API is atrocious.
Instead, I want a set of nice functions that do things like put a graphical chart on the page - all in one call. Or one call to pass a bunch of 3D triangles or splats to visualize in a WebGL canvas. Or one call to play some audio samples. Or a function to poll for recording audio. And so on...
if option A works, why aren't there any frameworks yet that implement it?
maybe all the framework devs are waiting for C?
but why?
you could be right about A but at present the majority view seems to be that C is the right option. which is what pushes me into going with B because i have no interest in developing my own framework.
if a framework appears that implements option A i'll gladly consider it. (just as long as it isn't tightly coupled with a backend)
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.
Its web targeted version is still not accessible, even though they promised that they will actually render to HTML elements as much as possible. A single canvas element is not that.
> The Flutter team would like to eventually turn the semantics on by default in Flutter Web. However, at the moment, this would lead to noticeable performance costs in a significant number of cases, and requires some optimization before the default can be changed
Ah, so you admit it does indeed include accessibility but now what you're complaining about is performance. Not that you've actually tried it of course.
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".
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.
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.
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.
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:
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.
So need to install node and npm and then typescript. Go is 1 binary to download and throw in a dir.
I don't find js hard to learn (and I have been programming in it since it came out (I was in the CMS business since the early 90s), I just find it ugly and annoying to work with. But yeah, I guess the ecosystem definitely doesn't help as it's hard to see the proliferation of terrible software/frameworks and habits totally separate from the language; apparently there is something in it that attracts these terrible practices.
Kotlin is a lipstick on a pig that effectively doesn’t exist outside of IntelliJ, single vendor that is only interested in driving sales to their IDEs and doesn’t work without bringing baroque Gradle.
It has amazing coroutines library and it started with a nice set of features but failed to evolve. Sealed types are a joke compared to union types in TS. No inline types so you’re forced to created stupid data classes everywhere even if it’s used only once. Constant fight between wannabe functional programmers that try to replicate Rust’s Result monad, but without official language support, and exceptions crowd.
Static delegation. Still no pattern matching when even freaking Java has it nowadays. Hilarious. Constant focus on KMM, even though language stagnated for a while.
Rust is just a pain to develop. Slow to compile and constantly have to please borrow checker. I’m not sure if you’re joking, but you can’t seriously think that Rust is better language for prototyping than JS/TS.
> designed much later and not so hastily, so they have less warts than JavaScript as a result.
That’s irrelevant. Modern JS has evolved over the years and is a joy to use now.
No, I wasn't suggesting that Rust is better for prototyping, the only thing I said is that Kotlin and Rust (that you mentioned yourself) are better than JavaScript because they were designed much later and more thoroughly. TypeScript is a different thing to me, it makes part of this new generation of languages, its only problem is that it works on top of JavaScript.
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.
JavaScript for some scripting, any other language for bigger applications.