Web Assembly
github.com
github.com
1. factorial in S-expressions: https://github.com/WebAssembly/spec/blob/master/ml-proto/tes...
2. ray tracing in a C style: https://github.com/ncbray/wassembler/blob/master/demos/raytr...
I'm still in love with the idea of a language-agnostic, web-centric compilation target, but I think we should all emotionally prepare for 10+ years before it's feasible to use in production, let alone well-integrated with our favorite languages.
There are already a bunch of awesome community implementations of the MVP WebAssembly spec [0][1][2]. Meanwhile, the V8 [3], SpiderMonkey [4], Chakra [5], and JSC [6] teams have all started work on implementing wasm in actual browser engines.
We've still got a long ways to go, but it's much nearer than 10+ years!
[0]: https://github.com/WebAssembly/wasm-jit-prototype [1]: https://github.com/WebAssembly/wasmint [2]: https://github.com/WebAssembly/wasm-aot-prototype [3]: https://github.com/WebAssembly/v8-native-prototype [4]: http://hg.mozilla.org/mozilla-central/file/ca086f9ef8bc/js/s... [5]: http://blogs.msdn.com/b/mikeholman/archive/2015/06/17/workin... [6]: https://bugs.webkit.org/show_bug.cgi?id=146064
(Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)
[0]: https://github.com/WebAssembly/design/blob/master/TextFormat... [1]: https://twitter.com/BrendanEich/status/643828456631857152
(Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)
WebAssembly will impact a lot more than just the pages currently using asm.js, and I fear it will introduce the Halting Problem in to a lot more areas. The concern isn't asm.js - it's frameworks like angular (no-content-without-js websites are already a problem). The availability of a parse tree doesn't help if I have to run it to access the structure that is current available in the DOM. With the current drama over adblopcking, I expect advertisers will jump at a technology that lets them treat clients as something they control. (compile an obfuscated version of freetype into small WebAssembly download will be be the key features).
WASM doesn't "introduce the Halting Problem" — I'm not sure how you could even think that was possible. JS is already a Turing-complete language, as are C and C++ (the most common compile-to-asm.js-languages), and the Halting Problem already affects them as much as it affects all Turing-complete languages; the way web browsers "solve" the Halting Problem is that if a script takes too long to run, it's killed. There's no reason that would be any different with a faster-to-parse and smaller-in-bytesize compilation target, which is all that WASM is.
If "the concern isn't asm.js — it's frameworks like angular," then — what? Angular already exists, and is written in regular JS. No new compilation target needed.
And in regards to ad-blocking: what? Ad-blocking works by not running (or loading) content from specific, known advertising networks. That would work regardless of whether the content was written in WASM or asm.js or regular JS or anything else. Just block the network requests and you're done.
Not if the ad scripts are mixed in with the content-rendering scripts, in which case you'll need to do some on-the-fly modifying of scripts. Host-level blocking still works for ads served from exclusive servers, but a lot of them are starting to realise that it's so easy to block and are resorting to more subtle methods.
That said, a new type of adblocker based on pattern-matching against a JS syntax tree would be pretty useful.
This is true, but it's not problem unique to WASM. In fact, your proposed pattern matching AdBlocker seems like it would be much easier to produce targeting WASM.
It's also worth nothing what an edge case this is. Some sites might do this, but large enough sites to be worth doing this will likely be large enough to inspire site-specific workarounds. Smaller sites will be unlikely to couple their ads to their rendering so tightly.
I couldn't convince him/her that any future trends towards pre-built ads rendered on server proxies, or seamless "native advertising", is orthogonal to WebAssembly.
Um, the DOM will still exist.
This is the part of your post where I concluded that you were deeply confused and stopped reading. The didactic part of me wants to teach you what the halting problem is, but I'm not even sure what it is you don't know at this point.
However, bugs like [2] suggest to me that the Chrome and Firefox teams do not place an especially high priority on readability and debuggability with source maps in plain old JavaScript. Basically, it's impossible to use Chrome Devtools to see original variable names from the source file (e.g. 'jquery.js') instead of the minified file (e.g. 'jquery.min.js') mapped by the source-map file. This essentially makes source maps useless for debugging complex code and has been a known issue for almost two years.
The most recent comment in that ticket notes work is blocked until a new version of the sourcemap spec is shipped, but the linked resources indicate there hasn't been any public activity on them in three weeks with the Sterland proposal [3] and three months with the Fitzgerald proposal [4].
If keeping the web open source is indeed a priority of Google and Mozilla, then why haven't more resources been allocated to develop those specifications?
In brief, the lack of urgency for bugs like [2] suggests to me that Google and Mozilla don't take "The JavaScript Trip" described by Stallman [5] seriously. I fear that wasm could make it much worse.
-
1. https://github.com/WebAssembly/design/blob/master/TextFormat...
2. https://code.google.com/p/chromium/issues/detail?id=327092
3. https://gist.github.com/asterland/edf028ed7947c8c258d1
4. https://github.com/fitzgen/source-map-rfc/blob/scopes-and-bi...
The wasm/asm.js story goes like this so far:
1. emscripten, a JavaScript backend for LLVM, demonstrates that you can "compile" C/C++ code into JavaScript.
2. Some vendors start writing specific optimisations for emscripten-style JavaScript code.
3. This is formalised into a subset of JavaScript called asm.js.
4. More browser vendors get onboard with asm.js optimisations.
5. wasm is proposed. Initially it is a compact binary format that is equivalent to asm.js and that can be trivially translated into asm.js at runtime using a polyfill.
The future might look like this:
6. Browsers adopt wasm natively, so the asm.js shim can be dropped, giving more performance benefits.
7. Further enhancements to wasm follow and wasm perhaps begins to diverge from its underlying JavaScript runtime.
8. ???
Some people say Javascript is the best language , you see the problem ? nobody will ever agree on what "a better language" means.
JavaScript is constrained by forward compatibility. The goal here is to let people choose the language they want to develop with. The APIs will stay the same, and that's what matters. Front end development shouldn't be about knowing Javascript ninja tricks, but web and DOM apis.
http://www.elevatesoft.com/blog?action=view&id=why_limit_web...
From the post, there's this very illuminating link that I'm sure most here have already seen:
https://github.com/jashkenas/coffeescript/wiki/list-of-langu...
That's a pretty long list. :-)
Almost feels like a throwback to the days of entirely flash-based websites......
Outside that one advantage, web applications (not talking about simple documents here) are worse in almost every way than native applications. (It’s not without reason that Photoshop, ProTools, Maya, Excel, Final Cut, SolidWorks, ArcGIS, Sibelius, Mathematica, Visual Studio, and thousands of other serious tools don’t have credible web alternatives.)
They’re slower. They aren’t persistent. They change all the time with no ability for the user to prevent it, sometimes spontaneously breaking when the developer stops supporting the user’s browser or goes out of business. They make it hard for users to load/save local data, and instead they store personal data on a faraway server. Accidentally pressing the back button can destroy hours of user work. They usually have terrible accessibility. They don’t interoperate with other applications on the system. They flagrantly violate UI design conventions on every platform. They can’t access most local hardware devices. They have an extremely limited user input device model. Their UI layout tools are limited, inflexible, and incredibly hard to work with. They throw out decades of implementation effort on various standard solutions to problems and force complete reimplementation from scratch. They are difficult or impossible to build proper cryptographic primitives on top of.
In short, web applications are inherently second-class citizens on every platform.
BUT! Web applications are also amazing. Dropping the barrier to entry – URLs and HTTP and fairly reliable code sandboxing – makes all the difference, and makes the web an extremely attractive platform despite its many flaws.
Yes. By design. If a webpage can impersonate a local app, you have a serious security problem.
> They make it hard for users to load/save local data
There are good reasons for a lot of that, from denial-of-service protections, limiting stealth cookies, etc.
> They don’t interoperate with other applications on the system.
That's a feature.
> They flagrantly violate UI design conventions on every platform.
The user agent can render the page however it wants. This is a feature.
> They can’t access most local hardware devices.
Are you trying to introduce even more security problems?
> They are difficult or impossible to build proper cryptographic primitives on top of.
That's not the place you should be implementing crypo.
> Accidentally pressing the back button can destroy hours of user work.
Ok, that one would be nicer to fix, but that's a problem for the browser, and shouldn't impact the page at all.
--
If you want to develop software that uses more than the web can provide, you should choose a platform that actually provides those features. There is a trade-off, of course, but making that kind of decision is a an important part of software engineering.
While many people have been ignoring some or all of the security aspects of programming, it is important to remember that anything connected (even indirectly) to a network is under attack, so security must be considered first.
Flash is still an excellent IDE for artists. And I enjoy some "creativity" on the web. The "everything's flat and like the next site because Bootstrap" web is getting old.
[0]: https://github.com/Flipboard/react-canvas [1]: https://github.com/WebAssembly/design/blob/master/HighLevelG...
Although... I also think that at some point the line between the web, browser and operating system might have to blur or disappear entirely.
For example, it's a goal to have WebAssembly modules interopt with the ES6 module system, and as soon as GC is supported, you'll be able to access the DOM and the JavaScript context in WebAssembly [0]. Both of these are huge steps towards ensuring that wasm plays well with everything that's great about the web today.
[0]: https://github.com/WebAssembly/design/blob/master/Web.md
(Disclaimer: I'm a Google Chrome PM contributing to the WebAssembly project)
Do you have any anticipated timeline for this? For React, at least, we're eagerly looking forward to the opportunity to write at a lower level while maintaining the same JS-facing API.
[0]: https://github.com/WebAssembly/design/blob/master/GC.md
[0]: https://github.com/WebAssembly/design/blob/master/FAQ.md#is-...
The web is awesome because it's document based, and largely because of links embedded in a open document format. Get rid of the document and you get rid of readable links, web crawlers, find-in-page, screen readers, and on and on...