4 ms·
I've had this fight a dozen times and there's nothing really new for me to add, but I consider GUI frameworks that target WebGL and Canvas for their basic eleme
by danShumway 5y ago
I've had this fight a dozen times and there's nothing really new for me to add, but I consider GUI frameworks that target WebGL and Canvas for their basic elements like text and sliders to be usually harmful, for multiple reasons[0].
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.
----
[0]: https://news.ycombinator.com/item?id=27132087 https://news.ycombinator.com/item?id=27132087
- videogreg93 5y ago> No Right click menus anywhere Just wanted to add that I think that's going to be added soon, I see there's a pull request[0] to get those in. Seems like development on this is pretty active ---- [0]: https://github.com/emilk/egui/pull/543 https://github.com/emilk/egui/pull/543
- ampdepolymerase 5y agohttps://makepad.dev/ https://makepad.dev/
- Rd6n6 5y agoWhat an amazingly detailed write up, thanks for sharing. For web libraries or frameworks, what are your preferred options and why?
- danShumway 5y ago> For web libraries or frameworks Sort of a broad question, I think that depends a lot on what you're trying to build, what programming styles are most natural to you, what dependency requirements you care about, etc... I'm not sure I can pick out one or two JS frameworks for web interfaces and say they'll be the clear right choice for everyone.
- ducktective 5y agoAmazing review. Thanks for posting. Since you are experienced in GUI tech, what cross-platform solution do you think "has got it right"? I like QT apps alot for snappiness alone. What do you think of https://quasar.dev/ https://quasar.dev/ and https://ionicframework.com/ https://ionicframework.com/ ?
- danShumway 5y agoRight to start, going to be clear that I would not consider myself to be particularly experienced in GUI tech. I have a checklist of things that I look for whenever a "run native code in the web" project gets posted, but I haven't downloaded and checked the native performance of any of these technologies. I'm really just looking at their web demos. That being said, on the web, Blazor is what I'm paying the most attention to right now. Being in C# might be a pro or a con for you. But Blazor will spit out an actual DOM tree, it seems to have a lot of promise from what I can see. There's a heavy emphasis on writing UI in C#, but having good interop with browser technologies and JS libraries. On the Rust side of things, pay attention to https://www.areweguiyet.com/ https://www.areweguiyet.com/, they've been doing a great job of cataloging different efforts. A lot of the Rust efforts have either gone in the direction of "embed a Webrender instance in a native app" or "embed a native app in the browser." I'm not sure that's a great direction, at some point I think it might make more sense to treat the HTML as a compile target rather than an authoring language. Again, I point towards Blazor. Not the C# part obviously, keep it in Rust. But I wish some of the Rust GUIs would take Blazor's approach and spit out separate HTML for the web (even if the results look slightly different) rather than trying to embed the same renderer everywhere. I don't personally use Qt, but that is purely a personal preference, if you're doing native cross-platform apps, I don't think there's anything wrong with Qt. It's popular for a good reason. However, I do think that Qt's web export is really bad. It's making the same mistakes as Egui, but Egui has the benefit of clearly a large amount of work devoted to performance, UX, etc... not to say that Qt's web export hasn't had a lot of work put into it, but Equi's seems to have actually paid off, and the Qt demos don't give me that impression. That's purely on the web though, as a user for native cross platform code I don't really have many complaints about Qt, if you like it you should keep using it. Ionic and Quasar are obviously going to have great results on the web because they're based on React and Vue, which are web technologies -- so of course they're going to render to DOM in those situations. I'm not sure how their native performance will be. My immediate concern with both of them is that they're trying to upsell me on a license. You might also take a look at React Native if those libraries seem attractive to you. I don't know what the consensus is on whether React Native runs well on mobile devices. And again going to stress here, I'm opinionated but I'm not an expert. I'm not really commenting on the ease of use or the architecture paradigms or language choices or anything here, I'm just looking the web demos online that these technologies have and checking to see if they run OK inside a browser.