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.
WebAssembly support now shipping in all major browsers
231–240 of 346 posts
Re: WebAssembly support now shipping in all major browsers
#232Earlier 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!
Re: WebAssembly support now shipping in all major browsers
#233Earlier 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.
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
#234Unfortunately 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…
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
#235Earlier 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.
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
#236Earlier 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.
Re: WebAssembly support now shipping in all major browsers
#237Earlier 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…
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
#238Earlier 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 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
#239Great. 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.
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
#240Unfortunately 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?