Mobile app development is a relatively recent field of endeavor. Third-party developers have been able to build mobile apps for less than a decade, so it is no surprise that tools are still evolving.
OEM SDKs
The Apple iOS was released in 2008 and the Google Android SDK in 2009. These two SDKs were based on different language: Objective-C and Java.
App talks to the platform to create widgets, or access services like the camera. The widgets are rendered to a screen canvas, and events are passed back to the widgets. This is a simple architecture, but you pretty much have to create separate apps for each platform because the widgets are different, not to mention the native languages.
WebViews
The first cross-platform frameworks were based on JavaScript and WebViews. Example include: PhoneGap, Apache Cordova, Ionic, and others. Before Apple releases their iOS SDK they encouraged third party developers to build webapps for the iPhone, so building cross-platform apps using web technologies was an obvious step.
App creates HTML and displays it in a WebView on the platform. Note that it is difficult for languages like JavaScript to talk directly to native code (like the services) so they go through a "bridge" that does context switches between the JavaScript realm and the native realm. Because platform services are typically not called all that often, this did not cause too many performance problems.
Reactive Views
Reactive web frameworks like ReactJS have become popular, mainly because they simplify the creation of the web views through the use of programming patterns borrowed from reactive programming. In 2015, React Native was created to bring the many benefits of reactive-style views to mobile apps.
React Native is very popular, but because the JavaScript realm access the OEM widgets in the native realm, it has to go through the bridge for those as well. Widgets are typically accessed quite frequently (up to 60 times a second during animations, transitions, or when the user "swipes" something on the screen with their finger) so this can cause performance problems.
Flutter
Like Reactive Native, Flutter also provides reactive-style views. Flutter takes a different approach to avoiding performance problem cause by the need for a JavaScript bridge by using a compiled programming language, namely Dart. Dart is compiled "ahead of time" (AOT) into native code for multiple platforms. This allows Flutter to communicate with the platform without going through a JavaScript bridge that does a context switch. Compiling to native code also improves app startup times.
The fact that Flutter is the only mobile SDK that provides reactive views without requiring a JavaScript bridge should be enough to make Flutter interesting and worth trying, but there is something far more revolutionary about Flutter, and this is how it implements widgets.
Widgets
Widget are the element that affect and control the view and interface to an app.
The look (look good) and feel (feel natural) of widgets is paramount.
Widgets perform fast: to create the widget tree, inflate the widgets (instantiating their children), lay them out on the screen, render them, or (especially) animate them.
Widgets are extensible and customizable.
Flutter doesn't use OEM widgets (or DOM WebViews), it provides its own widget.
Flutter raises the widgets and renderer from the platform into the app, which allows them to be customizable and extensible. A.ll that Flutter requires of the platform is a canvas in which to render the widgets so they can appear on the device screen, and access to events (touches, timers, etc.) and services (location, camera, etc.).
There is still an interface between the Dart program (green) and the native platform code (blue, either iOS and Android) that does data encoding and decoding, but this can be orders of magnitude faster than JavaScript vridge
Moving the widgets and the renderer into the app does affect the size of the app. The minimum size of a Flutter app on Android is approximately 6.7MB, which is similar to minimal apps built with comparable tools.
Layout
Layout determines the size and position of widgets based on a set of rules (also called constraints).
Traditionally, layout uses a large set of rules that can be applied to any widgets. The rules implement multiple layout methods. In CSS, CSS has properties (the rules), which are applied to HTML elements (the widgets). CSS3 defined 375 properties.
CSS includes a number of layout models, including box models, floating element, tables, and so on. But in traditional layout new layout models can't be added by the developer, so flexbox and grid had to added to CSS and implemented on all browser.
Another problem with traditional layout is that the rules can interact (even conflict) with each other, and element often have dozens of rules applied to them. This make layout slow.
In Flutter
Instead of having a large set of rules that could be applied to any widgets, each widget would specify its own simple model.
Because each widgets has much smaller set of layout rules to consider, layout can be optimized heavily.
To simplify layout even further, we turned almost everything into a widget.
In Flutter, centering and padding are widgets. Themes are widgets , which apply to their children. And even applications and navigation are widgets.
Flutter has a unique model which is used for scrolling. Layout in Flutter is do fast it can be used for scrolling.
Most of the time, Flutter can do layout in a single pass, which means in linear time, so it can handle large numbers of widgets. Flutter also does caching and other things so it can avoid doing layout at all, when possible.
Custom design
Because widgets are now part of the app, new widgets can be added and existing widgets can be customized to given them a different look and feel, or to match a company's brand.
More about Reactive Views
Libraries for reactive web views introduced virtual DOM. DOM is the HTML Document Object Model, an API used by JavaScript to manipulate an HTML document, represent as a tree of elements. Virtual DOM is an abstract version of the DOM created using object in the programming language, in this case JavsScript.
In reactive web views (implemented by system like ReactJS) the virtual DOM is immutable, and is rebuilt from scratch each time anything changes.The virtual DOM is compared to real DOM to generate a set of minimal changes, which are then executed to update the real DOM. Finally , the platform re-renders the real DOM and paints it into a canvas.
This may sound like an awful lot of work, but it is well worth it because manipulating
Reactive Natives does a similar thing, but for mobile apps. Instead of DOM, it manipulates the native widgets on the mobile platform. Instead of virtual DOM, it builds a virtual tree of widgets and compares it to the native widgets and only updates those that have changed.
Remember that React Native has to communicate with the native widgets through the bridge, so the virtual tree of widgets helps keep passes over the bridge to a minimum, while still allowing the use of native widgets. Finally, once the native widgets are updated, the platform then renders them to the canvas.
React Native is a big win for mobile development, and was an inspiration for Flutter, but Flutter takes this a step further.
In Flutter, the widgets and the renderer have been lifted up out of the platform into the user's app. There are no native OEM widgets to manipulate, so what was a virtual widget tree is now the widget tree.Flutter renders the widget tree and paints it to a platform canvas. This is nice and simple (and fast). In addition, animation happens in user space, so the app (and thus the developer) have more control over it.
The Flutter renderer itself is interesting: it uses several internal tree structures to render only those widgets that need to be updated on the screen. For example, the renderer uses "structural repainting using compositing". Unchanged widgets, even those that have moved "bit blitted" from cache, which is super fast.
Because widgets (and renderer for those widgets) are part of your app, not the platform, no "compat libraries" are needed. Apps will not only work, but they will work the same on recent OS versions. This significant reduces the need to test apps on older OS versions.Plus it is likely that your apps will work on future OS versions.
There is one potential concern. Because Flutter doesn't use the OEM native widgets, will it take long for the Flutter widgets to be updated when a new version of iOS or Android comes out that supports a new kind of widget, or changes the look or behavior of an existing widget.
Google is a big internal user of Flutter.
Flutter’s widgets are so extensible and customizable that anyone can update them.
A brief history of mobile app development
Mobile app development is a relatively recent field of endeavor. Third-party developers have been able to build mobile apps for less than a decade, so it is no surprise that tools are still evolving.
OEM SDKs
The Apple iOS was released in 2008 and the Google Android SDK in 2009. These two SDKs were based on different language: Objective-C and Java.
App talks to the platform to create widgets, or access services like the camera. The widgets are rendered to a screen canvas, and events are passed back to the widgets. This is a simple architecture, but you pretty much have to create separate apps for each platform because the widgets are different, not to mention the native languages.
WebViews
The first cross-platform frameworks were based on JavaScript and WebViews. Example include: PhoneGap, Apache Cordova, Ionic, and others. Before Apple releases their iOS SDK they encouraged third party developers to build webapps for the iPhone, so building cross-platform apps using web technologies was an obvious step.
App creates HTML and displays it in a WebView on the platform. Note that it is difficult for languages like JavaScript to talk directly to native code (like the services) so they go through a "bridge" that does context switches between the JavaScript realm and the native realm. Because platform services are typically not called all that often, this did not cause too many performance problems.
Reactive Views
Reactive web frameworks like ReactJS have become popular, mainly because they simplify the creation of the web views through the use of programming patterns borrowed from reactive programming. In 2015, React Native was created to bring the many benefits of reactive-style views to mobile apps.
React Native is very popular, but because the JavaScript realm access the OEM widgets in the native realm, it has to go through the bridge for those as well. Widgets are typically accessed quite frequently (up to 60 times a second during animations, transitions, or when the user "swipes" something on the screen with their finger) so this can cause performance problems.
Flutter
Like Reactive Native, Flutter also provides reactive-style views. Flutter takes a different approach to avoiding performance problem cause by the need for a JavaScript bridge by using a compiled programming language, namely Dart. Dart is compiled "ahead of time" (AOT) into native code for multiple platforms. This allows Flutter to communicate with the platform without going through a JavaScript bridge that does a context switch. Compiling to native code also improves app startup times.
The fact that Flutter is the only mobile SDK that provides reactive views without requiring a JavaScript bridge should be enough to make Flutter interesting and worth trying, but there is something far more revolutionary about Flutter, and this is how it implements widgets.
Widgets
Widget are the element that affect and control the view and interface to an app.
Flutter doesn't use OEM widgets (or DOM WebViews), it provides its own widget.
Flutter raises the widgets and renderer from the platform into the app, which allows them to be customizable and extensible. A.ll that Flutter requires of the platform is a canvas in which to render the widgets so they can appear on the device screen, and access to events (touches, timers, etc.) and services (location, camera, etc.).
There is still an interface between the Dart program (green) and the native platform code (blue, either iOS and Android) that does data encoding and decoding, but this can be orders of magnitude faster than JavaScript vridge
Moving the widgets and the renderer into the app does affect the size of the app. The minimum size of a Flutter app on Android is approximately 6.7MB, which is similar to minimal apps built with comparable tools.
Layout
Layout determines the size and position of widgets based on a set of rules (also called constraints).
Traditionally, layout uses a large set of rules that can be applied to any widgets. The rules implement multiple layout methods. In CSS, CSS has properties (the rules), which are applied to HTML elements (the widgets). CSS3 defined 375 properties.
CSS includes a number of layout models, including box models, floating element, tables, and so on. But in traditional layout new layout models can't be added by the developer, so flexbox and grid had to added to CSS and implemented on all browser.
Another problem with traditional layout is that the rules can interact (even conflict) with each other, and element often have dozens of rules applied to them. This make layout slow.
In Flutter
In Flutter, centering and padding are widgets. Themes are widgets , which apply to their children. And even applications and navigation are widgets.
Flutter has a unique model which is used for scrolling. Layout in Flutter is do fast it can be used for scrolling.
Most of the time, Flutter can do layout in a single pass, which means in linear time, so it can handle large numbers of widgets. Flutter also does caching and other things so it can avoid doing layout at all, when possible.
Custom design
Because widgets are now part of the app, new widgets can be added and existing widgets can be customized to given them a different look and feel, or to match a company's brand.
More about Reactive Views
Libraries for reactive web views introduced virtual DOM. DOM is the HTML Document Object Model, an API used by JavaScript to manipulate an HTML document, represent as a tree of elements. Virtual DOM is an abstract version of the DOM created using object in the programming language, in this case JavsScript.
In reactive web views (implemented by system like ReactJS) the virtual DOM is immutable, and is rebuilt from scratch each time anything changes.The virtual DOM is compared to real DOM to generate a set of minimal changes, which are then executed to update the real DOM. Finally , the platform re-renders the real DOM and paints it into a canvas.
This may sound like an awful lot of work, but it is well worth it because manipulating
Reactive Natives does a similar thing, but for mobile apps. Instead of DOM, it manipulates the native widgets on the mobile platform. Instead of virtual DOM, it builds a virtual tree of widgets and compares it to the native widgets and only updates those that have changed.
Remember that React Native has to communicate with the native widgets through the bridge, so the virtual tree of widgets helps keep passes over the bridge to a minimum, while still allowing the use of native widgets. Finally, once the native widgets are updated, the platform then renders them to the canvas.
React Native is a big win for mobile development, and was an inspiration for Flutter, but Flutter takes this a step further.
In Flutter, the widgets and the renderer have been lifted up out of the platform into the user's app. There are no native OEM widgets to manipulate, so what was a virtual widget tree is now the widget tree.Flutter renders the widget tree and paints it to a platform canvas. This is nice and simple (and fast). In addition, animation happens in user space, so the app (and thus the developer) have more control over it.
The Flutter renderer itself is interesting: it uses several internal tree structures to render only those widgets that need to be updated on the screen. For example, the renderer uses "structural repainting using compositing". Unchanged widgets, even those that have moved "bit blitted" from cache, which is super fast.
The Dart programming language
https://github.com/Ericlin99/notes/issues/2
Hot reload
Compatibility
Because widgets (and renderer for those widgets) are part of your app, not the platform, no "compat libraries" are needed. Apps will not only work, but they will work the same on recent OS versions. This significant reduces the need to test apps on older OS versions.Plus it is likely that your apps will work on future OS versions.
There is one potential concern. Because Flutter doesn't use the OEM native widgets, will it take long for the Flutter widgets to be updated when a new version of iOS or Android comes out that supports a new kind of widget, or changes the look or behavior of an existing widget.
Other benefits
What is new and exciting about Flutter
Reference