Flutter for Web detailed pre-research

Thank habitat ice @ @ Zu Jianguo put together for pre-research FFW to do!

background

Google launched a Flutter for Web on the latest Google I / O, to further solve the code once, run many-fold problem. Flutter for Web is still in its early test version, the official is not recommended for use in production environments. So in the end how it actually happens then? We did a pre-research. We hope that this preliminary research results can help you decide whether to use or not FFW.

Flutter for Web principles

flutter architecture	flutter web architecture

Flutter Flutter for Web and are in the upper Dart environment, two are different, Dart Dart code running in the virtual machine Flutter, the interface engine processes the Flutter, via the GPU to draw on the screen through the graphics engine Skia. Flutter for Web and the Dart code into the JavaScript, part of the interface into a standard html tags, partially converted into a custom tag Canvas drawn ultimately constitute a tree dom.
Differences on this very important principle, which allows us to directly through the principle of the following conclusions:

There is a contradiction on Flutter for Web experience and consistency

If Flutter for Web pursue (and Flutter) perfect consistency, it is bound to need a lot of use Canvas to draw, and the Canvas to draw performance components (especially in the mobile terminal) at least no better than html tags. If FFW pursuit of performance and limit the use of a large number of standard html tags, which will bring the same consistency and Weex, RN et al: Flutter for all the controls are set in the code to draw graphics engine, if for Flutter for Web to use a lot of html tag, then how to ensure the consistency of it? It can only work by a large number of fine grinding. So FFW must properly handle the balance.

Why not use canvas rendering performance is better than it handwriting html, qualitative analysis from several perspectives:

1. FFW drawn on the canvas assembly with a lot of animation and visual characteristics of the MD, such as shadows, Z axis changes, the performance of this portion is greater than the consumption of ordinary html tags
2. FFW is converted to a DSL Dart dom through the tree structure, the tree conversion dom very complicated, less likely to be more compact than hand tree dom
3. Use canvas controls, captures the distribution of its gesture events are relying on their own to achieve the FFW framework, emmmm
   situation while not excluding Google vigorously miracle, but in any case, the same quality of the developer, the same interface, performance can not be superior html + css + js

Another point, if FFW involving the conversion of a large number of HTML tags in principle, it is bound to involve a process of fragmentation, the degree of fragmentation browser can be that is not less than the fragmentation of the Android system. Flutter itself as the reason why so many people are valued, because it is through this layer drawing engine, perfectly avoid fragmentation and ensure consistency.
So the best balance is that only a limited part of the standard html tags FFW can be reused, it must have several properties:

1. Label function itself is simple and intuitive
2. Best not to have a direct graphical display, or only responsible for simple graphical display (such as drawing a square)
   a few typical label is <p>, <div>this kind of

Flutter official is doing, so my conclusion is:
in general there is no problem on the consistency of performance, FFW should not be better than the pure html tags handwriting interface.

Official Status & recommendations

According to the official website and Github repo on the argument, we order a bit:

1. Flutter for Web and Flutter is currently being two warehouses, the official ongoing merger, did not give a conclusion. This is very important in engineering, it illustrates several issues:

   1. Currently there is no official confidence in the maturity of FFW, while FFW iteration speed is also fast.
   2. Currently FFW and Flutter guarantee up to API, implement the principle of difference can be very large, but does not guarantee that all controls have been implemented on the FFW.
2. The official is not recommended for use in a production environment
3. Currently plug capacity is very limited, and some of the lack of ability to interact with the system, such as photographs and so on.
4. Performance can not be guaranteed to run slower, there may be dropped frames
5. FFW against parts of the desktop UI is not completed (I have anything to do with wireless?)
6. Development can only be debugged in Chrome (what does it matter?), Release version that can run on any browser (except IE, another minimum supported version of the doubt).

practice

For such a new thing, the official online content is indeed small, and simple view of these issues seem to have nothing, it can not be used for in the end, we still need to eat crab mentality of holding preliminary research into the specific moment, in order to clarify as soon as possible I plan to find a app we've done a flutter page, it migrated into FFW, the entire migration process to be assessed look at the results page, basically will be able to draw conclusions.
Specific details of the migration is not mentioned, the official website also migrate documents , is generally so few steps

1. Installation Flutter for Web tool webdev
2. SDK dependent change, the new Web folder (and existed before the android, ios folder at the same level), add some other files (index.html, main.dart, etc.).
3. All code dependent flutter flutter package, into the package flutter_web
4. Remove all non-compliant code, such as multi-language, routing, Platform.isAndroidetc.
5. Compile and run

The main practical purposes, are the following:

1. There is a perception of depth and breadth of the whole pit, easy to calculate the cost to fill the pit
2. There is a grasp of the overall performance of FFW and experience, especially our own pages run on what FFW experience.
3. JS call each other for FFW and have specific knowledge and, if applicable, that the Group has the ability to reuse (such as mtop) pit will be much smaller

Delete a million lines of code to run successfully after finally get some conclusions on the engineering, development experience, user experience, the following conclusions, I feel part of the experience on my mix2s of:

engineering

1. Release mode and debug support, the latter is a high performance (variation is obvious).

   1. After debug mode supports code changes automatically recompiled, and other front-end frame (I only used Django) consistent
2. Support hotreload, temporarily did not try
3. Support webdev buildcommand compile index.html + js, you can do a reverse proxy by nginx.
4. Very important compiled code, before gzip compression, the simplest of helloworld main.dart.jssize is about 500k, gallery the size of the sample is about 2M, castrated version of the show with a list of orders pure size is about 1.3M. text gzip compression ratio is generally 80%, but also easily compressed size of a few hundred k. And main.dart.jsnot finished loading, the interface is not displayed.

Development experience

1. Very important flutter for web use flutter_web library, and does not support many other plug-ins, this will bring a few questions

   1. The situation on the project can not be elegant solution to flutter and flutter_web coexistence of up to put forward a conditional import dart2 (This feature may not be in the official documentation oh)
   2. Dependent on several libraries flutter sdk, especially in multi-language library can not be used in flutter_web, and Google certainly will not be alone as flutter_web fit, but do support the consolidation. This means that at this stage all dependent flutter sdk libraries can not be flutter_web use.

2. Difficult to debug

   1. Error Log You can print to the console browser, but try catch not right to take part in the stack
   2. Browser stack is very complex, but basically you can find dart error codes
   3. There is no ability to find single-step debugging
3. Platform.isAndroidAll error, do differentiate impressions on Android and iOS not yet know whether there are other ways to do it.
4. There is no inconsistency found api local control, but control the behavior of some very unusual, such as pull-down refresh, often stuck on Android phones fail. Heavy speculation interact with some controls are likely to have similar problems, but the cost is too high test again.
5. Picture controls NetworkImagecan be used directly, but now look at some paste, uncertainty is the issue of official controls, or we do cdn url policy problems.
6. dart code can call js, similar development experience and reflection, and the need to address and type JS Dart type of conversion. Dart and JS interaction rate is unknown. FFW can only say that even if there are many browsers do not support the API, you can extend the capabilities by JS.

7. Differences in language itself Dart and Js will bring increased costs of testing and compatible, although Dart can be compiled into Js, but run on DartVM of Dart's performance, and compile it into Js run in the browser's performance is not identical . For example, the following code

   Map<String, String> query = null;
   val b = query["abc"];

   DartVM The code can be executed, the result is b=null; however, after running Js Because compiled query is null, the null pointer will be reported.

user experience

Use of chrome, uc, millet browser comes with a list of orders were tried and official sample-gallery interface and experience as follows:

1. Loading speed almost, because it is a local area network environment, imperceptible differences.
2. Very important only played main.dart.jsand the part of the resource file (such as MaterialIcons) did not load came out, the interface does not show.
3. The frame-rate or fluency, chrome> uc >> Millet comes with a browser, which is probably the most chrome smooth experience, but sample some of the animations and page transitions can see the obvious Caton.
4. The text display, see flutter for web interface, chrome for most word processing is very clear, millet own browser to see the text of a noticeably blurry. The following two graphs comparing, after a large open view point, the text of the page FFW vague obvious.

Flutter for Web	Flutter

1. All browsers can not select the text to copy and paste. flutter for web process should be based on canvas to display text, so as to explain why some font size will be blurred, and can not select the text.

2. iOS safari and chrome visit the demo page, TextField whole is not available, including the following issues:

   1. Soft keyboard pops up strange logic, most of the time pop up automatically retracts when the normal pop-up a small part (Android this part of the performance of normal); but when the focus shifts do not automatically recover
   2. You can not enter text safari, chrome can be entered (Android this part of the performance of normal)
   3. You can select text, copy and paste does not take effect (the same Android issue)
   4. When the focus to TextField interface will automatically zoom in, zoom is difficult at this time to go back (Android this part of the performance of normal)

to sum up

According to the above, the overall sum up, Flutter for Web has several more serious problem, not solve it is estimated can not be applied to the production environment:

1. Packet size of the problem, this will bring a few questions:

   1. FFW package is much larger than normal h5 package, traffic and page loading speed is a big challenge
   2. FFW JS labeled as a package, multiple FFW page can not be multiplexed on public assembly, further wastage.
   3. FFW is not js package finished loading, the page can not display, the user experience is poor; and the H5 can be progressive load, can js after admission.

2. SDK separate issue, which will also have a few questions:

   1. Engineering, it is difficult elegant solution to the problem of the coexistence of two SDK
   2. The ability to rely on the official Flutter SDK libraries, such as multi-language library does not support FFW SDK. Only a multi-language self-study program.
3. Do not use Form scenes FFW, TextField when it comes to the question above I do not know whether the application layer to the solution.
4. Some heavy interacting components, such as pull-down refresh and so on, there is a problem, almost unusable. How the quality of the overall situation of uncertainty components, one by one to see costs too much.

in conclusion

1. Not very strong or technology-driven business demands, do not attempt to use Flutter for Web is currently in a production environment.
2. If you are determined to fill the hole, and willing to invest, and do not care about packet size, frame rate and so the user experience is not valued, it can be considered at this stage to try.
3. I judge to fill the pit costs at more than 100 man-days (ceiling unknown), and some pit (packet size) may simply not be filled.
4. When can I follow up again? I think in FFW incorporated into the Flutter SDK when, as to their specific planning needs to be asked of the people at Google.

Filled pit refers to the North

The main purpose of this section is to list the assumptions do FFW, we need to do the technical terms and the corresponding program.