Live data from Hacker News

WebAssembly support now shipping in all major browsers

blog.mozilla.org

201–210 of 346 posts

Re: WebAssembly support now shipping in all major browsers

#201
post #63

Earlier quoted context omitted.

Red herring. People install or explicitly download code they want to run. The general public doesn't even realize that most web pages are full of code (js not html) and most developers have gotten so used to it they feel entitled. The goal should be to try harder to use less code, not enable native execution. I understand, engineers like to think about what is possible (wouldn't it be cool if..!) but sometime they ne…

> People install or explicitly download code they want to run Not really, explicit installation are not the real difference: you ask for one package in some package manager and you will commonly implicitly get a bunch of other dependencies installed, you will likely never be able to feasibly personally audit all those implicitly installed packages if we are talking about e.g OS repositories... The real differences ar…

The last time that a package I installed proceeded to install code that the vendor didn't know about was never.

The last time a web page caused my browser to download and run js that the page owner didn't know about was five minutes ago.

Re: WebAssembly support now shipping in all major browsers

#202
post #34

A good occasion to watch Gary Bernhardt's talk "The Birth & Death of JavaScript" [0] again, where he talks about the precursor of WebAssembly: asm.js and the future implication it "could" have in the future in a really humorous way. A few years old but still relevant. You want Gimp for Windows running in Firefox for Linux running in Chrome for Mac? Yeah sure. [0] https://www.destroyallsoftware.com/talks/the-birth-and…

There's another reason why I want JavaScript in the browser to die: We haven't had a new browser engine written from scratch since KHTML. Firefox is a descendant of Netscape, Chrome (and Safari) is a descendant of WebKit which is itself a descendant of KHTML, Edge is closed source, but I'm almost sure there's some old IE code in there. Why? It's simply too expensive to create a fast (and compatible) JS engine. If Web…

The real problem is CSS. Implementing a compliant render engine is nearly impossible, as the spec keeps ballooning and the combinations of inconsistencies and incompatibilities between properties explode.

Check out the size of the latest edition of the book "CSS: The Definitive Guide":

https://twitter.com/meyerweb/status/929097712754098181

Until CSS is replaced by a sane layout system, there's not going to be another web browser engine created by an independent party.

Re: WebAssembly support now shipping in all major browsers

#203

Earlier quoted context omitted.

I completely disagree that the issue is JavaScript here. In my opinion, the issue is the DOM. It's API is massive, there is decades of cruft and backwards compatibility to worry about, and it's codebase is significantly larger in all major open source browsers out there.

I'm not sure I agree that the DOM is that bad(more that people are using it improperly and for the wrong things), but yeah, modern JavaScript is hardly to blame for anything. The closest thing to an argument I've heard is "mah static typing". Asking WebASM to be everything, including a rendering engine, is asking for problems at such an atrocious level.

> I'm not sure I agree that the DOM is that bad(more that people are using it improperly and for the wrong things)

If an API makes it easy to make mistakes it's a bad API. Blaming "people" is a cop-out.

Re: WebAssembly support now shipping in all major browsers

#204

Earlier quoted context omitted.

Red herring. People install or explicitly download code they want to run. The general public doesn't even realize that most web pages are full of code (js not html) and most developers have gotten so used to it they feel entitled. The goal should be to try harder to use less code, not enable native execution. I understand, engineers like to think about what is possible (wouldn't it be cool if..!) but sometime they ne…

> "Red herring. People install or explicitly download code they want to run." When you visit a website, and you have given your browser permission to run JS, you're giving your permission to run JS. If you want to block scripts by default, use an extension like uMatrix: https://addons.mozilla.org/en-GB/firefox/addon/umatrix/

>> When you visit a website, and you have given your browser permission to run JS

My browser never asked me about JS. Even if it did, browser developers would switch the preference rather than annoy the user with a prompt every time a site wanted to run some JS. The end result is that whatever is common practice, the users will end up accepting by default. In such cases it is the responsibility of the people setting standards to keep the users safety in mind. The responses in this thread really make my point. So many making excuses for running excess code and even advocating more APIs.

Re: WebAssembly support now shipping in all major browsers

#205

Unfortunately SIMD is still not supported on any browsers and with the move away from SIMD.js it looks like this might take a while. We've been working on porting over our fairly large barcode scanner library to WebAssembly. While the performance is close to what we have on other platforms ( http://websdk.scandit.com ), the major bottleneck for now is not being able to use optimized code relying on SIMD (and not havi…

The barcode scanner is really impressive, it worked well on my G5 plus running FF.

I'm excited for WebAssembly.

Re: WebAssembly support now shipping in all major browsers

#206

I want to see a WASM+react framework where the application state/logic is fully in WASM and merely the rendering is done by react.

I would want the inverse of that, where the application logic is in some high-level language, and the rendering is done in WASM, i.e. react-dom and the diffing parts of react are in WASM.

Re: WebAssembly support now shipping in all major browsers

#207
post #191
post #185

Earlier quoted context omitted.

My CS background is a bit weak... is the hypothetical Metal architecture he describes supposed to be satire or actually a good idea?

Mostly satire because the math doesn't really work out in such a way.

It doesn't? How so? I was under the performance savings calculations he used were at least plausible. (Though obviously just a back-of-the-napkin estimate.)

Re: WebAssembly support now shipping in all major browsers

#208
post #135
post #34

A good occasion to watch Gary Bernhardt's talk "The Birth & Death of JavaScript" [0] again, where he talks about the precursor of WebAssembly: asm.js and the future implication it "could" have in the future in a really humorous way. A few years old but still relevant. You want Gimp for Windows running in Firefox for Linux running in Chrome for Mac? Yeah sure. [0] https://www.destroyallsoftware.com/talks/the-birth-and…

And for a somewhat more practical but at the same time more exotic example, the Internet Archive has a ton of old minicomputers and arcade games running in MESS/MAME, each compiled to webasm. One click and you can boot anything and play it in your browser. https://archive.org/details/softwarelibrary https://archive.org/donate/

Are you sure that's actually using WASM? It sounds to me like it's currently using ASM.js compiled via Emscripten. (Though in theory there's no reason why it _couldn't_ be WASM, since Emscripten supports WASM as a compiler target.)

Re: WebAssembly support now shipping in all major browsers

#209

Earlier quoted context omitted.

HTML, CSS, SVG and other things your browser will interpret might be more complex than JavaScript and surely their implementation contains bugs and exploits. Hell, I recently learned about CSV injection (comma separated values). You can't realistically discard JavaScript and think that you're safe. The world is full of complex data formats ready to be exploited. Proper solution is to embrace sandboxes and put many wa…

This is wrong. The focus will simply switch to sandbox escapes. On x86, the only real "sandbox" you have is what your MMU gives you. For as long as executable has access to browser's address space, it can do anything a browser can, including reading your webcam, mic, sensors, GPS, etc

>> This is wrong. The focus will simply switch to sandbox escapes.

Thank you. We have a winner here! And the people trying to escape them will have the full capability of native code running on your CPU.

In the mean time, permissions will be granted for ever increasing parts of the system. Users will not be prompted to "allow" for every site they visit because that will be tedious so browsers will start the enable permissions by default. But either way, we now have the browser acting as the keeper of permissions that our OSes are not able to enforce at the granularity we need for such things.

We've been continually migrating the browser to the role of an OS. It's just insane.

Re: WebAssembly support now shipping in all major browsers

#210

Earlier quoted context omitted.

I completely disagree that the issue is JavaScript here. In my opinion, the issue is the DOM. It's API is massive, there is decades of cruft and backwards compatibility to worry about, and it's codebase is significantly larger in all major open source browsers out there.

I'm not sure I agree that the DOM is that bad(more that people are using it improperly and for the wrong things), but yeah, modern JavaScript is hardly to blame for anything. The closest thing to an argument I've heard is "mah static typing". Asking WebASM to be everything, including a rendering engine, is asking for problems at such an atrocious level.

I'm not implying that the DOM is bad (IMO it's one of the most powerful UI systems that I've ever used. Both in what it's capable of, as well as the speed that I'm able to develop and iterate something with it), just that it's BIG.

There's a lot of "legacy" there, a lot of stuff that probably should be removed, or at least relegated to a "deprecated" status.

Post reply on HN