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.
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.
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.
I found that hard to believe. But, clicking that link and trying the pizza demo... Yikes. It's not exaggerated at all.
So no pizza demo for me.
Qt for WebAssembly is available under the GPL3 and the Qt commercial license, though.
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”
Furthermore users don't care about the technology used to build the application if it works, that's the unfortunate reality.
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.
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
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.
emscripten/WebAssembly is pretty viable.
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.
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.
I don't see why you couldn't write your entire business logic, state management, etc. in C or Rust and treat it effectively like a client-side server, but I've never used wasm in that way so I can't speak from experience there. Either way, I can certainly see how that would require some extra effort, and of course it would only really be useful for applications that don't offload most of their work to a server.
With Emscripten, you can embed Javascript source code directly into the C code and then call the embedded JS function from the C side as well as C functions from inside Javascript.
E.g. JS embedded in C code:
https://github.com/floooh/sokol/blob/4c56a2ee15d81cac91b738b...
...called from C:
https://github.com/floooh/sokol/blob/4c56a2ee15d81cac91b738b...
...and a C function:
https://github.com/floooh/sokol/blob/4c56a2ee15d81cac91b738b...
...called from a JS function embedded in the C code:
https://github.com/floooh/sokol/blob/4c56a2ee15d81cac91b738b...
How about debugging? Is it possible to step through a mix of C and JS stack frames?
https://developers.google.com/web/updates/2020/12/webassembl...
The embedded Javascript can be debugged as usual.
In my case I usually debug the platform-agnostic code compiled natively in IDEs like Visual Studio or Xcode, and for the HTML5 specific code (which is just a few hundred lines) traditional "printf-debugging".
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.
...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 :/
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.
It’s not about controversy. It’s just that in most apps, the UI is far more than 10% of the code base.
No, just non-represenative of most apps, who are closer to CRUD than "GPS Navigator".
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.
------------------------
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.
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.
I'm not sure about the quality. I'm bullish on Flutter but the iOS reviews for the app are awful.
Nobody needs native UI. It's time we get passed that!
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.
Yes.
>Is it that hard to find developers who know more than one programming language?
Who said everybody has a team or this luxury?
Those were painful days...
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.