Qt for WebAssembly Technology Preview
blog.qt.io
blog.qt.io
I have faith that the Qt project won't spend time shipping this if it doesn't offer advantages. Give them time, and a little benefit of the doubt based on a very long history of excellence.
Given that, why would you use this instead of just building a compiled package for a targeted platform?
I would argue that Qt's problem is:
* Licensing is expensive (look it up, you can't just use it for free for large-scale commercial projects, contrary to what many people believe)
* Getting started with Qt is painful and integrating it into an existing codebase even moreso - get ready to suffer with C++ linker nonsense
* You have to write in languages that are not particularly enjoyable to ship a production application (C++, JavaScript but without The Nice Parts of modern JS web dev)
* The "deploy" bit is completely left to the reader, Qt doesn't help you write apps and ship them end-to-end. Contrast this with Electron which has a pretty strong (albeit a bit mysterious) packaging and auto-update pipeline
Qt experts will argue on all these points, "It's a library, it shouldn't do XYZ", but at the end of the day, Qt is a means to ship Desktop and Mobile Software, and by ignoring the entire Developer Experience from end-to-end, they miss the mark.
I should look this up because Qt is something I've got my eyes on for small projects that could get big. On that note, are you able to define "large-scale" for me? Would a desktop app' interfacing with a remote API be "large-scale"?
> You have to write in languages that are not particularly enjoyable to ship a production application (C++, JavaScript but without The Nice Parts of modern JS web dev)
I'm looking at the Golang bindings for Qt (to implement my point above.) Have you considered it? Is Go something you'd consider?
I would love to use Qt but their licensing and terms just immediately kill it for me: https://www1.qt.io/faq/#_Toc_2_5
You can make commercial software using one if the open source licenses. (Of course; otherwise it wouldn't be an open source licence.)
Usually software licenses for commercial development tools have a few more zeros, or not even that, forcing one to schedule a meeting with their sales people.
Before the FOSS movement, startups somehow managed to pay for their software.
You can absolutely use it for free in any project, as long as you conform to LGPLv3.
Regarding JS: You're not supposed to write more than glue logic in JS - well, that's the practical experience. For some reason, the Qt company recommends more JS use than that.
I think the main reason that's a commercial offering is that developers of proprietary software like shipping binaries instead of human-readable QML files.
So you're saying there are projects where I cannot use Qt? The fact is, there exists projects that do not have the option of using Qt without paying for expensive licensing. Such projects should at least consider using Electron which might have significant non-technical advantages for them.
It is cool that what many consider to be the best commercial desktop GUI is also open source, I will admit that much. Still, we shouldn't complain too much when many projects choose to use Electron, it's licensing is just so much more permissive which is a significant advantage for many projects.
I don't think QT and Electron are architecturally equivalent.
"I don't want to pay for software, so here take a bloated browser as fake native app".
Electron uses components that are under LGPL (Chromium for instance) so it's basically exactly the same license questions than with Qt.
* Getting started: I agree it is painful. There's a definite learning curve here. I believe it's worth it obviously, but that's obviously subjective.
* Language choices: There are binding for quite a few other languages. There's a lot of pyqt projects out there. But I disagree that C++ is painful - it really depends on who wrote it. Well written C++ is pleasant, poorly written C++ that abuses things is awful. The javascript portion does suck tho, you are right. It will improve, but it doesn't improve quickly.
* Deploy bit: you predicted my argument here. I favor the system package manager.
Not saying it makes sense, just that groupthink is strong.
It doesn't play ball with IP business and NDA rules that are common place in the industry.
Edit: To clarify, if you provide the parts of your application that are proprietary as statically linked libraries wherein the recipient can relink to a modified version of the LGPL'ed library then that satisfies the LGPL.
1: https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
The only other options is the hybrid approach which uses native widgets like wxWidgets, but this means you're limited by the lowest common denominator.
One of the best things to happen lately is reader view which does make a good chunk of the web match my theme. There's always been plugins, custom css, etc to work around this failing of the web.
I think most people consider visual studio to be an exception, not the norm. Whether or not visual studio's performance success represents what the typical developer should be expected to get when writing idiomatic JavaScript in Electron has probably not been fairly evaluated in the face of popular performance slugs like slack.
Use of native controls and their benefits is greatly exaggerated and it all comes down to some murky-feely subjective opinion.
The only issue I have with non homogeneous UI is that it is often an opportunity for not so gifted developers to become creative in term of basic UX and we often end up with no obvious way to go back, non discoverable features and other UX fails.
I find it quite acceptable.
- Willing to give your work for free the same way as taking Qt's work? No problem, LGPL has you covered.
- No issues with dynamic linking, still wanting to use the work of others for free? No problem, LGPL has you covered.
- What to sell it for lots of cash? Then give the Qt guys a piece of the cake back and be happy they still exist.
I wonder what are the nice parts of JS web dev, collecting new frameworks and build tools every week, or functions as packages?
In fact I am pretty opinionated that some of the new UI goodies are only exposed via QML, which wouldn't be a problem if people stopped writing logic there.
Deployment is a little bit of a pain but they actually provide software to help - macdeployqt and windeployqt bundle everything up into a dmg or a zip.
You aren't forced to use QML. I kind of hate it and QtWidgets are much more mature - I just use those. Sure maybe they aren't being developed so much but they're still maintained. I don't think they'll go away for a long time.
Qt is great.
Can anyone explain why it is free to use if you link with dynamically, but not statically? (I've seen this point come up a few times in discussions about Qt here on HN.) I know what dynamic and static linking mean, but not clear about the connection to free vs. paid Qt use. Is it something obvious that I'm missing? Only thing I can think of (admit I didn't think a lot about it yet) is that if you use it for free with dynamic linking, deployment is more of an issue, vs. just shipping a self-contained statically linked app.
Thanks in advance.
long story short: it's actually false, you can entirely ship your app linked statically with Qt under LGPL and still comply with the license. However, you have to ship your .o files: basically, what the LGPL requires is for people getting your app to be able to relink your app with their custom version of the LGPL libs (so Qt).
https://github.com/Timmmm/robocut/blob/master/CMakeLists.txt
Also they already build tooling for Qt such as Qmake and Qt Creator, it seems to me their goals are clearly to make those goals attainable, it may not be as perfect as the alternatives but it does do a decent job at the very least, but I do agree, the licensing does keep me away from using Qt usually just because I never know where a pet project might end me up.
uh... yes you can. It's LGPL. Chromium and libchromiumcontent used in Electron are also under LGPL and this does not cause problems anywhere.
Qt with Rust is progressing well.
Oh boy, sometimes you just walk away from a crash, but you're never the same.
The mechanisms are still there but the practice died when Qt stopped focusing 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.
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.
I've shipped a dozen products with it over the course of my career.
On embedded targets I'd never use anything else. The alternatives are way too simple or overscripted playback engines that have no flexibility with underlying code.
http://blog.qt.io/blog/2018/02/22/qt-roadmap-2018/
> So, quite many new things for Qt Quick users, but not to worry – we have not forgotten users of Qt Widgets. On the contrary, already during the past year we have been increasingly addressing open bugs of Qt Widgets and intend to continue doing so during 2018 and beyond. Both Widgets and Qt Quick have their strong points and they complement each other nicely as fully supported parts of the Qt offering.
Web-apps are architected fundamentally different than classical software.
#include <QLabel>
#include <QApplication>
int main(int argc, char** argv)
{
QApplication app{argc, argv};
QLabel label{"hello world!"};
label.show();
return app.exec();
}
$ g++ -O2 -g0 -fPIC hello.cpp -I/usr/include/qt -I/usr/include/qt/QtWidgets -lQt5Widgets -lQt5Core
$ du -csh a.out
16K a.out
So nice to see people fabricating numbers and passing them off as data.
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.
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.
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.
Qt should create an html/Dom/css front end that binds to the webassembly backend. Would be more efficient and web friendly.
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.
Electron can.
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 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.
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.
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.
And there is no way to validate that.
while i agree with your point about this being sub-optimal for both software-development and free software as a whole, i think it is a separate issue.
> 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.
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 ?
I feel ill just reading that sentence
Qt WebGL streaming (qplatform/qpa plugin):
The Qt binary runs on your PC as normal, but instead of opening an X11/Win32 window, opens a network port. You can open the URL in a browser to see the interface. Only one connection is allowed / only one user can interact with the app at a time.
Technology preview since 5.10, will be "TP2" status in 5.11. See http://blog.qt.io/blog/2017/11/14/qt-webgl-cinematic-experie... and http://blog.qt.io/blog/2017/07/07/qt-webgl-streaming-merged/
Qt for WebAssembly:
The entire QtWidgets / QML libraries are compiled to WASM and run clientside. There is no server-side component.
Will be released as a technology preview in the upcoming 5.11 release.
But a webgl canvas id doable and I think what they are aiming for. Which would be great for QML.
GTK 3 has something like that, too. Tried it once; super weird seeing Nautilus inside a browser. Cool, but weird.
Yeah. It's called Broadway. If someone wish to give a try, see https://developer.gnome.org/gtk3/stable/gtk-broadway.html
Also it is very incomplete. For example there's no way to do custom widgets that draw text (e.g. a graph). There's no good text area widget (there is one but it is extremely limited - you couldn't use it for a log output for example).
Plain QtWidgets is way way better on every level except animation and styling. And maybe touch support.
But if I were making a mobile app I'd definitely use Flutter. Much nicer experience than QML.
1. Refactor out to separate components a lot.
2. Use the .ui.qml and .qml code behind pattern to separate UI from code.
3. Use singleton QtObjects to create abstract classes that contain any non-UX behavior.
As for graphing, the built in components work pretty well:
https://doc.qt.io/qt-5.10/qtcharts-index.html
As far as QML widgets go, they have improved greatly since they released Quick Controls 2 (a rewrite of the initial set of controls).
And not like: JS is so shitty, better we make everything with it, even if there are better alternatives.
?
I can't imagine many people would like to download a 60GB AAA game or something like Photoshop to run it in the browser.
There are plenty of downsides to having ubiquitous WASM-compiled cross-platform "browser-native" apps, and having basically everything forcefully turned into an experience akin to ChromeOS out of convenience for app developers, but that doesn't feel like one.
Not saying we're there yet, but it's not hard to see where WASM could take us.
Difference being that WASM is kind of blessed format.
You won't get in the same universe as that until the web grows real threading support. Not this no-shared-data, ultra expensive, ultra heavy webworker nonsense.
Given SharedArrayBuffer seems to be un-shippable now due to Spectre, the planned future of WASM's threading seems uncertain. And without that WASM seems rather pointless to be honest. You just can't compete with native at anything compute when you can't use 80%+ of the CPU.
0 - http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
It's impressive and exciting it can run a full app like KATE. It feels as if you're running a Linux VM inside the browser, but no!
Edit: Forgot to mention that I tested on Windows with a screen reader and Chrome.
If you wish to have accessible applications, you'll need to run the native applications instead.
Complain to the browser developers then, they’re the reason why this is so hard for Qt running on the web.
The QTWebView is a separate plugin component with its own set of dependencies.
You wouldn't want to do that anyways, much more effecient to just communicate from Qt to Javascript webviews (but I'm sure you know that :))
But seriously, you say this like it's horrible, but a bytecode/VM that allows us to abstract over code that runs in a browser/code that runs a native app/code that runs in a device driver is really exciting. The fact that it allows infinite nesting is a inevitable mildly beneficial side effect to having interoperability.
Let's say 20% of that is images (it's actually less) ... it is not a problem to fit quite an extensive C++ program in that.
You jest, but this sort of thing probably is the death of almost all native software, sadly.
It’s 2018 and we still don’t have a common, wide spread, OSS framework for self-updating native apps that runs on all the major desktop operating systems. And let’s not even go into app store territory...
Is that the end of the world? No, of course not. But we aren't building better tools over time--for instance, google docs is distinctly worse than the word I used on macintosh back in the 90s for all the use cases I care about. So is pages! All this software is more complex, and generally for little benefit.
Sure, some users, in some cases, may happen to use some features that are new. The pitch isn't "this is a good tool", it's "you have to use this tool to interact with others or retain data portability." Seems pretty user hostile to me.
Disclaimer: My last job was Qt developer.
If only some people would stop contributing to creative work you don't see the value of and distributing it for free on the internet!
At present you have
Debian and a bazillion ubuntu derivatives using a debian package. ubuntu/debian are going to have different versions of some libraries but you can package deps with your app.
Arch and derivatives have a pkgbuild. This is quite simple if anyone cares about your app your arch users will probably upload one for you to the arch user repo.
Fedora and suse have rpms. These will be similar but not identical.
3 packages and you can cover most of your potential users.
In the future you reasonably may expect to be able to distribute a flatpak and be done with it.
No one really took FHS seriously, each installation is a special snowflake with its own GUI and dynamic libraries story across Linux variants is even worse than it was on other OSes.
With modern Windows, macOS, Linux, iOS, Android, I'm going to have to run around for ages figuring out how to sign my packages. Despite what you might say, it's never easy or pleasant.
1. https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...
> To give an example, the app I’m working on (https://github.com/OSSIA/score) is roughly 300kloc of Qt / C++ code and compiled in WASM almost from the first try. I’m still having freezes in some places but overall it’s working great.
But then again, since 2017, anything that can happen will.
On the other hand, if you already do have a Qt application, then you can maybe get a webapp for almost free?
I've been asked by a customer to port my recent Qt app to iOS. Got the equipment, was about to get the development environment set up, got XCode installed....and now this.
This is pretty exciting if it all works as expected.
EDIT: aaaaaaand after trying some of the demos at https://github.com/msorvig/qt-webassembly-examples using a brand new iPad (iOS11/A10 Fusion core) using Safari, half the examples run out of memory, and the other half aren't touch enabled. Hmm.
EDIT2: Firefox iOS, same set of crashes.