Intent to deprecate and remove the HTML renderer in Flutter Web

[yjbanov]

Document Link

https://flutter.dev/go/deprecate-html-renderer

What problem are you solving?

The HTML renderer is complex, underperforming, and limited in graphical expressivity compared to WebGL-based CanvasKit and Skwasm renderers. Flutter Web’s WebGL-based renderers matured to a point where the value provided by the HTML renderer no longer outweighs the maintenance costs, the developer-facing complexity (having to choose between multiple renderers and work around their limitations), and loss of focus on the WebGL renderers.

See the document for an expanded problem statement.

[Juliotati]

The link in "TBD" is 404. Could it be that it will be available later?

[Novined]

Canvas renderer is awful. It's slow, even on high-end devices there are freezes, impossible to copy text even in text fields. Web renderer gives an opportunity to generate, not excellent, but ok-working solution

[yjbanov]

@Juliotati The go/ link is live now.

@Novined Text fields work identically between HTML and CanvasKit. I'm surprised there's a difference. We'd appreciate if you could file an issue explaining what's not working. Same about slowness. All indicators we have show that CanvasKit is faster in most scenarios. The only scenario where it's slower is in the presence of platform views, which is discussed in the proposal. We plan to focus on platform view optimization between now and the time we remove the HTML renderer.

[ImadBouirmane]

I'm not much close to your understanding but can you just give me a brief the dfiferent between Rendering by HTML or by CanvasKit. Look to hear from you.

[yvrez]

Go for it. Webgl rendering + wasm is the way to go & we need the team to focus on a single performant & futur proof renderer.

[ditman]

I'm not much close to your understanding but can you just give me a brief the dfiferent between Rendering by HTML or by CanvasKit. Look to hear from you.

Check the document that @yjbanov linked at the beginning of the thread; I think it summarizes well the pros/cons of each renderer.

[dxvid-pts]

Sunsetting the html renderer would be very problematic for one of our projects as the canvaskit renderer is still buggy in platform view scenarios.

An example: https://github.com/flutter/flutter/issues/143747. We also experience various other issues when platform views are present. For example

• Firefox is flickering until the platform view is removed from the scene
• Rendering issues on old safari versions (Safari version 14).

These issues are not present when using the html renderer.

[gildaswise]

I'm still not comfortable with the CORS situation. Is the Flutter team really expecting everyone to give up Image.network working with any image and pivot to using platform views with fixed sizes? The proxy solution isn't that good either.

For context, I'm developing deck.blue, a Bluesky client which means that I will never "own" the images displayed and would rely on them turning on CORS. And that also wouldn't work 100% due to how federation works and soon there will be media hosted outside of their CDN. What then? Should I just use proxies and have to pay for that?

[SaadArdati]

The HTML renderer still performs better than CanvasKit in certain browsers like WebKit (any iOS browser) & Safari.

My reference is developing this Flutter website https://hyperzones.hyperdesigned.dev/. It performed extremely poorly under 10fps on CanvasKit, and peforms significantly better (but still not great) on WebKit. So we force-enable HTML when building and deploying it.

I would not remove HTML Renderer.

[r3flow]

If WebGL or Skwasm works well and is stable in the iOS browser, you can remove the HTML renderer. If not, then no.

[josiahsrc]

The biggest issue for us is load time. Canvaskit increases load time significantly, so I'm weary of this change unless the speed can be improved.

For context, our onboarding site is built using canvas-kit flutter web. We track drop-off and are able to see how many users visit the site and at which point users leave (typical funnel). Using this, we found that 33% of leads drop off during the time it takes to load the app (to be clear, 33% is a lot). The 3 culprits seem to be dart.main.js 1.6mb, canvaskit.wasm 1.5mb, and the time it takes to spin up the engine. We're going to run an experiment to see how html-renderer improves these stats.

We love sharing the same onboarding code between web and mobile, but are considering switching the web portion over to react because of this.

[dutsky]

Could you please consider not deprecating the HTML renderer? One significant advantage not mentioned in the documentation is its performance on slower machines, such as terminals. Web applications that run on CanvasKit on machines without a dedicated, decent GPU tend to consume a substantial amount of CPU resources, and the situation on terminal servers is even more challenging. The HTML renderer was a more-or-less suitable solution.

Thanks

[slavap]

Instead of deprecating HTML renderer - assign resources to improve it (Google is not poor and can afford to hire five additional developers). It has to be more configurable than it is right now, e.g. "famous" hack to force p element for showing texts: https://github.com/flutter/flutter/issues/81215#issuecomment-827441516 Also, this improved and configurable HTML renderer could be later used to "soften" SEO problems, and could be used to solve this issue https://github.com/flutter/flutter/issues/139292 Understandably, there always be some limitations in html renderer - but in many use cases, it does not matter at all.

In any case, please DO NOT deprecate html renderer till all major problems (e.g. CORS for images, platform views, ...) are solved in canvaskit. When they are solved, then it will be at least understandable to move to the one 100% better renderer, but currently canvaskit is not obviously better.

Also, 10mbit connection is not always the case, on phones it could be much slower, especially in developing countries.

[yeras-is]

Hey, glad to hear that, in my project I always force to use Canvas Kit, only problems is on first launch it's still janky and doesn't have smooth animations, and emojies doesn't match theirs colors. Hey @yjbanov can Flutter team integrate with Google Chrome team and add CanvasKit to Chromium so if browser based on Chromium we can load CanvasKit locally ?

[yjbanov]

To summarize the feedback, it seems we should focus on the following:

• CORS images
• Platform view efficiency
• Platform view bugginess
• Load time
• iOS browsers (i.e. Safari/WebKit)

We are actively working on the first three (CORS image fix is related to platform views). For load time, we are launching a new bootstrap design that takes advantage of parallelism when fetching static resources. For example, you should now see canvaskit.wasm fetched simultaneously with main.dart.js and from separate hosts, so the actual start-up cost of CanvasKit should be much smaller. The bootstrap API also allows creating a plain HTML landing page for the app while loading the Flutter app in the background. By the time the user is done interacting with the landing page most of the Flutter app will be ready. Most of the slowness in iOS is due to lack of ImageDecoder API, so we'll need to find a better image decoder fallback than the current single-threaded wasm codec solution.

Unfortunately, the following would be impractical for us to address:

• Supporting hardware without GPUs.
  • On the native side Flutter already requires a GPU, and with Impeller that requirement will go even further and require the latest crop of graphics APIs that don't make sense without GPUs at all. I doubt that Flutter Web is positioned to fight that trend or risk putting brakes on Flutter overall. I think if GPU-less hardware is important for your app, Flutter may not be the right choice.
• Hiring more engineers to support the HTML renderer.
  • Hiring is not about cost, but about opportunity cost. It's not that Google can or cannot afford hiring more engineers, but that when it does hire engineers the company needs to decide what projects to assign them to. Unfortunately, the HTML renderer does not present a good case here.

[yjbanov]

@yeras-is We try to participate in the web standards process in a framework vendor capacity. We inform the W3C efforts about Flutter developer needs on the web. For example, we provided early feedback on the WasmGC proposal, and the Canvas Formatted Text. Bundling CanvasKit into Chrome is unlikely to be a scalable solution for several reasons:

• It would make it Chrome-only.
• We'd have to deal with versioning issues, where the browser gives you one version of CanvasKit but the Flutter SDK moves on to the next.
• We'd have less freedom to improve CanvasKit. Right now we can make large changes to CanvasKit. For example, we reduced its size from 3.2MB down to 1.5MB. Skwasm, which is a from-scratch rewrite of CanvasKit bindings, reduces it down to 1MB. If you make it built into the browser, our hands would be tied.

[slavap]

@yjbanov Unfortunately, the HTML renderer does not present a good case here.

I strongly don't agree with that statement - having a "customizable" html renderer could solve multiple problems. It could be limited by supported features, but if it works and perhaps able to create "human readable" DOM structure - it will be a great help for SEO scenarios and also useful for "classic" web testing tools working through the interaction with DOM elements, see https://github.com/flutter/flutter/issues/97455 Also in real life it is very often necessary to integrate Flutter webapp with an existing website, and html renderer could be more suitable for such cases.

Nobody arguing that canvaskit renderer is better for Flutter overall, but you are trying to ignore the fact that html renderer (even limited) could be very useful for Flutter Web in various scenarios.

iOS browsers (i.e. Safari/WebKit) And for god's sake, please fix this issue https://github.com/flutter/flutter/issues/69529 On the phones Flutter webapp looks like "retarded" because of this :-(

And please don't forget to address Ctrl+F search somehow - you have it in the docs, and it is quite important for webapp.

And the question about SVG support - does canvaskit support it? Or huge flutter_svg package is still required to support it? Because with html renderer SVG support comes "for free" from the browser.

[dxvid-pts]

@yjbanov good summarization of the issues If these will be fixed we don't see any problems not to sunset the html renderer.

[ditman]

Just for completeness, bringing another argument against deprecating the renderer from r/FlutterDev:

• VenkatPerla: Html renderer works in an environment not connected to the internet. The other renderer(default one), needs internet and usually does an api call to get the renderer. In some of my projects, I need the environment to be not connected to the internet.

(unsure if the user is more concerned about load time, that additional assets need to be downloaded at all, or maybe that there's no good offline mode)

[slavap]

@yjbanov @ditman I think "native" SVG support should be planned for canvaskit (if it is not already implemented), if I understand it correctly, part of Chromium optimizations were based on using "browser" image processing functionality.

[NeroSong]

Support putting more resources into CanvasKit, but please also keep the HTML Renderer, even if it doesn't get updated much.

We've had lots of projects in production using the latter, and they perform well on low-performance phones and load faster, and it's easy to embed some HTML elements.

Removing the HTML Renderer would inevitably result in huge migration costs for many older projects 😢

[aanari]

For load time, we are launching a new bootstrap design that takes advantage of parallelism when fetching static resources. For example, you should now see canvaskit.wasm fetched simultaneously with main.dart.js and from separate hosts, so the actual start-up cost of CanvasKit should be much smaller.

That's great, please do not deprecate the HTML renderer until CanvasKit's load time is on par with it!

[w830207]

放棄Html renderer從長遠來看一定是好的方向！支持！

Giving up Html renderer must be a good direction in the long run! support!

[Jeremiah-Griffin]

For load time, we are launching a new bootstrap design that takes advantage of parallelism when fetching static resources.

I appreciate this, however there remains the problem of sheer bundle size. On my own application, building with canvaskit bloats the compressed size application by a factor of 5 - from ~500kb - 2.5mb.

To this end, I strongly disagree with the out of hand rejection of increased bundle size as a valid concern by the linked document (I'll call it the Design Document).

Mild: the extra payload needed for WebGL only costs 0.8 seconds on a connection that is now considered 2.5x slower than the old definition of “broadband”.

The citation of this metric is , in my view, improper for a wide variety of reasons

1. a. The FCC is not an international regulatory body, but an American one. Making technical decisions predicated upon broadband speeds for a country with the fifth fastest fixed broadband internet in the world is an incredible disservice to residents of nations not likewise privileged.

Nowhere in the copy of Flutter Web is it alleged that the framework is designed only for web apps delivered in America. As such, the impact of technical decisions should not be inferred by calculus done solely for Americans and American policy makers.

b. What the document asserts as a standard for broadband, the FCC report on page 41 states the following:

Consistent with past Commission practice, we decline to set a benchmark for determining service availability of advanced telecommunications capability for mobile services (mobile advanced telecommunications capability) in this Report.

Considering that by default flutter delivers the HTML renderer to mobile browsers, removing a feature seemingly retained for them on the citation of a citation of a document that explicitly refuses to remark upon mobile web services is , in my view, unsound.

c. The standards set for raw throughput of broadband is only one factor of overall quality of service. Packet loss - particuarly when compounded by transport latency and/or signal strength - is another technically relevant metric that is uncited by the document. While many connections may meet the throughput demands to only suffer a "0.8 second performance hit", this is seemingly a mathematical approximation divorced from the reality of WiFi, mobile, and Satellite connections which all suffer degredations in QoS wrought by the aforementioned factors with a high degree of regularity; a real-world test is bound derive a significantly poorer result, especially on marginal examples of these connections.

d. The 0.8 second figure is only for the network download. It does not include the cost due to parsing all that additional WASM. On my machine this is not insignificant.

e. Bandwidth cost, neither for those hosting flutter web applications nor consumers of them on metered connections, to include the vast majority of mobile users is not considered.

2. This is a standard used in no small part to regulate marketing terminology. While it is informed by offerings available on the market, the actual FCC release clearly states that the proposed standard is not being universally met:

   100/20 Mbps terrestrial fixed broadband service4 has not been physically deployed to approximately 7% of Americans. Rural areas and Tribal lands significantly trail more urban areas, with approximately 28% of people living in rural areas and approximately 23% of people living on Tribal lands lacking access to 100/20 Mbps fixed broadband services.

While this statement is rebutted toward the end of the FCC report by commissioner Carry on account of the emerging satellite internet constellations like SpaceX's starlink and Amazon's project kuipier, the findings of the majority consensus itself do not support the claims the Design Document is attempting to assert by transitively citing it.

3. Even if this standard was suitable for such decision making, it is an exceptionally recently set one, hence that if it was tied to real world performance, like any other standard technical or no, there must be time allotted for adherence to the standard to become widespread. Less than a month has passed since the publishing of this standard and today, and less than that since the publishing of the Design Document.

To the authors of this Document and the broader flutter team, in your decision making please:

• incorporate real-world metrics of internet performance, rather than regulatory standards of the same.
• incorporate international, rather than solely American metrics on internet performance.
• incorporate real-world testing or simulation of QoS degredation on the impact of load times

Finally, while I have not personally been able to test the WASM backend myself due to some bugs presumably with runtime feature detection, it is my understanding that WASM as opposed to delivery of minified JS has benefits regarding compressibility, binary packing, link time optimization between other wasm assets, and streaming parsing that could potentially produce bundles smaller than using JS as a compilation target, or otherwise ameloriate the penality of large bundle sizes in general. However, being unable to test the WASM backend myself and having not found any concrete metrics on bundle size and network performance of flutter projects compiled to Web Assembly, I would personally - and imagine the community at large would as well - greatly appreciate some metrics on bundle sizes produced by the dart WASM backend in a real world application compared with the JS backend between both CanvasKit and HTML renderers. Only then would I be comfortable with the HTML renderer being deprecated.

[OlehSv]

CanvasKit looks like a future of flutter web, while HTML renderer from my experience is too buggy and can't suggest anything promising.

[zsxawerdu]

@OlehSv I agree, I have a few flutter web apps in production and canvas kit is a hard requirement. I was wondering when they would remove the html renderer.

[uldall]

Just for completeness, bringing another argument against deprecating the renderer from r/FlutterDev:

* [VenkatPerla](https://www.reddit.com/r/FlutterDev/comments/1br2n3c/comment/kx8eaid/): Html renderer works in an environment not connected to the internet. The other renderer(default one), needs internet and usually does an api call to get the renderer. In some of my projects, I need the environment to be not connected to the internet.

(unsure if the user is more concerned about load time, that additional assets need to be downloaded at all, or maybe that there's no good offline mode)

The canvaskit URL can be declared with --dart-define=FLUTTER_WEB_CANVASKIT_URL such that it is downloaded from a local web server.

[yjbanov]

@Jeremiah-Griffin Your concern is valid, and we will continue working on reducing the overall bundle size. As for the choice of 10 mbps as our baseline network speed, according to the link you shared the world average is shown to be 52 mbps for mobile. We're targeting 1/5 of that. Of course, there will still be situations where network speeds are too terrible for Flutter Web apps. In that case, perhaps Flutter Web is not the right choice. Perhaps an AOT-compiled app (Android or iOS) is better, which does not require any network to launch the app. However, if web support is absolutely required on very bad connections, then perhaps Flutter is not the right choice for the time being.

@uldall Yes, you can specify a local CanvasKit and a local source of fallback fonts. If you have both, then the app can run in fully offline mode (if preinstalled as a PWA). Unfortunately, we do not make it easy to bundle our Noto fallback font bundle. You have to find it among our CIPD packages, fetch it manually, and put it on your server. We'd like to make it easier eventually, or even automate it entirely.

[slavap]

@yjbanov and what about SVG support? Is the plan to rely on flutter_svg package or some support will be added CanvasKit?

[Jeremiah-Griffin]

@Jeremiah-Griffin Your concern is valid, snip

Agreed, but the problem remains that the design document does not accurately depict the costs of the bundle size.

• multiplying bandwidth costs vs html rendered apps by 5 (in my experience ) times. Considering the prior default was to deploy the smaller build to mobile devices which make up over half of web traffic, this could pose a silent and very sudden increase to hosting costs for those who deploy flutter web applications. This is particuarly notable as the official flutter docs promote firebase hosting as a hosting provider for flutter web app which meters bandwidth.

Put another way, once the update which deprecates the HTML renderer lands, a developer who used the hosting provider that is recommended by the project, and uses the default settings of the project should expect to see their hosting costs double with an update. That is something that should be conveyed by the document in my view, particuarly for the benefit of the largest, most important users of flutter web (not myself)

• performance degredation in light of QoS of mobile connections
• Parsing time (particuarly on mobile, chromebooks, older desktops/laptops etc) is not insignificant

My gripe is not solely with the citation of what I feel to be an inappropriate resource which minimizes the apparent penalty of the change, it's that the document is not comprehensively noting the penalties - some of which could be quite expensive for scale users of flutter web.

[maggie44]

The biggest issue for us is load time. Canvaskit increases load time significantly, so I'm weary of this change unless the speed can be improved.

For context, our onboarding site is built using canvas-kit flutter web. We track drop-off and are able to see how many users visit the site and at which point users leave (typical funnel). Using this, we found that 33% of leads drop off during the time it takes to load the app (to be clear, 33% is a lot). The 3 culprits seem to be dart.main.js 1.6mb, canvaskit.wasm 1.5mb, and the time it takes to spin up the engine. We're going to run an experiment to see how html-renderer improves these stats.

We love sharing the same onboarding code between web and mobile, but are considering switching the web portion over to react because of this.

I haven't got as far as to experience any issues with CanvasKit, I am doing my due diligence on Flutter and the initial time to first interaction is too long for it to really be viable for web.

I see some people are hacking together loading pages. A loading page is something that should probably be included in the starter templates, or at least a working model documented. A white screen with no indication of anything going on breaks the most basic product rules, those drop-off rates are no surprise. Rendering as html doesn't completely solve the problem, but at least moves it a little closer to useable. Hopefully a simple solution around time to first interaction could be implemented before deprecating html render.