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

WebAssembly’s post-MVP future

hacks.mozilla.org

Post reply on HN
Print view View original

21–30 of 207 posts

Re: WebAssembly’s post-MVP future

#21

Post by auganov »

skybrian wrote: post #12

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

That's actually why I'm pretty bullish on WASM. It could become everything Java/JVM has ever wanted to be.

Almost inevitably JS will have the best interop, with the great trend for javascriptization of everything WASM could find it's way into all sorts of environments (like the native apps you mentioned).

People are already looking into WASM VMs for blockchains https://www.parity.io/wasm-smart-contract-development/

Re: WebAssembly’s post-MVP future

#22

Post by ergothus »

eksemplar wrote: post #14
skybrian wrote: post #12

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up. Yet I can make a pretty web application with vue with minimal efforts. Add st…

> another important reason is how productive modern JS is

Some people will argue on this, but I'm actually in agreement.

That said, it is important to realize WHY the JS productivity is so important: We're iterating a LOT. Web is so young, web interfaces are so young, the problems we are trying to solve on web are ever changing, and the devices we use to interface with web are changing almost as fast. We have to iterate again and again to be decent at the problem we're trying to solve only to toss it aside in favor of the new problem.

Some of this is wasteful, some of this is just part of being part of a big technological change. (I'm sure TV, radio, fax, printers, copiers, etc all had similar iterations, albeit at not quite the same speeds). But regardless of the "if we should" aspect, it's important to note that the current JS needs are both (1) currently real - trying to adopt some philosophically "pure" tenet in the defiance of these needs will fail and (2) not necessarily permanent - We can extrapolate into the near future from this, but I'm hard pressed to say much about more than 2 years in the future.

> Add stuff like graphql

Funny, I thought about graphql when the article mentioned HTTP caches, since graphQL _can't_ make use of that (most graphQL implementations use non-GET for everything, so you have to rely on server-side or client-app caching, since you can't rely on the network or browser) and took it as a hit on graphQL, not wasm.

That said, I'm interested to see where wasm goes - short term, we're in agreement that anyone expecting it to be the "Js-killer" is missing the mark, but long term I don't expect it to be dead-on-arrival, just used for not-what-was-expected.

Re: WebAssembly’s post-MVP future

#23

Post by tyingq »

jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

It seems to be tracked under/after GC, since that would be a prerequisite.

See https://github.com/WebAssembly/gc/blob/master/proposals/gc/O.... Things like DOM access are specifically mentioned.

Re: WebAssembly’s post-MVP future

#25

Post by kodablah »

jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)?

0 - https://github.com/WebAssembly/host-bindings/blob/master/pro...

Re: WebAssembly’s post-MVP future

#26

Post by rifung »

eksemplar wrote: post #14
skybrian wrote: post #12

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

I’m not impressed by wasm yet. One of the reasons JS is so good is because it can manipulate data without doing a full page reload, and wasm will do that, but another important reason is how productive modern JS is. I’m not a UXer, never was, and I moved into management long before programs even got pretty so I’ve never even had to pick up. Yet I can make a pretty web application with vue with minimal efforts. Add st…

I'm not really sure wasm is meant to compete with JS like that though?

To me the main benefits of wasm are that you can * make web pages with languages besides JS * do lower level things not possible with JS (low latency real time games?)

If you already know JS well and want to make a normal website I don't think you need WASM necessarily although it will enable those who don't know JS or want to use JS to make them too.

Re: WebAssembly’s post-MVP future

#27

Post by jdc »

kodablah wrote: post #25
jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)? 0 - https://github.co…

Performance

Re: WebAssembly’s post-MVP future

#28

Post by cm2187 »

kodablah wrote: post #25
jholman wrote: post #17

Okay, I've only done the over-breakfast skim of this, and I hate to be that guy who comments without having fully read TFA, but here I go anyway... I don't see any explicit mention of what I understand to be the killer feature: the ability to directly access the browser's WebAPIs, from Accelerometer to Document to MimeType to XPathExpression. Start with modifying the DOM, and go from there. Of course fast WASM/JS int…

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)? 0 - https://github.co…

I’d assume you would get a performance (and therefore battery) benefit by not maintaining a js layer, though a js layer is a perfectly acceptable temporary solution.

Re: WebAssembly’s post-MVP future

#29

Post by beatgammit »

skybrian wrote: post #12

I'm reminded a bit of Java's early days when Sun was able to create the illusion that it would take over the world. WebAssembly has had a lot of early success and its limits are hazy, but it seems like they must be out there somewhere? To speculate: On the server side, it seems like docker format has already won. Maybe cpu architecture portability doesn't matter there and x86 is good enough? Although serverless and e…

One awesome thing about WebAssembly is that it makes a lot of sense as an extension language. Instead of building around the JVM or .NET to get access to languages on those platforms and instead of standardizing on one embedded language (Lua, Python or JavaScript), I can use anything that supports WebAssembly and double dip with that same ecosystem working in the browser. And that list of supported languages will only continue to grow since we finally have an alternative to compiling to JavaScript.

Now, I don't think it'll "take over" the way C has, but I also wouldn't be surprised to see it edging out other VMs in many contexts, like the Lua or Python VMs, which may end up porting to WebAssembly instead of trying to justify another dependency for your app.

I hope we'll finally get to the point where I can choose what language to use for a specific task based on the merits of the language instead of making the larger argument that it's worth getting it to work in our existing app.

Re: WebAssembly’s post-MVP future

#30

Post by s-macke »

jhpriestley wrote: post #8
hencq wrote: post #7

I wonder if eventually with some of the stuff like GC in place, you could write a javascript JIT on top of wasm. I'm only half kidding. It would be pretty neat if wasm became a kind of universal IR that different (AOT and JIT) compilers could target.

JIT is pretty hard to do with wasm. There's a strict separation between code and data in wasm, for security reasons. You can't jump into the heap. So the best you could do is to generate your new JITted code as a separate wasm module.

That's exactly what I was thinking when I tried a more theoretical approach to my web emulator. I wrote a little about my approach in the Wiki [1]. Definitely one of my worst hacks :-) . Unfortunately the demo doesn't work anymore. I need to find out why.

[1] https://github.com/s-macke/jor1k/wiki/Breaking-the-1-billion...

Post reply on HN