New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intent to deprecate and remove the HTML renderer in Flutter Web #145954
Comments
This comment was marked as outdated.
This comment was marked as outdated.
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 |
@Juliotati The @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. |
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. |
Go for it. Webgl rendering + wasm is the way to go & we need the team to focus on a single performant & futur proof renderer. |
Check the document that @yjbanov linked at the beginning of the thread; I think it summarizes well the pros/cons of each renderer. |
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: #143747. We also experience various other issues when platform views are present. For example
These issues are not present when using the html renderer. |
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? |
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. |
If WebGL or Skwasm works well and is stable in the iOS browser, you can remove the HTML renderer. If not, then no. |
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 |
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: #81215 (comment) 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. |
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. |
To summarize the feedback, it seems we should focus on the following:
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 Unfortunately, the following would be impractical for us to address:
|
@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:
|
@yjbanov 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 #97455 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 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. |
@yjbanov good summarization of the issues |
Just for completeness, bringing another argument against deprecating the renderer from
(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) |
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 😢 |
That's great, please do not deprecate the HTML renderer until CanvasKit's load time is on par with it! |
放棄Html renderer從長遠來看一定是好的方向!支持!
|
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).
The citation of this metric is , in my view, improper for a wide variety of reasons 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:
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.
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.
To the authors of this Document and the broader flutter team, in your decision making please:
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. |
CanvasKit looks like a future of flutter web, while HTML renderer from my experience is too buggy and can't suggest anything promising. |
@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. |
The canvaskit URL can be declared with |
@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. |
@yjbanov and what about SVG support? Is the plan to rely on flutter_svg package or some support will be added CanvasKit? |
Agreed, but the problem remains that the design document does not accurately depict the costs of the bundle size.
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)
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 there's an example here: https://docs.flutter.dev/platform-integration/web/initialization#example-display-a-progress-indicator |
@ditman @maggie44 Those stats I mentioned above are from a website that uses a (very fancy) loading indicator. Sadly it doesn't seem to help the funnel drop-off. You can check it out here; The sunrise is the loading indicator. https://start.joinrelay.app/#/onboarding |
@josiahsrc, I happened to open the link to joinrelay from my iPhone (12 Mini), Safari. It has AdGuard adBlocker running on it. The site doesn't open, it just sits on the sunset loading page and never progresses. With AdGuard disabled it loads. May be worth exploring if that or something similar is a chunk of the drop offs. |
Wow, great find! I'll look into this. Thanks @maggie44! However our drop-off seems to originate from countries with slower internet speeds. So I believe packet size is at play here. |
@Jeremiah-Griffin by default, if you just run @josiahsrc I think a proper landing page (not just a progress bar) could improve the user experience even further. The page would use @slavap We aim to have SVG to be as good as on Flutter mobile. Whether it will be better than the browser's SVG engine is a different question (depending on the browser engine we may be sometimes faster, sometimes slower; also it is not a goal to implement the full SVG spec). For complete SVG support, I think platform views will be the appropriate choice, similar to CORS images. |
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.
The text was updated successfully, but these errors were encountered: