I don't understand why more resources aren't being put into Qt and making that easier to use or building a more "web-developer-friendly" abstraction layer on top.
I don't know if they've changed their approach over the past year, but the last time I looked at Qt demos for the web, I was solidly unimpressed.
At the time, they were making almost all of the same mistakes that Flutter is, and the devs I talked to seemed to be of the opinion that those problems wouldn't be fixed until browsers started adding brand new capabilities specifically for them.
Looking now at the demos at https://www.qt.io/qt-examples-for-webassembly, a lot of the same problems are jumping out at me. A complete lack of accessibility features, poor handling of scroll events, large load times, unfocusable fields, lack of keyboard controls, etc...
Halfway through playing with their pizza app, the page just froze and stopped responding to any clicks at all. Maybe those demos are outdated?
Blazor and Rust are showing a lot of promise here, but from what I know about Qt I'm much less optimistic, because Qt is used to handling everything about rendering itself -- and as Flutter is showing that's just not a good approach to building web GUI frameworks. But (again, purely from what I've seen) trying to layer on a system where Qt is actually interacting with the DOM seems like it would require a somewhat difficult shift in its architecture. Maybe I'm misunderstanding the problem though.
> Looking now at the demos at https://www.qt.io/qt-examples-for-webassembly, a lot of the same problems are jumping out at me. A complete lack of accessibility features, poor handling of scroll events, large load times, unfocusable fields, lack of keyboard controls, etc...
I found that hard to believe. But, clicking that link and trying the pizza demo... Yikes. It's not exaggerated at all.
At least you got the pizza demo to work at all. All I got was a large Qt logo with the message: Application exit (TypeError: undefined is not an object (evaluating 'handle[name]'))
For the moment the only useful usecase of qt for webassembly I found is: https://qmlonline.kde.org/ It's really useful to share some bits of QML but otherwise I wouldn't recommend using Qt for the web as much as I wouldn't recommend to use Flutter for the web.
I don't even fully understand why "cross-platform UI development" is such a holy grail. Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is? Is it that hard to find developers who know more than one programming language? With a lot of these frameworks and higher level abstractions, if you go off the toy-app happy path, you end up fighting the framework and tools more than you're writing your app anyway.
> Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is?
I mean... yes? There is a ton of incidental complexity (i.e. unrelated to the business domain) involved in creating nice user experiences. If dev salaries weren’t so high then sure, more companies would probably spend the money to repeat the same work across several platforms, but right now? No way.
That said, I still think I agree that you give up more than you gain by going cross platform, at least for now, but I totally get how companies look at how much it’s costs to hire and says “you know what? I’ll take a cross-platform compromise”
Not to mention the LARGE realm of internal tools where you need something functional as conveniently as possible and aren't trying to drive a consumer-product-level market-differentiated experience.
It also takes time to ensure the feature is developed for all platforms. Due to low usage you may not bother developing for that platform. Thus feature in one platform lag other.
I worked for a company where we did iOS release after very 3 android release coz android was 80% users and iOS 20%. Mind you this was a cross platform Iconic/Cordova app. Now think if we did native. iOS users would have to wait even longer
Companies are too efficient for that, even if dev salaries were cheaper they would still want to fund just one version and pocket the difference, and eventually market competition will make that the norm.
Not only that, but corporations are not everything. What about one and two person shops? It would really be nice to be able to develop a product without first having to invent the universe.
Counterexample: banks started with shitty cross-platform UI type apps, but those received low customer satisfaction figures so most of them have now switched over to native apps. A similar thing happened with Facebook.
Users are not knowledgable enough to know what technology was used to build a product, but many have repeatedly complained about non-native UIs.
Heck, Lotus Notes went from being a market leader to an also-ran and user complaints about UX to corporate IT departments definitely played a role in convincing those departments in switching away.
More recently, this also happened with many mobile apps made with cross platform/HTML5 toolkits. They got low review scores and low user engagement across many firms, prompting a switch to native.
It’s not just a “small UI layer” — there’s an entire stack that goes with it. Want to build iOS apps? Can’t do it on Windows or Linux; you have to buy a Mac, run macOS, learn that whole stack, install Xcode, figure that whole thing out, learn how the App Store works, including all of its rules and regulations. But that’s not all—you also have to figure a CI pipeline for that whole thing too.
Rinse and repeat for every platform.
That’s what makes the web beautiful: you write the app once and it mostly runs everywhere. You have to figure out the infrastructure I described above once and you’re done.
Or at least that’s how it use to be before the major platform players realized how lucrative it is to charge developers App Store fees.
> Is it that expensive to separate your business logic from UI and write the small UI layer
Not sure what apps you've built, but usually that business logic is the minority of the codebase. The rest of the stuff is boilerplate, like drawing boxes, describing layouts, handling events, managing state. All this has nothing to do with business logic.
Ideally, I want to write it once that I want a row of buttons what colors they have and what function should be called when the user clicks on it.
I did what you describe and extracted all the logic in a small component I manage and the result was very banal, extremely straight forward code with was essentially "business logic". The 90% rest was building the UI based on it.
Last major one I worked on that needed to be cross platform was a GPS navigator, which had massive functionality in C and C++ under the hood, called from the platform-specific UI/event handling code through Objective-C-to-C++ on iOS, through JNI on Android, and directly on PC native platforms. It worked pretty well. The ratio of platform-specific to platform-independent code was very small, so it was not like writing the app N separate times. Major engineering savings AND each platform's build had its own UI idioms that users of those platforms were accustomed to. Guess I never realized this was a controversial approach to take!
And write your shared business logic in what language? If it's a C library perhaps you could do this on iOS and Android, but how is that going to run in a browser?
I'm aware of things like the LLVM based C to JS compilers, but they're not really viable for anything non-trivial.
That's why a lot of shops are writing the same logic N times in N languages and frameworks. It can actually be easier than having to target something these wildly different platforms share.
If your business logic is in C - well you are in luck! Use emscripten to compile this to WASM and you can use it in the browser. This approach is very much viable. Large scale commercial web-applications like Figma are written in C++.
Well, if “viable” means “doable but really fiddly”.
C/C++ is fine on iOS (at least when interoperating with Obj-C, Swift is trickier).
C/C++ is “doable but really fiddly” on Android, same as web. There’s a compiler toolchain but not much IDE support, and you have to do all the JNI marshaling yourself.
So C/C++ is only barely usable for common cross-platform code, and yet it’s the best option. What other language are you going to use?
It’s kind of ridiculous, but that’s the way it is. Programming languages are all the same in principle, but in practice they don’t interoperate well and they can’t easily be used everywhere.
> and you have to do all the JNI marshaling yourself.
After 10 years of Android, while I understand the goal is to force developers not to write unsafe native code, Android team could have already provide better tooling.
However they have always behaved as the NDK was something they had to offer, not something they actually wanted us to use.
> but in practice they don’t interoperate well and they can’t easily be used everywhere.
...and yet, it's still much better than replicating the same code in different languages just to support different platforms.
The idea that a platform dictates the language to be used for creating applications on that platform has always been ridiculous, just because it was the status quo on the web for a bit over a decade doesn't mean it's a good idea that should be copied :/
I at least agree with this! It’s a big shame that the major mobile OS platforms bless only one or two languages for targeting their devices, and are at best neutral, at worst hostile to developing in other languages.
I'm not commenting on any other platforms, but I maintain a few C/WebAssembly libraries and they work exactly as expected without being unreasonably large. C-in-JS has been viable for a number of years now.
I realise it works, I just don’t think it’s really useful for what was asked for, a way to write common cross-platform business logic for a platform-specific UI.
Unless there are some great new tools I’m not aware of, C on WebAssembly seems about the same as C on Android. You can compile stuff just fine, and run it, but actually connecting it up to any substantial UI written in JS/Java is going to be incredibly tedious.
For a computation library with well-defined inputs and outputs, and that “just works” and doesn’t need any debugging in situ, it makes a lot of sense. But I think business logic by definition is going to need a much richer interaction with the UI, and that’s what makes it hard.
you release feature X. The first person writes it for the web. The web version was easy, because the feature relied on URL deeplinking, which is nice and easy with browsers.
You then realize that Windows doesn't really offer such a concept as easily. You think about application URLs. That mostly works, but it takes a couple weeks for the Windows team to get it working.
You implement the feature over on Macs as well copying the Win strategy. But a recent Mac OS update causes a bunch of permission popups that mess with another thing. Now you're messing around with that, and your internal users are pissed (cuz they're all on Macbooks).
There is no Linux version, luckily.
I mean... OK, yeah, you still have to deal with platform differences even when using Electron. But you are in the same boat with like.... Slack, Discord, etc etc. You get _all_ that shared knowledge, a unified code base. And in theory you throw any of your engineers at the problem and they can try very hard googling "Electron [issue] windows".
I also bemoan the fact that _even Slack_, with its billions of dollars, didn't feel the need to have a native application. But I do get it, especially when there's a lot of pressure to ship.
While I realise you’re just providing an example, Windows has supported deep linking in one form or another since Windows 3.1 (DDE, specifically topics), but also HTTP-style application URLs (eg app://command?options=opts) ever since ActiveDesktop and WebView.
Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.
By unifying the codebase, the team removed feature disparity between platforms and eliminated over half a million lines of code.
Google Pay also reports that their engineers are far more efficient, with a huge reduction in technical debt and unified release processes such as security reviews and experimentation across both iOS and Android.
That's very interesting in light of the facts that
1) This announcement seems to claim that Flutter 2 apps can be deployed as web apps as well as mobile apps, yet
2) This very morning I received an email from Google stating that pay.google.com is going away and the service can only be used via the mobile app going forward.
>Is it that expensive to separate your business logic from UI and write the small UI layer in whatever the platform's "best practice" native language is?
Yes.
>Is it that hard to find developers who know more than one programming language?
Working on an app that's running on... 6 different OSs/UI toolkits on last count, yeah, that "small UI layer" is costly. And yes, finding devs that know more than one language/one UI toolkit is hard. (Heck, for some UI toolkits, finding developers is hard period)
Isn't the licensing for Qt a very curious and weird quagmire? Maybe it's better these days but I remember about 10 years ago there was a weird divide and unanswered questions about if you could really take a bet on using Qt and not be violating GPL.
No. 10 years ago it was 100% fine. About 25 years ago there was a licensing issue, and the Gnome project talks about it as their reason to exist to this day (which amounts to spreading FUD at this point, IMO).
QT isn't neccesarily a crowd pleaser, and in 2020 it's starting to look a little long in the tooth. Don't get me wrong though, I love QT on the desktop, and it powers some of my favorite software out there. Ultimately though, I don't think QT's fate is on the web.
At the time, they were making almost all of the same mistakes that Flutter is, and the devs I talked to seemed to be of the opinion that those problems wouldn't be fixed until browsers started adding brand new capabilities specifically for them.
Looking now at the demos at https://www.qt.io/qt-examples-for-webassembly, a lot of the same problems are jumping out at me. A complete lack of accessibility features, poor handling of scroll events, large load times, unfocusable fields, lack of keyboard controls, etc...
Halfway through playing with their pizza app, the page just froze and stopped responding to any clicks at all. Maybe those demos are outdated?
Blazor and Rust are showing a lot of promise here, but from what I know about Qt I'm much less optimistic, because Qt is used to handling everything about rendering itself -- and as Flutter is showing that's just not a good approach to building web GUI frameworks. But (again, purely from what I've seen) trying to layer on a system where Qt is actually interacting with the DOM seems like it would require a somewhat difficult shift in its architecture. Maybe I'm misunderstanding the problem though.