6 ms·

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 h

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.

modarts 7y ago
> Simple views are easy enough to handle, but these functional style guis don't tend to deal with complex views very well. Citation needed
vertex-four 7y ago
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.
- seanalltogether 7y ago
  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.
lhnz 7y ago
Do you think SwiftUI was a mistake for that reason then, since it's for native applications?
- seanalltogether 7y ago
  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.
  - nwienert 7y ago
    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.
chris_st 7y ago
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!
rvz 7y ago
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.
- littlestymaar 7y ago
  > 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.
  - jcelerier 7y ago
    > 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.
    - raphlinus 7y ago
      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.
    - pjmlp 7y ago
      I don't have any issues with DirectX.
choward 7y ago
> 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?

modarts 7y ago

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

vertex-four 7y ago

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.

seanalltogether 7y ago
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.

lhnz 7y ago

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

seanalltogether 7y ago
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.
- nwienert 7y ago
  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.

chris_st 7y ago

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!

rvz 7y ago

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.

littlestymaar 7y ago
> 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.
- jcelerier 7y ago
  > 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.
  - raphlinus 7y ago
    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.
  - pjmlp 7y ago
    I don't have any issues with DirectX.

choward 7y ago

> 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?