Live data from Hacker News

Making WebAssembly a first-class language on the Web

hacks.mozilla.org

201–210 of 287 posts

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

#201
post #101

I love WebAssembly components and that's great progress. But I feel like everyone is missing a golden opportunity here to take apart the giant OS-sized web API and break some of it out into smaller standard or subscribable subsets that also don't try to mix information presentation and applications in a forced way. Example subsets: - (mainly textual) information sharing - media sharing - application sharing with, sma…

iirc webassembly components need to explicitly import anything they use, so it should be transparent which dependencies something has by just grepping its WIT for `import`

I wonder what a 'mixed model' would look like (e.g. is it even possible), e.g. an application which wants to call into component model APIs, but at the same time also needs to call into JS code which then accesses the same APIs. This hybrid model will definitely be needed for any non-trivial web application.

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

#202
post #101

I love WebAssembly components and that's great progress. But I feel like everyone is missing a golden opportunity here to take apart the giant OS-sized web API and break some of it out into smaller standard or subscribable subsets that also don't try to mix information presentation and applications in a forced way. Example subsets: - (mainly textual) information sharing - media sharing - application sharing with, sma…

Yeah, the web API layer stack is essentially inverted, and important parts are missing entirely. Ideally there would be a 3D API at the bottom, on top of that a text-and-font API (e.g. allow to render high quality text into a 3D-API surface without bringing your own text renderer), to the side a vector/shape rendering API as the base for SVG, and a layouting/compositing API, the DOM should only be implemented on top that.

The chance for that ever materializing is most like zero though.

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

#204
post #181

Earlier quoted context omitted.

Hello COM, CORBA, RMI, Jini, .NET Remoting, Tcl Agents,..., that is basically what it is.

Very reductive :) there are flavors and hints of all these previous technologies /paradigms in WebAssembly + Component Model today, because only fools would attempt to build something without considering relevant prior art. Won't bother trying going through differences/how-this-is-not-that but I'll say this: This time, it's slightly better, just like every time before. I'd even go so far as to say this iteration is m…

So far I haven't seen that on the existing tooling, nothing that would make me say it is much better, rather it looks much worse given the developer experience.

Zero IDE integration, no right mouse click to generate or consume interfaces/stubs, no debugging tools, no integration with existing toolchains like those alternatives, no wire debugging,....

It feels designed for those that never left the command line, vim and emacs kind of world.

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

#206
I agree with the direction, but it seems to miss the golden hour. This concept should have been on the roadmap at least several years ago. After all, in most use cases, execution speed is not the main issue with JavaScript.

I believe that the need for JavaScript glue code has significantly hindered the appeal and interest in WASM, as well as the resulting ecosystem growth.

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

#207
post #203

Say goodbye to writing multiple kinds of plugins and userscripts for random websites I guess. I don't want the transition to wasm because it looks like it will make most things unchangeable binary blobs

I don't follow? when you write userscripts you modify the dom not the already running scripts usually, no?

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

#208
This was supposed to happen already in the 2000s. JVM in everywhere, especially in the browser. There was Java rings you could wear, Java Card VM (JCVM), Squawk VM, Java ME.

"Java the language is almost irrelevant. It's the design of the Java Virtual Machine. And I've seen compilers for ML, compilers for Scheme, compilers for Ada, and they all work. Not many people use them, but it doesn't matter: they all work." --James Gosling

Then Microsoft happened. MS realized that "Write Once, Run Anywhere" kills their OS monopoly, so they polluted Java with brilliant Embrace, Extend, Extinguish strategy (Sun vs. Microsoft revealed the emails where the stated goal was "Kill cross-platform Java" by growing the "polluted" Java market.):

Embrace: Microsoft licensed Java from Sun Microsystems and built the MSJVM. It was the fastest JVM for some time.

Extend: They created a programmer tool for Java with proprietary Windows-specific "extensions" and also removed standard features like RMI and JNI.

Extinguish: Developers using MS tools (90% of devlopers at the time) produced "Write Once, Run Only on Windows" software and killed it and pivoted to C# and .NET

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

#209

It's still not a great idea IMHO ;) (there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837 ) E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM. E.g. if I main…

Your logic is circular though. You are saying that there won't be much speedup for the sort of things people already do in WASM - but the reason they're doing them in WASM is because they're not slowed down too much.

What you don't get much is people doing standard SPA DOM manipulation apps in WASM (e.g. the TodoMVC that they benchmarked) because the slowdown is large. By fixing that performance issue you enable new usecases.

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

#210

It's still not a great idea IMHO ;) (there was also some more recent discussion in here: https://news.ycombinator.com/item?id=47295837 ) E.g. it feels like a lot of over-engineering just to get 2x faster string marshalling, and this is only important for exactly one use case: for creating a 1:1 mapping of the DOM API to WASM. Most other web APIs are by far not as 'granular' and string heavy as the DOM. E.g. if I main…

Your logic is circular though. You are saying that there won't be much speedup for the sort of things people already do in WASM - but the reason they're doing them in WASM is because they're not slowed down too much. What you don't get much is people doing standard SPA DOM manipulation apps in WASM (e.g. the TodoMVC that they benchmarked) because the slowdown is large. By fixing that performance issue you enable new…

IMHO the bang-for-the-buck proportion isn't right. The core problem is slow string marshalling in the JS shim (because it needs to create a JS string object from an ArrayBuffer slice - where the array buffer is the WASM heap).

Integrating the component model into browsers just for faster string marshalling is 'using cannons to shoot sparrows' as the German saying goes.

If there would be a general fast-path for creating short-lived string objects from ArrayBuffer slices, the entire web ecosystem would benefit, not just WASM code.

Post reply on HN