Subtitle: Leveraging the power of web platforms for app-centric experiences.
Original address: medium.com/flutter/goi…
Http://medium.com/mariam.has…
Published: 29 July 2020-8 minutes to read
Today we want to give you an update on our progress in bringing Flutter to the web, in particular the deep and native integration we are doing with the web platform.
Our vision for Flutter is to provide a portable toolkit to build beautiful experiences wherever you might want to draw pixels on the screen. As we mentioned earlier, we were intentionally application-centric, choosing our frameworks and apis to build a layered architecture that can scale across mobile, desktop, and embedded devices without compromising performance or quality.
The network is at the heart of what we do. Flutter was born out of an exploration by the Chrome team. It draws inspiration from the productivity and iterative development patterns of the web, and many of our engineers have years of experience building browser engines and web standards. We targeted the Web browser because it is the beating heart of the Internet: the most pervasive, flexible, and widely applied model in the history of computing.
For years, the Web platform and the HTML DOM were essentially the same thing. But more recently, the Web platform has been extended with richer and richer apis and features, exposing the underlying operating system and hardware. From hardware-accelerated graphics to shell integration and PWA, from Server workers to new layout and painting apis, the Web is an increasingly powerful target for complex applications and even frameworks layered on top of it.
The Web support for Flutter is not simply a DOM port: it takes full advantage of this emerging set of apis to provide an experience that is faithful to the Web without losing the expression of Flutter.
In this article, we delve deeper into this story and share how Flutter utilizes the web to enable a rich interactive experience without having to rewrite existing Flutter code. We also discussed areas like accessibility and back-end compilation choices that might not be obvious to the average experimenter.
Detail Canvas drawing
What does it mean to draw the Flutter widget as pixels on a web page?
Let’s start with a review of Flutter’s web architecture. A Flutter is a multi-layered system:
- aThe frameworkIt provides abstractions for common idioms such as widgets, animations, and gestures.
- aengineRender to the target device using its exposed system API.
The framework code is written in Dart. We combine this with your own code and apply pruning algorithms at compile time, so that only the code used by your application is downloaded to the browser. Flutter uses a reactive model, rendering the user interface based on state changes. Within each frame, Flutter builds the widgets, performs the layout, and finally paints the user interface using the underlying browser API.
The Web architecture of Flutter is a multi-tier system with a Framework on top of the browser engine
By default, Web mode uses standard HTML DOM and Canvas technology. In this mode, the engine translates each generated Flutter scene into HTML, CSS, or Canvas, and renders the frame onto the page as a tree of HTML elements.
We call this method the DomCanvas back end. It provides us with the strongest cross-browser compatibility, compact code size, and is ideal for applications that require quick startup and short sessions.
While we continue to make good progress on the performance and fidelity of DomCanvas, we are also simultaneously developing a CanvasKit-based back end that can render Skia’s paint commands in the browser using WebAssembly and WebGL. We started by trying to use CanvasKit because Skia is the same graphics engine used by Flutter movement and desktop, and unlike the HTML DOM, it allows direct access to the low-level graphics stack, thus achieving full equivalence to native Flutter.
DomCanvas offers wider browser support, smaller code size, and faster initial page loading, while CanvasKit allows Flutter developers to embrace new technologies to build graphically intensive Web applications. In the future, the advantages of one approach may become overwhelming, but right now Flutter gives you the option to choose the back-end that best fits the use case you need.
Achieve the native experience in the browser
For a Web application to feel at home in a browser, it must support a variety of browser habits, including natural text interaction and scrolling behavior, backward/forward navigation, and accessibility, all of which must perform well across a variety of device and form factors.
Text rendering
One of the biggest challenges we faced in building web support for Flutter was developing a layout system specifically for text layout. To layout a paragraph, Flutter creates a paragraph object and calls its layout() method. Since the Web currently lacks a direct text layout API, we use DOM to make various measurements of paragraphs by triggering Layout () and observe the side effects of layout attributes on other elements in the framework.
As you can imagine, these measurements can get pretty expensive, so we’ve recently started experimenting with measuring text using the Canvas API to improve both of these back-end methods. We found that it improved text layout performance by a factor of six, and it also solved several problems with multi-line text fields and text overflow. You can enable these canvas text improvements through the publish mode flag.
While rendering text quickly and correctly is important to the end user experience, being able to interact with text on a browser is equally important. Today, you can make text selectable on the Flutter Web application by using the SelectableText or EditableText widget. Soon, you’ll also be able to copy/paste selected text, as well as have better text editing interactions, including text field focus processing, form editing, and more.
rolling
There are two ways to make the Flutter web app feel more natural: scroll performance and scroll endurance.
Whether it’s a mobile application or a Web application, scrolling can determine whether an application is considered “Janky.” For our rendering system, scrolling defines a specific usage pattern for how and when we load content. Over the past quarter, we have focused specifically on improving the performance of scrolling, by optimizing static content scrolling and adding performance benchmarks to ensure we don’t slip back in the future.
Since the Framework of Flutter was originally designed for native mobile applications, the Flutter Web app already has good support for the gesture and scrolling physics of mobile browsers. The scrolling behavior of the desktop browser depends on the work we do for the Flutter desktop at the frame level. So far, we’ve been able to handle drag scrolling with the mouse and other mouse/wheel events, but we still need to add keyboard scrolling support.
navigation
Unlike native apps, Web apps have a built-in back button in the browser. Today, the browser’s back button behaves just like navigator.pop () in any Flutter application. This means that when a user opens a link to the Flutter Web application in a browser, the framework divides the initial route into several parts and pushes each part.
To take the navigation support for Flutter today as an example, you can try it from google.com to gallery. Flutter. Dev /#/demo/bann… Then click the browser back button.
You’ll notice that it doesn’t take you back to Google.com as you might expect, but to the site’s home page: gallery.flutter. Dev. Flutter splits the original gallery application path and pushes both the gallery.flutter. Dev and /demo/banner pages, so when the browser’s back button triggers navigator.pop (), it goes back to gallery.flutter. Because that’s how the in-app history is set up.
Efforts are being made to improve navigation/routing in Flutter by providing Navigator 2.0 and the new Router widget for all platforms. This will not only make navigation more declarative and flexible, but also improve how the route history of Flutter network applications works.
Frictionless access
Designed to be unobstructed, Flutter constructs a SemanticsNode tree separated from the RenderObject tree. Flutter’s accessibility system is currently optional, which means that end users must choose whether to enable assistive technologies. When enabled, the SemanticsNode tree is generated by scanning the render tree and merging semantic nodes that represent individual logical interaction elements on the screen.
To do this on the network, we generated a second DOM tree parallel to the DOM tree used as the RenderObject tree and translated flags, actions, labels, and other semantic properties into ARIA.
Every Flutter Web application can be accessed. For example, once you first enable screen reader assistive technology like VoiceOver, the Flutter Gallery app can be accessed for Web apps on iOS and macOS. When you explicitly enable application accessibility as instructed by the screen reader, you will see a semantic tree generated.
Every Flutter web application exposes a semantic tree to accessible tools such as VoiceOver.
The Web semantic capabilities of Flutter are already at the same level as the Flutter semantic system is currently, but we need to increase automated testing to ensure that we don’t have regression. There are some complex features that we need to support, such as the relationship between tables and elements.
Rive: A demonstration of Flutter on the Web.
A wealth of interactive applications demonstrate the web support capabilities of Flutter. A prime example is Rive, which today launched a rewrite of design collaboration tools built entirely with Flutter.
Rive is an animation design application that allows designers and developers to create high-quality assets that can be easily integrated into any platform. To combine the user interface with trouble-free animation in real time, Rive requires a lot of graphical rendering and performance experience on modern browsers as well as other platforms.
Rive 2 Beta is completely rewritten with Flutter and, as a result, provides web and desktop versions from the same code base. Their web experience uses a CanvasKit backend to provide a skIA-consistent experience on both platforms. Stay tuned for Rive’s upcoming tech blog post describing how they used Flutter to rebuild their tool. Now, you can sign up for one of their limited slots to try out their beta web app.
www.youtube.com/watch?v=rJZ…
A video shows off new features and enhancements to the Rive 2.
conclusion
We hope this gives you more insight into how we are leveraging the power of the web platform to build Flutter support for the web. Just a few years ago, it was not possible to offer Flutter over the network at an acceptable level of quality and performance, but the introduction of new networking technologies and continued advances in the platform allow us to leverage more of the potential of the underlying device. As the web continues to evolve, we will evolve with it and improve our support for text interaction, scrolling, navigation and accessibility as we continue to work towards stable versions.
Check out our documentation on how to start building a Flutter Web application. If you’ve built something, we’d love to see it! Share what you’re working on, either as a CodePen or with a URL. You can find us on Twitter at @Flutterdev — we can’t wait to see what you’ve created!
Translation via www.DeepL.com/Translator (free version)