Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Is WebAssembly Going to Get DOM Support?

queue.acm.org

Post reply on HN
Print view View original

131–140 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#131

Post by giancarlostoro »

xg15 wrote: post #116

Is there any data on the performance cost of JS/WASM context switches? The way the architecture is described, it sounds as if the costs could be substantial, but the approaches described in the article basically hand them out like candy. This would sort of defeat the point that WASM is supposed to be for the "performance critical" parts of the application only. It doesn't seem very useful if your business logic runs…

Not entirely sure, but C#'s Blazor is amazing. I can stick to purely C# code, front-end and back-end, we rarely call out to JS unless its for like file uploading dialogs. I don't want to ever touch JavaScript again after this workflow.

Edit:

And if you don't want to do "WebAssembly" you can have it do it all server rendered, think of a SPA on steroids.

Re: When Is WebAssembly Going to Get DOM Support?

#132

Post by markdog12 »

xg15 wrote: post #116

Is there any data on the performance cost of JS/WASM context switches? The way the architecture is described, it sounds as if the costs could be substantial, but the approaches described in the article basically hand them out like candy. This would sort of defeat the point that WASM is supposed to be for the "performance critical" parts of the application only. It doesn't seem very useful if your business logic runs…

Yeah, it's very unfortunate for WebGL/WebGPU apps, where every call has to pass/convert typed arrays and issue a js gl call. It pretty much kills any advantage of using WASM. Hope that changes.

Re: When Is WebAssembly Going to Get DOM Support?

#133

Post by DonHopkins »

secondcoming wrote: post #46
adastra22 wrote: post #43

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?

Oracle bought Sun and now owns Java, remember? All technical discussions about Java -vs- any other languages can now be immediately terminated by mentioning the word "Lawnmower", which overrides all technical issues.

https://news.ycombinator.com/item?id=15886728

Re: When Is WebAssembly Going to Get DOM Support?

#134

Post by shagmin »

diffuse_l wrote: post #54
thaumasiotes wrote: post #51

Earlier quoted context omitted.

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…

Flash was a security nightmare, with multiple vulnerabilities discovered regularly. It was eventually killed because Apple decided it won't support it on the iPhone.

And conveniently around the same time javascript was rapidly evolving.

Re: When Is WebAssembly Going to Get DOM Support?

#135

Post by breve »

markdog12 wrote: post #132
xg15 wrote: post #116

Is there any data on the performance cost of JS/WASM context switches? The way the architecture is described, it sounds as if the costs could be substantial, but the approaches described in the article basically hand them out like candy. This would sort of defeat the point that WASM is supposed to be for the "performance critical" parts of the application only. It doesn't seem very useful if your business logic runs…

Yeah, it's very unfortunate for WebGL/WebGPU apps, where every call has to pass/convert typed arrays and issue a js gl call. It pretty much kills any advantage of using WASM. Hope that changes.

WebAssembly is the faster option for WebGL applications on the web, not least because you also might want to run things like physics engines:

https://playgama.com/blog/general/boost-html5-game-performan...

Re: When Is WebAssembly Going to Get DOM Support?

#136

Post by markdog12 »

breve wrote: post #135
markdog12 wrote: post #132

Earlier quoted context omitted.

Yeah, it's very unfortunate for WebGL/WebGPU apps, where every call has to pass/convert typed arrays and issue a js gl call. It pretty much kills any advantage of using WASM. Hope that changes.

WebAssembly is the faster option for WebGL applications on the web, not least because you also might want to run things like physics engines: https://playgama.com/blog/general/boost-html5-game-performan...

All depends on your app, of course. My point is having additional overhead for every gl call is pretty bad.

Re: When Is WebAssembly Going to Get DOM Support?

#137

Post by sitkack »

markdog12 wrote: post #132
xg15 wrote: post #116

Is there any data on the performance cost of JS/WASM context switches? The way the architecture is described, it sounds as if the costs could be substantial, but the approaches described in the article basically hand them out like candy. This would sort of defeat the point that WASM is supposed to be for the "performance critical" parts of the application only. It doesn't seem very useful if your business logic runs…

Yeah, it's very unfortunate for WebGL/WebGPU apps, where every call has to pass/convert typed arrays and issue a js gl call. It pretty much kills any advantage of using WASM. Hope that changes.

How can you reconcile this with all of the AAA games that have been shown to work well on Wasm+WebGL ? What is different between your usage and theirs?

Re: When Is WebAssembly Going to Get DOM Support?

#138

Post by DonHopkins »

Aardwolf wrote: post #69
secondcoming wrote: post #46

Earlier quoted context omitted.

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 thr…

That's because Java used the old piece-of-shit NPAPI (Netscape Plugin Application Programming Interface) from 1995, first released in the NetScape 2.0b3 Plug-in SDK:

https://en.wikipedia.org/wiki/NPAPI

Problems Found with the NetScape Plug-in API. By Don Hopkins, Kaleida Labs:

https://donhopkins.com/home/archive/netscape/Netscape-Plugin...

More about Netscape's fleeting obsession with Java and Javagator in the pre-LiveConnect/XPConnect/NPRuntime/ActiveX/DHTML/XPCOM/XUL days:

https://news.ycombinator.com/item?id=22708076

>I hope NetScape can come up with a plug-in interface that is good enough that they can implement their own navigator components with it (like the mail reader, outliner, progressive jpeg viewer, etc). The only way it's going to go anywhere is if they work closely with developers, and use the plug-in interface for non-trivial things themselves. Microsoft already has a VRML plug-in for their navigator, so presumably they have a plug-in interface, and from what I've seen on their web site, it may not be "good enough", but it's probably going to do a lot more that you can do with NetScape right now, since they're exposing a lot of their navigator's functionality through OLE. They seem to understand that there's a much bigger picture, and that the problems aren't trivial. Java isn't going to magically solve all those problems, folks.

Early Browser Extension Wars of 1996:

https://news.ycombinator.com/item?id=19837817

>Wow, a blast from the past! 1996, what a year that was.

>Sun was freaking out about Microsoft, and announced Java Beans as their vaporware "alternative" to ActiveX. JavaScript had just come onto the scene, then Netscape announced they were going to reimplement Navigator in Java, so they dove into the deep end and came up with IFC, which designed by NeXTStep programmers. A bunch of the original Java team left Sun and formed Marima, and developed the Castanet network push distribution system, and the Bongo user interface editor (like HyperCard for Java, calling the Java compiler incrementally to support dynamic script editing).

More about browser extension APIs:

https://news.ycombinator.com/item?id=27405137

>At the time that NSAPI came around, JavaScript wasn't really much of a thing, and DHTML didn't exist, so not many people would have seriously thought of actually writing practical browser extensions in it. JavaScript was first thought of more as a way to wire together plugins, not implement them. You were supposed to use Java for that. To that end, Netscape developed LiveConnect.

>Microsoft eventually came out with "ActiveX Behavior Components" aka "Dynamic HTML (DHTML) Behaviors" aka "HTML Components (HTCs)" that enabled you to implement ActiveX controls with COM interfaces in all their glory and splendor, entirely in Visual Basic Script, JavsScript, or any other language supporting the "IScriptingEngine" plug-in interface, plus some XML. So you could plug in any scripting language engine, then write plug-ins in that language! (Easier said than done, though: it involved tons of OLE/COM plumbing and dynamic data type wrangling. But there were scripting engines for many popular scripting languages, like Python.)

Javagator Down Not Out:

https://www.cnet.com/tech/tech-industry/javagator-down-not-o...

>Though Netscape has ceased development efforts on its Java-based browser, it may pass the baton to independent developers.

Shockwave (the Macromedia Director Player Library) came long before Flash, and it used NPAPI (and ActiveX on IE), but later on, Google developed another better plug-in interface called "Pepper" for Flash.

1995: Netscape releases NPAPI for Netscape Nagivator 2.0, Macromedia releases Shockwave Player on NPAPI for playing Director files

1996: Microsoft releases ActiveX, FutureWave releases FutureSplash Animator and NPAPI player for FutureSplash files, Macromedia acquires FutureSplash Animator and renames it Flash 1.0

2009: Google releases PPAPI (Pepper Plugin API) as part of the Native Client project, suddenly Flash runs much more smoothly

Re: When Is WebAssembly Going to Get DOM Support?

#139

Post by landonxjames »

hardwaresofton wrote: post #31

Disclaimer: I work on Jco, one of the user-facing Bytecode Alliance WASM JS ecosystem projects Just a note, but there is burgeoning support for this in "modern" WebAssembly: https://github.com/bytecodealliance/jco/tree/main/examples/c... If raw WebIDL binding generation support isn't interesting enough: https://github.com/bytecodealliance/jco/blob/main/packages/j... https://github.com/bytecodealliance/jco/blob/main/p…

I have used Jco quite a bit (and contributed a few times) to build out simple utilities binding Rust code to JS [1][2]. I think it is great and the Component Model is the most exciting step towards real useful polyglot libraries I have seen in years. I wish it were better publicized, but I understand keeping things lowkey until it is more fleshed out (the async and stream support coming in Preview 3 are the real missing pieces for my usecases).

[1] https://github.com/awslabs/aws-wasm-checksums [2] https://github.com/landonxjames/aws-sdk-wasi-example

Re: When Is WebAssembly Going to Get DOM Support?

#140

Post by msgodel »

adastra22 wrote: post #43
apatheticonion wrote: post #41

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.

The classpath that came with the JVM was much more well thought out than the web is. That's the real problem.
Post reply on HN