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

WebAssembly support now shipping in all major browsers

blog.mozilla.org

Post reply on HN
Print view View original

321–330 of 346 posts

Re: WebAssembly support now shipping in all major browsers

#321

Post by [deleted] »

exDM69 wrote: post #86
zurn wrote: post #64

Earlier quoted context omitted.

SIMD is like the kids version of GLSL, which works today :)

Running anything with the GPU introduces a huge amount of latency, it only makes sense when you need high throughput and have large enough workloads to justify the latency. SIMD code can be interleaved with normal native code with zero latency. And then there's the fact that WebGL is so much behind the state of the art that it's not even funny. Sticking to an old version of GL/GLSL severely limits what you can do wit…

[deleted]

Re: WebAssembly support now shipping in all major browsers

#322

Post by steveklabnik »

austincheney wrote: post #255
sli wrote: post #244

Earlier quoted context omitted.

I am extremely unclear on whatever point you're trying to make, here, because it really does seem to come from a place of ignorance on WASM and JS. It makes no sense. It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access, even though it's planned[1]. There are even VDOMs[2] for WASM already. Future WASM implementations that include DOM access can absolutely, and for many folk…

> It seems like you're claiming, in a really roundabout way, that WASM will never have DOM access I am not going to say never . It does not now and will not for the foreseeable future though. I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority. Part of the problem in implementing DOM access to a unrestricted bytecode format is security. Nobody wants to relax security…

> I know DOM interop is a popular request, but nobody has started working on it and it isn't a priority.

I linked to the latest proposal downthread; people are absolutely working on this.

Re: WebAssembly support now shipping in all major browsers

#324

Post by steveklabnik »

rl3 wrote: post #320
boomlinde wrote: post #163

Earlier quoted context omitted.

> We're still a long ways off from garbage-collected languages inside wasm. I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult? For what it's worth, here's Lua (which implements a garbage collector in its runtime) in WebAssembly: https://github.com/vvanders/wasm_lua

> I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult? Yes, in that you'd have to implement the GC inside the wasm module itself (as in your example). In contrast to other languages, Lua is very lightweight. Many GCs are non-trivial. Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story…

> Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better.

I commented with a link elsewhere, but it seems that people have found a way around that!

Re: WebAssembly support now shipping in all major browsers

#325

Post by tyingq »

austincheney wrote: post #225
greenhouse_gas wrote: post #174

Earlier quoted context omitted.

There's another reason why I want JavaScript in the browser to die: We haven't had a new browser engine written from scratch since KHTML. Firefox is a descendant of Netscape, Chrome (and Safari) is a descendant of WebKit which is itself a descendant of KHTML, Edge is closed source, but I'm almost sure there's some old IE code in there. Why? It's simply too expensive to create a fast (and compatible) JS engine. If Web…

WebAssembly has nothing to do with JavaScript. When people make this association it is clear they are painfully unaware of what each (or both) technologies are. WebAssembly is a replacement for Flash, Silverlight, and Java Applets.

At the moment it is because the only performant visual output is the canvas.

They are adding native DOM access, which changes things.

Re: WebAssembly support now shipping in all major browsers

#326

Post by krapp »

rhabarba wrote: post #184

WebAssembly is not worth the effort unless it finally is supported by the LINK tag. Seriously, using JS to load a JS alternative is ridiculous.

Before HTML5 deprecated it, it was assumed that browsers would just supply plugins to support various scripting languages or whatever, which is why the tag had a type attribute.

Unfortunately, integrating a new runtime like will probably never happen. A link tag, to me, specifies a static resource rather than executable code (although since CSS supports animations now that's probably a distinction without a difference.) might be a good candidate but I don't know if it's still supported.

But, we can't get rid of JS altogether. Browsers will have to support javascript indefinitely, otherwise most of the web becomes unreadable. That being the case, using JS to load WebAssembly seems like the most reasonable backwards-compatible compromise available.

Re: WebAssembly support now shipping in all major browsers

#327

Post by austincheney »

askvictor wrote: post #312
austincheney wrote: post #310

Earlier quoted context omitted.

Yes and no. The language specification requires the use of semicolons. If a semicolon is not supplied the interpreter will insert it for you. That magical insertion step is referred to as ASI. I don't remember if ASI is mentioned in the spec (as I don't think it is), but at the very least it is a de facto standard as missing ASI breaks the web. As stupid as all that sounds... semicolons are actually required to termi…

And yet somehow the web doesn't break when one programmer uses \r\n while another uses \n. What was your original point about line terminators in this context?

I suppose that goes to how the language defines line termination and whether that language is OS aware. JS is completely independent of its execution context. Python may achieve this as well, and if so, then I am wrong in my thoughts about Python.

Here is how JavaScript does this:

* https://www.ecma-international.org/ecma-262/#sec-source-text

* https://www.ecma-international.org/ecma-262/#sec-line-termin...

ASI is defined in the spec here: https://www.ecma-international.org/ecma-262/#sec-automatic-s...

Re: WebAssembly support now shipping in all major browsers

#328

Post by austincheney »

sixdimensional wrote: post #291
austincheney wrote: post #230

Earlier quoted context omitted.

Currently DOM interop is a distant wishlist, so I wouldn't hold my breath. JavaScript isn't a perfect language, but it does have native lexical scope, which makes it a good fit for the architecture of web technologies. > Seriously JS should not be the lingua franca of the web What would you recommend for a replacement? When I typically see this it is from people can't figure out JavaScript as opposed to any rational…

If you have the ability to compile to WASM, and a little glue in the form of an isomorphic application framework (something to glue together server-side with client-side processes), I'd say it's quite a compelling alternative to JS. If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end…

> If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one?

That is not necessarily a language oriented concept. JavaScript can run on the front-end and back-end having an MVC architecture at both points. A better question is why a developer should wish to impose MVC at all at either point?

These concepts become easier to reason about when the software runs at a single location using an HTTP service (on localhost) to talk amongst its clusters. It is just a multiprocess application with the bits running asynchronously from each other.

When one (or more) ends of the environment are distant factors change drastically. First, you don't control the remote environment. You are completely at the mercy of what the user is willing to execute and they may modify your application in ways you do not anticipate. Secondly, there is a delay between distant ends.

Regardless of the application or language in question the environmental and security considerations at hand will continue to impose a separated JavaScript-like web application.

Re: WebAssembly support now shipping in all major browsers

#329

Post by rl3 »

steveklabnik wrote: post #324
rl3 wrote: post #320

Earlier quoted context omitted.

> I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult? Yes, in that you'd have to implement the GC inside the wasm module itself (as in your example). In contrast to other languages, Lua is very lightweight. Many GCs are non-trivial. Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story…

> Moreover, proper GC support is a piece of the puzzle for the wasm/JS/DOM interop story to get better. I commented with a link elsewhere, but it seems that people have found a way around that!

Relevant discussions in case anyone's interested:

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

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

I didn't see those, thanks. That's good news. Hopefully host bindings land sooner now than they otherwise would have if tied to the GC proposal.

The wasm32-unknown-unknown LLVM backend target for Rust is also quite exciting. I say this after having just spent a minor eternity compiling the Emscripten toolchain. :)

Re: WebAssembly support now shipping in all major browsers

#330

Post by CyberDildonics »

themihai wrote: post #313
CyberDildonics wrote: post #309

Earlier quoted context omitted.

> not to do just server-side stuff He didn't say anything about 'only server side stuff'. There is plenty that has already been demonstrated with webasm - video editing and filtering, audio editing and filtering, advanced computer graphics, direct porting of games, etc.

>> There is plenty that has already been demonstrated with webasm - video editing and filtering, audio editing and filtering, advanced computer graphics, direct porting of games, etc. Even for that it doesn't work without some js. The promise was that you can use your favorite language for web development and that's not the case. WASM is now more about the integration with JS.

The point also isn't that you don't need any javascript. It seems like people really aren't getting that webasm enables new things to be possible. Using javascript to bridge to certain APIs really hasn't been a problem. WebGL already works well, even with pure javascript. Between JIT compiling and bulk transfer functions, there aren't actually that many calls happening per frame.

> The promise was that you can use your favorite language for web development

I can see where you are confused. The promise was never about using your favorite language for web development. It was about being able to compile languages to a synthetic ISA that will run at near native speeds.

> WASM is now more about the integration with JS.

It was never about getting away from javascript, it was always about being able to run software at near native CPU speeds in the browser.

Post reply on HN