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

What makes WebAssembly fast?

hacks.mozilla.org

Post reply on HN
Print view View original

71–80 of 238 posts

Re: What makes WebAssembly fast?

#71

Post by shadowmint »

ncantelmo wrote: post #66
Svenskunganka wrote: post #34

> In the last article, I explained that programming with WebAssembly or JavaScript is not an either/or choice. We don’t expect that too many developers will be writing full WebAssembly code bases. I see this statement all the time, but it doesn't make sense. If you're looking at any programming language out there, they all have a growing members of their community asking and showing interest in targeting WebAssembly…

I agree completely, but I would take it a step further: If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS. We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. N…

> something else that offers native bindings to other languages will eventually...

No it won't.

This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript.

Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mobile and desktop?

Microsoft? Come on. Apple? Google? Google tried with dart and failed.

Who else, seriously, is going to step up?

We can day dream about the magical 'no js' world, but it's never going to happen if web assembly doesn't work.

Currently we're seeing the reverse, js stretched off the browser, onto the server, into mobiles, onto iot devices.

You've got to layout some pretty damn fine arguments about why that trend is going to suddenly reverse.

Web assembly is pretty much our last best chance to flip javascript off and have something better...but it might already be too late for that to work. :/

Re: What makes WebAssembly fast?

#72

Post by ncantelmo »

shadowmint wrote: post #71
ncantelmo wrote: post #66

Earlier quoted context omitted.

I agree completely, but I would take it a step further: If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS. We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. N…

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

I don't quite agree with the all-or-nothing assessment, but your passion is exactly why this will happen.

Too many of the silent developer masses (probably mostly back-end engineers) have and continue to feel this way about being stuck with JS. The genie's out of the bottle, it's not going back in.

Re: What makes WebAssembly fast?

#73

Post by ClassyJacket »

>At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent.

I support anything that improves performance and efficiency. But the best of both worlds is always great. I'm wondering if it would be possible to implement reference counting (and maybe automatic reference counting) similar to Objective-C, and if so, would that simply be a matter of the particular language and WebAssembly transpiler you're using supporting it? And are there disadvantages to reference counting that make it a bad idea? I enjoyed using it doing earlier iPhone programming.

Re: What makes WebAssembly fast?

#74

Post by wybiral »

shadowmint wrote: post #71
ncantelmo wrote: post #66

Earlier quoted context omitted.

I agree completely, but I would take it a step further: If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS. We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. N…

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

> This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript.

Do people really hate JavaScript that much? I've grown fond of it in recent years, especially after ES6.

Re: What makes WebAssembly fast?

#75

Post by hacknat »

pmontra wrote: post #28

> At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. Ouch, back to the 80s, early 90s. I think I'll stick with JavaScript at least until WebAssembly gets garbage collection. I might be wrong but I don't see many peopl…

It doesn't prevent a language from adding its own GC.

Re: What makes WebAssembly fast?

#76

Post by jfoutz »

shadowmint wrote: post #71
ncantelmo wrote: post #66

Earlier quoted context omitted.

I agree completely, but I would take it a step further: If wasm doesn't overtake JS, something else that offers native bindings to other languages will eventually. There are huge benefits to be had for teams that want to be able to code their full stack in a language that isn't JS. We never asked for JavaScript (well the vast majority of us), but we've been stuck with it for the past two decades for all things web. N…

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

Wild guess? Oracle with Java.

Re: What makes WebAssembly fast?

#77

Post by dalailambda »

ClassyJacket wrote: post #73

>At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. I support anything that improves performance and efficiency. But the best of both worlds is always great. I'm wondering if it would be possible to implement referenc…

Since languages like Rust/C++/Swift compile reference counting into machine code already, there's no real reason why they shouldn't be able to compile it to WebAssembly.

Re: What makes WebAssembly fast?

#78

Post by shadowmint »

jfoutz wrote: post #76
shadowmint wrote: post #71

Earlier quoted context omitted.

> something else that offers native bindings to other languages will eventually... No it won't. This is our one chance to kill javascript; if we don't do it now, it'll be entrenched forever, and best we'll ever get is 'compiles-to-js' languages like clojurescript and typescript. Let's be realistic; who has the man power, community good will and business savvy to push an entirely new language across all platforms, mob…

Wild guess? Oracle with Java.

:troll: well played.

Re: What makes WebAssembly fast?

#79

Post by q3r3qr3q »

ClassyJacket wrote: post #73

>At least for now, WebAssembly does not support garbage collection at all. Memory is managed manually (as it is in languages like C and C++). While this can make programming more difficult for the developer, it does also make performance more consistent. I support anything that improves performance and efficiency. But the best of both worlds is always great. I'm wondering if it would be possible to implement referenc…

> And are there disadvantages to reference counting that make it a bad idea?

I thought it had a performance cost.

Re: What makes WebAssembly fast?

#80

Post by acqq »

barrkel wrote: post #67
acqq wrote: post #53

Earlier quoted context omitted.

I think you confuse the tracing during the interpretation of JavaScript with asm.js&WebAsm. Namely asm.js&WebAsm are designed to avoid as much as possible anything deciding in the run-time, except for verifying and generating the machine code, exactly because these "let's see what the code is doing in the run-time" were already implemented and were used for "plain" JavaScript, but had too much overhead, compared to w…

> I do not rule out that WebAssembly developers, similarly, will find hat there are ways to use runtime information that speed up WebAssembly code. Think about that: it they would find something like that, exactly the same technique could be used to speed any native code, including Linux kernel and anything native you imagine. That's exactly what profile-guided optimization does. It's not a new invention, it's workin…

> it's far from inconceivable that PGO could be applied to the intermediate code that web assembly effectively is.

A developer could do some kind of PGO before he produces the final binary, I can imagine that. But then it's still just a static binary.

And I personally can't imagine PGO being done in the user's browser and not being slower than the alternative of not doing it, just like I've never heard of some OS which does PGO on the native binaries when user runs them. Maybe you know of something like that? The PGO I know is always a slow process, done only before shipping the binary to the user, it's a kind of "post-processing" step of compiling, not of the normal execution at the user's computer.

Post reply on HN