Live data from Hacker News

WebAssembly support now shipping in all major browsers

blog.mozilla.org

231–240 of 346 posts

Re: WebAssembly support now shipping in all major browsers

#231

Earlier quoted context omitted.

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…

WebAssembly has nothing to do with JavaScript. When people make this association it is clear they are painfully unaware of what each (or both) technologies are. WebAssembly is a replacement for Flash, Silverlight, and Java Applets.

and js. eventually!

Re: WebAssembly support now shipping in all major browsers

#232

Earlier quoted context omitted.

WebAssembly has nothing to do with JavaScript. When people make this association it is clear they are painfully unaware of what each (or both) technologies are. WebAssembly is a replacement for Flash, Silverlight, and Java Applets.

and js. eventually!

JS is a language and not a bytecode media. Perhaps chocolate will replace cars and airplanes. I love me some chocolate.

Re: WebAssembly support now shipping in all major browsers

#233

Earlier quoted context omitted.

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.

So every package author understands each of their dependencies and all of their respective sub-dependencies, recursively on down? This is probably the best bit of programming humor I've read all morning.

>So every package author understands each of their dependencies and all of their respective sub-dependencies, recursively on down?

Have they personally audited every dependency? Probably not. Is the list of dependencies known? Yes. Is the list fixed? Yes.

On the webpage side:

Does the content provider know what will be served by their ad network? No. Does the ad network provided content change? Yes, constantly. Does the content provider even know who ultimately will be putting crap on their web page via the ads? No.

Re: WebAssembly support now shipping in all major browsers

#234

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…

> Unfortunately SIMD is still not supported on any browsers

Is SIMD portable though? Will it run good on mobile devices? And what about other non-Intel architectures in general?

Re: WebAssembly support now shipping in all major browsers

#235

Earlier quoted context omitted.

and js. eventually!

JS is a language and not a bytecode media. Perhaps chocolate will replace cars and airplanes. I love me some chocolate.

JS is a language and not a bytecode media.

That's an arbitrary distinction that's driven by developer group politics, not a meaningful technical distinction. (Much like the old Rubyist, "It's an interpreter, not a VM.")

Machine languages were originally intended to be used by human beings, as were punch cards and assembly language. There's no reason why a person couldn't program in bytecode. In fact, to implement certain kinds of language runtime, you basically have to do something close to this. Also, writing Forth is kinda close to directly writing in Smalltalk bytecode. History also shows us that what the language was intended for is also pretty meaningless. x86, like a lot of CISC ISAs, was originally designed to be used by human beings. SGML/XML was intended to be human readable, and many would debate that it succeeded.

Re: WebAssembly support now shipping in all major browsers

#236

Earlier quoted context omitted.

and js. eventually!

JS is a language and not a bytecode media. Perhaps chocolate will replace cars and airplanes. I love me some chocolate.

Yes but the point is JavaScript as the "one true way to do client side scripting" can be replaced by webassembly in that capacity.

Re: WebAssembly support now shipping in all major browsers

#237

Earlier quoted context omitted.

JS is a language and not a bytecode media. Perhaps chocolate will replace cars and airplanes. I love me some chocolate.

JS is a language and not a bytecode media. That's an arbitrary distinction that's driven by developer group politics, not a meaningful technical distinction. (Much like the old Rubyist, "It's an interpreter, not a VM.") Machine languages were originally intended to be used by human beings, as were punch cards and assembly language. There's no reason why a person couldn't program in bytecode. In fact, to implement cer…

> That's an arbitrary distinction that's driven by developer group politics

Not at all. JavaScript is a textual language defined by a specification. Modern JavaScript does have a bytecode, but it is completely proprietary to the respective JIT compiler interpreting the code and utterly unrelated to the language's specification.

> There's no reason why a person couldn't program in bytecode.

True, but that isn't this discussion.

Re: WebAssembly support now shipping in all major browsers

#238

Earlier quoted context omitted.

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…

How about Servo?

Servo doesn't render major websites properly (last I checked). Their UI is placeholder. Their Network/Caching layer is placeholder. There's no updates, configuration, add-ons, internationalization.

Servo is not meant to be a real browser. That's not a bad thing, but I don't think you can use it as an example of a browser built quickly by a small team.

Re: WebAssembly support now shipping in all major browsers

#239
post #102
post #91

Great. We will soon have an entire JVM running inside each browser's tab, just to run an animated slider. Maybe even more than one. Plus a .NET VM, several Python and Ruby interpreters, and so on. Because webmasters will keep loading ready-made plugins from CDNs, exactly like they are doing now, except that the new generation of web software will carry their own interpreter or runtime with them, because the developer…

We're still a long ways off from garbage-collected languages inside wasm. That said, it's not the technology's fault that people abuse or otherwise make poor use of it. I see no point in limiting it on that basis.

> That said, it's not the technology's fault that people abuse or otherwise make poor use of it.

I felt like I should respond to this, too.

It's not, but it is not unreasonable to object to implementing new ways for browsers to hog resources pretty much at the hosts' discretion. In this case it can be argued that it's poor use of technology to implement it in the browser.

On a similar basis, one might argue that it's poor use of technology to kill people with dynamite, but it is also reasonable to take a step back and argue that it is poor use of technology already at the point at which you gave a toddler the detonator. Regardless, dynamite is an excellent and useful technology.

Re: WebAssembly support now shipping in all major browsers

#240

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…

> Unfortunately SIMD is still not supported on any browsers Is SIMD portable though? Will it run good on mobile devices? And what about other non-Intel architectures in general?

Yes. Phones have SIMD. Hell, the cheapo MIPS in my router has SIMD. You use the portable simd instructions and they get compiled to native simd instructions for your platform. Just like any other part of webassembly.
Post reply on HN