First of all, thank you @ Qibing @ zujianguo for their investment in FFW’s pre research!
Google launched the flutter for web on the latest Google I / O, aiming to further solve the problem of one-time code and multi-terminal operation. Flutter for web is still in the early pilot version and is not officially recommended for use in production environments. So what is the actual situation We did a preliminary study. I hope the results of this preliminary study can help you decide whether to use FFW or not.
Principle of fluent for Web
This difference in principle is very important, which can directly lead us to the following conclusions through the principle:
Conflict between consistency and experience of fluent for Web
If the flutter for web pursues (and flutter) perfect consistency, it is bound to need a lot of canvas to draw, and the performance of canvas to draw components (especially on the mobile side) is at least not better than HTML tags. If FFW pursues performance limit and uses a large number of standard HTML tags, it will bring the same consistency problem as weex, RN, etc.: for all the controls of flutter, a set of code is drawn on the drawing engine. For flutter for web, if a large number of HTML tags are to be used, how to ensure consistency? It’s just a lot of fine grinding. So FFW has to deal with this balance.
Why canvas is not better than handwritten HTML in rendering performance? Qualitative analysis from several perspectives:
- FFW draws components on canvas with many MD features of vision and animation, such as shadows, z-axis changes, etc., which consumes more performance than ordinary HTML tags
- FFW is a DOM tree structure transformed from DART’s DSL. The transformed DOM tree is very complex and unlikely to be simpler than the handwritten DOM tree
- Using the control of canvas, the capture and distribution of gesture events are all realized by FFW framework itself, emmmm
Although we don’t rule out Google’s great efforts in miracles, no matter what, developers of the same quality, the same interface and performance can’t be better than HTML + CSS + JS
On the other hand, if FFW involves the transformation of a large number of HTML tags in principle, it is bound to involve the processing of fragmentation. The degree of fragmentation of the browser is no less than that of Android system. The reason why flutter itself is valued by so many people is that it perfectly avoids fragmentation and ensures consistency through the drawing engine layer.
So the best balance is that only a limited number of standard HTML tags can be reused by FFW, which must have several properties:
- The function of label itself is simple and intuitive
- It is better not to have direct graphic display, or only be responsible for simple graphic display (compared with picturesque Square)
The typical labels are
<div>This kind of
This is what flutter does officially, so my conclusion is:
In terms of consistency, there will be no problem. In terms of performance, FFW should not be better than pure handwritten HTML tag interface.
Official status & Suggestions
According to the official website and GitHub repo, we organized the following:
At present, flutter for web and flutter are two warehouses for the time being. The official is in the process of merging, and no conclusion is given. This is very important in engineering. It shows several problems:
- At present, the government has no confidence in the maturity of FFW, and the iteration speed of FFW is very fast.
- At present, FFW and flutter guarantee the same API at most, and the difference in implementation principle may be very large. At the same time, it does not guarantee that all controls have been implemented on FFW.
- Officially not recommended for use in production environments
- At present, the plug-in ability is very limited, and some ability to interact with the system is missing, such as taking photos.
- The performance cannot be guaranteed, the operation will be slow, and there may be frame dropping
- The UI part of FFW for the desktop is not completed (what does it have to do with my wireless?)
- In development, you can only debug in Chrome. The release version can be run in any browser (in addition to ie, the minimum supported version is in doubt).
For such a new thing, the content on the official website is not much, and it seems that these problems are not very important in a simple way. So we need to go in with a crab eating mentality to study it in advance. In order to make it clear as soon as possible, I plan to find a flitter page that our app has already done, migrate it to FFW, and make an assessment of the whole migration process, Look at the page effect again, and you can basically come to a conclusion.
The specific migration details will not be mentioned. There are migration documents on the official website, which are basically these steps
- Webdev, a tool for installing flutter for Web
- Change the SDK dependency, add a new web folder (the same level as the existing Android and IOS folders), and add some other files (index.html, main.dart, etc.).
- Change the flitter package that depends on in all the flitter code to the flitter web package
- Remove all incompatible code, such as multilingualism, routing
- Compile and run
The main purposes of practice are as follows:
- Have a knowledge of the depth and breadth of the whole pit, so as to calculate the pit filling cost conveniently
- Have a grasp of the overall performance and experience of FFW, especially what experience our own page runs on FFW.
- Have a specific understanding of FFW and JS mutual calling. If it is feasible, the pit of multiplexing group’s existing capabilities (such as MTop) will be much smaller
After deleting 10000 lines of code and running successfully, I finally got some conclusions on engineering, development experience and user experience. In the following conclusions, the experience part is my experience on my mix2s:
Support debug and release mode, the latter is better than the former (the difference is obvious).
- Debug mode supports automatic recompilation after code modification, which is consistent with other front-end frameworks (I only used Django)
- Support for hotreload, no attempt at this time
webdev buildCommand to compile index. HTML + JS, you can use nginx as the reverse proxy.
very importantCompiled code, before gzip compression, the simplest HelloWorld’s
main.dart.jsThe size is about 500K, the gallery in sample is about 2m, and the order list for display only of castration version is about 1.3m. The compression ratio of gzip to the text is generally 80%, and the compressed text should be several hundred kilos. And
main.dart.jsWithout loading, the interface will not be displayed.
very importantFluent for Web uses the fluent Web Library and does not support many other plug-ins, which brings several problems
- In engineering, it is not possible to solve the problem of coexistence of fluent and fluent web gracefully. At most, we can make a conditional import of dart2 (this feature is not in the official document)
- Several libraries that rely on the fluent SDK, especially the Multilingual Library, cannot be applied to the fluent web. Google will certainly not adapt the fluent web alone, but support it when merging. This means that at this stage, all libraries that rely on the fluent SDK cannot be used by the fluent web.
- The error log can be printed to the browser’s console, but the stack in the try catch section is not easy to get
- The stack in the browser is complex, but you can basically find the wrong dart code
- At present, no single step debugging capability is found
Platform.isAndroidAll errors are reported. It’s not known whether there are other ways to do differential display for Android and IOS.
- At present, there is no inconsistency in the API of controls, but some controls behave abnormally, such as pull-down refresh, which is often stuck or invalid on Android phones. Guessing that some controls of re interaction may have similar problems, but the cost of testing once is too high.
- Picture control
NetworkImageIt can be used directly, but now it’s a bit confusing. It’s not sure whether it’s the official control or the CDN URL strategy we made.
- Dart code can call JS, the development experience is similar to reflection, and needs to handle the conversion of JS type and dart type. The interaction speed between dart and JS is unknown. It can only be said that even if FFW has many browser APIs that do not support it, it can also extend its capabilities through JS.
The difference between dart and JS will increase the cost of testing and compatibility. Although dart can be compiled into JS, the performance of dart running on dartvm is not exactly the same as that of its compiling into JS running in browser. For example, for the following code
Map<String, String> query = null; val b = query["abc"];
In dartvm, the code can be executed, and the result is
b=null; however, when it is compiled into JS, it will report a null pointer because query is null.
Using chrome, UC and Xiaomi’s browser, we tried the order list and the official sample Gallery interface, and the experience was as follows:
- The loading speed is almost the same, because it’s the LAN environment, so there’s no difference.
very importantThe only one
main.dart.jsAnd some resource files (such as
MaterialIcons）When it is not loaded, the interface will not be displayed.
- In terms of frame rate or fluency, chrome > UC > > Xiaomi has its own browser, of which Chrome is the most fluent experience. However, some animations and page transitions in sample can also see obvious stuns.
- On the text display, look at the interface of fluent for web. Chrome handles most of the text very clearly. Xiaomi’s own browser looks at the text clearly fuzzy. Compare the following two pictures, click open and zoom in, the text of FFW page is very fuzzy.
- All browsers cannot select Copy and paste text. Fluent for web should use canvas to process display text, so as to explain why some font sizes are fuzzy and text cannot be selected.
When Safari and chrome of IOS access the demo page, textfield is not available as a whole, including the following problems:
- The pop-up logic of the soft keyboard is weird. Most of the time, the pop-up automatically retracts, and a small part of the pop-up is normal (Android is normal); however, the pop-up will not automatically retract when the focus is shifted
- Safari can’t input text, chrome can input (Android works normally)
- You can select the text, copy and paste will not work (the same Android problem)
- When the focus is on textfield, the interface will automatically zoom in, which is hard to zoom back (Android works normally)
According to the above, to summarize the whole, there are several serious problems in fluent for web, which can’t be applied to the production environment if they are not solved:
Package size, which can cause several problems:
- FFW package is much larger than normal H5 package, which is a great challenge to traffic and page loading speed
- FFW is printed into a JS package, and multiple FFW pages cannot reuse the common components, which further causes waste.
- The JS package of FFW is not loaded completely, the page cannot be displayed, and the user experience is extremely poor; H5 can be loaded gradually, and JS can enter later.
The problem of SDK separation also brings several problems:
- In engineering, it is difficult to solve the problem of coexistence of two SDKs gracefully
- In terms of capabilities, official libraries that rely on the flutter SDK, such as multi language libraries, do not support the FFW SDK. Only one multilingual solution can be developed.
- Don’t use FFW for form scenarios. I don’t know if the above mentioned textfield problems can be solved in the application layer.
- Some interactive components, such as pull-down refresh, have problems and are almost unusable. I’m not sure about the quality of the overall components. It’s too expensive to look at them one by one.
- Do not try to use the fluent for web in the production environment at present without strong business demands or technical promotion.
- If you are determined to fill in the pit, and you are willing to invest, and you don’t care about the package size, and you don’t care about user experience such as frame rate, you can consider trying at this stage.
- My personal judgment is that the pit filling cost is more than 100 person days (the upper limit is unknown), and some pits (bag size) may not be filled at all.
- When can I follow up again? I think when FFW is merged into the flutter SDK, they need to ask Google about their specific planning.
Fill the pit North
The main purpose of this section is to list the technical items and corresponding schemes that we need to do if we want to do FFW.
Read the original text
This is the original content of yunqi community, which can not be reproduced without permission.