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 universal readline-esque keybindings (and is configurable globally) which, as an Emacs user, very, very useful.
Most Mac apps use Cocoa as the GUI toolkit, so basically all kinds of apps can benefit these keybindings.
Another example of this directly benefiting users is the addition of tabs in macOS Sierra.
macOS Sierra added tabs to Cocoa apps, and applications could get the feature without additional modification. I can use tabs in any application, with the same look-and-feel, in all apps.
Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!)
Adding Flutter or any other UI library that draws everything from scratch is a bad idea.
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 app be friendly by being unique. The thing that "users prefer native" was just because users like fast and responsive UIs, if Flutter can provide fast and responsive UIs, nobody cares if it isn't native.
Even on desktop, the best UIs I've ever seen (take the new Blender's 2.8 widely appreciated UI) just use OpenGL and draw their own widgets.
People say they care about "coherence" or "consistency" when they are too clueless to figure out what's actually broken about their UIs, so they assume this is the issue. An awesome UX/I is one that would keep being awesome even if each and every button would have a different and inconsistent style, what matters is higher level. Let us stop bitching about things being incoherent or inconsistent when the actual issue is the lack of ability to figure out what is so wrong with a UI that it hinders users!
(Oh, and everyone will always want custom branding and styles, whether we like it or not... We need technology that can embrace uniqueness and incoherence and inconsistency and make it work properly and shippable in time!)
The massive success of Electron apps shows that users don't really care about native controls. Even though electron is terrible in resource usage it enables unmatched development speed for teams. If libui or other libraries can give this experience then most teams won't hesitate using it!
> Windows apps usually just re-invent all kinds of UI elements
It wasn't always this way. Before Win8, most apps used native controls on Windows.
When it became apparent GPU rendering is the way forward, MS re-implemented them in WPF. It does draw everything from scratch, because the backend is now DirectX 9. But it was a first party reimplementation, the UX is good.
Then came Windows 8 and Windows 10, trying to converge PCs and phones. They screw up the UX. Now windows phones are shut down, but UX on PCs still suffers the consequences. The new GUI framework is better then ever, but there's no consistent UX on top.
> Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!)
and on next line you say
> Adding Flutter or any other UI library that draws everything from scratch is a bad idea.
The first thing you said is the reason why we need something like Flutter. There might be a standard way of doing things on Mac but on Windows and Linux there isn't. Flutter at least gives the hope that we will see consistent UIs across multiple platforms while maintaining same code base. That isn't bad thing.
Author here. Never expected it to reach here. 24k views and it's been ~14 hours since I wrote it. I agree with you. There is currently a competition between kotlin multiplatform and flutter, a shared backend vs a shared UI. Guess what, exactly what you said, it's a lot easier to share the backend than recreate the full UI like a game does. I'm not against flutter, but it feels too immature for now and the pains really show up. Apple showed up their new UI toolkit for developers, which does animations in the best way possible, Flutter team reaction was "you can make a library to improve it if you want" and "we should improve our docs" but no one will recognize there are issues in the framework that could be improved.
I agree with this 90%, but I'm not sure about the state of GUI apps after Windows 7. Up to Win7 though, most applications simply used native controls, sometimes wrapped by WPF or WFC.
I used to write for WINAPI/GDI and I used to loathe it; I mostly disliked the way messages were handled by default: huge switch statements. After switching to Linux and checking out the many "toolkits" I find myself craving for some GDI-esque toolkit. GDI was bad, outdated when I started writing it (circa 2009) but things "just worked", looks were consistent and controls would do the same across applications. The GNU/Linux counterpart is a mess: drag & drop sometimes works across toolkits, sometimes it does not; some toolkits are unwillingly to standarize with each other; the looks are all different, the functionalities too. Need an IME? Well here's one for KDE and another one for GTK. And if you use a different toolkit, chances are there's no IME for you. Right clicking on text-boxes and getting the same default options is great, so is being able to extend the same text-boxes systemwide. This is simple on Windows, but GNU/Linux requires one implementation per widget type per toolkit. It's all fragmented and no one cares. I miss GDI, I crave for a simple standard X11-wide widget system. Users do care about widgets working the same on different applications and they don't care about which toolkit is being used, specially non-tech savvy people. I believe those issues are more linked to the meme of "year of the desktop Linux" never arriving than anything else, really: UX should be consistent.
Add to this Accessibility: Standard widgets normally have accessibility features built in, working well and tested to make sure apps work correctly with various assistive technologies like screen readers, zooming, key controls, etc.
> 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.
If you’re talking about macOS, then I agree with you, that’s something I cared about when I was using Apple’s OS. Recently I moved to Windows for my personal machine, on this system you really don’t have coherence between applications, even between things developed by the same company or for applications tightly coupled with the OS! It’s just a big mess where each interface has its own set of rules incompatible with others. I would understand if people more familiar with Windows don’t care at all about the overall coherence given how random things seems to be.
> We really should be trying to use the native GUI toolkit
Yes.
The problem with that is that it requiere experience * each toolkit and that is pain-full for many.
This cause a FORCED split (when multi-platform):
- You want easy to use and fast iteration. You NOT use native UI. Reach for mediocre options
- You want the BEST of the BEST of the BEST. You pick native UI. However sometimes that toolkit is nuts (Windows API, Android, Linux. Ok like all of them?) Or if lucky you know the other alternative (Windows -> Delphi, Android -> Kotlin, Linux -> ????)
----
This is not a fair fight. UI is too hard everywhere. C++ toolkits are nuts.
UI derived from BaseUI..
//customize it for my project or create a new platform
UI.register(UIButton...
UI.register(UIWindow for "Window"
//Attach listeners..
UI.listen(...)
//Run the UI
UI.run(the UI directory)
When using a "no namespaced" control like "Button" it work like Flutter: The engine chose whatever it want. When use a specific control "UIButton" it trust the launcher to handle it. Or fallback if to the generic.
---
To be clear:
This is almost the same as usual. Except it work like a interpreted language: It have a monolithic core but is possible to code a specific version per platform (if desired). The critical component is the ability to register to the engine (very easily!) new widgets, listeners, behaviors. etc.
> it took them almost a year to add support for 64 bit in APK
While the author's confusion is understandable, because most of the people posting in the linked Github issue have the same confusion, it's always been possible to build a 64-bit APK (and a 32-bit APK). The linked issue is actually about building a single "fat" APK with both 32-bit and 64-bit native libraries in it, which Google Play Store then repackages to have just the needed library for the device it's being downloaded to.
Shipping two separate APKs has always been possible and gives the same end result for just a little more build process work, which is (/should be) automated anyway.
I've been shipping an app like this for some time now, and it's really not a hardship in any way, certainly not one that justifies the amount of hand-wringing in that Github issue.
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 frankly painfull to work with. You just can't create beautiful apps with ease; it's always a hassle. It's also messy and not easy to read the resulting code. The way the whole way the framework is structured entails ugly code in my opinion. This all becomes evident when you use different apps on Google Play. You get the sense that every app reinvented their UI; there is no real UI continuity. Google became a freeloader after JetBrains created Kotlin and marketed it will. The thing is Kotlin made just a little better; in terms of boilerplate stuff; the framework I still hate compared to Flutter. What I really like about flutter is the framework and “it’s all a widget” idea. You can basically do crazy things in UI with ease and on the other hand just use the standard UI components with a great result.
As an example I've created an alternative to Nissan's Connect EV app. It's basically a way to control and monitor your electric vehicle from Nissan. The official app is I’m very disappointed by; it’s slow and full of wrong decisions.
@tobiaswk - good job with your apps! I completely agree with Android and UI design which is painful. Flutter is far from perfect but a non designer can create something pretty decent. Users appreciate the experience.
I am working on 3 Flutter Applications & 2 of them are currently in production. On average we receive 1 major bottleneck a month, which gets resolved with 3rd Party fixes.
Happy to help if you are stuck on any issue with Flutter. Our background is native application development, so far this is the best Cross-Platform Development toolkit available.
Phonegap, Ionic & others are web wrappers. PLEASE let Flutter grow!
React Native isn't a web wrapper. It uses a Javascript engine to render native iOS/Android components (unlike Flutter, which doesn't use native components, and instead renders everything from scratch).
Flutter is young, and there are bugs, but velocity is high and it is advancing the state of the art. It is a huge leap in accessibility and productivity.
I really don't understand the complaint about setup. If expanding an archive and setting an environment variable are that daunting, wait til you try mobile development...
Snark aside, remember phonegap/cordova? Pine for those glory days of low friction?
The question is: if Flutter will not get traction that Google expects, what will happen with the project?
The space of multi-platform mobile apps toolkit is already occupied by several well established players (React Native, Qt, Xamarin and a dozen of other more or less popular tools, sometimes well entrenched in their niches, like Unity for games).
Flutter comes with rather obscure language and is late in the game, so it will have to provide something truly game-changing to succeed and I am not sure if that what it offers now is sufficiently appealing.
While it may not appeal to native devs I've found Flutter a lot more appealing compared to React Native.
React Native just keeps breaking things, like for example at something like 0.56 the textinput just broke on Android beyond usable and was stuck at that for like half a year.
I don't particularly like Dart as a language but as an SDK Flutter just feels a lot more solid than RN.
As a flutter user, I think the answer to what is "game-changing" is the flexibility it provides for making custom UI screens that would be really challenging in other frameworks. Also, there's the top notch animation support. When combined with tools like Flare, things are much more straight forward to create and they are cross-platform to boot.
It will get cancelled just like every other Google project that's not the best in its field. Google can't seem to handle being second best in any project they start, so they use cancelling projects as a way to hide the evidence of their failures.
I like Flutter very much. In some aspects it is much better than native iOS development. But it's far from perfect, so perhaps this post will prompt Google to hire more people to handle issues.
But, it's not like other companies are much better at this. At React Native they just autoclose them after some time. While Apple most likely has more open issues than Flutter but the data is not public.
Tip: For anyone trying out Flutter, please remember to evaluate it based on release builds of your app. Scrolling and animations can feel a bit "off" when running the default debug builds. The 60 FPS butter is only really applied when that `--release` flag gets tacked on.
Not using Android Studio, so not sure how easy it is to miss the massive performance difference of optimized vs. debug builds in that workflow.
If running in Debug mode means it's running < 60fps I wouldn't touch it with a bargepole. Native stuff doesn't do that and React Native/Nativescript don't do that either!
I have a couple of android app PoCs in mind but didn't want to go down the Android SDK way which IMO is becoming more and more complicated and verbose with every release.
Just tried Flutter and React-Native yesterday for the first time, and I'm sorry to say both were sorely disappointing.
Flutter was easier to install and get working, but Dart seems to be as verbose as Java with some JavaScript style syntax mixed in. The main dart file was as verbose as a boilerplate native SDK Activity.
RN was worse, though I expected it to be simpler. Something called metro server nearly froze the entire machine on every attempt. Had to power off and restart about 5 times. Then, based on GitHub discussions, built something else called watchman from sources. The official docs don't mention that watchman is critical. That improved it for a while but then the system wide near-freeze came back again. I wasn't even able to display a simple hello world app because of installation and deployment problems.
So far, Kivy seems to be the only alternative that is both simple to code and to deploy. Its file sizes are massive, but given that I already find Android SDK so frustrating to design and implement quickly, I don't want alternatives that are equally frustrating.
While it's good feedback to the respective project owners to make onboarding easier, it is a mistake to judge tools based on < 1 day of usage (which is almost entirely onboarding angst). You are only experiencing one, relatively infrequent transient story, not the steady-state one.
In the beginning of a devs experience framework code appears to eclipse app code in size and complexity, but over time the app will tend to grow to overwhelm the framework.
Yep, React Native has horrible dev experience... this is what drove me to Flutter. Dart may be ugly but after you get used to it it's mostly "Typescript done right" imo ;)
I tried Flutter a few times to have a play - really like it. Obviously a lot of the packages available hook you into the Google ecosystem (Firebase is ridiculously easy to get working).
There are quite a few things missing, and I personally found it quite hard to get going (but that might just be a general lack of skill at getting tooling set up), but there's an awful lot to like if you want to dive into getting something set up on-device quickly.
This seems like a fairly biased post (as he admits himself). Flutter has a lot of problems, but if you've used any other cross-platform system, you know it's a hard problem to solve.
A friend described it to me as "Unity for apps", which I think is pretty positive and accurate.
Author here. Yeah, it was supposed to be "here are my frustrations", not like "Flutter is bad, let's burn it".. but of course, the thing grew up beyond control. 38k view so far.
For those who are looking for an alternative to Flutter/React Native, please check out Nativescript @ https://docs.nativescript.org!
It's different in a few key ways:
- Draws native components (Flutter draws every pixel)
- Pure JS native (i.e. JNI powered) shim layer (you can write stuff like `const intent = new Intent()`)
- Typescript as first-class (not quite so with React Native, and IMO Typescript > Dart as far as type systems and ergonomics are concerned)
- Ability to use both Angular and Vue to structure your app (there's also projects out there like Svelte-Native, which is extremely promising from the performance perspective)
- More community driven project (with Progress standing behind, following the open-source & extra features business model)
I've recently done a bit of Flutter development and have enjoyed it quite a bit. The third party Provider API solves all the state management issues, it should become the default.
OP has some valid points for sure, but fact is that any framework is going to have issues. Just part of the game.
That sounds interesting. What would be the go to documentation for a good Provider API implementation (i.e. like a best practice guide with an example)?
I've written one app in flutter and the experience was good. It was very easy to get started, and the dev experience was on par with web development with very fast hot reload.
However I would say where it excels at is in creating a fully custom-branded experience rather than sticking to the native elements. I reckon https://reflectly.app/ is the poster child for this.
I am not sure if users care about controls being "native". Examples from desktop: Photoshop used non-native controls, and nobody cared. MS Office always had non-native looking menus. DAW (digital audio workstation) apps all look non-native.
All it does is let you write iOS UI code in Java or Kotlin, and target both iOS and Android from a single project.
It uses the actual underlying iOS API, and simply provides Java wrappers for them, that map one-to-one.
I keep wondering, and don't know why it hasn't gained much traction. It is so much better than Flutter, is obviously reliable since it's a simple 1-1 mapping/translation layer. (There is more work involved with it, as you have to write the UI lawyer twice, but that's about it.)
‘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?
Flutter is not that bad. It is a step in the right direction but there are some paradigms that makes simple things hard. Animations are harder than necessary and building non default layouts requires a bit of thinking to get right.
My biggest issue is that there is still this "uncanny valley" feeling when using a flutter app. It feels much better than a react native or Cordova app, but something still feels off.
Right now it seems great for prototyping. For iOS however, I've been playing around a bit with SwiftUI which currently (even in its beta state) provides an astronomically better dev experience and user experience.
[+] [-] pcr910303|6 years ago|reply
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 universal readline-esque keybindings (and is configurable globally) which, as an Emacs user, very, very useful.
Most Mac apps use Cocoa as the GUI toolkit, so basically all kinds of apps can benefit these keybindings.
Another example of this directly benefiting users is the addition of tabs in macOS Sierra.
macOS Sierra added tabs to Cocoa apps, and applications could get the feature without additional modification. I can use tabs in any application, with the same look-and-feel, in all apps.
Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!)
Adding Flutter or any other UI library that draws everything from scratch is a bad idea.
[+] [-] nnq|6 years ago|reply
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 app be friendly by being unique. The thing that "users prefer native" was just because users like fast and responsive UIs, if Flutter can provide fast and responsive UIs, nobody cares if it isn't native.
Even on desktop, the best UIs I've ever seen (take the new Blender's 2.8 widely appreciated UI) just use OpenGL and draw their own widgets.
People say they care about "coherence" or "consistency" when they are too clueless to figure out what's actually broken about their UIs, so they assume this is the issue. An awesome UX/I is one that would keep being awesome even if each and every button would have a different and inconsistent style, what matters is higher level. Let us stop bitching about things being incoherent or inconsistent when the actual issue is the lack of ability to figure out what is so wrong with a UI that it hinders users!
(Oh, and everyone will always want custom branding and styles, whether we like it or not... We need technology that can embrace uniqueness and incoherence and inconsistency and make it work properly and shippable in time!)
[+] [-] jazoom|6 years ago|reply
Some would say re-writing the same app 5 times (Windows, macOS, Linux, iOS, Android) and maintaining 5 codebases is a bad idea.
[+] [-] vijaybritto|6 years ago|reply
[+] [-] Const-me|6 years ago|reply
It wasn't always this way. Before Win8, most apps used native controls on Windows.
When it became apparent GPU rendering is the way forward, MS re-implemented them in WPF. It does draw everything from scratch, because the backend is now DirectX 9. But it was a first party reimplementation, the UX is good.
Then came Windows 8 and Windows 10, trying to converge PCs and phones. They screw up the UX. Now windows phones are shut down, but UX on PCs still suffers the consequences. The new GUI framework is better then ever, but there's no consistent UX on top.
[+] [-] rohan1024|6 years ago|reply
> Stories like these are mostly only macOS; since Windows apps usually just re-invent all kinds of UI elements, while Linux's GUI toolkits are super-fragmented. (GTK vs Qt is one thing, and there are lots of other options!)
and on next line you say
> Adding Flutter or any other UI library that draws everything from scratch is a bad idea.
The first thing you said is the reason why we need something like Flutter. There might be a standard way of doing things on Mac but on Windows and Linux there isn't. Flutter at least gives the hope that we will see consistent UIs across multiple platforms while maintaining same code base. That isn't bad thing.
[+] [-] bernaferrari|6 years ago|reply
[+] [-] IshKebab|6 years ago|reply
Also on Desktop, macOS is the only one that even has a single official "native" toolkit.
[+] [-] stelonix|6 years ago|reply
I used to write for WINAPI/GDI and I used to loathe it; I mostly disliked the way messages were handled by default: huge switch statements. After switching to Linux and checking out the many "toolkits" I find myself craving for some GDI-esque toolkit. GDI was bad, outdated when I started writing it (circa 2009) but things "just worked", looks were consistent and controls would do the same across applications. The GNU/Linux counterpart is a mess: drag & drop sometimes works across toolkits, sometimes it does not; some toolkits are unwillingly to standarize with each other; the looks are all different, the functionalities too. Need an IME? Well here's one for KDE and another one for GTK. And if you use a different toolkit, chances are there's no IME for you. Right clicking on text-boxes and getting the same default options is great, so is being able to extend the same text-boxes systemwide. This is simple on Windows, but GNU/Linux requires one implementation per widget type per toolkit. It's all fragmented and no one cares. I miss GDI, I crave for a simple standard X11-wide widget system. Users do care about widgets working the same on different applications and they don't care about which toolkit is being used, specially non-tech savvy people. I believe those issues are more linked to the meme of "year of the desktop Linux" never arriving than anything else, really: UX should be consistent.
Well now I'll end my rant.
[+] [-] russellbeattie|6 years ago|reply
[+] [-] dgellow|6 years ago|reply
If you’re talking about macOS, then I agree with you, that’s something I cared about when I was using Apple’s OS. Recently I moved to Windows for my personal machine, on this system you really don’t have coherence between applications, even between things developed by the same company or for applications tightly coupled with the OS! It’s just a big mess where each interface has its own set of rules incompatible with others. I would understand if people more familiar with Windows don’t care at all about the overall coherence given how random things seems to be.
[+] [-] nicoburns|6 years ago|reply
[+] [-] mamcx|6 years ago|reply
Yes.
The problem with that is that it requiere experience * each toolkit and that is pain-full for many.
This cause a FORCED split (when multi-platform):
- You want easy to use and fast iteration. You NOT use native UI. Reach for mediocre options
- You want the BEST of the BEST of the BEST. You pick native UI. However sometimes that toolkit is nuts (Windows API, Android, Linux. Ok like all of them?) Or if lucky you know the other alternative (Windows -> Delphi, Android -> Kotlin, Linux -> ????)
----
This is not a fair fight. UI is too hard everywhere. C++ toolkits are nuts.
And it not need to be this way.
I think today we already have a good idea in how truly a good toolkit must be done: https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh...
- A lot can be actually cross-platform: Layouts, Units, colors, fonts calculation...
- Widget definition with a DSL (like SwiftUI) This allow:
- Real-time drawing of widgets AND easy drag-drop UI creation like Delphi or HyperCard (this is where HTML beat almost everything)
The above are candidates for cross-ui then you need:
- Rendered by each toolkit. With native controls
- Some way to communicate the backend to this front-end
I think this is alike a game engine:
1- You define the UI:
2- You have a driver that launch the UI: When using a "no namespaced" control like "Button" it work like Flutter: The engine chose whatever it want. When use a specific control "UIButton" it trust the launcher to handle it. Or fallback if to the generic.---
To be clear:
This is almost the same as usual. Except it work like a interpreted language: It have a monolithic core but is possible to code a specific version per platform (if desired). The critical component is the ability to register to the engine (very easily!) new widgets, listeners, behaviors. etc.
[+] [-] _-___________-_|6 years ago|reply
While the author's confusion is understandable, because most of the people posting in the linked Github issue have the same confusion, it's always been possible to build a 64-bit APK (and a 32-bit APK). The linked issue is actually about building a single "fat" APK with both 32-bit and 64-bit native libraries in it, which Google Play Store then repackages to have just the needed library for the device it's being downloaded to.
Shipping two separate APKs has always been possible and gives the same end result for just a little more build process work, which is (/should be) automated anyway.
I've been shipping an app like this for some time now, and it's really not a hardship in any way, certainly not one that justifies the amount of hand-wringing in that Github issue.
[+] [-] tobiaswk|6 years ago|reply
As an example I've created an alternative to Nissan's Connect EV app. It's basically a way to control and monitor your electric vehicle from Nissan. The official app is I’m very disappointed by; it’s slow and full of wrong decisions.
My alternative is called "My Leaf" and its available on Google Play and the App Store; https://play.google.com/store/apps/details?id=dk.kjeldsen.ca... https://apps.apple.com/us/app/my-leaf-for-nissan-ev/id143670... It's completely open source.
[+] [-] dkobia|6 years ago|reply
[+] [-] 555513|6 years ago|reply
[+] [-] desaiguddu|6 years ago|reply
Happy to help if you are stuck on any issue with Flutter. Our background is native application development, so far this is the best Cross-Platform Development toolkit available.
Phonegap, Ionic & others are web wrappers. PLEASE let Flutter grow!
[+] [-] GeneralTspoon|6 years ago|reply
[+] [-] onetimeaccount1|6 years ago|reply
[+] [-] ibejoeb|6 years ago|reply
I really don't understand the complaint about setup. If expanding an archive and setting an environment variable are that daunting, wait til you try mobile development...
Snark aside, remember phonegap/cordova? Pine for those glory days of low friction?
[+] [-] andrekandre|6 years ago|reply
in what ways?
[+] [-] piokoch|6 years ago|reply
The space of multi-platform mobile apps toolkit is already occupied by several well established players (React Native, Qt, Xamarin and a dozen of other more or less popular tools, sometimes well entrenched in their niches, like Unity for games).
Flutter comes with rather obscure language and is late in the game, so it will have to provide something truly game-changing to succeed and I am not sure if that what it offers now is sufficiently appealing.
[+] [-] krzat|6 years ago|reply
Popularity of Flutter increases steadily: https://trends.google.pl/trends/explore?cat=31&date=today%20...
[+] [-] verttii|6 years ago|reply
React Native just keeps breaking things, like for example at something like 0.56 the textinput just broke on Android beyond usable and was stuck at that for like half a year.
I don't particularly like Dart as a language but as an SDK Flutter just feels a lot more solid than RN.
[+] [-] marktechson|6 years ago|reply
[+] [-] Bootwizard|6 years ago|reply
[+] [-] krzat|6 years ago|reply
But, it's not like other companies are much better at this. At React Native they just autoclose them after some time. While Apple most likely has more open issues than Flutter but the data is not public.
[+] [-] mekkkkkk|6 years ago|reply
Not using Android Studio, so not sure how easy it is to miss the massive performance difference of optimized vs. debug builds in that workflow.
[+] [-] jinglebells|6 years ago|reply
[+] [-] lovelearning|6 years ago|reply
Just tried Flutter and React-Native yesterday for the first time, and I'm sorry to say both were sorely disappointing.
Flutter was easier to install and get working, but Dart seems to be as verbose as Java with some JavaScript style syntax mixed in. The main dart file was as verbose as a boilerplate native SDK Activity.
RN was worse, though I expected it to be simpler. Something called metro server nearly froze the entire machine on every attempt. Had to power off and restart about 5 times. Then, based on GitHub discussions, built something else called watchman from sources. The official docs don't mention that watchman is critical. That improved it for a while but then the system wide near-freeze came back again. I wasn't even able to display a simple hello world app because of installation and deployment problems.
So far, Kivy seems to be the only alternative that is both simple to code and to deploy. Its file sizes are massive, but given that I already find Android SDK so frustrating to design and implement quickly, I don't want alternatives that are equally frustrating.
[+] [-] javajosh|6 years ago|reply
In the beginning of a devs experience framework code appears to eclipse app code in size and complexity, but over time the app will tend to grow to overwhelm the framework.
[+] [-] nnq|6 years ago|reply
[+] [-] gamma3|6 years ago|reply
Author expects bugs in open source projects to get fixed for free, by someone else.
We need to support open source maintainers instead of shaming them. I'm excited about Open Collective and made a monthly donation to a project I use.
[+] [-] wastedhours|6 years ago|reply
There are quite a few things missing, and I personally found it quite hard to get going (but that might just be a general lack of skill at getting tooling set up), but there's an awful lot to like if you want to dive into getting something set up on-device quickly.
[+] [-] gitgud|6 years ago|reply
A friend described it to me as "Unity for apps", which I think is pretty positive and accurate.
[+] [-] bernaferrari|6 years ago|reply
[+] [-] hardwaresofton|6 years ago|reply
It's different in a few key ways:
- Draws native components (Flutter draws every pixel)
- Pure JS native (i.e. JNI powered) shim layer (you can write stuff like `const intent = new Intent()`)
- Typescript as first-class (not quite so with React Native, and IMO Typescript > Dart as far as type systems and ergonomics are concerned)
- Ability to use both Angular and Vue to structure your app (there's also projects out there like Svelte-Native, which is extremely promising from the performance perspective)
- More community driven project (with Progress standing behind, following the open-source & extra features business model)
[+] [-] ex3ndr|6 years ago|reply
[+] [-] deanclatworthy|6 years ago|reply
[+] [-] rishav_sharan|6 years ago|reply
[+] [-] latchkey|6 years ago|reply
OP has some valid points for sure, but fact is that any framework is going to have issues. Just part of the game.
[+] [-] sgt|6 years ago|reply
[+] [-] karma_fountain|6 years ago|reply
However I would say where it excels at is in creating a fully custom-branded experience rather than sticking to the native elements. I reckon https://reflectly.app/ is the poster child for this.
[+] [-] codedokode|6 years ago|reply
[+] [-] winter_blue|6 years ago|reply
All it does is let you write iOS UI code in Java or Kotlin, and target both iOS and Android from a single project.
It uses the actual underlying iOS API, and simply provides Java wrappers for them, that map one-to-one.
I keep wondering, and don't know why it hasn't gained much traction. It is so much better than Flutter, is obviously reliable since it's a simple 1-1 mapping/translation layer. (There is more work involved with it, as you have to write the UI lawyer twice, but that's about it.)
[+] [-] TylerE|6 years ago|reply
[+] [-] jimmcslim|6 years ago|reply
[+] [-] navd|6 years ago|reply
My biggest issue is that there is still this "uncanny valley" feeling when using a flutter app. It feels much better than a react native or Cordova app, but something still feels off.
Right now it seems great for prototyping. For iOS however, I've been playing around a bit with SwiftUI which currently (even in its beta state) provides an astronomically better dev experience and user experience.
[+] [-] royal_ts|6 years ago|reply