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.
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.