6 ms·

I’ve been writing SwiftUI lately and it’s the most productive GUI toolkit out there. Taylor Holliday of the Audulus fame is porting it to Rust https://github.

I’ve been writing SwiftUI lately and it’s the most productive GUI toolkit out there. Taylor Holliday of the Audulus fame is porting it to Rust https://github.com/audulus/rui https://github.com/audulus/rui

tayistay 4y ago
I'm the author of rui, in case anyone has questions :)
- sawaali 4y ago
  How different is the state managementin SwiftUI compared to the state in rui?
  - tayistay 4y ago
    I've built some of the same sort of primitives, albeit with different syntax. Rui's `state` function will give you a state handle allowing you to mutate state similarly to how @State works in SwiftUI. rui also has a notion of bindings, just like SwiftUI, and even environment. This is all great for defining state that's local to a widget, which I've seen some other reactive/declarative libraries struggle with actually. Rui doesn't have an equivalent of @ObservedObject, and it's not clear to me that it needs one because state values can be accessed by reference.
anonymouse008 4y ago
So I’m still not sold on SwiftUI, and I’m beginning to think I’m learning the wrong paradigms to “get it.” What would you say are the core concepts that make it click for you? Do you have any resources to recommend?
- adamnemecek 4y ago
  Did you watch any WWDC videos? Also the objc.io book on the topic is decent.
  - jen20 4y ago
    The videos from PointFree [1] are also excellent. [1]: https://pointfree.co https://pointfree.co
ohgodplsno 4y ago
Except for the part where components are locked to an iOS/macOS version. Still have to support iOS 13 ? Have fun basically doing everything with only VStacks. Compose at least makes it only a library bump away.
- andrekandre 4y ago
  > Compose at least makes it only a library bump away. this to me is the most annoying thing with regard to swiftui and apple development in general... especially considering swiftui views are mostly wrapping uiviews....
bowsamic 4y ago
I like SwiftUI, but somehow I still like UIKit and even AppKit a little more. Some things are still just slightly too broken in SwiftUI, for example navigation. In the WWDC talk when they introduced SwiftUI they said that we can let Apple do the work of making the UI just by listing what we need, but I don't trust Apple to do this yet.
- adamnemecek 4y ago
  You can go back and forth relatively easily. I think that even if most of your views are still NSViews/UIViews SwiftUI makes sense even just to hook them up. ViewControllers are an anti-pattern.
  - bowsamic 4y ago
    How are ViewController an anti-pattern? It depends how they're used, no? And yeah it's easy to use a SwiftUI view in AppKit or UIKit using a UIHostingController or NSHostingController
    - adamnemecek 4y ago
      A big part of what ViewControllers do is synching data. I think that bindings do a better job at this.
      - bowsamic 4y ago
        Bindings might be better but that doesn't necessarily mean that ViewControllers are an anti-pattern. Is there a better way to do it in an non-declarative OOP way?
        andrekandre 4y ago
        not the op but what i usually do is just write a plain-old-class with actions/outlets/delegate-methods and place those in the storyboard/xib if you are programmatically doing it, then you can just init it directly or use some injection/indirection mechanism you can use the responder chain to send messages up to the nearest view controller if you need to, and if you need some lifecycle awareness, you can always delegate those from the view controller in various ways (protocols, notifications etc) testing is also easier since they are plain objects with a few methods on them (just fill in their outlets with mocks and you are ready)
copperx 4y ago
Yours is the first positive comment I read on HN about SwiftUI.
- adamnemecek 4y ago
  Why are people complaining? That it’s buggy or that it’s fundamentally flawed?
  - Pulcinella 4y ago
    It can be very buggy (even on iOS 15), especially when you start doing anything complicated. It’s also still relatively new compared to UIKit and AppKit, so it can be hard to tell if something is not working because you aren’t doing it right or if there is a legitimate bug. It’s missing a lot of features that are currently in UIKit and the way that views are structs and it’s a declarative UI means it can be hard to add custom UI and work around missing features. You have to wait for Apple’s developers to implement things. In UIKit you can just start overriding things (even if you probably shouldn’t). Also in my experience performance can be awful in ways you can’t work around or fix easily, if at all. e.g. The framework is supposed to diff and determine if things have changed, if two views are equivalent, etc. This can slower than just forcing the system to consider everything changed and nothing is equivalent so it should reload everything. This might be a bug, but sometimes this diffing can happen even when you change nothing. Ive gotten incredibly stuttery performance when scrolling. When I hook it up to the performance analyzer I see it’s trying to diff the whole screen multiple times every frame for static, scrolling content. But this only happens with finger scrolling. Programmatic scrolling (e.g. with the crown in the watch) doesn’t do this and is stutter free. Finally, Xcode support is bad. It still gives inscrutable errors (that are usually just a misplaced parenthesis or brace) and the type inference system can peg up the CPU at 100% CPU (and then the system will throw up its hands that the type is too complicated to figure out.) Prototyping in SwiftUI is so, so much faster than in UIKit though.
    - Escapado 4y ago
      To add to the list: Coming from the web and being used to having a ton of control how every thing looks I found that customizing elements sometimes have surprising limitations in SwiftUI. Also be wary of trying anything UX wise which is non-conformant with the official spec. Also xcode in general is such a bizarre IDE compared to the IDEA products or even VSCode which I felt was limiting me severely, even after making quite some effort to adjust and learn shortcuts. I also found that the screen/component preview was just so inconsistent, performance hungry and slow that I stopped using it pretty quickly. I want to like SwiftUI but it feels too rough around the edges for me so I guess I'll check back in a year. I tried flutter after and it was SO much less painful, more/easier customizable and tooling felt heaps better.
Ygg2 4y ago
First time I see it, pretty nice framework. Rust needs more of those.
- raphlinus 4y ago
  Watch this space. Specifically I am writing up my ideas for a fusion of SwiftUI and Druid, inspired in large part by Taylor's work on rui. This work is conceptual at the moment, not a finished product, but I am hopeful it will be a better direction for UI in Rust.

tayistay 4y ago

I'm the author of rui, in case anyone has questions :)

sawaali 4y ago
How different is the state managementin SwiftUI compared to the state in rui?
- tayistay 4y ago
  I've built some of the same sort of primitives, albeit with different syntax. Rui's `state` function will give you a state handle allowing you to mutate state similarly to how @State works in SwiftUI. rui also has a notion of bindings, just like SwiftUI, and even environment. This is all great for defining state that's local to a widget, which I've seen some other reactive/declarative libraries struggle with actually. Rui doesn't have an equivalent of @ObservedObject, and it's not clear to me that it needs one because state values can be accessed by reference.

anonymouse008 4y ago

So I’m still not sold on SwiftUI, and I’m beginning to think I’m learning the wrong paradigms to “get it.” What would you say are the core concepts that make it click for you? Do you have any resources to recommend?

adamnemecek 4y ago
Did you watch any WWDC videos? Also the objc.io book on the topic is decent.
- jen20 4y ago
  The videos from PointFree [1] are also excellent. [1]: https://pointfree.co https://pointfree.co

ohgodplsno 4y ago

Except for the part where components are locked to an iOS/macOS version. Still have to support iOS 13 ? Have fun basically doing everything with only VStacks. Compose at least makes it only a library bump away.

andrekandre 4y ago
> Compose at least makes it only a library bump away. this to me is the most annoying thing with regard to swiftui and apple development in general... especially considering swiftui views are mostly wrapping uiviews....

bowsamic 4y ago

I like SwiftUI, but somehow I still like UIKit and even AppKit a little more. Some things are still just slightly too broken in SwiftUI, for example navigation. In the WWDC talk when they introduced SwiftUI they said that we can let Apple do the work of making the UI just by listing what we need, but I don't trust Apple to do this yet.

adamnemecek 4y ago
You can go back and forth relatively easily. I think that even if most of your views are still NSViews/UIViews SwiftUI makes sense even just to hook them up. ViewControllers are an anti-pattern.
- bowsamic 4y ago
  How are ViewController an anti-pattern? It depends how they're used, no? And yeah it's easy to use a SwiftUI view in AppKit or UIKit using a UIHostingController or NSHostingController
  - adamnemecek 4y ago
    A big part of what ViewControllers do is synching data. I think that bindings do a better job at this.
    - bowsamic 4y ago
      Bindings might be better but that doesn't necessarily mean that ViewControllers are an anti-pattern. Is there a better way to do it in an non-declarative OOP way?
      - andrekandre 4y ago
        not the op but what i usually do is just write a plain-old-class with actions/outlets/delegate-methods and place those in the storyboard/xib if you are programmatically doing it, then you can just init it directly or use some injection/indirection mechanism you can use the responder chain to send messages up to the nearest view controller if you need to, and if you need some lifecycle awareness, you can always delegate those from the view controller in various ways (protocols, notifications etc) testing is also easier since they are plain objects with a few methods on them (just fill in their outlets with mocks and you are ready)

copperx 4y ago

Yours is the first positive comment I read on HN about SwiftUI.

adamnemecek 4y ago
Why are people complaining? That it’s buggy or that it’s fundamentally flawed?
- Pulcinella 4y ago
  It can be very buggy (even on iOS 15), especially when you start doing anything complicated. It’s also still relatively new compared to UIKit and AppKit, so it can be hard to tell if something is not working because you aren’t doing it right or if there is a legitimate bug. It’s missing a lot of features that are currently in UIKit and the way that views are structs and it’s a declarative UI means it can be hard to add custom UI and work around missing features. You have to wait for Apple’s developers to implement things. In UIKit you can just start overriding things (even if you probably shouldn’t). Also in my experience performance can be awful in ways you can’t work around or fix easily, if at all. e.g. The framework is supposed to diff and determine if things have changed, if two views are equivalent, etc. This can slower than just forcing the system to consider everything changed and nothing is equivalent so it should reload everything. This might be a bug, but sometimes this diffing can happen even when you change nothing. Ive gotten incredibly stuttery performance when scrolling. When I hook it up to the performance analyzer I see it’s trying to diff the whole screen multiple times every frame for static, scrolling content. But this only happens with finger scrolling. Programmatic scrolling (e.g. with the crown in the watch) doesn’t do this and is stutter free. Finally, Xcode support is bad. It still gives inscrutable errors (that are usually just a misplaced parenthesis or brace) and the type inference system can peg up the CPU at 100% CPU (and then the system will throw up its hands that the type is too complicated to figure out.) Prototyping in SwiftUI is so, so much faster than in UIKit though.
  - Escapado 4y ago
    To add to the list: Coming from the web and being used to having a ton of control how every thing looks I found that customizing elements sometimes have surprising limitations in SwiftUI. Also be wary of trying anything UX wise which is non-conformant with the official spec. Also xcode in general is such a bizarre IDE compared to the IDEA products or even VSCode which I felt was limiting me severely, even after making quite some effort to adjust and learn shortcuts. I also found that the screen/component preview was just so inconsistent, performance hungry and slow that I stopped using it pretty quickly. I want to like SwiftUI but it feels too rough around the edges for me so I guess I'll check back in a year. I tried flutter after and it was SO much less painful, more/easier customizable and tooling felt heaps better.

Ygg2 4y ago

First time I see it, pretty nice framework. Rust needs more of those.

raphlinus 4y ago
Watch this space. Specifically I am writing up my ideas for a fusion of SwiftUI and Druid, inspired in large part by Taylor's work on rui. This work is conceptual at the moment, not a finished product, but I am hopeful it will be a better direction for UI in Rust.