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

61–70 of 91 posts

Re: Assembling WebAssembly

#61

Post by flohofwoe »

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?

I think it'll be more like 1..3 MB for something like the .NET mscorlib, but yes, the runtime overhead cost is definitely there. The more "managed" the language is the worse this will be. That's why it makes a lot of sense to use 'bare metal' languages which have a very small, or even completely optional runtime for WebAssembly, and use an 'embedded platform' programming style, that way you can get useful WebAssembly modules down to a few dozen kilobytes.

Re: Assembling WebAssembly

#62

Post by comex »

themihai wrote: post #54

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."

That text is a bit misleading. WebAssembly currently can't access the DOM directly, but it's definitely a goal to let it do so in the future:

https://github.com/WebAssembly/design/blob/master/GC.md

Re: Assembling WebAssembly

#63

Post by jlebrech »

baq wrote: post #58
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.

boom, qt, gtk, even xlib (or a win32 clone) would be better than html/css/js bullshit

Re: Assembling WebAssembly

#65

Post by vanderZwan »

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?

Wouldn't modules allow you to load the language runtime separately from a CDN, so that it remains cached? Kind of like people do right now with jQuery? It still would be nice if that runtime was slim of course; IIRC mobile browsers especially have small caches.

Re: Assembling WebAssembly

#66

Post by majewsky »

jlebrech wrote: post #63
baq wrote: post #58

Earlier quoted context omitted.

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

boom, qt, gtk, even xlib (or a win32 clone) would be better than html/css/js bullshit

HTML/CSS/JS has some huge advantages from the user perspective. When a designer has made some questionable choices, all it takes is a user stylesheet or a quick tour to the devtools to fix the font size and contrast ratio.

The whole world of extensions that improve existing websites with additional buttons etc. is only possible because the page structure is exposed in the DOM. If Reddit were only WASM rendering on a , there were no "Better Reddit" extensions.

Re: Assembling WebAssembly

#67

Post by majewsky »

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?

Just look at Go binaries. They include all the standard library modules that they use. A typical "Hello World" in Golang compiles to around 1-1.5 MB (and that's after you strip debug info).

Re: Assembling WebAssembly

#68

Post by jlebrech »

majewsky wrote: post #66
jlebrech wrote: post #63

Earlier quoted context omitted.

boom, qt, gtk, even xlib (or a win32 clone) would be better than html/css/js bullshit

HTML/CSS/JS has some huge advantages from the user perspective. When a designer has made some questionable choices, all it takes is a user stylesheet or a quick tour to the devtools to fix the font size and contrast ratio. The whole world of extensions that improve existing websites with additional buttons etc. is only possible because the page structure is exposed in the DOM. If Reddit were only WASM rendering on a…

reddit would probably have an opensource rendering layer or third party uis that use it's api.

wasm will be the new android without the need to install apps.

Re: Assembling WebAssembly

#69

Post by k__ »

majewsky wrote: post #66
jlebrech wrote: post #63

Earlier quoted context omitted.

boom, qt, gtk, even xlib (or a win32 clone) would be better than html/css/js bullshit

HTML/CSS/JS has some huge advantages from the user perspective. When a designer has made some questionable choices, all it takes is a user stylesheet or a quick tour to the devtools to fix the font size and contrast ratio. The whole world of extensions that improve existing websites with additional buttons etc. is only possible because the page structure is exposed in the DOM. If Reddit were only WASM rendering on a…

Also, nobody wants to pay a C++ dev for doing a JS devs work, haha

Re: Assembling WebAssembly

#70

Post by baq »

majewsky wrote: post #66
jlebrech wrote: post #63

Earlier quoted context omitted.

boom, qt, gtk, even xlib (or a win32 clone) would be better than html/css/js bullshit

HTML/CSS/JS has some huge advantages from the user perspective. When a designer has made some questionable choices, all it takes is a user stylesheet or a quick tour to the devtools to fix the font size and contrast ratio. The whole world of extensions that improve existing websites with additional buttons etc. is only possible because the page structure is exposed in the DOM. If Reddit were only WASM rendering on a…

there's reddit and then there are all the in house enterprise-ish apps that basically amount to moving buckets of bits between cross-linked tables for which html+css is not cost effective.
Post reply on HN