7 ms·

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

by rayalez 10y ago

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?

Ajedi32 10y ago
Best-case scenario: in 5-10 years you can use any language you want for building apps on the front-end, just like you currently can for the back end. 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.
- xigency 10y ago
  Really, that's all possible now using emscripten and it still doesn't sound productive.
  - raquo 10y ago
    Not sure how the integration with JS looks like in Emscripten. Scala.js is fabulous, with typed facades for the DOM, easy interaction with dynamic JS types, etc.
Yuioup 10y ago
Finally getting rid of Javascript and its spawn nodejs and npm.
c-smile 10y ago
As soon as this will be in place: 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.
- ethbro 10y ago
  As someone with a better grasp on this, care to comment on a wasm-based future and the idea of a browser essentially turning into a network-driven hypervisor? 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.
  - c-smile 10y ago
    "network-driven hypervisor" is what we have already with modern browsers. WebSockets, WebWorkers, WebRTC ... all that. 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.
  - indolering 10y ago
    The original vision of the browser was a cross-platform vehicle for delivering applications over the network. It's not just an idea, it was always the explicit goal and WASM is the last piece of the puzzle. 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!
raquo 10y ago
Also, remember that Electron will also benefit from this. More performant cross platform apps!
rasz_pl 10y ago
+ no more js - Idapro/radare for web debugging
- ZenoArrow 10y ago
  Two points: 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.
ComodoHacker 10y ago
Not sure about best case, but I see three things WASM will be immediately used for: DRM, games, malware.

by rayalez 10y ago

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?

Ajedi32 10y ago

Best-case scenario: in 5-10 years you can use any language you want for building apps on the front-end, just like you currently can for the back end. 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.

xigency 10y ago
Really, that's all possible now using emscripten and it still doesn't sound productive.
- raquo 10y ago
  Not sure how the integration with JS looks like in Emscripten. Scala.js is fabulous, with typed facades for the DOM, easy interaction with dynamic JS types, etc.

Yuioup 10y ago

Finally getting rid of Javascript and its spawn nodejs and npm.

c-smile 10y ago

As soon as this will be in place: 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.

ethbro 10y ago
As someone with a better grasp on this, care to comment on a wasm-based future and the idea of a browser essentially turning into a network-driven hypervisor? 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.
- c-smile 10y ago
  "network-driven hypervisor" is what we have already with modern browsers. WebSockets, WebWorkers, WebRTC ... all that. 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.
- indolering 10y ago
  The original vision of the browser was a cross-platform vehicle for delivering applications over the network. It's not just an idea, it was always the explicit goal and WASM is the last piece of the puzzle. 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!

raquo 10y ago

Also, remember that Electron will also benefit from this. More performant cross platform apps!

rasz_pl 10y ago

+ no more js - Idapro/radare for web debugging

ZenoArrow 10y ago
Two points: 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.

ComodoHacker 10y ago

Not sure about best case, but I see three things WASM will be immediately used for: DRM, games, malware.