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

331–340 of 375 posts

Re: WebAssembly: Mozilla Won

#331

Post by roca »

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…

WebAssembly APIs give you access to the compiled code of a module. A Web page can store that code locally, e.g. using IndexedDB, so it doesn't have to be downloaded and recompiled again. Thus, the first time you visit a page, you're effectively installing the app. See https://developer.mozilla.org/en-US/docs/WebAssembly/Caching... for details.

Re: WebAssembly: Mozilla Won

#332

Post by roca »

johnhattan wrote: post #76

One of the best things about Flash was that you could pack up all your bytecode and bitmaps and vectors and sounds and fonts into a single compressed SWF file that contained your entire application/game/demo. That made it really easy to do stuff like double-click-able client demos and deliverables for websites. Ditto for Java and JAR files. Looks like the "compressed bytecode that runs really fast" part is now a real…

You can already do this with existing Web platform APIs; JS libraries for asset streaming and management already exist.

Re: WebAssembly: Mozilla Won

#333

Post by roca »

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.

4x performance is worth having for many applications.

The other thing is it's not just about performance, but also about running existing and future C/C++/Rust etc code on the Web.

Re: WebAssembly: Mozilla Won

#334

Post by roca »

SquareWheel wrote: post #154
sanxiyn wrote: post #83

Earlier quoted context omitted.

The point of the article is that while Google is mostly aligned on the issue, Google also does things like creating PNaCl, which is not an aligned behavior.

(P)NaCl was introduced to replace NPAPI, at a time when the majority of rich web interaction still happened through plugins. I'm glad to see it killed off, and have been expecting it for a few years now. JS/asm and (hopefully soon) WebAssembly have supplanted many of its features and benefits. Still, this doesn't strike me as anti-open web. Google offered a solution when one was needed - it didn't gain traction, so t…

Google introduced PNaCl and made it available as a feature any Web page could use, knowing that there was effectively zero chance it would ever become a cross-browser Web standard. That was anti-open-Web.

Re: WebAssembly: Mozilla Won

#335

Post by technion »

Touche wrote: post #107

WebAssembly is nice and all, but I don't understand why Mozilla is so obsessed with this feature that will be useable by 0.01% of applications. Meanwhile they are falling far behind in a variety of features that are useful to a much bigger % of the web. Safari and Edge have leapfrogged Firefox in providing the important things to web developers.

I'm expecting that a lot of people that don't plan on using it still will. Front-end JavaScript developers using something like SJCL have a much more positive future with those crypto primitives done in something other than JavaScript, even if they themselves are just calling them from a JavaScript binding. Graphing and graphics libraries may turn to web assembly for performance. etc etc.

Re: WebAssembly: Mozilla Won

#337

Post by Houshalter »

d2p wrote: post #308
Houshalter wrote: post #191

Earlier quoted context omitted.

That's weird. Any time I search for anything in chrome that doesn't contain a space, it asks me "Did you mean to go to http://x ?"

It does a DNS lookup and if it's a valid domain shows you this. If you see it for complete nonsense, then it's possible your ISP is doing DNS Hijacking like mine! Eg. if I type "cheese", it shows "Did you mean to go to http://cheese/" ? If I click that link I get TalkTalk's "Error Replacement Service" full of ads (or at least I did, till I switched to Google DNS because TalkTalk's "opt-out" system has been convenient…

Ah, that explains that. I always found that feature annoying, I didn't know it was because my ISP misbehaving. I always get a century link search page when I typo urls.

Re: WebAssembly: Mozilla Won

#338

Post by kuschku »

dmitrygr wrote: post #304
kuschku wrote: post #267

Earlier quoted context omitted.

How do you get Firefox on devices? If OEMs want to use the Google Play store on any single of their devices, they have to make Chrome the default browser on all of them.

Open play store and install it unlike iOS, android supports setting any browser as default. You can then even completely disable chrome

Again, 90% of users out there will never change the browser, not even if the default is IE6 (as the browserchoice case showed).

As long as Chrome is preinstalled, it will win.

Re: WebAssembly: Mozilla Won

#339

Post by z3t4 »

roca wrote: post #333
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.

4x performance is worth having for many applications. The other thing is it's not just about performance, but also about running existing and future C/C++/Rust etc code on the Web.

those C/C++/Rust apps will perform worse on the web and a lot of glue code will be needed.

Re: WebAssembly: Mozilla Won

#340

Post by fasquoika »

empath75 wrote: post #108
rwj wrote: post #75

Earlier quoted context omitted.

It is not about running C/C++, it is about running native code (or something approximating it). With the right backend, most languages should be able to target WebAssembly. The other complication with supporting Go or Rust is that, even if the language is memory safe, the code still needs to be sandboxed.

Gc'd languages will take a while.

What does Go's GC need that WebAssembly doesn't have? I understand it might be hard for a language like Java that expects a GC in the VM
Post reply on HN