That being said, some (imo high) praise:
- Demo is faster than most other WebGL/Canvas-backed frameworks that I've looked at in the past, including Flutter and Qt. It easily blows them out of the water.
- Demo works in Firefox
- Demo respects platform scroll direction(!!!)
- Demo supports platform-specific cut/paste(!!!)
- Demo responds to (some) browser zoom events(!!!)
- Demo is at least semi-responsive (again, compared to Qt/Flutter this is miles ahead)
- Demo handles touch events
- A ton of impressive attention to detail around UX affordances like showing link locations and tooltips on hover. Clearly focused on actual usability, not just on showing off tech.
- Just again stressing that interactions are really snappy and performant. Kind of starts to chug if I open a ton of windows, but... I'm comparing this to the last Flutter demo I saw on HN; the performance is great.
----
And some criticism:
- Evergreen accessibility concerns (I've seen some conversations about exposing a separate API, this... misses some of the point of how accessibility on the web is designed to work imo. Also, the DOM is an accessibility layer. I don't understand why we keep reinventing the wheel here, I don't understand why we're recreating content trees to send to screen readers when the browser has a content tree baked in)
- Search doesn't work at all
- No right click menus anywhere
- Font rendering appears to be heavily platform/DPI dependent (?), on some of my screens the whole app just looks blurry, I would abandon any app in the real world that had fonts that looked this bad on some of my screens.
- Copy/paste/text-selection disabled in most of the demo (for example, no way to copy links)
- Good on the demo for catching platform settings for scrolling, but it doesn't catch any of my other custom keyboard shortcuts or gestures. Even some stuff that's not platform-specific: I'm not sure why page down/up isn't getting caught.
- Demo blocks some mouse gestures that should filter up to the browser level (pinch to zoom, etc)
- Demo has no fallback if WebGL isn't enabled, which makes this solution unworkable for anyone configuring their browser to avoid fingerprinting (hopefully Firefox will make this concern go away in the future by bundling WebGL permissions into Canvas permissions. This is not really the author's problem to solve, I don't think).
- Evergreen criticism that demo does not respect my font choices or work with any of my browser extensions. This is the important thing, because I still don't see how (short of re-implementing the entire DOM) a GUI framework like this is ever going to respect my browser settings and extensions. You can polish a GUI framework for eternity, that doesn't mean 3rd-party extensions are going to start working with it. This is a huge step backwards for the web in my opinion, I regularly customize and extend the sites I visit. There's no way for a developer to allow that using a framework like this.
----
TLDR I think this is easily the best Canvas-backed GUI demo I've seen so far, the author(s) should be very proud of it. I can't speak to its native performance but I'm seriously impressed by how the demo performs in the browser. Also seriously impressed by some of the little UI touches I'm seeing. I can't stress this enough, good job.
However, this is still not the right way to build a cross-platform GUI that targets the web. The demo still has serious flaws that aren't the result of a lack of polish, they're the result of the rendering target itself. I still heavily advocate that people trying to build GUIs for the web use something else (even for the stated use case of a simple GUI). There are multiple cross-platform GUIs that will spit out actual DOM content. A polished cross-platform GUI that spits out HTML instead of pixels as its render target won't have the problems that I listed above.
I understand that working with HTML is frustrating, particularly in some native circles where the way developers think about UIs is primarily visually. But the DOM is not a framework for displaying visual graphics, the DOM is a render target. A lot of benefits on the web stem from the fact that we treat the DOM as its own render target. That philosophy is why a lot of extensions and behaviors on the web are possible. No rule is absolute, there are instances where WebGL is the right choice. But for most frameworks, particularly frameworks that are displaying text data, it's not.
This focus on taking the DOM out of the picture to get rid of the messy details of how it works is a bit like arguing that the best way to improve command line interfaces is to abandon text and start streaming OpenGL buffers to the terminal output. It's missing the point. Yes, working with the DOM is frustrating, but a lot of the frustrating parts are a result of the medium itself. The DOM is part of the user interface.
----