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-death...
Too bad makers of the original Minesweeper did not think to build touch input support.
I actually do. I want all code ever written and every environment it was ever written for to have a URL that will let me run it in the browser. Everyone else seems to want the web to go back to being whitepapers but I want actual cyberspace already!
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 WebAssembly takes off, I hope that one we'll have more than three browser engines around.
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.
At least some of the JS engines are used in non-browser projects (V8 and Microsofts), which at least superficially would suggest you could write a new browser engine and tie it to one of those existing JS interpreters. WebAssembly will gain interfaces to the DOM as well, so the complexity of that interaction will remain.
EdgeHTML is a fork of Trident, so yes. That said, I'm led to believe there's about as much commonality there as there is between KHTML and Blink: they've moved quite a long way away from where they were.
> It's simply too expensive to create a fast (and compatible) JS engine.
I don't think that's so clear cut: Carakan, albeit now years out of date, was ultimately done by a relatively small team (~6 people) in 18 months. Writing a new JS VM from scratch is doable, and I don't think that the bar has gone up that significantly in the past seven years.
It's the rest of the browser that's the hard part. We can point at Servo and say it's possible for a comparatively small team (v. other browser projects) to write most of this stuff (and break a lot of new ground doing so), but they still aren't there with feature-parity to major browsers.
That said, browsers have rewritten major components multiple times: Netscape/Mozilla most obviously with NGLayout; Blink having their layout rewrite underway, (confusingly, accidentally) called LayoutNG; IE having had major layout rewrites in multiple releases (IE8, IE9, the original Edge release, IIRC).
Notably, though, nobody's tried to rewrite their DOM implementation wholesale, partly because the pay off is much smaller and partly because there's a lot of fairly boring uninteresting code there.
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.
WebAssembly is a replacement for Flash, Silverlight, and Java Applets.
And while yes, Mozilla's Spidermonkey comes from the Netscape days, and Chakra in Edge descends from JScript in IE, plus aforementioned JavaScriptCore, each of those engines still evolved massively: most went from interpreted to LLVM-backed JITs over the years. I suspect that no more than interface bindings remain unchanged from their origins, if even. ;-)
(1) I can't currently find the primary sources from when Chrome released on my phone, but here's a contemporary secondary one: https://www.ft.com/content/03775904-177c-11de-8c9d-0000779fd...)
[1] Such as V8, Chakra, JavaScriptCore, SpiderMonkey, Rhino, Nashorn, there is a variety to choose from, also experimental models such as Tamarin, they are almost certainly not the critical blocker for developing a browser.
Netscape navigator on DOS in Firefox via WebAssembly.
I think it's a great idea, though many disagree. It's basically ChromeOS but to the next level.
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 having an existing C fallback as all other platforms we target have SIMD support)
wow, this is really cool! thx for sharing :]
Is SIMD portable though? Will it run good on mobile devices? And what about other non-Intel architectures in general?
I'm excited for WebAssembly.
OTOH having SIMD would speed it up significantly and probably get them all up to speed.
And then there's the fact that WebGL is so much behind the state of the art that it's not even funny. Sticking to an old version of GL/GLSL severely limits what you can do with it.
HN discussion: https://news.ycombinator.com/item?id=14495893
The awesome-wasm list is also a good start: https://github.com/mbasso/awesome-wasm
I'm not a collaborator on the WebAssembly Org, but I can still see that issue just fine.
I almost wish I was a student again so I could relearn math for the first time with all of these great tools...
The only benefit I can think of that benefits is specialized software like games or scientific analysis/simulation. But for what most users want, JavaScript is fast enough. The example I keep hearing is "imagine gimp in the browser" but it's already possible to make a gimp like application in the browser using things like canvas and the file api.
So by the time webassembly is ready for the prime and has needed features like memory management and Dom access, will it even by worth it beyond a few specific applications?
But neither of those necessitate JavaScript; JS is just a language that happens to run in the browser and has DOM API bindings (and the other browser APIs too). There's no reason those identical bindings couldn't be provided in any other language.
I'm sure if you sampled all developers the number that would say Javascript is their favorite programming language would be in a substantial minority. So if it makes it easier for developers to write client side code in their preferred language its worth it.
That being said, I'm worried a bit. Javascript being awful has traditionally kept developers doing as much runtime work as possible server side. In the last 5 years the rapid growth of JS libraries, client side frameworks, and recently ES6 have all reduced the pain points and correlated to a dramatic rise in client side code being loaded on users computers with corresponding huge page size bloat.
I wouldn't be so sure of that.
https://insights.stackoverflow.com/survey/2017#technology-mo...
Exactly. Only javascript can access attributes and call functions so good on exported document and window objects.
Does WebAssembly actually open up any new API hooks? I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already?
Whats new avenues of development is WebAssembly expected to open up? Is the whole point just to enable an easy way to compile games made on other platforms (Unity) to the web?
WASM is an intermediate representation which is output by your compiler (of your favorite language) and consumed by the browser's compiler to emit native code.
WASM is a bit similar to LLVM IR, but it's architecture independent.
Compare this to, say, LLVM and Clang. Clang (the C compiler front end) will read C code and emit LLVM IR. LLVM (the compiler backend) will read LLVM IR and emit assembly code for your CPU. With WASM, the developer will run the "front end" and distribute the WASM code over HTTP and the web browser will run the backend and turn WASM into native assembly code.
> I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already?
No, WASM code is not JavaScript at any point. ASM.js is a predecessor to WASM that was a compiler-friendly variant of JavaScript that can be compiled to native code.
This means that WebAssembly is actually broader than just the web; for example the Etherium folks have been discussing using wasm as their language to script their blockchain.
It doesn't currently open up any real new API hooks; it's mostly about being an efficient language for computation. You get near-native performance in the browser. In the future, it may or may not grow more hooks directly into the web platform, rather than needing to call into JS to do so.
WebAssembly and asm.js are both intended to be compile targets - you don't write them by hand, but instead write your code in another language (c, Rust, etc.) and then complie to them.
The main benefits are 1) JavaScript is no longer the only language of the web, and 2) it's possible to get better performance than JS ever allowed for.
There is a lot of c code out there that probably isn't worth rewriting fron scratch in JS, but may well be worth recompiling to run as a web app.
Also, in the future, WebAssembly should get DOM access, optional garbage collection and other features that will allow it to be a compile targets for other languages such as Python and Ruby. So then you can use a single language for all of your development without that language being JavaScript.
The really exciting thing people should be talking about is not WebAssembly but the general availability of SharedArrayBuffer[0] which finally makes it possible to run "foreign" multi-threaded code efficiently.
[0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Unfortunately, integrating a new runtime like <script type="text/lua" src="main.lua" module="lua.wasm"/> will probably never happen. A link tag, to me, specifies a static resource rather than executable code (although since CSS supports animations now that's probably a distinction without a difference.) <object> might be a good candidate but I don't know if it's still supported.
But, we can't get rid of JS altogether. Browsers will have to support javascript indefinitely, otherwise most of the web becomes unreadable. That being the case, using JS to load WebAssembly seems like the most reasonable backwards-compatible compromise available.
What? The original WebAssembly announcement[1], which can be viewed as the manifesto for how WASM was envisioned, it clearly says "once browsers support the WebAssembly syntax natively, JS and wasm can diverge". Eich's goal with WebAssembly is not replacing JS, it's providing a better compilation target for other languages. WebAssembly is a replacement for asm.js, not JavaScript. No one is selling a lie here.
[1]: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
That certainly is a shame, but it's not like we have to accept that as the future. HTML is a document markup language, but we've hijacked it to build interactive UIs. It might be that WASM is just a native-ish FFI system for javascript today, but tomorrow it could be something completely different.
WASM can be great if they allow it to.
For completely unrelated reasons, I was already thinking of adapting (my fork of) the LZ-string library[0] to directly compress/decompress typed arrays to "websafe" UTF16 strings, similar to the already existing `compressToUTF16` functionality in LZ-string. Essentially, the strings would represent LZ-compressed bitstreams, using 15 bits per string character.
Could this be useful for reducing the size of WASM binary when encoded in plain JavaScript? (the minified library would probably be around 1kb after gzip)
[0] https://github.com/JobLeonard/lz-string/tree/array-lookup
[1] http://pieroxy.net/blog/pages/lz-string/index.html#inline_me...
> an explicit Uint8Array should only only necessary if you want to inline the wasm directly with the JS that instantiates it.
Are there any realistic scenarios where this is the more sensible option?
Anyway, I should have searched MDN first, the relevant bit of documentation is pretty clear:
fetch('simple.wasm').then(response =>
response.arrayBuffer()
).then(bytes =>
WebAssembly.instantiate(bytes, importObject)
).then(results => {
results.instance.exports.exported_func();
});
You just compile, upload and share the URL. Like in the old days ;)
That's the plan. That "interfaces actual HTML" thing isn't available yet, but you can already hack around it.
For example imagine being able to run a full self hosted C++ compiler itself from a browser on any device with a browser.
I recently discovered that while Safari supports WebRTC, a "WebView" or a safari view that is added to the home screen does not.
For C and C++, you have emscripten. For Rust, we have an emscripten-based toolchain that works today, but have a PR open for using LLVM's built-in wasm backend.
For emscripten: https://kripken.github.io/emscripten-site/docs/#
For Rust: https://hackernoon.com/compiling-rust-to-webassembly-guide-4... (slightly older but still should work afaik) And the new backend https://github.com/rust-lang/rust/pull/45905
As far as I am concerned, all the languages I care about already have compilers that target JS.
The idea of being to write in one language for embedded software, system software, cli tools, web applications, distributed applications, and now the web client?
That's a very enticing idea. It might finally be the realization of what Java failed to accomplish (technically it did, but never gained a lot of traction on the client b/c it was too slow at the time).
WASM is much lower level, and should allow compilers and VMs to use best-fitting data structures and layout.
Is Internet Explorer not a major browser anymore? I’m talking relevant as in your webpage needs to work fine in Internet Explorer.
For example, my company still has Internet Explorer configured as default browser as Edge is not compatible with some internal pages.
Look at your Google Analytics, it's really not that important anymore.
Chrome 56.69%
IE 12.69%
Firefox 11.14%
Safari 9.84%
Edge 7.86%
I anticipate that IE will never gain support for WebAssembly, and your company will eventually change its default.
Most development I see nowadays supports only IE11 and is about to drop that one too in favor of Edge. IE is on its way to deprecation right now.
But in the mean time, it's very helpful to encourage companies to base their browsers on standards, and move away from outdated software -- at least a s security precaution.
"GC support" means being able to integrate with JS's GC, basically, so that your language's wasm runtime could use it instead of your own, saving bytes.
But DOM interop is needed. Can't wait to get my fingers on the DOM via native C code :)
[0]: https://github.com/WebAssembly/design/issues/1079
edit: Scratch all of that above. I stand corrected. Here's the DOM proposal: https://github.com/WebAssembly/host-bindings/
You could simply compile (relevant parts of) Firefox or Chromium to WASM :)
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 wanted to use Python or whatever.
The web is getting better by the day.
Web 4.0 pages are obfuscated WebAssembly payloads, that draw their contents via WebGL. This way, adblocking becomes impossible, as the actual content and ads are within the same opaque WebGL framebuffer. Stealing copyrighted text is also made significantly harder, beause the Web 4.0 platform leaves it up to the publisher to enable glyph selection and copying. You have concerns about accessibility? Web 4.0 is 100% accessible thanks WebAudio based realtime speech synthesis!
No, it'd just take a sufficiently smart AI.
I do agree that runtime-less languages have an advantage here though.
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.
I'm not sure what you mean by that. Is there some limitation inherent to WebAssembly that makes implementing garbage collection particularly difficult?
For what it's worth, here's Lua (which implements a garbage collector in its runtime) in WebAssembly: https://github.com/vvanders/wasm_lua
> Seriously JS should not be the lingua franca of the web
What would you recommend for a replacement? When I typically see this it is from people can't figure out JavaScript as opposed to any rational technological reasoning. I cringe at the idea that people would offer forth really bad things that don't fit well merely to satisfy their own insecurities.
If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one?
I'm thinking, for example, something like this... write C#, use a framework (fictional "Isomorph#") that can determine whether code should run on the client or server, and if you have interfaces to UI, you have the full solution. C# (client/server) + WASM/JS + remoting/web services + HTML/CSS/SVG/etc UI = real "apps".
And that could just as easily have been Python (client/server) + WASM/JS and the rest of the stack, or Go + WASM/JS.. etc. etc. I was shocked when I learned of Skulpt.org, which is a python interpreter running in the browser - so we can't be far off from the same thing running on WebAssembly.
The world goes around in circles.
The "wasm is just the JVM all over again" meme needs to die.
Yes, it's just about time for another generation to be old enough to think that we need to rewrite everything in a new language.
I'm not thrilled with that because I really like the old-school lightly-styled-HTML web, but I have to admit it's really really bad at "app" style layouts and interactivity, so if we must do that with the web (and apparently we must) it's gotta go, or it's gonna continue to suck.
But neither should this. Really, keep your code off my computer as much as possible.
I can't imagine there are many people in this world who have a computer with more than even 1% their own code running on it.
If you're not one of these guys that refuse to execute any binary code that you have not compiled yourself, you should welcome the possibility of running binary code from a sandboxed web environment.
I, for one, wish I could run all my proprietary software on the web, and restrict all my native applications to FOSS. That's a prospect WASM enables.
See this issue, for example: https://github.com/rust-webplatform/rust-webplatform/issues/...
People don't learn. The web dev community have just managed to force browsermakers to unify web development on browser side JS, and throw Java applets, activex, and action script to the bucket, just to have a kind of JVM being made a part of the web standard, and forced upon us yet again.
The core problem with Java applets was that they were Java applets
An option to keep the source of the web app closed will fragment the web dev community yet again.
Do you? The comparison with Java has been made before, including on HN.
"While Java and Flash [2] came early to the Web and offered managed runtime plugins, neither supported highperformance low-level code, and today usage is declining due to security and performance issues. We discuss the differences between the JVM and WebAssembly in Section 8. "
https://github.com/WebAssembly/spec/blob/master/papers/pldi2...