Something else that’s a problem is that as a drawing app, FlowBetween wants to be able to get access to data from a digitizer: pen pressure and tilt in particular. A lot of UI libraries don’t think to pass that through from the operating system, or have an awkward API (browser support is also very spotty for this)
If you’re trying to do touch and pen on non-web platforms, things tend to be very messy if you want to handle all three types of pointers optimally.
But browser support spotty? I find the pointers events API a marvellous abstraction over platform differences, doing the right thing automatically for >99% of cases, and making the remaining cases possible. The only thing I feel it actually lacks is standardised gesture support for touch. I wrote a simple pressure-capable drawing app a couple of years back in the very early days of pressure-sensitivity (back when Edge was the only browser on Windows that supported it, so I targeted Edge only until other browsers got it), and I found it a refreshingly straightforward system to work with. And since then, everyone implements things like tilt and pressure.
So I’m curious to hear what you’re quibbling over, as someone that’s been using this stuff in anger more recently than I.
Other browsers don't do this, but they've had a few other issues: what I remember in particular - some only support pressure information using the touch API, and some seemed to support pressure information on different APIs on different platforms, so both pointer events and touch events were needed.
All of these are maturity issues rather than real problems with the API, though and I haven't re-checked some of the older issues recently - that Chrome issue was still happening back in January so might still be around, but the others I last encountered over a year ago so may have been fixed by now.
I believe that the pointer events API is in current browsers now uniformly superior in functionality to the touch events API which it obsoletes.
When I started I picked Rust because I’d been learning it and wanted to try using it on a more substantial project. I’m very happy with it as a choice of language: it definitely has a difficult learning curve especially with the way borrowing looks similar to references in a garbage-collected languages but works very differently. However, it’s a very expressive language: something about it makes it very easy to write code quickly that’s still very easy to follow later on.
I suspect everyone goes through a phase of hating borrowing when learning Rust: it's helpful to know that it's something that eventually 'clicks' and really stops being an issue. It didn't exist when I was learning, but 'Learning Rust with Entirely Too Many Linked Lists' looks like it would have helped a lot.
It's sort of starting to make the transition between a pile of ideas and an actually useful tool at the moment. The whole idea is to be a vector editing application that works more like a bitmap tool when it comes to painting, so there's a flood-fill tool and a way to build up paths just by drawing on the canvas rather than having to manually mess around with control points.
The way I built the UI is unique too I think. Choices for UI librarys for Rust were quite limited when I started so I built it to be easy to move to different libraries. I don't think there's any other UI library in existence that is as seamless for switching between platforms (or which can turn from a native app to a web app with a compiler flag without resorting to something like Electron)