Hacker News Reader

Comment by seanalltogether | Hacker News Reader

Personally, I don't think developers should be mimicking Elm or React when they have the opportunity to build a custom gui library from scratch. Elm/React are helpful for overcoming the inherent problems in the html component development, but that requires them to be more ineffecient then typical native gui frameworks. Simple views are easy enough to handle, but these functional style guis don't tend to deal with complex views very well.

View on HN

The problems in HTML component development are largely the same as in any other GUI - state management. I've run into plenty of UI state bugs across many, many applications using "typical native gui frameworks", both open-source and proprietary - I don't think it's a solved problem.

Wiring views to reflect model state correctly is a problem that exists regardless of framework, how effeciently your framework deals with state changes from single or multiple sources is the problem I have with these pure functional frameworks. We've recently backed away from React Native because of the performance problems inherent in its design.

Let alone some GUI libraries like this one are starting to require hw-accelerated web canvases + vulkan for drawing on the screen just for the requirement to have a cross-platform GUI on the desktop these days which is quite frankly unnecessary in this use-case, unless you're developing a game.

In the end, constructing a GUI from that would be questionable and would end up being even more uglier than a barebones Qt5 example. You might as well create your own in-game GUI library or use ImGUI with Rust bindings.

> Let alone some GUI libraries like this one are starting to require hw-accelerated web canvases + vulkan for drawing on the screen just for the requirement to have a cross-platform GUI on the desktop these days which is quite frankly unnecessary in this use-case, unless you're developing a game.

Web browser and OS UI toolkits are also GPU accelerated these days. In fact, that's completely silly to do any kind of rendering on the CPU when you have a GPU available! It's just way slower and much more expensive in terms of power consumption.

> It's just way slower and much more expensive in terms of power consumption.

really depends on what you want to draw. there is still nothing that renders fonts with freetype quality on the GPU and rendering paths / drawings / svg-like stuff is still a pain as the only GPU maker who cares about 2D drawing is NVidia.

That was true a few years ago, but fortunately the state of the art for 2D rendering on GPU has been moving forward. Among others, Pathfinder 3 is quite comparable in quality to Freetype, and there are lots of good results coming out for performant vector drawing on GPU, including my own piet-metal work.

I don't have any issues with DirectX.

unnecessary? maybe. but if it comes for free with a toolkit, why not?

The efficiency argument is appropriate for things like real-time games, where response time should be as fast as possible.

For the other 99% of apps, a clean, clear mental model for the developer is pretty nice to have, and this looks like a very nice implementation. I'd use it!

Do you think SwiftUI was a mistake for that reason then, since it's for native applications?

I think SwiftUI was a waste of genuine effort that Apple could have put toward making their existing component model easier to work with. Things like adding stylesheets or simplifying layout constraints, or just adding @State binding to existing components. SwiftUI tries to look like react but really it's just normal databinding+restricted access to the direct component tree.

SwiftUI is so much better than what came before it it’s a joke. Minus many bugs and missing features, SwiftUI is the best thing that’s come out of Apple’s dev work maybe ever.

> Simple views are easy enough to handle, but these functional style guis don't tend to deal with complex views very well.

Citation needed

> that requires them to be more ineffecient then typical native gui frameworks

Inefficient in what way? Performance? Is it noticable? Why should I care unless it's noticable and hindering UX? Should we all be writing out GUIs in assembly then?

Reply on news.ycombinator.com