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

Assembling WebAssembly

webkit.org

Post reply on HN
Print view View original

51–60 of 91 posts

Re: Assembling WebAssembly

#51

Post by pjmlp »

pizlonator wrote: post #4
JoshTriplett wrote: post #3

I really look forward to the day when WebAssembly stops being seen as "JavaScript's fast sidekick" and starts being seen as "the language of the web". It won't take that much to expose APIs directly to WebAssembly rather than just to JavaScript.

We're a long way away from that. Here's what you'd need: - GC types in WebAssembly. That's still an open problem, but that would give you API access. - Ability to load WebAssembly via something like . - WebAssembly would have to load and start as quickly as JS. The last one is probably the hardest in the long run, since wasm is being optimized for the kinds of apps where you want to pay some cost up front so that you…

> GC types in WebAssembly. That's still an open problem, but that would give you API access.

Nothing prevents one to implement a GC on top of existing WebAssembly as it is, no different than when implementing bare metal runtimes.

Of course having a GC as part of WebAssembly does simplify implementations, but only as an easy solution, because the best GC implementations need to be language aware for optimal performance.

Re: Assembling WebAssembly

#52

Post by merb »

jfbastien wrote: post #22
merb wrote: post #21

Earlier quoted context omitted.

I'm not sure if that is true. our application takes at least 100ms or more to parse. only parsing. on Safari 10.1.1 on a macbook pro 2013 late. well chrome and firefox is as slow as that. I don't think the same stuff in WebAssembly would take that long (i.e. angular 1 application, if we add angular 4 which we are planning it will prolly take even longer since we need more vendor stuff.)

Link to repro?

not open source. but start with angular 4 hello world. that takes a little while to parse, too.

Re: Assembling WebAssembly

#53

Post by pcwalton »

tyingq wrote: post #48
jfbastien wrote: post #47

Earlier quoted context omitted.

WebAssembly is as Turing-complete as JavaScript is, and has fewer APIs. The only API it has JS doesn't really is grow_memory, and even that can kinda be done with ArrayBuffer. I'm not sure what you think makes it the harbinger of closed web. As the WebAssembly CG chair, I'd be interested in understanding that.

I don't see it as THE harbinger, but one of many. Some people will use it for the same reasons that they obfuscate things today. See, for example, the dropbox client. It's python, but they go to great lengths to keep you from peeking behind the kimono. I understand WASM isn't reverse engineering proof, but it certainly raises the bar. Especially sans source maps.

I don't think it raises the bar at all. You could already do everything you can do in wasm today with Emscripten, and any harebrained attempts at DRM schemes shipped over the wire would almost certainly be using Emscripten. Wasm is easier to read than Emscripten'd code because of types.

Re: Assembling WebAssembly

#54

Post by themihai »

This sounds quite disappointing to me: "WebAssembly cannot access the DOM except by calling into JavaScript. WebAssembly is meant to be used in conjunction with JavaScript."

Re: Assembling WebAssembly

#55

Post by OskarS »

pjmlp wrote: post #51
pizlonator wrote: post #4

Earlier quoted context omitted.

We're a long way away from that. Here's what you'd need: - GC types in WebAssembly. That's still an open problem, but that would give you API access. - Ability to load WebAssembly via something like . - WebAssembly would have to load and start as quickly as JS. The last one is probably the hardest in the long run, since wasm is being optimized for the kinds of apps where you want to pay some cost up front so that you…

> GC types in WebAssembly. That's still an open problem, but that would give you API access. Nothing prevents one to implement a GC on top of existing WebAssembly as it is, no different than when implementing bare metal runtimes. Of course having a GC as part of WebAssembly does simplify implementations, but only as an easy solution, because the best GC implementations need to be language aware for optimal performanc…

I hadn't thought about this before, but your comment made me aware that if you wanted to compile any kind of high-level language with GC into WebAssembly, you have to download it with an entire runtime. I wonder how much overhead that adds to downloads. Like, if you compile a C# or Java thing for wasm, do you have to download a 30mb runtime every page you load?

Re: Assembling WebAssembly

#56

Post by Someone »

luke_wagner wrote: post #17
saamyjoon wrote: post #10

Earlier quoted context omitted.

It's implementation dependent. Most implementations JIT Wasm up front (I think Chakra is the only engine that interprets). So, JS loads faster because almost all engines interpret first (all?).

I think the primarily-AOT compilation strategy we see today is a consequence of many of the initial workloads being frame-based animation where AOT avoids animation stutters. But this is likely to evolve over time as wasm workloads evolve. If and when we see wasm showing up in frameworks in contexts where page-load is the primary concern I can see a more lazy JIT strategy being the right thing and then we'd want to s…

WebKit already has a more lazy JIT strategy. From the article being discussed:

"WebKit’s WebAssembly implementation, like our JavaScript implementation, uses a tiering system to balance startup costs with throughput. Currently, there are two tiers to the engine: the Build Bytecode Quickly (BBQ) tier and the Optimized Machine-code Generator (OMG) tier. Both rely on the B3 JIT as their low-level optimizer."

Re: Assembling WebAssembly

#58

Post by baq »

jfbastien wrote: post #2

Summarizing the "JSC https://news.ycombinator.com/item?id=14489577 Now that these points are out of the way, let's discuss implementation details, WebAssembly, and things!

Give me qt in the browser, the rest are details.

Re: Assembling WebAssembly

#59

Post by pjmlp »

OskarS wrote: post #55
pjmlp wrote: post #51

Earlier quoted context omitted.

> GC types in WebAssembly. That's still an open problem, but that would give you API access. Nothing prevents one to implement a GC on top of existing WebAssembly as it is, no different than when implementing bare metal runtimes. Of course having a GC as part of WebAssembly does simplify implementations, but only as an easy solution, because the best GC implementations need to be language aware for optimal performanc…

I hadn't thought about this before, but your comment made me aware that if you wanted to compile any kind of high-level language with GC into WebAssembly, you have to download it with an entire runtime. I wonder how much overhead that adds to downloads. Like, if you compile a C# or Java thing for wasm, do you have to download a 30mb runtime every page you load?

Yes, but one can probably trim it down to what is actually used.

Java runtime is only 8MB (JVM) + whatever classes are actually required, other ones can be removed by something like ProGuard or the new linker.

.NET Native is quite similar.

Same applies to OCaml, Haskell, Scala, Go, ....

Re: Assembling WebAssembly

#60

Post by AriaMinaei »

I hope soon we'll have a shot at rethinking the browser's rendering stack. Not necessarily ala WebRender [0] since it needs to be backwards-compatible, but something with a clean slate.

I imagine programmable layout, GPU contour rasterization, motion-blur, programmable shaders, layer blending, LOD and infinite zooming, and render-to-texture (for putting 2D surfaces in a 3D scene).

None of this is unnecessary if you bring AR/VR to the mix. Soon people will want to put on their AR/VR glasses and read books, select pieces of text, open links, etc. There are no APIs that allows them to do that in a web browser. Ergo => flock to native.

Quite a bit of work remains for that to happen. A whole bunch of APIs need to be exposed in the browser, such as native text rendering APIs, a better-than-WebGL2 API for graphics [1][2], a way to make the webpage accessible to non-humans (eg. How do you make the page reader-friendly? how do you do "Find in page"? How do you index the content?), etc.

[0] https://wiki.mozilla.org/Platform/GFX/Quantum_Render [1] https://github.com/KhronosGroup/WebGLNext-Proposals [2] https://github.com/gpuweb/nxt-standalone

Post reply on HN