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

291–300 of 375 posts

Re: WebAssembly: Mozilla Won

#291

Post by fixermark »

acdha wrote: post #279
Touche wrote: post #151

Earlier quoted context omitted.

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

As people have pointed out, that's Chrome-only at the moment but that's also a big moving of the goal-posts. Your original comment was “far behind in a variety of features that are useful to a much bigger % of the web” — precisely how much user-visible benefit do you think comes from a feature which may accelerate the first load slightly? If that was that critical, it'd be easy to point to e.g. webpagetest.org traces…

How much user-visible benefit?

Do a quick text search of this Hacker News thread for people talking about Firefox "feeling" slower than Chrome.

Preload is a big underlying "why" of that experience.

Re: WebAssembly: Mozilla Won

#292

Post by fixermark »

dylan604 wrote: post #233
pmontra wrote: post #140

Earlier quoted context omitted.

Actually http://kb.mozillazine.org/Network.prefetch-next says > Link prefetching is when a webpage hints to the browser that certain pages are likely to be visited, so the browser downloads them immediately so they can be displayed immediately when the user requests it. This preference controls whether link prefetching is enabled. > Possible values and their effects > true > Enable link prefetching. (Default) You can…

How does prefetching affect things like the not-yet-viewed website's stats? Since it is a Google browser and Google Analytics is so dominate, is it to Google's advantage to do this for reasons other than convenience to the user? (Inflated stats for the prefetched website even though the user never viewed it?)

Google Analytics checks the visibilityState of a loaded page and does not fire the GA tag if the page is prerender.

Re: WebAssembly: Mozilla Won

#293

Post by throwaway-1209 »

KORraN wrote: post #284
throwaway-1209 wrote: post #247

Earlier quoted context omitted.

I can tell you exactly why I'm not using FF: due to extremely poor support for switching between multiple profiles. Oh, it's possible, but compared to Google's seamless support for the same, its very awkward, even if you install an extension (which is only available from a third party).

Then try containers from Test Pilot and probably you will not need profiles anymore :)

Thanks for the suggestion, just from the screenshots it looks pretty good. Will give it a try.

Re: WebAssembly: Mozilla Won

#294

Post by sqeaky »

Touche wrote: post #149
jahnu wrote: post #117

Earlier quoted context omitted.

> useable by 0.01% of applications. I think you will be surprised how many apps will use WASM in the future. I'm a C++ dev and working with WASM (and asm.js as a fallback) full time. It's going to be absolutely huge.

Even if it causes Photoshop and CAD software and such to be ported to the web (which would be a huge business model change, so don't hold your breath) we're still talking about a tiny percentage of apps. There's no reason why Slack would rewrite in C++.

Rewrites have never been where its at, there are so many new possiblilities web assembly opens.

Imagine if every AAA game had a web demo?

Imagine real support for Peer to Peer video that worked in several browsers and platforms?

What could editors in browsers be? Not just text, but any kind of office suite that exists on the local

Anything requiring a 3d canvas that was limited by javascript's speed.

Re: WebAssembly: Mozilla Won

#295

Post by fixermark »

ericfrederich wrote: post #69

It seems there is this effort to get C/C++ code performing fast inside of a browser... then at the same time there seems to be an effort to get people to stop coding in C/C++ altogether and switch to something more memory safe. Go or Rust for example. Also, I watched a talk from DConf and saw that D is adding memory safety as well. You need to mark any part of code doing pointer arithmetic as "system code" or somethi…

Web assembly could allow dynamically-typed Python to become a first-class citizen, if someone were inclined to write a Python interpreter stack that compiled to LLVM (which might already exist? https://github.com/dropbox/pyston)

The purpose of WebAssembly, pNaCl, and its ilk, is to get out from under the unfortunate accident that the "assembly language" target for browsers---i.e. the symbol set the browser can directly interpret and translate into machine operations---is JavaScript, which is not a language designed with memory or runtime performance deeply considered (or type safety, for that matter). While there are projects that somewhat ameliorate this issue (TypeScript, for example, tries to add type safety to the language), writing a something-to-JavaScript compiler is a much taller order than writing a something-to-LLVM compiler, which can then be used by an LLVM-to-WebAssembly compiler---letting you ultimately write your web site in any language you are fluent in.

Re: WebAssembly: Mozilla Won

#296

Post by fixermark »

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.

The larger goal is to provide alternatives to compiling to JavaScript. JS is a relatively large, mobile, and ugly target for a compiler relative to tightly-defined bytecode alternatives like LLVM.

Re: WebAssembly: Mozilla Won

#297

Post by TheSisb2 »

calcifer wrote: post #128
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.

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

Styling scrollbars

Re: WebAssembly: Mozilla Won

#298

Post by [deleted] »

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.

[deleted]

Re: WebAssembly: Mozilla Won

#299

Post by [deleted] »

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.

[deleted]

Re: WebAssembly: Mozilla Won

#300

Post by eridius »

Houshalter wrote: post #203
_0w8t wrote: post #82

Earlier quoted context omitted.

NaCL verifier is just a loop that essentially matches the instructions against a white list and checks their format and offsets. WebAssembly needs parser/linker/optimizer/assembler. Granted that the format is optimized for fast translation, but just the amount of code to support data structures in the implementation like maps, lists etc. must be big.

NaCL also needs those things because it has to compile it's bytecode to machine code on multiple architectures. It's no different than webasm, just a different bytecode. A big advantage of webasm is that it's integrated into the existing javascript VM, that has already been sandboxed and battle hardened.

I believe that's PNaCl. NaCl just handles already-compiled machine code. But of course NaCl isn't portable, which is why PNaCl exists.
Post reply on HN