Flutter doesn't do what I feel React Native does best, rendering down to native components for Android and iOS (also web/tvOS). Flutter seems to render to custom view components so for better or worse your apps will probably look the same on all platforms. It's interesting to see what projects Google is using Flutter though, see https://en.wikipedia.org/wiki/Google_Fuchsia
> Flutter doesn't do what I feel React Native does best, rendering down to native components for Android and iOS
Well of course it doesn't do that, they explicitly avoided it. And it's as you said, to make apps look and behave the same on all platforms. But that doesn't stop you from using their "Material" components on android and "Cupertino" components on iOS.
yes! And for those who have struggled with getting RecyclerView to work as expected, or with changing a text typeface in an action bar on some older android version, or felt that the Fragment plus ViewPager routine was a little more complicated than they'd hoped, in short for those who are looking for some different way to organize the UI and display logic, Flutter is an interesting alternative.
Rendering to native components is a dead end. It creates huge surface area for bugs to appear, and it's slow.
I had a "pleasure" of working with Xamarin Forms and interactions between native UI, behaviour difference between Android manufactures and versions, etc. were a constant source of pain.
With Flutter, if something works on one device it will almost certainly work on all devices. You can also customize per platform.
It is also possible to run it on desktop (although not officially supported). IMO that's a big deal and a potential Electron killer.
It is easier than HTML/CSS/JavaScript dependency hell and Frankenstein frameworks.
QML is as pretty as the design skills of the developer, just like CSS. And better because the full power of the graphics stack is available to the developer, down to pixel perfect graphics, unlike CSS where Houdini still isn't a thing.
Any native application is faster than a Electron based app. It is quite trivial to achieve.
In theory React Native delegates things to the native platform widgets but in fact a ton of RN components don't really do this. They use the platform's native UIView/View class but not the higher level controls in a lot of cases. Navigation in particular is kind of a mess in RN and diverges from the built-in mechanisms on Android and iOS significantly.
Besides, even native apps (made with iOS or Android SDK) try to look as different as possible with custom made styles. So there is really no "native look" on mobile platforms.
Yeah that's true. For better or worse, designers try to make their mark by coming up with very distinctive designs that all too often throw affordance and usability out the window. Mobile UX is in a pretty bad place overall right now. Watching my parents struggle to do basic things on an iPad has been a good reality check for me in this regard.
One of the legacies of the successes of Flash and the web is that brands are pushing for an aesthetic that feels like their own.
On the desktop, most Mac apps looked like most other Mac apps. On the web, authors often created their own components, and could completely customize their look. Mobile has largely tacked towards the web, where Airbnb looks more like Airbnb than it does like any other Android or iOS app.
Spotify uses its own skin, as does Windows iTunes. NetBeans uses Swing with the Nimbus look-and-feel. Firefox and Chrome use their own toolkits (e.g. on their Settings windows). Even Microsoft Word feels like 'its own thing'. UWP applications don't tend to feel native. At least RoboMongo and the CMake GUI feel like proper Windows applications, but they both use Qt.
Flutter controls all the actual pixels, recreating the iOS and Material styles in Flutter code. React Native describes its view contents in JavaScript, but uses native Java/Cocoa APIs to draw the actual pixels.
Flash/AIR and desktop Java are other well-known technologies that controlled how the actual pixels were drawn. If you wanted a native-looking UI, you had to mimic one in framework code.
React lead Tom Occhino pointed this out at the React Native launch. With the React Native approach, your app matches the iOS N+1 style when the user upgrades. With the Flutter/Flash approach, your app matches N+1 when you upgrade your version of Flutter and push a new release.
I'm starting to love Flutter, but I'm afraid to invest in it -- Google has a history of abandoning projects they get bored with. I took a long time to come on board with Golang for the same reason...
I'll jump to flutter once they have a convincing media player / recorder native component as well as a google map equivalent. If this has good performance on both iOS and android, with features comparable to native ones, then i don't see what can stop them.
Unless Apple starts implementing its own cross-platform sdk in swift... But judging by the slow pace at which swift is moving (compared to its "worl domination" ambitions, that is), i don't think it'll happen anytime soon.
That's the #1 reason that I don't currently consider it in the same class as React Native. Once Google showcases how they're using it in business critical apps, then I think I'll have the confidence it won't be another project that gets the axe.
You can still play with the color scheme and typography to make it seem like native on iOS. (gray in iOS and blue in Android). Personally, I think that this is more convenient considering the UI will be more consistent and the development cycle will be more hassle-free.
Curious of the community's opinion on this article that was sent to me today on "Worst Programming Languages to Learn in 2018", with Dart being the #1. In light of Flutter gaining some ground, would anyone think it would push back at this conclusion?
My speculation is that those who marked it "the worst language to learn" never actually tried it, and based their opinions on something they heard 3-5 years ago. But now the dart is different and its goals are different. In any case, I believe this kind of negative opinion is grossly unfair.
They based it off 3 metrics: Community, Growth, and Job Market. I'm not surprised Dart is on the list. As good as the language may be, it remains a fairly niche.
I became quite interested in Flutter recently but it was pretty much impossible to find a range of good demo applications (or any demo applications) that show off what it is capable of so I gave up. LOTS of technical documentation however but nothing to sell me on using it.
Is having the UI layout and styling mixed in with the code considered a feature of Flutter, or is providing a way to specify them separately in a machine-readable or declaritive format just not done yet?
I'm a fuddy-duddy still doing UI in GTK and Qt, I haven't kept up in trends in web and mobile design, but I know that when our developers do the layout and design it comes out awful and unusable, but luckily with GTK and Qt we can just hand it off to our designer after the basic functionality is in place and he can do some layout tweaking with Glade or Qt Designer, and is comfortable with working with CSS to provide us with custom widget styling and images, and then he sends it back to us and we clean up the results and merge it.
All of the Flutter examples seem to have the UI written entirely in code, both layout and styling, and I don't think he'd be comfortable with that. You may note that we send it to him, he tweaks it, and sends it back to us to merge; we've never been able to teach him Git, but that's OK, because we don't expect him to teach us Photoshop and design.
So, I'm just wondering if Flutter is intended to always be like this, with the whole UI specified in executable code that needs to be compiled and run for each iteration, or if it is intended to add a way to separate out the design parts (layout and styling) in a way that they can be worked on at least somewhat independently of the code?
I know that there is IDE support for hot reload, which may be OK for a designer to work with, but I'm always a little skeptical of that since most developers I know use VIM or Emacs and not IDEs, so sometimes IDE tooling setup can break, and once a project gets complicated, the toolchain setup for running from within an IDE can get hard to install. The nice thing about Glade or Qt Designer is that they can work with purely declarative formats so that you don't need to worry about having to have your designer get the full toolchain installed.
Flutter is about simplicity so I doubt they are planning any designer tools.
And IMO, designers should stick to their favorite tool, and leave implementation details to programmers. Hot reload makes it easy (and IDE is not required for that).
> And IMO, designers should stick to their favorite tool, and leave implementation details to programmers.
I'm curious about how this would work if the designers have to use developer tools to do the final spit-and-polish.
I don't know about how other places do it, but what I'm familiar with is that a UI mockup is sketched out and requirements given to the developer, the developer implements something but in the process finds issues with the design as specified and iterates a bit while doing so, and eventually you have something that is functional but somewhat ugly because the original sketch was not specific enough or didn't anticipate some issues that came up or the like, and then finally you give it back to the designer to do the spit-and-polish.
In some cases, the spit-and-polish can be a lot of work, because you've used some new widgets that you don't already have standard styles and graphics for, or maybe it's your first app with a new toolkit and so you need to figure out how to get your branding and style to work with it.
For designers I've worked with, CSS is their favorite tool for styling, and they prefer UI tools for spit-and-polish layout tweaks. Are you saying that they should just deal with having to learn how to do all of that embedded in code, or that they should just hand off their assets and suggestions to the developers and the developers have to do the final spit-and-polish work?
If you say you have a beautiful, powerful, fast, full featured application development system then you need to be able to SHOW me, and its gotta knock me out in every possible way.
Honestly, the best way to see the advantages of the toolset is to complete the "Get started" section of flutter.io.
I develop iOS, Android, Web and Mac apps, and I was honestly blown away by the quality of the intelliJ and VSCode plugins available for Flutter. In fact, they've kinda ruined me for other language SDKs now.
Granted, the lack of material, demos and discussions makes it difficult to tackle some problems, but that seems to be changing these days. It's hard NOT to enjoy coding in Flutter, though, and I think that end up being its biggest strength.
The beta announce blogpost for flutter links to 3 apps published that used it[0]. Also, it seems according to that blog post and the Ars[1] post on it, Adwords may be using Flutter? But that doesn't seem clear to me.
I'm currently working on an open-source "wish list" application that will be Serverless with a Flutter based mobile application. I'm vLogging about it at my channel (youtube.com/opsfactory) and will be providing a premium training course going into much, MUCH more details than the YT videos. The course is due in a few months.
Firebase gets expensive very quickly. And the interface it provides is unfriendly to certain types of operations. In my own experience, I've never kept an app on Firebase longer than it took to prototype the app.
From what I can tell, Firebase Database and Functions are great. However, I used Expo and Firebase Storage for a React Native app I made for my wedding and they left a bad taste in my mouth. No file blob support in Expo (I know it's coming) meant that I had to base64 encode the file and send it up to a Firebase Function, which then stored it in Firebase Storage.
I thought it was over then, but it turns out you can't list the contents of a Firebase Storage bucket without the exact key to the file. The recommendation was to store that in Firebase Database when you persist the file. So I spent another 2 hours the day after my wedding scraping my images from Firebase Storage.
I ended up wasting days on what should have been simple photo upload functionality.
Granted, I could have avoided Expo or ejected the project, but at the time I wanted to stay on the Expo platform. I'm just surprised that Firebase Storage lacks basic functionality like listing the contents of a folder. It would also have been nice if it accepted base64 encoded files, to avoid having to use a Firebase Function to do the conversion.
TL;DR - tried Firebase for a mobile app recently, it was equal parts "wow, this is cool" and "wow, this is stupid"
Nice and very concise tutorial but it generously missed the entire AWS Lambda section (and how much pain it is to work with, IAM setup, API gateway setup, SDK support etc etc). Perhaps the author wanted the focus to be on Flutter and less on backend (AWS Lambda in this scenario).
It's comparatively compact for the kind of functionality the runtime provides. You also get instantaneous startup thanks to AOT. Performance is great, too.
My phone's calculator app is about 14 MB and the gallery is 10 MB in size. Flutter versions would have been probably a tad smaller than these native Android apps.
Well, just check the file sizes of the apps which you have installed on your phone.
Though I personally have an unmetered 100Mbps connection, my target market(s) for what I develop, are people who are very data sensitive.
A 7MB Hello World file might mean that my app with the world, universe and everything I need, might be bigger. It'd be great if y = m(x) + 7MB with a gentle gradient, but I'm already starting off bad.
I tried creating a hello world with most of the dependencies that I think I would need, but most couldn't load, so I don't know what size a specimen app could be.
Either way, a 15MB download for someone in my radar would mean them not installing the app. One also shouldn't underestimate how many phones in developing countries barely have enough space left. Google Play seems to need minimum 500MB for me to install/update apps on my high-end phone, so it might be dire for lower-end devices.
Yea, it's not a problem. Even more so if you can install apps onto SD cards. There is lots of room on my 32 GB card. I could literally install thousands of simple Flutter apps.
Indeed. It's inspired by react (diffing algorithm to determine what to render) but I saw nothing to indicate it can use react components inside flutter.
Based on my own experience, it doesn't feel like java at all. It is very easy to learn for those who know java, or javascript, or C# etc - that's true. But the "look and feel" is different. And it's not only the language - libraries (e.g. collections) are very well designed. Just try it out- you will like it. As for flutter - there are novel, original ideas in there. It's not a copy of something else.
Maybe "feels like" is too subjective but it absolutely feels like Java to me:
* Object-oriented with inheritance (sharing the same keywords such as 'class' and 'extends'
* Non-optional semicolons
* Constructors, method overriding, calling `super.whatever` in your overriden methods
* Presence of null
* A base Object class for all objects in Dart, with hashCode() toString() methods
These are mostly superficial observations, and it's not a criticism of the language, but it certainly feels like Java to me, more than Scala or Go does.
True, there are many similarities. But it seems to me that the author of this article makes Dart appear even more like Java by ignoring Dart features and idioms.
For instance, what's the point of those Java style getter methods in the Movie class? These are public instance variables after all, and Dart has special property syntax to transparently wrap instance variables if and when the need arises.
I know next to nothing about Dart. So maybe there is a reason for this weirdness. But I rather suspect that the author has written a lot of Java and almost no Dart in his life.
totally agree, at first i thought the same thing.. what is this java ?? then i wrote a bunch of dart.. it is a fantastic language and ecosystem.. and the tooling is excellent. VS code dart plugin is awesome
