What do you guys think is the best-case scenario for this project?
Like if everything goes well, how do you imagine it will affect the web in 5-10 years? What are we going to be able to do with it?
Like if everything goes well, how do you imagine it will affect the web in 5-10 years? What are we going to be able to do with it?
1. You will not see obfuscated (a.k.a.) uglified JavaScripts anymore. Everything will be compiled into bytecodes.
2. But don't worry, you will see bunch of webDisAssembly tools.
3. You will not see blog posts "How bad is that JavaScript" anymore.
4. But do expect to see "How bad is WebAssembly" though.
5. "Vanilla JavaScript" camp may have "Vanilla WebAssembly" banners on some tents.
6. You will not see anymore those ugly attempts to write Ray Tracer in JS.
7. Each framework will finally have its own programming language. Most advanced of them will change language on month basis, like Angular35 will use Rust build 3234.23.400. Moving asymptotically close to the Web Holy Grail.
8. Browser API will be decomposed to bare-bone state,
8.1 you will see immediate mode drawing a la WM_PAINT drawing style. Finally.
8.2 you will see CSS extendedable by custom layout managers and properties.
8.3 CSS modular system will reach its eternal ideal. Instead of them writing specs for us each our site will have its own CSS modules.
At the end: each team will write their own browser - FF, GC, IE will just provide WebAssembly loader means. Everything else will be just loadable.
So at the end you will get good Java Applet idea with User Agent exposing pure AWT alike primitives. With the browser as such a ClassLoader thing.
I realize the initial wasm spec doesn't seem to be aiming at that level of complexity, but I'm curious if/why repeated extensions of it won't move us in that direction.
Java was supposed to be key to that goal, but it didn't match the capabilities of the network and processing speed of the time. As painful as HTML, CSS, and JavaScript are to use, they actually worked.
Compile-to-JS, NaCL, and asm.js culminated in a realistic blueprint for how to build a low-level network-oriented runtime. Combined with increases to network speed (the average webpage is the size of the original DOOM) WASM is finally doable.
On the plus side, holy shit we can do (almost) anything! WASM will also mean outside money pumped into improving the browser runtime, such as Ethereum's migration to WASM.
Some of the parent comment is tongue-in-cheek, but you can already see one downside: fragmentation. Any good API gets screwed up in committee, so we end up with the most bare-bones and verbose implementation possible (WebComponents, IndexedDB, etc). Since they are so painful to use we end up importing 3rd party libraries which entails incompatibility. The content itself also becomes more opaque, as we can't just parse HTML to figure out the contents of the page.
That being said, holy-shit we can do anything!
The original vision for the browser was as a vehicle for browsing through interlinked documents. Web apps were an afterthought.
Personally I see WASM as a potential way to speed up technology evolution and acceptance.
Like from CSS 1.0 era authors were struggling with flexible layouts on HTML pages. In 2008 work on flexbox module had started in CSS workgroup at W3C. And at 2015 we've finally got something. 7 years and very far from ideal at the end to be honest. If CSS would have an open architecture and with something like WASM in place + an ability to hook up that almost native code in rendering tree creation and composition process ... We would have significantly better results and significantly faster.
That's just an example. May be that's too optimistic of course. In any case if web browser, that we all rely upon, would be an open platform/technology it will be better for all of us. Can WASM be the way to that? I wish to hope.
I laughed so hard on this. "finally" omg
<script type="text/javascript" src="js-code.js"></script>
<script type="application/wasm" src="ray-tracer.wasm"></script>
As far as I understand the main goal of WASM is to have bytecode that is 1:1 mapable to current CPU architectures. JS source is quite hard to JIT due to typeless nature of JS (as an example of one of problems).
This http://sciter.com/htmlcss-ui-in-medicine/ is an example of such a hybrid application that uses HTML/CSS/script with native code (C++) responsible for low level data processing and filtering. In some cases native code there is generating image fragments for rendering. That application uses http://sciter.com engine where it is possible to mix native code with HTML/CSS/script.
Existing, widely-used C libraries can be used in front-end applications if desired, and libraries in varying languages can all seamlessly interact with both each other and the DOM.
- Idapro/radare for web debugging
1. WebAssembly isn't an assembly format in the traditional sense, it's a compressed AST.
2. IIRC the plan is to develop a human-readable form of WASM that can be read directly from the browser. Basic debugging can be done directly in the browser.