flutter's custom canvas render on web means so much of the web stops working or is slow. type anything non ASCII like an emoji or CKJ and eat while it downloads a font. No other pages do this. Text fields are missing all the standard context menu options like define, translate, etc... Things that would be selectable on any other page are not, etc....
If you care about the web at all as a target, you must not use Flutter. It’s awful. They used to have a DOM renderer which you could use and everything would be fine, but apparently no one used it because it wasn’t perfect, and they’ve recently deprecated it and will remove it sooner or later—they’re doubling down on the pure-canvas direction where it’s completely impossible to produce a good result. And I do mean impossible, design limitations of the web platform that in some cases fundamentally cannot be relaxed and in others are very unlikely ever to be. With this direction, scrolling will never be good, text rendering will never be perfect, input and manipulation will never be acceptable, links will never work properly.
Flutter Web is for web apps, not web sites, so much of those concerns don't necessarily apply. And it's not "impossible" simply because Chrome itself runs on Skia which until recently Flutter did too, so clearly they were able to implement scrolling at least one time correctly.
When you want to draw this distinction: most web apps will still suffer heavily for many users if they use Flutter. To begin with, few web apps don’t use text, scrolling, or form fields. Games are almost the only thing that may not suffer, or only barely suffer. But beyond that: well, that’s what they say its purpose is, but at least two of the three times I’ve encountered Flutter in the wild on the web, it was inappropriate, and frustrating; regular DOM should certainly have been used. (The third, I’ve forgotten what it was. It was probably similarly inappropriate.)
Skia is not the bottleneck. The web platform is. Scrolling is limited on two counts: ① what browsers expose in events is insufficient to match the native implementation (which varies by platform) in scrolling amounts, overscroll behaviour, and related things; and ② the browser is a compositor, and your code will never get access to that layer, because it’s way too deep in performance-, security- and implementation-detail–land, so you’ll always be stuck at least sometimes at least one frame behind “native”, and janky.
Could you be more specific with what the browsers aren't exposing properly? Because in my experience, targeting WebGL+WebAssembly is pretty much exactly the same as targeting OpenGL+GLFW. I use my own renderer made with bare OpenGL + C++ though, not Flutter. All the things you have mentioned (scroll amount, overscroll behavior) are under the control of the GUI library and don't have much to do with what the browser exposes. The compositing of the whole scene is done by the gui library itself
I use Firefox, Sway, Linux, laptop with precise touchpad.
Normally, I get smooth scrolling at such-and-such a rate of pixels-per-centimetre, with momentum so-and-so, and since comparatively recently, particular overscroll behaviour.
On that site, I get janky scrolling at a somewhat slower rate, with no momentum, and no overscroll. (… and scrolling leftwards in the carousel triggers go-back-a-page rather than scrolling left, so you need to scroll right a little first to “unstick” it, but I believe this is something Flutter could have worked around.) It’s painful. Very painful.
It’s not possible to fix this within the scope of browser mouse events. They’re just the wrong primitive. The consequence is that you can only get native scroll behaviour if you use an actual scrolling area. Which you could do, with mild compromise to the pure-canvas approach, just an invisible one and watch what happens with it, rather than paying attention to scroll events. And that’s pretty much the approach you need to use to get good results: compromise on pure-canvas, and do bits and pieces with actual DOM. For scrolling. For links. For images. For text. For inputs. Oh… huh, look at that, we actually just want real DOM stuff everywhere. Fancy that.
Now you might not immediately get such a bad experience for scrolling: I seem to recall hearing that Safari on macOS basically implements inertia before sending the events, and sends the events with inertia applied. That solves some problems, but causes others.
Actually, I meant two distinct things by “overscroll behaviour”:
① Does it let you scroll past 100% a little and then pull it back, as is increasingly normal, or show some indicator that you’ve reached the end, like Android has historically done, or just do nothing, like all computers historically did?
② Scroll chaining, the CSS overscroll-behavior property, to do with nesting scrolling areas. And note that different platforms behave differently. If you do pure-canvas rendering, you’re stuck: the browser has some of the details needed (and is unlikely to ever tell them: they’re involved implementation detail that varies by platform), and you have some of the details needed, and you can’t really collaborate, it’s just not a good mixture.
When I speak of the browser being a compositor, I refer to how scrolling is no longer implemented in a blocking fashion in the UI thread; these days it’s in a different thread, so that it can implement viewport scrolling independently of content rendering, in order to maintain consistent frame rate even in the presence of slow drawing. Also to do various other tricks to avoid missing frames, mostly platform-specific and involved. Web content will never get that power.
Not sure why it's downvoted, I think it's quite an important distinction to make. I've heard people saying "Flutter is bad for web because it's not indexable by Google". And reply "do you expect your app - like a food delivery app - to be indexable by Google" if it's run on the web?
Existing food delivery apps are not only indexable by google but actively make sure to spam the top google results for all possible food related searches. You couldn't have choosen a better example to disprove your argument if you tried.
This. They can have all the deviations they want, but “input core” must be native. If a framework ignores it, users will notice and frown upon it immediately.
When flutter came out publicly, first I thought no way it can get away with custom everything. But it turned out some developers don’t care about that at all.
1. I shipped more than five Flutter web apps with actual users for a couple of years, and it's been a great experience so far.
2. "Native" web core should burn in hell, and I hope Wasm will finally contribute to it. Amount of developers who do not realize that "native web" is a typesetting engine from 80s with a pile of hacks on top of it, is too large to fight the opinion, of course. And yet, as a developer, I care about using the right tool for the right task, and no amount of browser engine optimization can change the fact that XML-based markup language is not the right tool for modern performant cross-platforms UIs.
you know that zero texting apps nowadays use native input anyway right? even native apps will implement their own input and it's always awful, but the pm needs those style previews... (you're still right thought)
Checked my whatsapp and tg, both use absolutely native inputs. The selection handles & menu, the hold-spacebar movement, the hold-to-magnify feature on ios is the same as everywhere else. If that’s not native, they did a great job for nothing.
Too lazy to check on android rn, but I recently worked with the apps/chats on it and entered text, it didn’t feel different.
Styles are possible with native text view, otherwise we couldn’t have fonts and colors and contenteditable and selection within <p>. I think you mistake “input core” with “web input element” here. The core I’m talking about is a text cell with characters on it that has no concept of own border. Controls like NSTextField, Win32.TextBox, GtkEntry - they all have platform text input (and output) system underneath. In case of gtk it implements it itself, cause X has none. The thing that implements all the familiar behaviors of the text input that you know.
So yes, compared to HTMLInputElement these are absolutely custom. But for a platform, absolutely native.
