4 ms·

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

by 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!
  - ZenoArrow 10y ago
    > "The original vision of the browser was a cross-platform vehicle for delivering applications over the network." The original vision for the browser was as a vehicle for browsing through interlinked documents. Web apps were an afterthought.
equasar 10y ago
Will hybrid applications benefit from this? In terms of performance.
- c-smile 10y ago
  If by "hybrid" you mean these two: <script type="text/javascript" src="js-code.js"></script> <script type="application/wasm" src="ray-tracer.wasm"></script> in the same HTML document then "yes" - it conceptually will work faster if instead of ray tracer in JS you will call native function doing that. 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/ 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 http://sciter.com engine where it is possible to mix native code with HTML/CSS/script.
neculaiandrei 10y ago
"7. Each framework will finally have its own programming language." I laughed so hard on this. "finally" omg

by c-smile 10y ago

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!
- ZenoArrow 10y ago
  > "The original vision of the browser was a cross-platform vehicle for delivering applications over the network." The original vision for the browser was as a vehicle for browsing through interlinked documents. Web apps were an afterthought.

equasar 10y ago

Will hybrid applications benefit from this? In terms of performance.

c-smile 10y ago
If by "hybrid" you mean these two: <script type="text/javascript" src="js-code.js"></script> <script type="application/wasm" src="ray-tracer.wasm"></script> in the same HTML document then "yes" - it conceptually will work faster if instead of ray tracer in JS you will call native function doing that. 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/ 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 http://sciter.com engine where it is possible to mix native code with HTML/CSS/script.

neculaiandrei 10y ago

"7. Each framework will finally have its own programming language." I laughed so hard on this. "finally" omg