5 ms·

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 sti

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.

mekkkkkk 4y ago
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.
- LocalPCGuy 4y ago
  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.)
  - mekkkkkk 4y ago
    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.
    - LocalPCGuy 4y ago
      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.
- chrismorgan 4y ago
  I’ve encountered a Flutter web app exactly once, https://app.travellerdeclaration.govt.nz/ 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).
  - mekkkkkk 4y ago
    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.
mhoad 4y ago
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.
- SemanticStrengh 4y ago
  > 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
  - LocalPCGuy 4y ago
    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).
    - SemanticStrengh 4y ago
      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.

mekkkkkk 4y ago

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.

LocalPCGuy 4y ago
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.)
- mekkkkkk 4y ago
  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.
  - LocalPCGuy 4y ago
    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.
chrismorgan 4y ago
I’ve encountered a Flutter web app exactly once, https://app.travellerdeclaration.govt.nz/ 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).
- mekkkkkk 4y ago
  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.

mhoad 4y ago

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.

SemanticStrengh 4y ago
> 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
- LocalPCGuy 4y ago
  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).
  - SemanticStrengh 4y ago
    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.