I still maintain that Flutter Web is not production ready. It could have a nice niche, like games. But for real apps, it's just not as good as web. They are still re-implementing things that have existed in the web for ages, and are not going to be able to keep up. It's basically good for an applet style usage IMO. I'll keep trying it out, I think Flutter is pretty great for mobile, even desktop, but every time I use a web app example I find issues and just shake my head at what they did.
FWIW I kind of agree and I’m a big fan of both Flutter and the web in general.
There are a couple of web platform technologies that I think are going to take Flutter web from ok to great in the next year or two including.
WASM Garbage Collection is going to allow them to move from compiling to JS to WASM. They have already built a WASM compiler ready to go when it lands.
WebGPU is another obvious one. Flutter is by definition a canvas optimised framework rather than strictly DOM based (although they support that too as a target). But they should be able to get blazing fast canvas rendering with those two technologies alone.
The other big one that I think will help them is going to be AOM. Lots of the built in browser accessibility stuff was built for a DOM based world, the web platform needs better primitives to support canvas frameworks too.
Yah, this is a pretty solid list of things that, if they all hit and work as we hope they do, it could enable building things with tech like Flutter and having it work well. I think that's why I generally say FlutterWeb isn't production ready and not that it'll never be. I don't care for the path they took originally, it feels like a bandaid and has a lot of issues. They may get there eventually, and I'll be happy to adjust my position when/if they do.
I’m betting on Flutter web across a 2-3 year timeframe but none of the things I’ve listed there are conceptual ideas that are only going to land in the distant future.
WebGPU and WasmGC are both already implemented in most browsers and are currently just behind a flag as far as I know.
It doesn’t feel like magical thinking to me at all, it’s a pretty clear path forward IMO.
Oh, I do mostly agree with you that it isn't magical thinking. I do think there were some choices made that might make it a bit more difficult to switch, but the Flutter team has been willing to make big shifts in the past.
Personally, I'm not willing to be on Flutter Web right now, and as you can see, I still actively dissuade it's use as I don't think it's good for the web as it is. But that doesn't mean that in a few years I'll think differently.
Isn’t Dart a very JS-like language? I really don’t believe that compiling to JS would cause any bottlenecks at all, like compiling Java to JS is also possible with Google’s own Closure compiler which produces crazy fast JS output.
Sure, JS is not a good compilation target but if you have a sufficiently similar language it is not too hard, and with the man-hours spent on JS JIT-compilers these won’t be slow at all.
Though surely the render codepath could use wasm, but that could be written natively as well without a need for GC.
As for WebGPU, I don’t think a web app would be okay with the latency of compiling shaders. Not sure whether it will be needed, or if it can be cached but it is not a trivial win either.
For the record Dart has something extremely similar to the Closure compiler built with the same ideas and similar performance AFAIK.
It’s totally fine, impressive even and currently runs the code producing the majority of their revenue via Ads which is all Dart.
But they also recognise (same with Google’s Java teams) that as the platform landscape is changing WASM with garbage collection should be the “next generation” of compile targets for the web for those languages for performance reasons. Both Java and Dart teams already have compilers ready to go once WasmGC is finalised and both of those teams are heavily involved in the standards team driving the broader effort.
I saw some hints at I/O about them building something called “managed languages” into the browser that covered both Dart and Java as well which seems to build on top of that.
I think this has some broader implications for the JS community as a whole for what it’s worth where “compile to JS” is no longer the only game in town in the near future.
As for WebGPU I don’t know enough about the internals to get real deep on the topic but they already have all those problems today but just with WebGL. This too as I understand things is just the “next generation” target for that code.
They (Flutter team) are also rewriting their entire shader pipeline engine from scratch as we speak to take advantage of everything they have learned to date.
In short, I believe them when they say it’s going to be fast and like native.
Edit: I missed your point initially about they could use WASM today. They do that also for parts of the code already (underlying graphics engine is C++ not Dart) but this allows them to move all of the Dart code to WASM now too.
> Flutter is by definition a canvas optimised framework
Not really, flutter has not the resources to develop their own 2D renderer so they use the chromium renderer for drawing. (Skia). It is canvas-like, everything is canvas-like at low level. But flutter like browsers implement retained mode rendering which is necessary for being jank free and have low energy consumption. Flutter on web canvas cannot properly do retained mode rendering.
spoiler, flutter non-web is generally slower than Ionic
CanvasKit still renders to canvas (maybe that's what you meant by "canvas-like", but it is still directly drawing to an HTML canvas), it just enables Flutter to utilize a more advanced feature set than the DOM canvas API. It also comes with a 2MB or so download (which is why by default it's off on mobile last I checked).
you did not understand my point, canvaskit is skia but slower, over wasm. It output to an HTML canvas and HTML canvas are immediate mode, they do not have retained mode rendering (display lists, occlusion, caching, etc).
Besides I don't think canvaskit is faster than regular HTML canvas. Even if canvaskit might avoid some compute that would normally be done at the HTML canvas level, canvaskit could implement retained mode rendering but 1) it does not 2) it would not really be appropriate because of the unstructured API (unlike DOM), 3) the final HTML canvas would still behave immediately.
As I said, it's important to realize that you are rendering skia (html canvas) on skia (canvaskit wasm) the amount of overhead and rendering duplication is in theory crazy.
SEO is important for websites which for the record you 100% should not use Flutter for.
Flutter is a great fit for applications which (and I say this as someone who did SEO for fortune 500s for many years) aren’t really all that relevant for SEO purposes and are difficult to index at best.
But the short answer to your question is the accessibility object model API is what gets used to surface relevant information that could be used by search engines along with all the other things that have nothing to do with the stuff that sits inside your body tags. Like it wouldn’t actually be that different IRL.
Important for web apps or websites? There's a difference, a product's landing page will need SEO, definitely, but the app itself, ie app.example.com, likely does not need SEO. For example, an easy example is Figma. The landing page is built with HTML, CSS and JS, but the actual app itself is actually built with WASM [0], very similar to the canvas based implementation of Flutter apps.
I'm not sure there's a good distinction between web apps or websites today.
Would you consider Instagram or Twitter a website or a web app?
If I type 'IG ${username}' or 'Twitter ${username}' or '@${username}' in a search engine, you should expect what is to be expected within the first result.
True, if the app needs SEO, then yes it should be built with HTML, CSS and JS, and not Flutter which uses a canvas element. However, there are many apps where SEO is unneeded, such as Figma above (no one will search for your company's design files on Google) or other such corporate apps, and that's where Flutter comes in handy.
The way it atleast used to be framed is that web is a fallback target. Meaning if the target device isn't running Linux, Windows, macOS, iOS or Android (unlikely), then hey, you can atleast build a passable version that will run in a browser.
I don't know if this has changed, but I know only a mad man would try to build a proper website in Flutter. It's not the tool for the job.
I’ve encountered a Flutter web app exactly once, https://app.travellerdeclaration.govt.nz/. It was very painful. (Part of the pain was related to them using a selectable-button style for radio buttons, which isn’t entirely Flutter’s fault, though I bet it contributed to that misguided decision; but when there’s no scrollbar and the Yes/No button you clicked is at the very bottom of the visible page—well, that was the position.) When I filled it out last year, they had an alternative, vastly better accessible version that I think didn’t even require JavaScript, though good luck finding it, since it was accessed by an invisible button that Flutter event handling made unfocusable. Now that button sets a flag in sessionStorage and reloads, and on startup checks for the flag and sets flutterWebRenderer = "html", so that at least the content is in the accessibility tree, even if they still badly reimplement half the stuff the browser provides manually (links, focus, scrolling, they even damage bits of IME).
That was painful indeed! Why you would use Flutter for something that seems to be web-only, and on a govt website that presumably values accessibility, is beyond me.
No, it is 100% being framed as "You can build your app once and deploy it everywhere" with everywhere including web. It's sorta maddening, IMO. There are certain types of apps I could see using Flutter for (basically, ones that would lean heavily on canvas anyways, games, drawing, etc.)
It's hard to quantify exactly what "everywhere" means, but for the vast majority of end-user devices, you'll have a more efficient Flutter build target than web.
You're probably right in that they are pushing the "first class web target" narrative a bit far, though.
Just to be clear, I used the word everywhere. I believe they are quite a bit more explicit in framing it for all platforms, including web specifically. It's possible we'll see it get there, but I think there is a lot of things to do (and undo) to do that.
