7 ms·

I think this is misdirected criticism. WebAssembly runs at almost native speeds on a single very lightweight "VM".

by alde 8y ago

k__ 8y ago
The problem here is probably more download time, not run performance.
- alde 8y ago
  WebAssembly is binary packed bytecode and generally takes much less space than UTF-8 JavaScript source files.
  - kllrnohj 8y ago
    Your JS source files typically don't have all the code necessary to re-implement 2D drawing, text handling, i18n code, etc... That's already been downloaded & provided in the form of the browser itself.
    - deleted 8y ago
      [deleted]
    - em3rgent0rdr 8y ago
      Couldn't Qt's webassembly library be cached in your browser, to be reused by any Qt webassembly app?
  - spearmunkie 8y ago
    I don't see why we won't be able to reference common 3rd party libraries along with their version number and cache them across websites. Eventually a giant repo of common libraries will be built.
    - bhouston 8y ago
      The versioning will be very custom and generally they will not be shared across apps. Just like react.js isn't shared across apps.
    - imtringued 8y ago
      tree shaking optimizations will result in everyone having a different qt.wasm.
  - CyberDildonics 8y ago
    Hello world in Qt is 25MB as a demonstration of 'lightweight' Qt.
    - joezydeco 8y ago
      Nobody optimizes and recompiles the libraries anymore to configure out the unnecessary parts. The mechanisms are still there but the practice died when Qt stopped focusing on embedded targets.
      - ahartmetz 8y ago
        Qt does focus very much on embedded targets: http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-project-qt-for-any-platform-any-thing-any-size/ http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-pr... Embedded is the biggest market for Qt right now.
        joezydeco 8y ago
        A few notes: 1) Qt Widgets development stopped with 5.0. I had bugs filed on the embedded Linux targets and was told "sorry, these will never be fixed". 2) #1 means that Qt wants you to use QML. I need to run a Javascript engine on my target? Note in the comments of that blog post that they hope to run on an A7 (or really fast M7)...someday. 2b) ...And if they do run on a lower end platform, you still need a POSIX O/S. uCLinux is not a great option on M3/M4 CPUs and keeping the binding dynamic on those cores to stay LGPL compliant is extremely difficult. 3) QML bindings are a pain in the ass, especially when you're trying to put a UI on legacy code. 4) Most crucial: Qt Lite and QtDC are commercial products only. So, in my opinion, embedded is still a 2nd class player. Or, I could clarify further: low end embedded is a 2nd class player. If you're working on automotive HMI/IVI? They'd love your business.
        k__ 8y ago
        Never understood the obsession some people have with Qt
  - rictic 8y ago
    Gzipped source in a high level language can be much smaller than the equivalent bytecode. That's not why these demos "Hello Framework" demos are 3-7MB though. That's due to the cost of shipping an entire widget system that takes complete responsibility for everything between raw user input to pixels on the screen, without using many of the affordances of browser APIs. This is really awesome for emulation, sandboxing, and preservation of software, but it's not a good route for saving bytes for the user.
bhouston 8y ago
It reimplements the UI layer and event layer instead of using the existing css/ Dom layer right? And does that not prevent scraping, accessibility and deep linking as well as adds a lot of download time? It is great for intranet applications for large companies and other internal tools that are already in it, but otherwise it is a non starter. Webassembly excels when it is minimized around core performance problems. Not when it is the whole app.
- krapp 8y ago
  The existing CSS/DOM layer is for rendering documents. It can be used to emulate a native GUI, just like languages can "compile" to javascript, and everyone can pretend it's really bytecode. But that doesn't mean this is a good idea, or that an actual bytecode for the web is just reinventing the wheel. >Webassembly excels when it is minimized around core performance problems. Not when it is the whole app. We don't really know that yet. Everything around Webassembly is still at the preview/POC stage, Webassembly itself hasn't matured and we don't know what sort of tooling, caching or modular integration of code would be feasible within browsers to make downloading software more efficient than just downloading one giant WASM blob.
  - bhouston 8y ago
    I think that is a fantasy of qt and c++ developers unfortunately. There will be very few use cases for qt in a browser loaded from the web. Optimized computation kernels yes. Full qt guis I do not see it happening. Qt should create an html/Dom/css front end that binds to the webassembly backend. Would be more efficient and web friendly.
    - bitL 8y ago
      Make Electron-like desktop apps but with Qt or within a browser with navigation/menu etc. bars? Running both over Internet and locally at native speed? Avoiding JavaScript for Web UI? I'd be happy to have that!
      - 8y ago
ori_b 8y ago
I think this is perfectly relevant criticism. Browsers are a huge amount of overhead to add to a cross platform toolkit, for virtually no benefit. Distributing full fledged programs like this via browsers is simply going to be a shit user experience, on top of the already terrible user experience that browsers give.
- krapp 8y ago
  Webassembly isn't designed or intended to run exclusively in the browser, though. A lot of people seem to assume that native webassembly apps would be packaged with Electron but I think that when the language matures a bit, it should be possible to get thinner native VMs without the unnecessary bulk of a browser.
  - littlestymaar 8y ago
    Why would you package it in Electron? AFAIK, webassembly is mainly intended to be run on the web, in the browser. The main goal being you don't need to install anything. Building a native app to wasm to package it into Electron sounds really weird to me. OK there's a security benefit thanks to sandboxing, but using Electron as a sandbox is really a strange idea. And when it comes to portability, if you build you native app to webassembly, it can run anywhere. But if you add Electron to the mix, you need to build a different version for each platform, which destroy the portability benefit. If your app can be built on wasm, it can probably be compiled for different platform already. Adding Electron to the mix doesn't change any of that.
    - yoz-y 8y ago
      Browsers still can not access the filesystem correctly, can't communicate with most of the devices you could plug into your computer, can't reasonably use keyboard shortcuts and so on. Electron can.
      - littlestymaar 8y ago
        But the native version already does that! What can electron do that the native version cannot ? The point of electron is that it let you write code once (in JavaScript or something that transpile to js, like TypeScript or Elm) and built multi-plateform software. But if you have a native software that can be built in wasm, it also can be built on Windows + Mac + Linux. Why using electron in that case? Electron is great if you don't want to write native code (and deal with the debugging complexity of C or C++). If you already have a cross-plateform native app in written with Qt, why the hell would you want to put that in Electron?! And remind that if your C++ isn't cross-plateform already, you won't be able to build to wasm.

I think this is misdirected criticism. WebAssembly runs at almost native speeds on a single very lightweight "VM".

by alde 8y ago

I think this is misdirected criticism. WebAssembly runs at almost native speeds on a single very lightweight "VM".

k__ 8y ago

The problem here is probably more download time, not run performance.

alde 8y ago
WebAssembly is binary packed bytecode and generally takes much less space than UTF-8 JavaScript source files.
- kllrnohj 8y ago
  Your JS source files typically don't have all the code necessary to re-implement 2D drawing, text handling, i18n code, etc... That's already been downloaded & provided in the form of the browser itself.
  - deleted 8y ago
    [deleted]
  - em3rgent0rdr 8y ago
    Couldn't Qt's webassembly library be cached in your browser, to be reused by any Qt webassembly app?
- spearmunkie 8y ago
  I don't see why we won't be able to reference common 3rd party libraries along with their version number and cache them across websites. Eventually a giant repo of common libraries will be built.
  - bhouston 8y ago
    The versioning will be very custom and generally they will not be shared across apps. Just like react.js isn't shared across apps.
  - imtringued 8y ago
    tree shaking optimizations will result in everyone having a different qt.wasm.
- CyberDildonics 8y ago
  Hello world in Qt is 25MB as a demonstration of 'lightweight' Qt.
  - joezydeco 8y ago
    Nobody optimizes and recompiles the libraries anymore to configure out the unnecessary parts. The mechanisms are still there but the practice died when Qt stopped focusing on embedded targets.
    - ahartmetz 8y ago
      Qt does focus very much on embedded targets: http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-project-qt-for-any-platform-any-thing-any-size/ http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-pr... Embedded is the biggest market for Qt right now.
      - joezydeco 8y ago
        A few notes: 1) Qt Widgets development stopped with 5.0. I had bugs filed on the embedded Linux targets and was told "sorry, these will never be fixed". 2) #1 means that Qt wants you to use QML. I need to run a Javascript engine on my target? Note in the comments of that blog post that they hope to run on an A7 (or really fast M7)...someday. 2b) ...And if they do run on a lower end platform, you still need a POSIX O/S. uCLinux is not a great option on M3/M4 CPUs and keeping the binding dynamic on those cores to stay LGPL compliant is extremely difficult. 3) QML bindings are a pain in the ass, especially when you're trying to put a UI on legacy code. 4) Most crucial: Qt Lite and QtDC are commercial products only. So, in my opinion, embedded is still a 2nd class player. Or, I could clarify further: low end embedded is a 2nd class player. If you're working on automotive HMI/IVI? They'd love your business.
        k__ 8y ago
        Never understood the obsession some people have with Qt
- rictic 8y ago
  Gzipped source in a high level language can be much smaller than the equivalent bytecode. That's not why these demos "Hello Framework" demos are 3-7MB though. That's due to the cost of shipping an entire widget system that takes complete responsibility for everything between raw user input to pixels on the screen, without using many of the affordances of browser APIs. This is really awesome for emulation, sandboxing, and preservation of software, but it's not a good route for saving bytes for the user.

bhouston 8y ago

It reimplements the UI layer and event layer instead of using the existing css/ Dom layer right? And does that not prevent scraping, accessibility and deep linking as well as adds a lot of download time? It is great for intranet applications for large companies and other internal tools that are already in it, but otherwise it is a non starter. Webassembly excels when it is minimized around core performance problems. Not when it is the whole app.

krapp 8y ago
The existing CSS/DOM layer is for rendering documents. It can be used to emulate a native GUI, just like languages can "compile" to javascript, and everyone can pretend it's really bytecode. But that doesn't mean this is a good idea, or that an actual bytecode for the web is just reinventing the wheel. >Webassembly excels when it is minimized around core performance problems. Not when it is the whole app. We don't really know that yet. Everything around Webassembly is still at the preview/POC stage, Webassembly itself hasn't matured and we don't know what sort of tooling, caching or modular integration of code would be feasible within browsers to make downloading software more efficient than just downloading one giant WASM blob.
- bhouston 8y ago
  I think that is a fantasy of qt and c++ developers unfortunately. There will be very few use cases for qt in a browser loaded from the web. Optimized computation kernels yes. Full qt guis I do not see it happening. Qt should create an html/Dom/css front end that binds to the webassembly backend. Would be more efficient and web friendly.
  - bitL 8y ago
    Make Electron-like desktop apps but with Qt or within a browser with navigation/menu etc. bars? Running both over Internet and locally at native speed? Avoiding JavaScript for Web UI? I'd be happy to have that!
    - 8y ago

ori_b 8y ago

I think this is perfectly relevant criticism. Browsers are a huge amount of overhead to add to a cross platform toolkit, for virtually no benefit. Distributing full fledged programs like this via browsers is simply going to be a shit user experience, on top of the already terrible user experience that browsers give.

krapp 8y ago
Webassembly isn't designed or intended to run exclusively in the browser, though. A lot of people seem to assume that native webassembly apps would be packaged with Electron but I think that when the language matures a bit, it should be possible to get thinner native VMs without the unnecessary bulk of a browser.
- littlestymaar 8y ago
  Why would you package it in Electron? AFAIK, webassembly is mainly intended to be run on the web, in the browser. The main goal being you don't need to install anything. Building a native app to wasm to package it into Electron sounds really weird to me. OK there's a security benefit thanks to sandboxing, but using Electron as a sandbox is really a strange idea. And when it comes to portability, if you build you native app to webassembly, it can run anywhere. But if you add Electron to the mix, you need to build a different version for each platform, which destroy the portability benefit. If your app can be built on wasm, it can probably be compiled for different platform already. Adding Electron to the mix doesn't change any of that.
  - yoz-y 8y ago
    Browsers still can not access the filesystem correctly, can't communicate with most of the devices you could plug into your computer, can't reasonably use keyboard shortcuts and so on. Electron can.
    - littlestymaar 8y ago
      But the native version already does that! What can electron do that the native version cannot ? The point of electron is that it let you write code once (in JavaScript or something that transpile to js, like TypeScript or Elm) and built multi-plateform software. But if you have a native software that can be built in wasm, it also can be built on Windows + Mac + Linux. Why using electron in that case? Electron is great if you don't want to write native code (and deal with the debugging complexity of C or C++). If you already have a cross-plateform native app in written with Qt, why the hell would you want to put that in Electron?! And remind that if your C++ isn't cross-plateform already, you won't be able to build to wasm.