Live data from Hacker News

Making WebAssembly a first-class language on the Web

hacks.mozilla.org

171–180 of 287 posts

Re: Making WebAssembly a first-class language on the Web

#171
I was just discussing/commenting on this a couple of weeks ago: https://news.ycombinator.com/item?id=47133223

Hear me out: Web APIs need to devolve into... APIs. DOM needs to devolve into a UI API. We have PWA's, File System APIs, USB APIs, peripheral device APIs, all the things a native webui client would be doing.

Yes, it is "back to square one" , we already have websites masquerading as native apps via electron and tauri.

On the other end you have a handful of tech companies dictating how our computing experience should be because they control browsers.

WASM should be the bytecode format for executing untrusted code from the network and running a UI-capable application with controlled access to the system, that runs in a secure sandbox. This is java applets but better.

You have the same issue on mobile where regular websites create apps, so they can be persistent and have access to things they shouldn't, and be all naughty. This happens because somehow we treat "native" differently than "web". it should all be restricted like web apps are, sandboxed tightly, but given access to resources like any electron app would (but not your entire file system, or entire anything, ever!)

There shouldn't be any "installing" anything, perhaps bookmarking an app instead. I'm not saying let's do away with proper native apps, non-GUI apps still have a place, as do system services and extensions which are a whole other class of system applications. But your banking app isn't one of those, neither is a social media app, or a photo editor, a game, uber,etc.. all these can run in WASM, and WASM in turn gets native access to APIs similar to but not exactly web apis. I learned in that other comment thread that replicating the web DOM APIs for WASM is a foolish effort since it is all built with JS in mind. However, an HTML5 compatible DOM layer, that is distinct from DOM-manipulation layers, and has a low-level styling layer (not a best like CSS, but something CSS can be compiled into, or that WASM styling code would natively compile into).

You will still need something to run the WASM like browsers do today, but here is the biggest value of my proposal: Unlike browsers, this would be heavily standardized, and as far as how your WASM renders and manipulates the DOM, that would be extremely consistent across WASM browsers, mainly because it would be so low-level there won't be any opinionated subjective interpretations between host apps. Unlike JS, there won't be any script runtime, unlike CSS, there is no styling engine. The responsibility of a beast like V8 is divided so that DOM, styling,security and API interactions are strongly defined in bytecode/ABI by the standard for the WASM host/browser, the actual UI of the app (tabs, themes, extensions,bookmarks, history,etc..) would not be different between WASM host/browsers, and of course the app's logic would be defined in whatever language, which will be compiled into WASM bytecode compatible with the aforementioned standard. This should result in consistent UI, fully networked apps with controlled resource access, that run ephemerally (caching as desired), storing persistent data as needed (no software updates per-app).

It is a lot of effort but consider the state of computing, between mobile apps, things like flatpak, electron, tauri, "vendoring", PWA apps, bloated chat apps like slack, teams, element, discord, web framework mess,etc.. is this the chaos we want to leave the next generation?

It might take a long time, but isn't it good to "build trees under whose shade you'll never sit"?

Re: Making WebAssembly a first-class language on the Web

#172
Nothing can't be first-class as long as it is not *directly* replacing the existing first-class citizens.

If Wasm modules can be loaded like this:

    
...and if Wasm could access the DOM like this:

    import dom, json, re, html, urllib.parse
    from datetime import datetime
    
    params = urllib.parse.urlencode({"category": "news", "limit": 10})
    data = json.loads(await (await fetch(f"https://api.example.com/data?{params}")).string())
    container = js.document.getElementById("app")
    container.innerHTML = "".join(f"..." for i in data["items"])

...then developers would have jumped in right away.

Re: Making WebAssembly a first-class language on the Web

#173

Earlier quoted context omitted.

I really want stringref to make a comeback.

My god yes. I'm building a new Wasm GC-based language and I'm trying to make as small as binaries as possible to target use cases like a module-per-UI-component, and strings are the biggest hinderance to that. Both for the code size and the slow JS interop.

Who killed stringref and why?

Re: Making WebAssembly a first-class language on the Web

#174

The web is fascinating: we started with a seemingly insane proposition that we could let anyone run complex programs on your machine without causing profound security issues. And it turned out that this was insane: we endured 20 years of serious browser security bugs caused chiefly by JavaScript. I'm not saying it wasn't worth it, but it was also crazy. And now that we're getting close to have the right design princi…

It's worth it if it gets rid of JavaScript

"out of the frying pan into the fire"...

I'd like to avoid wasm too...

Re: Making WebAssembly a first-class language on the Web

#175

Earlier quoted context omitted.

> Two goals that were added were: 1. Support non-Web API's. 2. Support limited cross language interop. I mean, surely it does not come to a surprise to anyone that either of these is a huge deal, let alone both. It seems clear that non-Web runtimes have had a huge influence on the development priorities of WebAssembly—not inherently a bad thing but in this case it came at the expense of the actual Web. > WebIDL is th…

Technology with "web" in the name, invented by Web fanboys, not really much good for working with key web API's like the DOM. Cool parts of the webassembly technology aside - this should be no surprise to anybody. News at 11. The non-sequitur in the title of this post should be enough to give everybody pause. Waiting for someone to chime in and tell me that the "web" in "webassembly" wasn't meant to refer to the "wor…

The web part is the security model and the tradeoffs between security and performance. PNaCL was in browsers but not "web" for this reason.

Like the assembly part means low-level and meant as a compilation target, not CPU instructions.

So websssembly is an assembly language for the web, like webgl is opengl for the web and webgpu are gpu APIs for the web. And behold none of those can access DOM APIs

Re: Making WebAssembly a first-class language on the Web

#176
I think WASM's real problem is language fragmentation. For 3D apps, C++ makes sense. But Go and other GC languages don't perform well on WASM - they implemented their own GC anyway. And honestly, I don't see the advantage of writing web apps in Rust over JS. The ecosystem, tooling, and debugging are all better with JS.

Re: Making WebAssembly a first-class language on the Web

#177

Earlier quoted context omitted.

Javascript isn't more insecure than any other language. Any language can have the same or other security issues.

Yeah, but you're not normally going to random websites, downloading an exe and running it. But every website you visit can run JS on your computer (as long as you don't disable JS). So maybe JS should be more secure than any other language.

> Yeah, but you're not normally going to random websites, downloading an exe and running it.

Most or many of secure mobile operating system zero days are caused by image parsing. There is a threat at least as big, if not bigger, in parsing complex file formats.

Sure gopher or gemini would be more secure, but even without JS the web ecosystem would be venerable.

Re: Making WebAssembly a first-class language on the Web

#178
I already hate it

There is a massive, pathetic drop in quality from the system designs of the past compared to the garbage we are seeing nowadays

You can tell they are fully embracing slop and stupid design

Tehy are trading efficiency and elegance for bloat, and it is absolute trash

They have stopped engineering, they abstraction junkies

OGs don't want to be associated with any of that trash, and it shows

Re: Making WebAssembly a first-class language on the Web

#179

If you’d like to get acquainted with modern WebAssembly, check out the component model book: https://component-model.bytecodealliance.org/ It includes high level concepts, practical code samples and more that introduce the really powerful parts of WebAssembly. With regards to the JS ecosystem specifically there are 3 projects to know: https://github.com/bytecodealliance/StarlingMonkey https://github.com/bytecodeallia…

Get your blatant component model propaganda outta here ;)

(to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly", just an option built on top of it, and of questionable value tbh)

Re: Making WebAssembly a first-class language on the Web

#180

Earlier quoted context omitted.

Technology with "web" in the name, invented by Web fanboys, not really much good for working with key web API's like the DOM. Cool parts of the webassembly technology aside - this should be no surprise to anybody. News at 11. The non-sequitur in the title of this post should be enough to give everybody pause. Waiting for someone to chime in and tell me that the "web" in "webassembly" wasn't meant to refer to the "wor…

Web assembly has never had anything to do with the web. At least that's been my experience whenever I find it in production.

It definitly had to do everything with Web, it was the agreement between Mozila going with asm.js, Chrome pushing for PNaCL, Adobe with CrossBridge, Sun with Java, Microsoft with ActiveX,....

Then some folks rediscovered UNCOL from 1958, all the systems influenced by it, and started to sell the dream of the bytecode that was going to save the world.

Post reply on HN