201–210 of 343 posts
Earlier quoted context omitted.
"I just don't trust it to be around long enough to be an investment for me." Normally I would be inclined to agree with you given that this is Google, but the good news is that Flutter is open source. So even if Google discontinues internal development on it, it's likely that the community will continue it anyway.
That's what I thought about Tcl/Tk.
What about a WASM powered UI kit? Wouldn't that finally fix the cross language issue?
Another example of where they follow standards/stick to browser specs is their use of web workers for background tasks [1]. In comparison Flutter uses dart isolates[2] which makes sense of course, since they use Dart -- similar performance models (do hard stuff in another thread).
[0]: https://www.nativescript.org/
[1]: https://www.nativescript.org/blog/using-workers-in-nativescr...
[2]: https://api.dartlang.org/stable/2.0.0/dart-isolate/Isolate-c...
Cross-platform frameworks that don’t use native controls have suffered from problems... - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.) - they don’t get updates to native c…
There's one place where none of this matters: Games engines. Games have the same, consistent (hopefully) easy to use interface across every platform they support. They either accomplish this, or they simply don't survive on the market. It has to be said that most modern UI frameworks ARE game engines, anyway. Or maybe its a tautology: game engines eventually become platforms, which become "OS's on other OS's". Which…
However, apps are not games. They're tools. And tools are not about giving your users challenges. They're about fulfilling a purpose as easily as possible. UI frameworks and conventions matter here because they lower the learning curve and cognitive switching cost, and they respect a user's preferences for how they wish to engage with their device (including valuable OS-wide capabilities like accessibility).
Companies that choose to use their own UI frameworks or avoid the platform's guidelines are doing so to the detriment of their user experience.
- Some do it accidentally, because they don't know the UX guidelines or subtleties of the platform
- Some do it for expedience, because they need to put out a product quickly with few resources
- Some do it strategically, because they want the user experience worse since it serves other purposes for them
Yes, UI frameworks change as OSes change, but it's rarely for 'no reason'. Stepping back, devices have gotten way more capable and their UX way more sophisticated... which does necessitate change. Though that's some extra work for developers, it's not about you. It's about your users.
Google has a history of introducing products and then killing them. For developing mobile apps they currently support "vendor native" via Android Studio using Java or Kotlin, Progressive Web Apps, and now Flutter. Will Google really support all three over the long term?
There is the chance of them throwing it away maybe noting it as an experiment on the way to whatever they land on inside Fuchsia but the amount of developer ire they would draw is hard to imagine.
[0]: https://9to5google.com/2018/03/02/fuchsia-friday-first-fuchs...
I have been a freelance Android Dev for past 4 or 5 years. I have recently built out a flutter app for a client. And honestly I am now looking for more Flutter work. UI development in Android is such a pain and I feel like I spend most of my time trying to get the UI just right. With Flutter I am building UI so much faster and getting to focus on the actual logic of the code. Dart was fine, I learned it as I went. I…
I haven't touched Android development since 2012. I remember the experience being a terrible hodge-podge of XML and Java which effectively required an absolutely attrocious IDE and an impossibly slow emulator. I assume things have changed since then, but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.
Yes, tremendously so. It's still XML for basic UI, but Kotlin is the primary language of choice these days, Android Studio is a solidly world-class IDE, and the emulator is very fast.
> but I wonder by how much and if Flutter's workflow skirts any of these issues altogether.
Flutter uses the regular Android emulator, and although you have more editor choice the recommended was to just use a plugin for Android Studio.
Like I said yesterday "The road block for adoption will be Dart. Why they didn't just choose Typescript or go with native javascript is beyond me. No one uses Dart. It was probably the poorest design decision they could make." The comment from pzo points out an even worst of an adoption showstopper.
They needed to be AOT compiled. Can't ship a JIT on iOS, after all. And JS is very unfriendly to static compilation. Dart is considerably better suited for AOT due to static typing.
There are other languages that are GC'd & AOT friendly, though, so I can't help you with why they didn't use any of those, though. But why they wouldn't use JS is pretty straightforward.
Earlier quoted context omitted.
I have recently gave a look at Qt after 5 years and it seems lots of things have changed for the better. You get the same hot reload like flutter when modifying GUI using QML (with V-Play you can even hot reload not just on simulator/emulator but on real device). Qt material theme has good look and feel. Sadly iOS theme is a little bit lacking. C++ is probably not the most productive language to write business logic…
Sadly, Qt has so many threats on their download pages that I feel it's only suited to companies that can keep full time lawyers on payroll...
Earlier quoted context omitted.
Sadly, Qt has so many threats on their download pages that I feel it's only suited to companies that can keep full time lawyers on payroll...
What? Qt is mostly LGPL. You don't need a lawyer.
Earlier quoted context omitted.
These seem like valid concerns at first glance, but I feel these are not really issues in practice (only in theory). >> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.) as `…
> as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not. On iOS, the extent of "branding themes" end up is often limited. > Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem? There is no Chrome on iOS. So Flutter is different from everything else out there. >…