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

WebAssembly: Mozilla Won

robert.ocallahan.org

Post reply on HN
Print view View original

321–330 of 375 posts

Re: WebAssembly: Mozilla Won

#321

Post by sqeaky »

z3t4 wrote: post #204

Seems like a lot of complexity for very little gain in performance. Optimizing JavaScript often gain 100x performance, and after that rewriting it to Web-assembly would only gain up to 4x performance.

There is a performance upper bound. You can only run instructions as fast as the machine can. Native code can get very close to this limit, in a way that in practice no interpreted or JITed code can. This is just emulating the techniques native code uses to get close to that upper bound in the same way.

It is not impossible to make pure JS run this fast, but its not going to happen without herculean effort put into JS runtimes. It is just easier to do it this way, and we get to leave JS, which is a benefit to everyone except people who actually like JS.

Re: WebAssembly: Mozilla Won

#322

Post by devrandomguy »

k__ wrote: post #24

Is WASM platform independent?

More importantly, could Docker be ported to WASM? Because then I could just send the server to the client. Send the whole cluster, run it all in a single threaded browser process. Make the client part of the cloud, sharing in all of the cloudly comforts. /jk

Re: WebAssembly: Mozilla Won

#323

Post by btschaegg »

tmaly wrote: post #224
SimonPStevens wrote: post #55

It's worth pointing out that Mozilla can only continue to put pressure on Google and fight for the open web if people continue to use Firefox and support them. Consider switching to Firefox even if you prefer Chrome. Report websites that don't support FF. We are all better off for the existence of Mozilla, and strong viable competition to Chrome and IE.

I donate to Mozilla every year, and I use Firefox on phone and desktop. I like that I can install ublock origin on mobile firefox. Chrome does not support this option.

You pretty much sum things up as they were for me half a year ago. I'm not happy about them putting the sword of Damocles over Vimperator and Pentadactyl though, which is why I'm mainly using Qutebrowser on the desktop now.

That said, Mozilla is still awesome and FF will most likely remain my second go-to browser.

Re: WebAssembly: Mozilla Won

#324

Post by dblohm7 »

Vinnl wrote: post #17

I don't really like the headline. I don't want Mozilla to "win", and I don't think Mozilla wants to either; I want the open web to flourish. That said, the article is very informative, and well-balanced. It was really good of Google and the other browsers to join the wasm bandwagon. And yes, although as the author himself points out, "proclaiming a "winner" is unimportant or even counterproductive", Mozilla does dese…

> I want the open web to flourish.

When the open web wins, Mozilla wins.

Re: WebAssembly: Mozilla Won

#325

Post by klodolph »

jhpriestley wrote: post #266

People seem way too optimistic about web assembly. The elephant in the room is download size. A wasm photoshop, even if it works and performs well, is still a multi-gigabyte "web page". The browser is in no way set up to handle that. Even simple things will be huge compared to javascript webpage. Let's say you write your todo app in Python with Qt bindings. Sure, wasm lets you run it on the web. You'll just have to s…

You're comparing JavaScript apps, where the runtime is built-in to the browser, against WebAssembly apps written in other languages with large runtimes. That's nothing more than stacking the comparison to get the conclusion you want.

Not everyone writes their apps in JavaScript. That's a given, we have no choice but to accept this. Some apps or libraries are already written in another language, and it would be nice to run them in the web browser, so people do that. Some people make web games using Unity. Lots of reasons that this happens.

So you end up with emscripten + asm.js, delivering a minified JavaScript blob multiple megabytes in size, which must be parsed, compiled, and executed. WebAssembly reduces the size of the blob you have to deliver and makes the parsing + compiling steps much faster.

You may not like that, but you don't have to write apps that way. You can still write JavaScript if that's what you like. WebAssembly delivers improvements for people who weren't writing JavaScript in the first place, or for people who wish they weren't writing JavaScript.

Re: WebAssembly: Mozilla Won

#326

Post by urda »

Touche wrote: post #151
calcifer wrote: post #128

Earlier quoted context omitted.

> Meanwhile they are falling far behind in a variety of features that are useful to a much bigger % of the web Do tell...

Too many to name, really. is one that immediately comes to mind.

... a chrome only feature, pushed by Google, that isn't considered a standard?

This type of thinking and behavior is going to make Chrome today what Internet Explorer was in the 90's: a toxic, dangerous platform that ignores standards.

Re: WebAssembly: Mozilla Won

#327

Post by pc2g4d »

ccozan wrote: post #311
flavio81 wrote: post #243

Earlier quoted context omitted.

As pointed out, this will be HUGE. For starters, this will enable client (browser) software development in a language other than Javascript/ES6. With, probably, a plethora of compilers to choose from, some of them giving better optiimizations than others. I think this will make an explosion of more browser-hosted applications, with much more power than before. And will make many more programmers go into serious front…

>full version of the language supporting the full libraries available for it. Does this mean, simply said, that I can take any arbitrary windows desktop app written in C++, for example, and run it in browser on every other OS?

I think there are still limitations around threading, but basically that's the goal. I think of it as the promise of Java (write once, run anywhere) re-implemented with buy-in from all the major vendors. (So no MS/IBM/Sun fragmentation).

Re: WebAssembly: Mozilla Won

#328

Post by debacle »

dleslie wrote: post #271
jhpriestley wrote: post #266

People seem way too optimistic about web assembly. The elephant in the room is download size. A wasm photoshop, even if it works and performs well, is still a multi-gigabyte "web page". The browser is in no way set up to handle that. Even simple things will be huge compared to javascript webpage. Let's say you write your todo app in Python with Qt bindings. Sure, wasm lets you run it on the web. You'll just have to s…

I don't see the problem. Given an enormous WASM binary one could write a small bootstrap binary that fetches the binary and stores it in local cache. Future updates to the mega-binary can be done with some kind of delta-diff mechanism. Now, let's say you rely on Qt in some manner. Well, likely the WASM package resides at some known URI and is subject to standard browser caching.

Great, you just built Second Life.

Re: WebAssembly: Mozilla Won

#329

Post by Rusky »

ericfrederich wrote: post #66

WebAssembly and PNaCL always seemed like a hack. A very elegant thought-out hack, but still a hack. It required a 64 bit OS but could only ever operate in 32 bit space. Should have been dead on arrival because of that fact alone. For something that was trying to bring C/C++ and video games into a browser setting a 4GB max on memory should have been a non-starter.

WebAssembly is unrelated to PNaCl and has no limitations on the bit width of the host OS or the running program. PNaCl has those limitations because of how its sandbox works, but WebAssembly does not use a sandbox at all- it uses Javascript's security model instead.

(The WebAssembly MVP only supports the wasm32 target, but wasm64 is also planned.)

Re: WebAssembly: Mozilla Won

#330

Post by cbhl »

jhpriestley wrote: post #266

People seem way too optimistic about web assembly. The elephant in the room is download size. A wasm photoshop, even if it works and performs well, is still a multi-gigabyte "web page". The browser is in no way set up to handle that. Even simple things will be huge compared to javascript webpage. Let's say you write your todo app in Python with Qt bindings. Sure, wasm lets you run it on the web. You'll just have to s…

> The elephant in the room is download size. A wasm photoshop, even if it works and performs well, is still a multi-gigabyte "web page". The browser is in no way set up to handle that.

So you split it into chunks and download the bits you need as you go.

Microsoft has already figured out how to do this -- you can run Office (the real, full Windows version) basically streaming from the Internet already.

Post reply on HN