Qt for WebAssembly Technology Preview(blog.qt.io)
blog.qt.io
Qt for WebAssembly Technology Preview
http://blog.qt.io/blog/2018/04/23/beta-qt-webassembly-technology-preview/
195 comments
I'm not sure I buy that, are you saying that the only reason that Qt hasn't completely taken over writing native software on (even desktop! not to mention mobile where Qt also works), is a marketing problem?
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 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.
* Licensing: IANA lawyer, but my understanding is that the LGPL doesn't force you to release the entire source, unless you are shipping a single static binary or a custom version of Qt. If you dynamically link, you are good to go.
* 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.
* 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.
Actually, you _can_ release a static binary if and only if you also provide all the components needed to re-link the static binary. Read part 1 of the LGPL FAQ section on static vs dynamic linking [1]. It's trickier on iOS and Android app stores due to the distribution method. IANAL, but at one point Apple had a (obscure) link to the object files needed to re-link one of their programs which linked to an LGPL library -- alas I can't find the link anymore.
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...
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...
FWIW gamedevs have a natural aversion to anything with the term "GPL" in it. http://codesuppository.blogspot.com/2009/01/
Not saying it makes sense, just that groupthink is strong.
Not saying it makes sense, just that groupthink is strong.
Games devs have aversion to the FOSS culture.
It doesn't play ball with IP business and NDA rules that are common place in the industry.
It doesn't play ball with IP business and NDA rules that are common place in the industry.
Licensing is quite cheap compared to other commercial products in the same league.
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.
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.
The licensing bit is really trivial to summarize: It's LGPLv3. Formerly v2, so now it can't be used for free in some applications where it formerly could.
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.
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.
It's not though if you want to use Qt Quick
What do you mean?
The QtQuick compiler is only licensed for commercial use, according to their licensing page.
You can use the Qt Quick without compiling though it slows the loading.
QtQuick doesn't need to be compiled. That's just an optimization. I've never used it or needed it, though admittedly I haven't worked on massive QtQuick projects.
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.
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.
The QtQuick compiler is only needed if you want to optimize startup performance (by compiling assets to binary form in the build process). I've never needed it. I'm guessing you've never actually tried QtQuick based on your comment.
Not since 5.11.
> You can absolutely use it for free in any project, as long as you conform to LGPLv3.
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.
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.
Yeah, right.
"I don't want to pay for software, so here take a bloated browser as fake native app".
"I don't want to pay for software, so here take a bloated browser as fake native app".
"Such projects should at least consider using Electron"
I don't think QT and Electron are architecturally equivalent.
I don't think QT and Electron are architecturally equivalent.
> Such projects should at least consider using Electron which might have significant non-technical advantages for them.
Electron uses components that are under LGPL (Chromium for instance) so it's basically exactly the same license questions than with Qt.
Electron uses components that are under LGPL (Chromium for instance) so it's basically exactly the same license questions than with Qt.
You can totally use it for free in large scale commercial projects. Just link with it dynamically.
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.
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.
>You can totally use it for free in large scale commercial projects. Just link with it dynamically.
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.
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.
> 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.)
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).
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).
Thanks for the reply.
> * 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)
uh... yes you can. It's LGPL. Chromium and libchromiumcontent used in Electron are also under LGPL and this does not cause problems anywhere.
uh... yes you can. It's LGPL. Chromium and libchromiumcontent used in Electron are also under LGPL and this does not cause problems anywhere.
Here is a CMake example of deployment. It's not that difficult:
https://github.com/Timmmm/robocut/blob/master/CMakeLists.txt
https://github.com/Timmmm/robocut/blob/master/CMakeLists.txt
All of the points you raise are solved by my open source library [1]. It's a Python wrapper around Qt that in particular solves the deployment problem. With it, you use Qt under the LGPL, and thus typically do not need a Qt license.
[1]: https://github.com/mherrmann/fbs
[1]: https://github.com/mherrmann/fbs
> 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.
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.
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.
> 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)
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 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?
It has nothing to do with scale, it's either LGPL or pay for a commercial license. The commercial licenses are not cheap- $459 per seat per month.
Qt devs need to eat too and they don't have a bunch of sugar daddies like Linus.
QT is a developed by a corporation. I would presume most QT core devs are employees of that organization.
That's more or less the story these days. Thiago Macieira (the maintainer for Qt Core) keeps stats on contributors.
https://www.macieira.org/blog/qt-stats/
https://www.macieira.org/blog/qt-stats/
Even so, that's EXPENSIVE! It rules out a startup I'd say.
I would have agreed prior to the re-licensing to include LGPL, but startups can still jump in and ship a dynamically linked executable. If you truly need/want static linking tho, then you are right the cost is prohibitive.
No, it is actually quite cheap.
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.
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.
It should be peanuts if you have any revenue at all.
You'll need a license if it's not open source as far as I can tell...
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
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
I think you misread that. For any use, you need a licence, and the possible licences to choose from are 1. Commercial, or 2. Open source (GPL or LGPL).
You can make commercial software using one if the open source licenses. (Of course; otherwise it wouldn't be an open source licence.)
You can make commercial software using one if the open source licenses. (Of course; otherwise it wouldn't be an open source licence.)
It's LGPL-compatible, though, isn't it? Can't you just wall off the Qt layer in a separate library, and release the source to that?
IANA lawyer, but my understanding is that you are correct. The LGPL doesn't force you to release the entire source, unless you are shipping a single static binary. If you dynamically link, you are good to go.
Perfect for me: develop the front end using Qt (on an OSS licence) and Go, which is just a dumb data rendering layer with caching, and keep all the actual business logic server-side. I'll happily open-source a "shell" :)
> You have to write in languages that are not particularly enjoyable to ship a production application
Qt with Rust is progressing well.
Qt with Rust is progressing well.
My main problem with Qt is just that it doesn't feel native, it's as simple as that. This trumps all other problems like the fact that it's a bazillion exabytes and painful to set up etc.
It certainly feels more native than web/electron, swing, XUL, GTK and just about every other cross platform technology. It's about as good as you'll get without a native client for each platform, which will always be the best option.
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.
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.
I used to care about the native feel, but now as long as something has a good UI I don't really care that much. Case in point, visual studio code. The file menu is native and that's about it. The rest is html / JavaScript and it's a great interface. I don't care that the buttons don't match whatever OS theme I'm using. The web never has.
> Case in point, visual studio code.
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.
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.
I was talking about nicely designed non-native UX/UI. Why are you talking about electron performance?
> The web never has.
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.
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 don’t know if it’s a good thing that every website must look like a bootstrap website and every iOS app must have the same Color and menus, etc.
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.
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.
Delphi is almost as "native" as they get on windows and you still need to do a lot of extra work just to draw a checkbox on a grid.
Use of native controls and their benefits is greatly exaggerated and it all comes down to some murky-feely subjective opinion.
Use of native controls and their benefits is greatly exaggerated and it all comes down to some murky-feely subjective opinion.
Agreed Qt is a great framework and I'm excited to see this development.
Qt is great and probably the best cross-platform app-development environment.
Given that, why would you use this instead of just building a compiled package for a targeted platform?
Given that, why would you use this instead of just building a compiled package for a targeted platform?
Sorry, I'm not sure I understand your question. Every project I've been part of does build a compiled binary for each supported target platform.
This reminds me of a time, when I used to work for a very large company. After an unfortunate amount of meetings and powerpoint presentations about ubiquity and compatibility, we ended up putting a Flash VM inside a Java client, to read HTML.
Oh boy, sometimes you just walk away from a crash, but you're never the same.
Oh boy, sometimes you just walk away from a crash, but you're never the same.
I think this is misdirected criticism. WebAssembly runs at almost native speeds on a single very lightweight "VM".
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.
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.
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.
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.
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.
Violating OSS licenses is far more common with e.g. desktop Windows software than with Web-based SaaS.
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.
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.
the only widely used license that i know of that would get violated by this kind of use (i think) is the AGPL.
It is not only about violating licenses, rather leeching whatever software they feel like it, without give a cent back.
And there is no way to validate that.
And there is no way to validate that.
i would assume they are not contributing but if i wanted to find out if they did, i'd ask them.
should be fairly easy to validate if you know what they're contributing to.
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.
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.
> 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.
> 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.
> 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 ?
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 ?
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.
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.
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.
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.
Electron can.
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.
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.
You are right, in this case it does not make sense since you can already distribute the Qt compiled version.
And even if you want to ship native code within your Electron app, why would you use wasm instead of the native code with ffi ?
This would of course have to be tested but there might be less overhead? I haven’t used FFI but they mention that it is significant. I have written a V8 add-on using NAN and the performance is very good (as in passing relatively large arrays between C++ and Node is in the few microsecond range)
You can just use nodejs to execute wasm code. Not sure about how to have a native GUI though.
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.
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.
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.
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.
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.
Qt should create an html/Dom/css front end that binds to the webassembly backend. Would be more efficient and web friendly.
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!
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.
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.
This is not what Wt was built for, but there's a similarity...
https://en.m.wikipedia.org/wiki/Wt_%28web_toolkit%29
https://en.m.wikipedia.org/wiki/Wt_%28web_toolkit%29
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?
The problem here is probably more download time, not run performance.
WebAssembly is binary packed bytecode and generally takes much less space than UTF-8 JavaScript source files.
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.
Couldn't Qt's webassembly library be cached in your browser, to be reused by any Qt webassembly app?
[deleted]
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.
The versioning will be very custom and generally they will not be shared across apps. Just like react.js isn't shared across apps.
tree shaking optimizations will result in everyone having a different qt.wasm.
Hello world in Qt is 25MB as a demonstration of 'lightweight' Qt.
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();
}
$ g++ -O2 -g0 -fPIC hello.cpp -I/usr/include/qt -I/usr/include/qt/QtWidgets -lQt5Widgets -lQt5Core
$ du -csh a.out
16K a.out
Try it again with Qt configured for -static and not -dynamic.
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.
So nice to see people fabricating numbers and passing them off as data.
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.
The mechanisms are still there but the practice died when Qt stopped focusing on embedded targets.
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.
http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-pr...
Embedded is the biggest market for Qt right now.
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.
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.
> 1) Qt Widgets development stopped with 5.0.
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.
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.
I'll believe it when I see it. That also kind of hints there were others like me that didn't believe in the QML future.
Never understood the obsession some people have with Qt
It's a solid toolkit that gets the job done and gets out of the way.
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.
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.
That's what I thought.
Web-apps are architected fundamentally different than classical software.
Web-apps are architected fundamentally different than classical software.
uh ? I have a large Qt / boost app (300kloc) that I compiled with Qt/WASM and the resulting .js is less than 20 megabytes.
That was for native compilation and those figures were from their own website.
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.
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.
> a Flash VM inside a Java client, to read HTML.
I feel ill just reading that sentence
I feel ill just reading that sentence
Note that Qt has two separate technology previews for porting Qt apps to run in the web browser:
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.
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.
> 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.
GTK 3 has something like that, too. Tried it once; super weird seeing Nautilus inside a browser. Cool, but weird.
GTK 3 has something like that, too. Tried it once; super weird seeing Nautilus inside a browser. Cool, but weird.
> GTK 3 has something like that, too.
Yeah. It's called Broadway. If someone wish to give a try, see https://developer.gnome.org/gtk3/stable/gtk-broadway.html
Yeah. It's called Broadway. If someone wish to give a try, see https://developer.gnome.org/gtk3/stable/gtk-broadway.html
They should port the rendering of the qt components to Dom/css with a web assembly backend. That would seem like a web app but allow for c++ code reuse.
I think that would be more feasible with something like wxWidgets or libui [0], which already use each platform's native widgets.
[0] https://github.com/andlabs/libui
[0] https://github.com/andlabs/libui
GTK isn't native on a huge number of users' desktops, including mine. It wouldn't be so bad if the GTK CADTs would stop breaking style configuration with each release.
I don't think it's doable on a Dom/css in a meaningful way as the semantics are too different.
But a webgl canvas id doable and I think what they are aiming for. Which would be great for QML.
But a webgl canvas id doable and I think what they are aiming for. Which would be great for QML.
Having used QML in the past, its made the most sense to me out of all the UI/Animation setups I have ever used. This sounds amazing
I've used it a fair bit and it gets very messy very quickly. It pretty much encourages spaghetti code.
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.
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.
It definitely can get messy, but there are some very easy ways to keep your project well structured.
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).
https://doc.qt.io/qt-5.10/qtquickcontrols2-index.html
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).
https://doc.qt.io/qt-5.10/qtquickcontrols2-index.html
Unlike most of Qt, QtCharts is GPL, not LGPL. You can't avoid the virality by dynamic linking.
Say what you will, we need these kind of projects in order to push forward WebAssembly (and eventually JavaScript may not be the only dominant language for front-end web development). I'm curious how much of the canvas they're taking advantage of if any of it. It's quite exciting. I might wind up porting one of my existing Qt applications just to try this out and see what that would be like.
Wasn't it more like: most people know JS so everything (server, mobile/desktpp apps, etc) was made with it.
And not like: JS is so shitty, better we make everything with it, even if there are better alternatives.
?
And not like: JS is so shitty, better we make everything with it, even if there are better alternatives.
?
It was the latter I am afraid. Then the general hype started and now we have insanity like Electron etc. Don't worry web assembly is here to help JS, not to replace it ;-).
I wouldn't be surprised to see WebAssembly only applications once WebAssembly matures and can "stand on it's own free" honestly. JavaScript for sure will hold dominance for many, many years however.
I could find a few live demos [0] although some are broken
[0] https://msorvig.github.io/qt-webassembly-examples/
[0] https://msorvig.github.io/qt-webassembly-examples/
No example is working for me.
I just have "NetworkError" for all of them.
It's rare I have to disable ublock, but that helped me.
aaaah, thanks a lot! I did not made the link with the error name...
Tried on iPad, constantly running out of memory.
I'm seeing a ton of snarky comments, but isn't this what exactly WebAssemly is about (which I see people praising everyday as it opens up possibilities)
I had the impression WASM was about writing parts of web apps in it, so they get more performance.
I can't imagine many people would like to download a 60GB AAA game or something like Photoshop to run it in the browser.
I can't imagine many people would like to download a 60GB AAA game or something like Photoshop to run it in the browser.
Actually, if I could have Photoshop run in a browser, with its full feature set, and running at >90% of full native speed, that would be pretty awesome. And I'd even be willing to wait for the multi-GB download as long as it only happened once (with small deltas thereafter).
Not saying we're there yet, but it's not hard to see where WASM could take us.
Not saying we're there yet, but it's not hard to see where WASM could take us.
> Actually, if I could have Photoshop run in a browser, with its full feature set, and running at >90% of full native speed, that would be pretty awesome.
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.
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.
I can see where web assembly could take us, but I am confused about why people seem to want to go there.
Because Flash, Applets, .NET, Silverlight, ActiveX, NaCL,....
Difference being that WASM is kind of blessed format.
Difference being that WASM is kind of blessed format.
It would be awesome indeed, but the disk cache can't grow indefinitely. I can't imagine anyone looking at their browser's 20GB disk cache and say it's ok.
How do people install their AAA games and Photoshop today? I'd think the majority downloaded them, right?
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.
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.
I mean, web apps today are optimized to get a click-and-play feeling. Software like Photoshop or GTA5 isn't optimized for that, you need to download and install them for hours.
There is emscripten-qt that built Qt apps w/ Emscripten for a while now[0] (since asm.js and WASM should not change anything even though it hasn't had updates in a few years). Appears this uses Emscripten as well. I wonder how this compares at a tech level.
0 - http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
0 - http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
Thank you for pointing to this, I'd seen it before and was reminded of it.
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!
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!
https://www.destroyallsoftware.com/talks/the-birth-and-death... The end is neigh
Is it common for people to call it YavaScript?
Apparently it's a joke:
https://www.quora.com/JavaScript-programming-language-Why-do...
Unfortunately, this port seems to lack accessibility for blind people and others that require assistive technology. My conclusion is based on the demos linked elsewhere on this thread. [0] I have no idea how to make a conventional GUI toolkit accessible with ARIA, but I hope the Qt developers figure it out.
Edit: Forgot to mention that I tested on Windows with a screen reader and Chrome.
[0]: https://msorvig.github.io/qt-webassembly-examples/
Edit: Forgot to mention that I tested on Windows with a screen reader and Chrome.
[0]: https://msorvig.github.io/qt-webassembly-examples/
Accessibility like that likely won't be possible, as the only way to get accessibility in browsers is with the DOM, which is very limited in functionality.
If you wish to have accessible applications, you'll need to run the native applications instead.
If you wish to have accessible applications, you'll need to run the native applications instead.
What if some application developers don't make a native version available? Accessibility should be the default on all platforms, not something that application developers have to go out of their way to support.
> Accessibility should be the default on all platforms, not something that application developers have to go out of their way to support.
Complain to the browser developers then, they’re the reason why this is so hard for Qt running on the web.
Complain to the browser developers then, they’re the reason why this is so hard for Qt running on the web.
So, you're saying I could use a QTWebView in the browser?
No no no. Obviously you should compile your existing Qt application to webassembly, put that in a QTWebView and have that be your application.
And we will run this all on nebulet, an OS being written for a pure web assembly user space [0].
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.
[0] https://github.com/nebulet/nebulet
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.
[0] https://github.com/nebulet/nebulet
So basically Squeak, a 25 yr old technology that still runs bitexact across all it's virtual machines.
[deleted]
Yo, I heard you like browsers, so we put a browser in your browser, so you can surf while you surf.
This would be for the QtQuick backend.
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 :))
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 :))
What would be the security model of such a browser environment? Maybe like an iframe?
I suspect similar to wt c++
I think you should run your QT app inside Electron!
This (assuming it's Qt Quick) opens the door for a competitor to HTML for web apps.
Except this looks like it would be a big download, wouldn't it? And how would this UI interact with assistive applications like screen readers?
According to my chrome network tab cnn.com now comes to 1.7 megabyte. Without ad blocking, over double that.
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.
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.
Have you checked the sizes of the Qt libraries lately? QtCore or QtWidgets larger than 5MB each. Qt is simply an enormous amount of code. I currently can't get any of the wasm files for the demos to load to compare those, though.
How long until someone uses this to make an Electron app?
Once we compile Chromium to webassembly, we can run Qt in Chromium in Chromium in Slack!
See also https://www.destroyallsoftware.com/talks/the-birth-and-death...
You jest, but this sort of thing probably is the death of almost all native software, sadly.
You jest, but this sort of thing probably is the death of almost all native software, sadly.
There are some things we mourn. Nobody mourns cross platform distribution of native apps. Anyone who does hasn’t had to manage the insanity of installer apps and of papering over a million different OS versions and app versions.
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...
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...
The best native apps aren't cross platform. The worst native apps often are (at least from a mac perspective). We are simply moving to the lowest common denominator for all platforms, to the profit of business and the loss of the end-user. We can now develop software that is equally shitty for everyone much cheaper than we could before.
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.
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.
I don't disagree that the best native apps are amazing. But it seems so wrong to regard a desire to build cross-platform software as some kind of scheme by developers against their users. In so many cases, being able to use a program/service on many platforms is a huge part of what makes it valuable to the end-user. You can get your gmail from your computer, or your phone, or from a web cafe, and have it all work the same. You can share google docs with anyone and know they'll be able to access them. You can decide you're fed up with windows/macos/android/ios and you want to switch to something else, and most of your software will still be there waiting for you on the other side...
> In so many cases, being able to use a program/service on many platforms is a huge part of what makes it valuable to the end-user.
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.
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.
Well it would be great if there weren't hundred of FOSS desktop variants....
This seems to be a common complaint as if we were all standing on a life raft pushing it down with the collective weight of our respective keisters.
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.
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.
It is not only about package formats, since even when the format is the same, the expected directory layouts or installed libraries will be completely different.
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.
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.
The cross platform part is called source code. If all the chunks you use to build your app are cross platform packaging wont be horrible.
Quick example: to delivery safely my app with an web app, I need to add HTTPS and that's basically it. These days I can add Letsencrypt trivially.
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.
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.
As long as performance is important, native software will always have an edge. Depends on the application.
I’m a big fan of native UI, but I doubt this particular claim. The web stack is almost certainly more performance than GTK, for example.
Apologies, when I say native software, I don't just mean the UI.
I don't agree on this count either. You can have performance and maintainability by writing your business logic in a daemon. Only very few applications will find this IPC cost unacceptable, and WASM promises to raise the performance ceiling even further. There are lots of good arguments for native software, but I don't find the performance argument to be particularly compelling.
Looking at software that uses Qt[1], I'd say I'll be impressed once they have compiled one of them, say for instance Stellarium, to Wasm. It'd be great to see how a full software, not just a toy demo, behaves in webassembly.
1. https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...
1. https://en.wikipedia.org/wiki/Qt_(software)#Applications_usi...
On a comment to the article:
> 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.
> 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.
If everybody has a problem with Qt why don't we see gtk on more systems. The last time I checked you can use gtk on win/Linux/Mac it is free, and it sort of works.
Honestly, I can't wait to try it. This is exciting.
It would be great if this could be done with JUCE too!
Also FLTK, both would be very small compared to Qt.
No demo page?
"Because you can doesn't mean you should." -common sense.
But then again, since 2017, anything that can happen will.
But then again, since 2017, anything that can happen will.
On the one hand, I find it funny that people are using bloated electron to avoid writing Qt code, and now you can write Qt code even on the web!
On the other hand, if you already do have a Qt application, then you can maybe get a webapp for almost free?
On the other hand, if you already do have a Qt application, then you can maybe get a webapp for almost free?
See, this is what I get for procrastinating.
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.
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.
EDIT3: got it to cross compile and load off a server. And....ugh. It's got a long way to go. It works, at least. Still too large for a mobile device however.
[deleted]
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.