[alde]

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

[ori_b]

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.

[pcwalton]

There are a whole lot of native apps I just won't use because I don't want to go through the hassle of installing software. The macOS App Store is bad; Windows installers are worse. Entering a URL is a lot less friction.

I don't think the user experience of Web apps has to be worse than native, but even if we grant that it's worse, I'll take it over the pain of installing apps. And, based on the experiences of numerous SaaS companies, I'm far from alone in this. A lot of native app developers wail and gnash their teeth about how the Web is a technically inferior solution (which, again, I disagree with, but let's leave that aside). But, from my point of view, native apps on the mainstream desktop platforms have consistently failed to get deployment right, and that's terribly important to users in practice.

Take, say, LibreOffice. Is it better than Google Docs? Sure, probably. But I have such basic needs in word processing and spreadsheets that the marginally better user experience of the native app doesn't make up for the added annoyance of downloading LibreOffice and keeping it up to date. All indications are that most users are like me.

[pjmlp]

Those SaaS are more than happy to have a Web wall to their products.

No more piracy, users only get access to the UI part.

They care use whatever they want from open source, without giving anything back and the world will only find out about license misuse if they employees speak out.

Best of all, they own their user's data, making it even harder to move away from them, than it ever was with Office formats.

[pcwalton]

Violating OSS licenses is far more common with e.g. desktop Windows software than with Web-based SaaS.

[pjmlp]

Well I cannot see what they run on their servers, so it is anyone's guess.

At least with native code I can check what is on my hard disk.

And given my experience, it is hardly the case any company outside the big SV ones or whose main business is unrelated to software, that actually bothers to contribute anything back.

[ake1]

the only widely used license that i know of that would get violated by this kind of use (i think) is the AGPL.

[colordrops]

> virtually no benefit.

> Distributing full fledged programs like this via browsers is simply going to be a shit user experience

These statements are simply FUD. Single click "installation" with no dependency management to virtually every platform out there at near-native speed is a huge benefit. And browsers are already capable of installing desktop menu entries and icons, and running frameless in a way that looks no different from any other native application.

[littlestymaar]

> And browsers are already capable of installing desktop menu entries and icons, and running frameless in a way that looks no different from any other native application.

Really ? I've heard about the concept of Progressive Web Apps that could do that but I thought it was more a long term-goal for browsers. I didn't know you could do that already. Any pointers on how I can use it ?

[krapp]

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]

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]

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]

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.

[yoz-y]

You are right, in this case it does not make sense since you can already distribute the Qt compiled version.

[imtringued]

You can just use nodejs to execute wasm code. Not sure about how to have a native GUI though.

[bhouston]

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]

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]

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]

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!

[bhouston]

Qt for desktop node sounds like a great idea. Because then it is native and fast. But qt in this case would not be webassembly but rather bindings to JavaScript.

[krapp]

It's a fantasy of mine because I'm afraid that without a way to port and run native code from the web there will be no way to preserve software long term as part of our cultural legacy. Software has to be able to run or else it will be ignored and discarded, preserving source code alone isn't enough. Only things that remain a part of current cultural interest get preserved.

[roywiggins]

This is not what Wt was built for, but there's a similarity...

https://en.m.wikipedia.org/wiki/Wt_%28web_toolkit%29

[baq]

There's a whole class of developers who won't touch js and html with a ten foot pole. Suddenly they can deploy software to the browser. What's not to like?

[k__]

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

[alde]

WebAssembly is binary packed bytecode and generally takes much less space than UTF-8 JavaScript source files.

[kllrnohj]

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.

[em3rgent0rdr]

Couldn't Qt's webassembly library be cached in your browser, to be reused by any Qt webassembly app?

[spearmunkie]

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]

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]

tree shaking optimizations will result in everyone having a different qt.wasm.

[CyberDildonics]

Hello world in Qt is 25MB as a demonstration of 'lightweight' Qt.

[jcelerier]

hello.cpp:

    #include <QLabel>
    #include <QApplication>

    int main(int argc, char** argv)
    {
      QApplication app{argc, argv};
      QLabel label{"hello world!"};
      label.show();
      return app.exec();
    }

build:

    $ g++ -O2 -g0 -fPIC hello.cpp -I/usr/include/qt -I/usr/include/qt/QtWidgets -lQt5Widgets -lQt5Core
    $ du -csh a.out
    16K	a.out

seriously...

[joezydeco]

Try it again with Qt configured for -static and not -dynamic.

[sirspudd]

I compile a Qt Quick application statically for the Raspberry Pi on a regular basis, and the whole binary is around 7 megs big. If you remove Qt Declarative (Your hello world just requires QtCore) it will be a fraction of this size.

So nice to see people fabricating numbers and passing them off as data.

[joezydeco]

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]

Qt does focus very much on embedded targets:

http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-pr...

Embedded is the biggest market for Qt right now.

[joezydeco]

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__]

That's what I thought.

Web-apps are architected fundamentally different than classical software.

[jcelerier]

uh ? I have a large Qt / boost app (300kloc) that I compiled with Qt/WASM and the resulting .js is less than 20 megabytes.

[CyberDildonics]

That was for native compilation and those figures were from their own website.

[rictic]

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.