As a concrete demo, try out
https://flutter.github.io/samples/web/material_3_demo/.
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.