[blacktriangle]

We're nagging because the apps suck and stick out like a sore thumb. Maybe Flutter will be the one to get there and be the holy grail of cross platform UI development, but the developer community has been burned by this promise so many times, we're going to have to see the final product before getting excited.

Just because a project is ambitious doesn't mean we should all jump on board, particularly when similar projects have crashed and burned, and there's really nothing stand-out about Flutter that separates it from prior efforts.

[hanniabu]

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.

[danShumway]

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.

[0xFluegel]

> 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.

[hnedeotes]

Qt for WebAssembly: Pizza Shop Application exit (TypeError: undefined is not an object (evaluating 'handle[name]'))

[sombersonder]

May I ask what browser and version you ran this in? It does look dated but ran okay for me on Firefox 86 and Chrome 89.

[hnedeotes]

Yeap, Safari 14.0.3

[barbarbar]

When I try that link I get: RangeError: WebAssembly.Memory(): could not allocate memory

So no pizza demo for me.

[gagege]

Whoa, yeah, none of those Qt demos are good or even seem to work properly. Yikes.

[sgerenser]

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]'))

[ognarb]

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.

[eska]

The pizza demo didn't even let me input text into the credit card input boxes..

[cachvico]

These demos remind me of Flash..

[ryandrake]

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.

[hamandcheese]

> 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”

[kbd]

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.

[prathiks]

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

[hackerfromthefu]

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.

[ironmagma]

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.

[signal11]

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.

[ljw1001]

The Web is a shitty cross-platform UI toolkit For building apps. It’s fairly popular.

[tiborsaas]

+1

Furthermore users don't care about the technology used to build the application if it works, that's the unfortunate reality.

[signal11]

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.

[ljw1001]

Lotus notes UI issues were extraordinary. Nothing comparable to the native iOS vs Flutter app difference

[bradgessler]

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.

[tiborsaas]

> 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.

[ryandrake]

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!

[WoodenChair]

> Guess I never realized this was a controversial approach to take!

It’s not about controversy. It’s just that in most apps, the UI is far more than 10% of the code base.

[coldtea]

>Guess I never realized this was a controversial approach to take!

No, just non-represenative of most apps, who are closer to CRUD than "GPS Navigator".

[avar]

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.

[lenkite]

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++.

[buu700]

I'm aware of things like the LLVM based C to JS compilers, but they're not really viable for anything non-trivial.

emscripten/WebAssembly is pretty viable.

[iainmerrick]

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.

[pjmlp]

> 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.

[flohofwoe]

> 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 :/

[buu700]

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.

[rtpg]

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.

[signal11]

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.

[achow]

The blog exactly answers this.

------------------------

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.

[boring_twenties]

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.

[themolecularman]

> Google Pay switched to Flutter a few months ago for their flagship mobile app, and they already achieved major gains in productivity and quality.

I'm not sure about the quality. I'm bullish on Flutter but the iOS reviews for the app are awful.

[coldtea]

>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?

Who said everybody has a team or this luxury?

[comeonseriously]

Because developers only want to work with their favorite language/frameworks and managers don't want 7 different teams.

[groby_b]

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)

[birthday]

Just imagine trying to build a mobile startup company and having to write 2-3 copies of your app (Android, iOS, Desktop). No thanks!

Nobody needs native UI. It's time we get passed that!

[saagarjha]

People with disabilities frequently do.

[qbasic_forever]

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.

[lmm]

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).

[heavyset_go]

It's better these days. For desktop application development, Qt is available under the LGPL and the Qt commercial license.

Qt for WebAssembly is available under the GPL3 and the Qt commercial license, though.

[heavyset_go]

Qt's QML + QtQuick follow the declarative and reactive programming paradigms and use JavaScript, and were released before React existed.

[ognarb]

And it has a very nice developer experience :)

[smoldesu]

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.

[throwaway123x2]

Oof remember when PhoneGap was the next big thing? RIP

[The_rationalist]

Pure nonsense, phonegap has been renamed Cordova and is widely used. The Electron of smartphones is Ionic which is a sexy and performant superset of Cordova. PhoneGap (Cordova + Ionic marketshare) has a bigger marketshare than flutter and react native! Source: https://www.appbrain.com/stats/libraries/tag/app-framework/a... Ionic is a gift and it will only get more widespread, the myth that chromium is slow is increasingly dying. Also, did you notice the irony/hypocrisy that flutter is using the rendering engine made by chrome developers for Chrome developers ?

[raihansaputra]

Ionic has released Capacitor as the successor for Cordova. And it's still compatible with Cordova plugins so all the work from Cordova days is not wasted. Ionic is definitely a gift.

[TheGuyWhoCodes]

I remember big corps betting on phonegap and sencha for mobile 7 years ago. I also remember big corps betting on GWT.

Those were painful days...

[dmitriid]

Funnily enough, Sencha still can't be reliably recreated by any lib/framework/browser built-ins du jour (without sinking as much effort as Sencha did): https://examples.sencha.com/extjs/7.3.0/examples/kitchensink...

[cztomsik]

true, just like wysiwyg we have for react/vue/angular is still joke when compared to delphi/visual studio

[auganov]

Time is on webview apps' side. IMO cordova/phonegap got too big too early and the industry still has a revulsion that may not be justified anymore. I don't think they will ever come to dominate, but I do think hybrids will eventually go back to using webviews.

If groundbreaking UX is your core competency you need native. Hybrids get you neither the best feel nor the best dev leverage. Hybrids are selling the exact same dream phonegap has. But they let developers distance themselves from the bad rep and claim they're doing something different. Alternatively, at the other end, they get developers to build essentially native apps while pretending to save a lot of time.

[drewda]

On this note, I have 60% fond memories of Appcelerator Titanium and 40% frustrating memories :)

[mattschmulen]

Yup, really they had the right idea in that it was native components that were hoisted by JavaScript binding... it really lost steam because it became easier to just build native Swift (and later kotlin android). It was a solid play at the problem in it’s time. Note: I worked at Appcelerator in the “gogo” years and it was great, and they/we almost made it happen in a real way.

[JamesSwift]

Man those are some rosy glasses you got. I've got 20% fond memories, 80% frustrating memories : )