Live data from Hacker News

When Is WebAssembly Going to Get DOM Support?

queue.acm.org

61–70 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#61
post #18

Earlier quoted context omitted.

WASM certainly had the potential for this, but I am afraid without direct DOM access it is never going to happen.

It is happening. Leptos is an example: https://www.leptos.dev/ Dioxus is another: https://dioxuslabs.com/ C# with Avalonia for a different use case: https://avaloniaui.net/ Avalonia solitaire demo: https://solitaire.xaml.live/ Avalonia Visual Basic 6 clone: https://bandysc.github.io/AvaloniaVisualBasic6/ Blazor can run as WebAssembly on the client side if you choose that runtime mode: https://dotnet.microsoft.com/en-…

how'd you compare dioxus and leptos?

Re: When Is WebAssembly Going to Get DOM Support?

#62

I'm worried that wide use of WASM is going to reduce the amount of abilities extensions have. Currently a lot of websites are basically source-available by default due to JS.

> Currently a lot of websites are basically source-available by default due to JS.

By default maybe, but JS obfuscators exist so not really. Many websites have totally incomprehensible JS even without obfuscators due to extensive use of bundlers and compile-to-JS frameworks.

I expect if WASM gets really popular for the frontend we'll start seeing better tooling - decompilers etc.

Re: When Is WebAssembly Going to Get DOM Support?

#63
It's not just the DOM, it's also all other APIs like WebGL2.

I ended up having to rewrite the entire interfacing layer of my mobile application (which used to be WebAssembly running in WebKit/Safari on iOS) because I was getting horrible performance losses each time I crossed that barrier. For graphics applications where you have to allocate and pass buffers or in general piping commands, you take a horrible hit. Firefox and Chrome on Windows/macOS/Linux did quite well, but Safari...

Everything has to pass the JavaScript barrier before it hits the browser. It's so annoying!

Re: When Is WebAssembly Going to Get DOM Support?

#64

I'm worried that wide use of WASM is going to reduce the amount of abilities extensions have. Currently a lot of websites are basically source-available by default due to JS.

With minimisers and obfuscators I don't see wasm adding to the problem.

I felt something was really lost once css classes became randomised garbage on major sites. I used to be able to fix/tune a website layout to my needs but now it's pretty much a one-time effort before the ids all change.

Re: When Is WebAssembly Going to Get DOM Support?

#65

The web is a platform that has so much unrealized potential that is absolutely wasted. Wasm is the perfect example of this - it has the potential to revolutionize web (and desktop GUI) development but it hasn't progressed beyond niche single threaded use cases in basically 10 years.

It should never have been web assembly. WASM is the fulfillment of the dream that started with Java VM in the 90’s but never got realized. A performant, truly universal virtual machine for write-once, run anywhere deployment. The web part is a distraction IMHO.

"Dream", well until you think about i18n and a11y..

Re: When Is WebAssembly Going to Get DOM Support?

#66

Earlier quoted context omitted.

Why did Java fail though, and why would wasm succeed when the underlying philosophy is the same?

I asked a number of times on HN why wasm was good when java applets, exactly the same thing, were bad. There was a vague feeling that java applets were insecure and that this would somehow not be an issue for wasm. It's not just applets; we also had Flash, which was a huge success until it was suddenly killed. As far as I can tell, the difference between java applets and Flash is that you, the user, have to install j…

> There was a vague feeling that java applets were insecure and that this would somehow not be an issue for wasm.

Nothing "vague" or "somehow" about that.

Applets were insecure, because A) they were based on the Netscape browser plugin API, which had a huge attack surface, and B) they ran in a normal JVM with a standard API that offeres full system access, restricted by a complex sandbox mechanism which again had a huge attack surface.

This IS, in fact, not an issue for wasm, since A) as TFA describes it has by default no access at all to the JavaScript browser API and has to be granted that access explicitly for each function, and B) the JavaScript browser API has extremely restricted access to OS functionality to begin with. There simply is no API at all to access arbitrary files, for example.

Re: When Is WebAssembly Going to Get DOM Support?

#67

Earlier quoted context omitted.

Why did Java fail though, and why would wasm succeed when the underlying philosophy is the same?

I asked a number of times on HN why wasm was good when java applets, exactly the same thing, were bad. There was a vague feeling that java applets were insecure and that this would somehow not be an issue for wasm. It's not just applets; we also had Flash, which was a huge success until it was suddenly killed. As far as I can tell, the difference between java applets and Flash is that you, the user, have to install j…

There wasn't a vague feeling. Both kept getting exploited. My favorite is Trusted Method Chaining, which is hard to find a reference on now, but showed the whole Java security model was fundamentally flawed. These days that security model has simply been removed: all code in the VM is assumed to run in the privilege level of the VM.

WASM sandboxes the entire VM, a safer model. Java ran trusted and untrusted code in the same VM.

Flash, while using the whole-VM confinement model, simply had too many "boring" exploits, like buffer overflows and so on, and was too much of a risk to keep using. While technically nothing prevented Flash from being safe, it was copyright Adobe and Adobe didn't make it safe, and no one else was allowed to.

Re: When Is WebAssembly Going to Get DOM Support?

#68

The web is a platform that has so much unrealized potential that is absolutely wasted. Wasm is the perfect example of this - it has the potential to revolutionize web (and desktop GUI) development but it hasn't progressed beyond niche single threaded use cases in basically 10 years.

Give me one thing that your theoretical WASM can "revolutionize". Aside from more efficient covert crypto mining on shady sites.

High performance web-based applications is pretty high on my list.

Low memory usage and low CPU demand may not be a requirement for all websites because most are simple, but there are plenty of cases where JavaScript/TypeScript is objectively the wrong language to be using.

Banking apps, social network sites, chat apps, spreadsheets, word processors, image processors, jira, youtube, etc

Something as simple as multithreading is enough to take an experience from "treading water" to "runs flawlessly on an 8 year old mobile device". Accurate data types are also very valuable for finance applications.

Another use case is sharing types between the front and back end.

Re: When Is WebAssembly Going to Get DOM Support?

#69

Earlier quoted context omitted.

It should never have been web assembly. WASM is the fulfillment of the dream that started with Java VM in the 90’s but never got realized. A performant, truly universal virtual machine for write-once, run anywhere deployment. The web part is a distraction IMHO.

Why did Java fail though, and why would wasm succeed when the underlying philosophy is the same?

I'm not sure how it's for others, but for me there was a perception issue with java applets on the web in the mid 2000s:

Java applets loading on a website started as a gray rectangle, which loaded very slowly, and sometimes failed to initialize with an "uninited" error. Whenever you opened a website with a java applet (like could happen with some math or physics related ones), you'd go "sigh" as your browser's UI thread itself halted for a while

Flash applets loading on a website started as a black rectangle, did not cause the UI thread to halt, loaded fast, and rarely gave an error

(the only reason I mention the gray vs black rectangle is because seeing a gray rectangle on a website made me go "sigh")

JavaScript was not yet optimized but the simple JS things that worked, did work without loading time.

Runescape (a 3d MMORPG from the early 2000s that still exists) used Java though and somehow they managed to use it properly since that one never failed to load and didn't halt the browser's UI either despite being way more complex than any math/physics Java applet demo. So if Java forced their applets to do whatever Runescape was doing so correctly, they'd not have had this perception issue...

Re: When Is WebAssembly Going to Get DOM Support?

#70

The web is a platform that has so much unrealized potential that is absolutely wasted. Wasm is the perfect example of this - it has the potential to revolutionize web (and desktop GUI) development but it hasn't progressed beyond niche single threaded use cases in basically 10 years.

It should never have been web assembly. WASM is the fulfillment of the dream that started with Java VM in the 90’s but never got realized. A performant, truly universal virtual machine for write-once, run anywhere deployment. The web part is a distraction IMHO.

What would you propose if you were to rename it?

Generalized Assembly? GASM?

Post reply on HN