4 ms·

Can we get over all this native JavaScript junk and finally move to either platform independent llvm bytecode (wasm as I understand it) or just use the damn jvm

Can we get over all this native JavaScript junk and finally move to either platform independent llvm bytecode (wasm as I understand it) or just use the damn jvm? There's no need other than faster Dev times (which can be handled in other ways) to keep the code in a non compiled format anymore. It's nuts and super inefficient. Let's move on already.

rinon 11y ago
I think the problem is cross-browser backwards compatibility. Until we solve this (maybe wasm will), we can't really deploy on the web in anything but JS.
vmorgulis 11y ago
If wasm is effectively adopted, the browser could become the cocoon of most of end-user applications. It will be like a VM plus an OS API: -DOM replace GUI frameworks (like Qt) -Canvas replace framebuffer (or GDI) -JS File API replace fopen() (or with emscripten virtual FS) - ... Like in 90s, we could see rewamping of applications but for the web this time (instead of Windows). We can see JS as a higher level shell and the Web API as a cross-OS POSIX.
- teacup50 11y ago
  The DOM is going to be the first thing to go if WebAssembly actually takes off. It's simply not a suitable performant model for a GUI event/render tree.
  - the8472 11y ago
    The DOM might not be quite as bad if you can do all your actual work on other threads and only submit changes to the UI thread asynchronously. If some non-renderable DOM tree could be cloned and transferred across threads you could basically operate in a clone-modify-splice cycle across threads. I think it's salvageable. But before you can even think about concurrent APIs you first need threads/parallel task executors. And Web Workers aren't going to cut it because they dictate what you're allowed to send (structured clone) instead of being extensible.
  - pdkl95 11y ago
    ...and the open web will be the 2nd thing to go. If businesses that rely on a walled garden approach (Facebook, a lot of "software as a service", etc) and the paranoid cartels that rely on re-creating scarcity (the {RI,MP}AA, "ebooks", what's left of newspapers) can bypass the DOM and render directly, they will. Does anybody seriously think that the people that try to disable the right-click context menu in a futile attempt to prevent people from using "save as" will bother to re-create copy-paste support? Is anybody delusional enough to believe that businesses will pay developers to add back in proper URL deep-linking support into their "app" with custom rendering that loads page content AngularJS-style? Sure, those of us that know what we are doing can [decompile and] read the source and bypass the whole mess. That doesn't help normal people, and worse it's a workaround; links will still be broken. Additionally, who knows how courts will interpret "decompiling" WebAssembly. Does that count as a "technological measure that effectively controls access" under the DMCA? The requirement of rendering to the DOM puts de facto limits on what can be done on the client, which is part of what has made the internet and the web so successful. Giving those that wish to lock up the commons the tools they need to build their own locks will be one of the worst things to happen to the internet. Unfortunately, I suspect that a lot of the people that should understand these issues will be distracted by shiny toys and promises about better tools and faster apps when they should be thinking about how the technologies they support will affect their future. edit: fixed spelling typo
    - walterbell 11y ago
      We are going to need self-declared URL labels/annotations plus third-party whitelists/blacklists, so that browsers/extensions can filter the "webs" that will splinter. This could extend all the way to suppressing the rendering of links which violate user preferences.
- the8472 11y ago
  > We can see JS as a higher level shell and the Web API as a cross-OS POSIX. A horribly crippled version of that. Where's my inotify? where are my UDP sockets and epoll? Security is the common objection to providing real APIs. But instead why not just sandbox them into containers which otherwise provide the full experience of what we already have instead of creating a dumbed-down wrapper? In other words: Creating a restricted subset of POSIX apis certainly is a sufficient approach for security, but it is not necessary.
andrewchambers 11y ago
pnacl was platform independent llvm bytecode. wasm is something even more wonky.
- michaelwww 11y ago
  PNaCL was a Chrome only project. According to the announcement, the PNaCL team is teaming up to create a truely multi-vendor solution. "Having both the PNaCl team and the V8 team from Google, along with key people from Microsoft and the asm.js and Emscripten gurus from Mozilla, collaborating closely once everyone saw the light, has been inspiring." https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
- bluejekyll 11y ago
  How is this wonky? You want high performing code without the overhead of the compile and dl of the ascii format. JS has done an amazing job up until now, but as more people move their code to client side only, it's becoming clearer that there are better ways to build the web applications. Or maybe this is a non problem, because everything will become native again on the mobile devices. No more html, no more Dom.
  - andrewchambers 11y ago
    It is wonky because the browser sandbox is a pointless layer between the os and native code. It is just adding more points of failure and bloatING the application stack. Pnacl already did this anyway without reinventing compiler ir in a goofy way.
    - bluejekyll 11y ago
      Wasm is basically the evolution of pnacl with backward compatibility through a similar mechanism to asm.js, no? Less wonky and more standard.
nickpsecurity 11y ago
It's been tried repeatedly without the browser makers' cooperation. It would be nice. The best I saw (for your entertainment) was the Juice [1] project that replaced Java applets (potentially Javascript) with Oberon. Leveraged fact that Oberon is a safe, compiles fast, runs fast, type of language. Combining that with good interface protection between it and the browser plus isolation would get us way more efficient web apps. Possibly more secure, too. [1] http://www.modulaware.com/mdlt69.htm http://www.modulaware.com/mdlt69.htm

rinon 11y ago

I think the problem is cross-browser backwards compatibility. Until we solve this (maybe wasm will), we can't really deploy on the web in anything but JS.

vmorgulis 11y ago

If wasm is effectively adopted, the browser could become the cocoon of most of end-user applications. It will be like a VM plus an OS API: -DOM replace GUI frameworks (like Qt) -Canvas replace framebuffer (or GDI) -JS File API replace fopen() (or with emscripten virtual FS) - ... Like in 90s, we could see rewamping of applications but for the web this time (instead of Windows). We can see JS as a higher level shell and the Web API as a cross-OS POSIX.

teacup50 11y ago
The DOM is going to be the first thing to go if WebAssembly actually takes off. It's simply not a suitable performant model for a GUI event/render tree.
- the8472 11y ago
  The DOM might not be quite as bad if you can do all your actual work on other threads and only submit changes to the UI thread asynchronously. If some non-renderable DOM tree could be cloned and transferred across threads you could basically operate in a clone-modify-splice cycle across threads. I think it's salvageable. But before you can even think about concurrent APIs you first need threads/parallel task executors. And Web Workers aren't going to cut it because they dictate what you're allowed to send (structured clone) instead of being extensible.
- pdkl95 11y ago
  ...and the open web will be the 2nd thing to go. If businesses that rely on a walled garden approach (Facebook, a lot of "software as a service", etc) and the paranoid cartels that rely on re-creating scarcity (the {RI,MP}AA, "ebooks", what's left of newspapers) can bypass the DOM and render directly, they will. Does anybody seriously think that the people that try to disable the right-click context menu in a futile attempt to prevent people from using "save as" will bother to re-create copy-paste support? Is anybody delusional enough to believe that businesses will pay developers to add back in proper URL deep-linking support into their "app" with custom rendering that loads page content AngularJS-style? Sure, those of us that know what we are doing can [decompile and] read the source and bypass the whole mess. That doesn't help normal people, and worse it's a workaround; links will still be broken. Additionally, who knows how courts will interpret "decompiling" WebAssembly. Does that count as a "technological measure that effectively controls access" under the DMCA? The requirement of rendering to the DOM puts de facto limits on what can be done on the client, which is part of what has made the internet and the web so successful. Giving those that wish to lock up the commons the tools they need to build their own locks will be one of the worst things to happen to the internet. Unfortunately, I suspect that a lot of the people that should understand these issues will be distracted by shiny toys and promises about better tools and faster apps when they should be thinking about how the technologies they support will affect their future. edit: fixed spelling typo
  - walterbell 11y ago
    We are going to need self-declared URL labels/annotations plus third-party whitelists/blacklists, so that browsers/extensions can filter the "webs" that will splinter. This could extend all the way to suppressing the rendering of links which violate user preferences.
the8472 11y ago
> We can see JS as a higher level shell and the Web API as a cross-OS POSIX. A horribly crippled version of that. Where's my inotify? where are my UDP sockets and epoll? Security is the common objection to providing real APIs. But instead why not just sandbox them into containers which otherwise provide the full experience of what we already have instead of creating a dumbed-down wrapper? In other words: Creating a restricted subset of POSIX apis certainly is a sufficient approach for security, but it is not necessary.

andrewchambers 11y ago

pnacl was platform independent llvm bytecode. wasm is something even more wonky.

michaelwww 11y ago
PNaCL was a Chrome only project. According to the announcement, the PNaCL team is teaming up to create a truely multi-vendor solution. "Having both the PNaCl team and the V8 team from Google, along with key people from Microsoft and the asm.js and Emscripten gurus from Mozilla, collaborating closely once everyone saw the light, has been inspiring." https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
bluejekyll 11y ago
How is this wonky? You want high performing code without the overhead of the compile and dl of the ascii format. JS has done an amazing job up until now, but as more people move their code to client side only, it's becoming clearer that there are better ways to build the web applications. Or maybe this is a non problem, because everything will become native again on the mobile devices. No more html, no more Dom.
- andrewchambers 11y ago
  It is wonky because the browser sandbox is a pointless layer between the os and native code. It is just adding more points of failure and bloatING the application stack. Pnacl already did this anyway without reinventing compiler ir in a goofy way.
  - bluejekyll 11y ago
    Wasm is basically the evolution of pnacl with backward compatibility through a similar mechanism to asm.js, no? Less wonky and more standard.

nickpsecurity 11y ago

It's been tried repeatedly without the browser makers' cooperation. It would be nice. The best I saw (for your entertainment) was the Juice [1] project that replaced Java applets (potentially Javascript) with Oberon. Leveraged fact that Oberon is a safe, compiles fast, runs fast, type of language. Combining that with good interface protection between it and the browser plus isolation would get us way more efficient web apps. Possibly more secure, too. [1] http://www.modulaware.com/mdlt69.htm http://www.modulaware.com/mdlt69.htm