181–190 of 191 posts
Earlier quoted context omitted.
>Adding Flutter or any other UI library that draws everything from scratch is a bad idea. Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.
React Native. Handles everything in your list. Experimentally Linux (via Qt).
While this has little relationship to the original article... We really should be trying to use the native GUI toolkit (or cross-platform native UI libraries like libui), not using Flutter-esque libraries that draws everything from scratch. Coherent UI is a very important point to users IMO. Users can assume that some special feature from App X will also work on App Y. For example, in macOS Cocoa, textboxes have univ…
> Coherent UI is a very important point to users Nah, it ain't. At all! I used to believe it did. That's what we geeks think. And on mobile it doesn't matters for us either - keybings working consistently doesn't matter you're only using touch... Same thing with React Native, everyone thought it's awesome because native UI controls. But users never care about that. For touch UIs it's more user friendly to have you ap…
I simply love Flutter for Android and iOS development and have been using it since alpha. I haven't tried the web application part; I'm pretty sure I never will. Here's my opinion. I've created several apps with Flutter and every time I enjoy it. The UI is easy to make beautiful and the resulting code easy to read. It feels like all what the current Android SDK is missing. The current Android SDK is old and quite fra…
Those 1-star reviews on the Play Store are infuriating !
Earlier quoted context omitted.
IMO it really depends. There's a lot of big companies that have more than enough resources to be able to pay multiple dev teams to build and maintain apps across operating systems. From a few years ago, Twitter and Facebook were famous examples. They pushed so hard to try and build their apps using web technology but kept running into performance issues (thanks to infinite scrolling). After spending fuck knows how mu…
> I just don't understand why they put so much effort into trying to fit a square peg into a round hole instead of just going with native development. I think in the case of something like Facebook, the sheer complexity of their product drives a need for a singular code base. It would slow their engineering organization to a halt to ensure feature parity with largely seperate code bases.
Earlier quoted context omitted.
Often you can offload the business logic to the backend. That way you don’t have to implement it multiple times for each platform and you can change it “immediately” even if users don’t update their apps.
In such cases that same backend can send an XML (or JSON if you will) DSL payload that generates such UIs on the fly using the native widgets. Pretty easy to create such framework in something like C++ or having a scripting language that drives the native UI widgets, something like JavaScript.
UI these days is often more complex than the underlying logic itself. App logic became, to me, even secondary. Most of those issues are solved problems (databases, sql, rest, xml, json) and are mindnumbingly stupid and boring to implement. Save data record.. query data record.. validate data record, yeah, yeah, really complex.
A good fancy UI however... good luck.
Earlier quoted context omitted.
I think the popularity of Electron has shown that is actually isn't very important to users to use native controls. Also on Desktop, macOS is the only one that even has a single official "native" toolkit.
UWP is actually pretty easy to use and looks great & native on Windows.
Is “one week of electric scooter rental in Bucharest” the new world currency?
‘Mobile phone minutes’ were a common medium of exchange in parts of Africa (Kenya?) for a while (and maybe still is?)... mobility is also another commonly desirable service, so sure, why not?
Earlier quoted context omitted.
React Native. Handles everything in your list. Experimentally Linux (via Qt).
Except you end up needing platform specific code with React Native anyway. Cross-platform toolkits don’t actually work in practice.
I've never finished a React Native app without native code. I've done a few now and I've come to believe it's not worth even trying to avoid it and sometimes worthwhile to look for places where a little native module can yield performance or UI wins. React Native is the glue or orchestration and it is, to me, extremely good glue.
I haven't seen many people beyond the tutorial level suggest otherwise. It provides a common structure (which is enormously useful), and some quick consistency wins for simple stuff like your About Us screen.
Earlier quoted context omitted.
> performance issues (thanks to infinite scrolling) This problem is already solved by virtualized lists available in any decent framework. Why people don't use it is beyond me.
It’s not built into any frontend web framework by default that I know of. It’s the default approach on Android on iOS.
Earlier quoted context omitted.
Not true. I'm working with C++/Qt/QML/Javascript. No need to maintain 5 codebases. Just a single codebase compiles to at least 9 platforms: Linux, Windows, macOS, iOS, Android, *BSD, Raspberry, QNX and WebAssembly.
> Not true What's not true? You just agreed with my statement. ¯\_(ツ)_/¯