7 ms·

I feel like the author and/or the team is confused about what HTML5 actually is. They're probably right to conclude that JavaScript/HTML5 won't perform as well

I feel like the author and/or the team is confused about what HTML5 actually is. They're probably right to conclude that JavaScript/HTML5 won't perform as well on lower end devices, but a few things struck me as odd. They mention Facebook switching away from HTML5, but I think Facebook is using the actual DOM, whereas their game would be using the canvas part of the HTML5 spec. Later they mention WebAssembly replacing HTML5, but what it's really replacing is JavaScript, and the actual canvas that you're rendering to will stay the same afaik. The impact on performance would probably be as they predict, but overall, their issues seem to be with JavaScript, not HTML5.

austincheney 9y ago
> but what it's really replacing is JavaScript That is a common misconception, but there no evidence of this. WASM replaces Flash and Flash never replaced JavaScript.
- tomovo 9y ago
  WASM replaces Javascript as the target of other language compilers. If you already use Javascript, WASM won't be much help. But WASM lets you compile C/C++ and with a bit more effort other languages into a bytecode instead of weird looking Javascript, or its more streamlined and still weird form, asm.js.
  - gech 9y ago
    This will ensure every web page application can be closed source then right?
    - kpcyrd 9y ago
      Minified javascript isn't really open source either.
      - irrational 9y ago
        No, but there are tons of prettifiers that can get minified/obfuscated JS back into a state that it can be read and reasoned about fairly easily. It's not like minifiying/obfuscating JS compiles it into byte code. It's still plain text.
        JeanSebTr 9y ago
        As we can use a decompiler with other languages.
        striking 9y ago
        Barely! It's not far from bytecode in some cases, especially with the advent of asm.js.
        bogomipz 9y ago
        Do you or anyone else have any recommendations for a good tool to recover minified java script?
        chr1 9y ago
        http://jsnice.org http://jsnice.org works well, though misses many oportunities of restoring variable names based on property names which cannot be minified.
      - Someone 9y ago
        Non-minified JavaScript with good comments documenting its behavior isn’t (necessarily) open source either. That you can read the code (or that it doesn’t claim a license) doesn’t make code open source.
        kpcyrd 9y ago
        Sure, but that definition of opensource wasn't implied with "closed source due to wasm".
    - eikenberry 9y ago
      Free software has never been about the technical possibility of something, but a moral and cultural value. I.E. Just because you can, doesn't mean you should. So favor sites which don't obfuscate or make their (WASM) source code available as free software.
    - seangrogg 9y ago
      Shouldn't it be possible to decompile from wasm to the language that was used to compile to it (or any target language that could've produced said wasm)?
      - Crespyl 9y ago
        Only to roughly the same degree that it's possible to decompile x86/64 binaries to C or C++. It depends heavily on the specific optimizations and obfuscations used, whether or not debugging information was left in, etc. There's a reason the GPL has a "preferred form for editing" clause.
        manigandham 9y ago
        It's better than that: http://webassembly.org/docs/faq/#will-webassembly-support-view-source-on-the-web http://webassembly.org/docs/faq/#will-webassembly-support-vi...
        qweqweqweqw 9y ago
        Yeah, but is that actually required? I don't know much about this, but I'd guess 90% of websites will strip this just like debug info in most proprietary software, 9% don't know about this or forget to remove it, if it's included by default and 1% consciously decides to ship it for transparency.
        manigandham 9y ago
        Then it's no different than minimized javascript...
    - rhizome 9y ago
      You may be interested in this thread going on right now: https://news.ycombinator.com/item?id=15958827 https://news.ycombinator.com/item?id=15958827
    - manigandham 9y ago
      Not necessarily, WebAssembly will support view source features: http://webassembly.org/docs/faq/#will-webassembly-support-view-source-on-the-web http://webassembly.org/docs/faq/#will-webassembly-support-vi...
  - austincheney 9y ago
    > WASM replaces Javascript as the target of other language compilers. Ugggh, still no evidence. WASM is a compile target in a sandbox. It is the new Flash or Java applet. Everything else is a wish list from people incredibly insecure about touching JavaScript. So far any advocation that WASM will magically replace JavaScript severely misunderstands both WASM and JavaScript. I will continue to await something more than mere fantasy.
    - floatboth 9y ago
      WASM replaces Javascript as the target of other language compilers. JavaScript is also a compile target in a sandbox. Emscripten started with outputting plain JS, then that was optimized to asm.js, now optimized to WASM. I completely agree that WASM should NOT replace JS for normal DOM apps. It's currently possible through awkward calls into JS, and might be possible in the future more directly, but there's no need to replace JS.
      - austincheney 9y ago
        > WASM replaces Javascript as the target of other language compilers. No, it does not. Compiling to WASM is not a replacement or synonym for compiling to JavaScript. JavaScript is not locked in a sandbox, in the same way, as it has a multitude of APIs. WASM does not have such APIs as it is just the sandbox. Here is the deal. All modern browsers now claim to support WASM. If WASM were capable of replacing JavaScript it would do so right now, but it isn't because it cannot. The demand is certainly there and yet despite that demand the results are completely absent. People claim this is because WASM lacks DOM bindings. True, but that is only a tiny bit of it. WASM also does not have a security model around code/data distribution. WASM also does not have access to the chrome of the browser (the parts outside the DOM). I also haven't heard much about asynchronous threads in WASM, which is a huge requirement when working with distributed code execution. This list could go on and on. This is common knowledge for people who do this work professionally. There is an incredible amount of work to do before an arbitrary compile target can replace a major platform consideration, and much of that work isn't API bindings. The people who claim WASM as a replacement for JavaScript, as evidenced on r/programming, tend to be the people most ignorant and fearful of JavaScript. They want a replacement so badly they assume this is it without any consideration for what the technical requirements are, because they have no idea what they are.
  - austincheney 9y ago
    If WASM replaces JavaScript then is this repository an example of JavaScript being replaced by.... JavaScript? https://github.com/ballercat/walt https://github.com/ballercat/walt
  - earenndil 9y ago
    > If you already use Javascript, WASM won't be much help I wouldn't be surprised if a js-to-wasm compiler showed up, allowing for greater performance on wasm-capable browsers.
- kpcyrd 9y ago
  https://github.com/koute/stdweb https://github.com/koute/stdweb There's a todomvc example app written in rust with no javascript besides the loader.
  - scottmf 9y ago
    I just glanced at that repo and what you say is not quite true. Looks like they have to reimplement the entire DOM API with JS interop: pub fn document() -> Document { unsafe { js!( return document; ).into_reference_unchecked() }.unwrap() }
    - steveklabnik 9y ago
      This is required for webassembly; it has to call into JS to access the DOM.
      - jgalar 9y ago
        Are there good DOM "bindings" available for other languages compiled to wasm?
        steveklabnik 9y ago
        I'm not sure, but I'd imagine so.
    - seangrogg 9y ago
      Valid point - currently, wasm cannot target the DOM. I think the GP would've been more accurate in saying the logic is all performed in Rust - JS is only used for DOM access.
      - shmerl 9y ago
        Is it because of security reasons?
        9y ago
singmajesty 9y ago
Facebook famously moved away from HTML5 for mobile applications, the author is talking about a time some years ago when his company began to look for other technology. I think the important thing here is that "HTML5" as a solution would mean wrapping it in a Phonegap/Cordova application for mobile. Haxe means HTML5 and/or Flash on the web, but also native for mobile.

austincheney 9y ago

> but what it's really replacing is JavaScript That is a common misconception, but there no evidence of this. WASM replaces Flash and Flash never replaced JavaScript.

tomovo 9y ago
WASM replaces Javascript as the target of other language compilers. If you already use Javascript, WASM won't be much help. But WASM lets you compile C/C++ and with a bit more effort other languages into a bytecode instead of weird looking Javascript, or its more streamlined and still weird form, asm.js.
- gech 9y ago
  This will ensure every web page application can be closed source then right?
  - kpcyrd 9y ago
    Minified javascript isn't really open source either.
    - irrational 9y ago
      No, but there are tons of prettifiers that can get minified/obfuscated JS back into a state that it can be read and reasoned about fairly easily. It's not like minifiying/obfuscating JS compiles it into byte code. It's still plain text.
      - JeanSebTr 9y ago
        As we can use a decompiler with other languages.
      - striking 9y ago
        Barely! It's not far from bytecode in some cases, especially with the advent of asm.js.
      - bogomipz 9y ago
        Do you or anyone else have any recommendations for a good tool to recover minified java script?
        chr1 9y ago
        http://jsnice.org http://jsnice.org works well, though misses many oportunities of restoring variable names based on property names which cannot be minified.
    - Someone 9y ago
      Non-minified JavaScript with good comments documenting its behavior isn’t (necessarily) open source either. That you can read the code (or that it doesn’t claim a license) doesn’t make code open source.
      - kpcyrd 9y ago
        Sure, but that definition of opensource wasn't implied with "closed source due to wasm".
  - eikenberry 9y ago
    Free software has never been about the technical possibility of something, but a moral and cultural value. I.E. Just because you can, doesn't mean you should. So favor sites which don't obfuscate or make their (WASM) source code available as free software.
  - seangrogg 9y ago
    Shouldn't it be possible to decompile from wasm to the language that was used to compile to it (or any target language that could've produced said wasm)?
    - Crespyl 9y ago
      Only to roughly the same degree that it's possible to decompile x86/64 binaries to C or C++. It depends heavily on the specific optimizations and obfuscations used, whether or not debugging information was left in, etc. There's a reason the GPL has a "preferred form for editing" clause.
      - manigandham 9y ago
        It's better than that: http://webassembly.org/docs/faq/#will-webassembly-support-view-source-on-the-web http://webassembly.org/docs/faq/#will-webassembly-support-vi...
        qweqweqweqw 9y ago
        Yeah, but is that actually required? I don't know much about this, but I'd guess 90% of websites will strip this just like debug info in most proprietary software, 9% don't know about this or forget to remove it, if it's included by default and 1% consciously decides to ship it for transparency.
        manigandham 9y ago
        Then it's no different than minimized javascript...
  - rhizome 9y ago
    You may be interested in this thread going on right now: https://news.ycombinator.com/item?id=15958827 https://news.ycombinator.com/item?id=15958827
  - manigandham 9y ago
    Not necessarily, WebAssembly will support view source features: http://webassembly.org/docs/faq/#will-webassembly-support-view-source-on-the-web http://webassembly.org/docs/faq/#will-webassembly-support-vi...
- austincheney 9y ago
  > WASM replaces Javascript as the target of other language compilers. Ugggh, still no evidence. WASM is a compile target in a sandbox. It is the new Flash or Java applet. Everything else is a wish list from people incredibly insecure about touching JavaScript. So far any advocation that WASM will magically replace JavaScript severely misunderstands both WASM and JavaScript. I will continue to await something more than mere fantasy.
  - floatboth 9y ago
    WASM replaces Javascript as the target of other language compilers. JavaScript is also a compile target in a sandbox. Emscripten started with outputting plain JS, then that was optimized to asm.js, now optimized to WASM. I completely agree that WASM should NOT replace JS for normal DOM apps. It's currently possible through awkward calls into JS, and might be possible in the future more directly, but there's no need to replace JS.
    - austincheney 9y ago
      > WASM replaces Javascript as the target of other language compilers. No, it does not. Compiling to WASM is not a replacement or synonym for compiling to JavaScript. JavaScript is not locked in a sandbox, in the same way, as it has a multitude of APIs. WASM does not have such APIs as it is just the sandbox. Here is the deal. All modern browsers now claim to support WASM. If WASM were capable of replacing JavaScript it would do so right now, but it isn't because it cannot. The demand is certainly there and yet despite that demand the results are completely absent. People claim this is because WASM lacks DOM bindings. True, but that is only a tiny bit of it. WASM also does not have a security model around code/data distribution. WASM also does not have access to the chrome of the browser (the parts outside the DOM). I also haven't heard much about asynchronous threads in WASM, which is a huge requirement when working with distributed code execution. This list could go on and on. This is common knowledge for people who do this work professionally. There is an incredible amount of work to do before an arbitrary compile target can replace a major platform consideration, and much of that work isn't API bindings. The people who claim WASM as a replacement for JavaScript, as evidenced on r/programming, tend to be the people most ignorant and fearful of JavaScript. They want a replacement so badly they assume this is it without any consideration for what the technical requirements are, because they have no idea what they are.
- austincheney 9y ago
  If WASM replaces JavaScript then is this repository an example of JavaScript being replaced by.... JavaScript? https://github.com/ballercat/walt https://github.com/ballercat/walt
- earenndil 9y ago
  > If you already use Javascript, WASM won't be much help I wouldn't be surprised if a js-to-wasm compiler showed up, allowing for greater performance on wasm-capable browsers.
kpcyrd 9y ago
https://github.com/koute/stdweb https://github.com/koute/stdweb There's a todomvc example app written in rust with no javascript besides the loader.
- scottmf 9y ago
  I just glanced at that repo and what you say is not quite true. Looks like they have to reimplement the entire DOM API with JS interop: pub fn document() -> Document { unsafe { js!( return document; ).into_reference_unchecked() }.unwrap() }
  - steveklabnik 9y ago
    This is required for webassembly; it has to call into JS to access the DOM.
    - jgalar 9y ago
      Are there good DOM "bindings" available for other languages compiled to wasm?
      - steveklabnik 9y ago
        I'm not sure, but I'd imagine so.
  - seangrogg 9y ago
    Valid point - currently, wasm cannot target the DOM. I think the GP would've been more accurate in saying the logic is all performed in Rust - JS is only used for DOM access.
    - shmerl 9y ago
      Is it because of security reasons?
      - 9y ago

singmajesty 9y ago

Facebook famously moved away from HTML5 for mobile applications, the author is talking about a time some years ago when his company began to look for other technology. I think the important thing here is that "HTML5" as a solution would mean wrapping it in a Phonegap/Cordova application for mobile. Haxe means HTML5 and/or Flash on the web, but also native for mobile.