Flutter is an open source SDK from Google that helps you create native apps for modern mobile platforms (currently, Android & iOS) from a single codebase with extensive tooling and widgets support for rapid prototyping.
Compared to other relevant solutions (e.g., React Native, PhoneGap, Cordova), Flutter focuses first on performance by compiling directly to native (ARM) code and by removing the overheads of context-switching to OEM widgets using a UI architecture that works with the GPU to render directly to canvas.
Flutter's layered architecture coupled with its open-source nature, makes it possible for developers to customize everything within the framework, while relying on battle-tested engines for optimized text (from Chrome), graphics (Skia, used in Android) and framework (Dart, used in production at Google) support.
Flutter is currently in alpha release. You can get a quick intro and links to more resources in the talk I gave at #WindyCityDevFest in Chicago in January 2018 or try the codelab for hands-on learning.
Update: You can also watch the video for that talk here or track the Flutter for Beginners playlist I'm curating on YouTube.
Top comments (14)
I liked its syntax when I first looked at it back in Feb 2014 (we ran a Dart Flight School event meetup.com/nyc-gdg/events/155911782) - the only reason I didn't pursue it further was that frankly there weren't enough projects that required the expertise.
However I am interested in revisiting it now because of Flutter - in particular I find I can learn/use something best if I have real world projects/deadlines to work with, and I didn't have one for Dart in 2014 but I can see a few possibilities in 2018 so hope to spelunk more there too.
That said, I don't think JavaScript will ever go away. It will just evolve to slowly shed the bad parts and embrace new requirements/capabilities that occur with such fast ecosystem changes.
As far as I know the main point of React-Native was near native perfomance, but at least being much better than the existing solutions.
I think React Native stands alone in the category in which it plays - which is that it allows you to
It still is my go-to for many projects and I think it always will be the most competitive amongst current options in that space.
What I have gotten interested in with Flutter is how they are approaching the issue with a different angle. You can build reactive apps, but they are doing things like looking at how you can apply those UI "diffs" (view changes between prev. and curr. page states) not in terms of patches to Physical DOM or Platform widgets, but to the graphics layer directly.
In some sense, their "application space widgets" are completely new components that paint directly to canvas and totally bypass/ignore OEM widgets or any web-view ideas or semantics.
Is that a good thing? I don't know.
Is that different? Yes, absolutely.
Is that going to gain mainstream adoption? Too early to tell.
Is it interesting enough to dive into? Oh yeah! :-)
PS. When I compared it to React Native, I wasn't saying that the main differentiation was performance, but that they were using performance as a reason to throw away all existing patterns for doing things and rethinking UI arch for mobiles from that singular viewpoint. I think for many existing devs, React Native would provide sufficient pattern familiarity + performance gains to still be popular -- but my approach is to always be pragmatic and explore new ideas/thinking
Any UI framework allows for the developer to build reactive views.
I can't edit my comments (only the main post) so I can try to clarify my intent here.
That statement was meant to say it allows you to do "ALL the three listed things" in one technology solution. So for instance there are other reactive UI frameworks which are not competitive here because they are not in JS, or they don't target deployment to native Android/iOS.
That said, I don't think "any" UI framework by implies "reactive by default". Let me explain my thinking here though.
To me, reactive is the about automatic state change propagation through the framework without the developer explicitly coding that propagation. Instead, developers focus on making local state changes in a component and handling change notifications from parents/children of that component -- with the framework effectively figuring out whether a local state change requires external propagation, and ensuring that those change notifications are triggered/pushed accordingly.
So for instance, when I think about my projects using jQuery UI and classic MVC/MVVM architectures (e.g., in modern Android), I would consider those to be frameworks with support for layout, rendering, data-binding etc. - but I wouldn't consider them reactive by default because any state changes that needed to propagate outside my current view, had to be done by me explicitly (imperative approach) and that added complexity.
But you have a valid point too. Any UI framework does "allow" developers to build reactive views. It's a question of whether the framework supports automated state change detection & propagation, or simply provides the developer with a mechanism (e.g., pub/sub) and requires them to manage the process imperatively.
I hope that helped clarify what I was trying to say though :-)
I think we might disagree on what qualifies as a framework, but other than that we're on the same page :)
I am absolutely happy to agree with you on that one :-)
I have long since realized that my usage of terminology [framework, platform, middleware, architecture] are not necessarily the best in context, so I always try to provide the context for clarification. So thank you! I am sure others had similar feedback but didn't venture to express it - and hopefully this helps them as well.
react native is even for windows, github.com/Microsoft/react-native-...
Great summary, I'm actually loving Flutter!
Now Google has released a course on Udacity, right here, maybe you could add it to your post!
Will do!! I am actually planning to do a series of posts soon on Flutter, leading up to a full day #FlutterCamp at GDG NYC later in June. So this is good incentive!
Short and precise. That's what I like about your articles. The overall concept of flutter development is easy to grasp here. I simply love the way you explained it here. Choosing flutter development can be one of the best decisions for an app developer in the modern world. It has taken the world by storm and there are already plenty of flutter templates out there ready to be your next application.
A lot happened at #io18 that focused on Flutter - and I hope to post a series of articles on all of that shortly. In the meantime, just wanted to share a 10-minute lightning talk on Flutter that I did recently at my local tech meetup that provides a rapid overview. And it has links to the key resources (Udacity course, IO18 Codelabs, I018 talks) that you will need to begin your self-guided learning journey.
Slides:
bit.ly/2018-05-flutter4dev
I haven't gotten the chance to try it out yet, but the most exciting Flutter feature to me was hot reloading. Is it as convenient as it looked in the demos?
Hot reloading (and it IS stateful) works just as advertised both from IDE (click the lightning bolt in toolbar) or command-line (if you run something with "flutter run" it will prompt you in the terminal to simply use "ctrl-r" for hot reloads) so from a convenience standpoint - yes!!
I am still trawling through docs and learning - but I do know there are cases where it will NOT work (see flutter.io/hot-reload/). I saw this happen when I added widgets to the current app (tree). In such cases, it does prompt you to do a full restart. But changing values (e.g., for styling) or functions (e.g., for processing) within classes should be fine.
One thing I liked is that it would give me an indication of how long it took to do the hot reloading. As I work with more apps/widgets, I hope to gain an intuition for what kinds of changes are ideally suited (or not) in terms of the time taken to effect a hot reload.
For instance, I hope to take the source code for the Flutter Gallery (examples/) app and deconstruct parts of it to get a better understanding of how to design complex apps within this architecture - how is the performance/reload-ability impacted by number of widgets in tree, number of source files used etc. So much to learn..
However, I think this is an awesome feature if you are working in teams (designer+developer) and want to quickly iterate and explore ideas in real time.
I am just starting to dig into more complex examples so stay tuned and do share your insights back here when you explore this further :-)