Item — HN Reader

I think your skepticism is well placed, and I think you are asking the right question.

Here is why I'm hopeful. SwiftUI is as you say wonderful, but is very much a closed ecosystem. You can't really implement your own custom views, rather you can assemble the premade ones in various (cool and interesting!) ways. If you wanted grid layout before iOS 14, you were on your own.

By contrast, in what I'm building, everything is open-ended, and you are invited to build fully custom versions of every piece of the system - change propagation, async resource loading, layout, drawing, animation, everything.

So yes, I am hopeful this approach will give good results for especially those highly intensive applications you mention. And if not, we'll learn something why not. I'm looking forward to trying!

2 comments

I’ll have to checkout your project. I’ve been experimenting with something similar, but in Nim. It’s interesting to devise declarative or immediate mode UIs that make use of compiled languages with good async. Animations become very easy. I think those more complicated UIs may work well with declarative frameworks.

I’m curious to see how you’re handling events. Best of luck!

1: https://github.com/elcritch/fidgetty

The node id path is interesting. I disabled it for performance reasons in Fidgetty since it wasn’t used, but was contemplating using it for a theming system similar to CSS. Do you have any ideas of combining declarative style UIs and CSS theme-ing?

Good luck! I sometimes wonder if it would be valuable to study the taxonomy of interactive software and compare/contrast the kind of architecture and data modeling best suited for each category. Perhaps the framing is too broad, but I often find myself wondering why an approach that clearly works great for my CRUD app can't really be generalized to effectively work with game state, or vice versa. (And part of me wonders if there's some yet-undiscovered paradigm that works remarkably well for almost every use case.)