Live data from Hacker News

Integrating Zig and SwiftUI

mitchellh.com

31–40 of 58 posts

Re: Integrating Zig and SwiftUI

#31
post #30

IMHO that’s one of the main benefits of following the Model-View-ViewModel architecture pattern for GUIs. You can have all the models and viewmodels defined in a platform agnostic library, and your views are the only thing to implement in a platform specific way. The core library can be implemented in any language, you just need a way to call methods and setters when the user interacts, and handle update events to up…

This seems like a really good idea! But at second glance, won’t differences between the UI designs on different platforms require subtly different viewmodels for each platform?

Not if you make the exqct same UI on each platform I bet, but if you do that, you might as well use something like Flutter or React Native and only code the whole thing once, no?

Re: Integrating Zig and SwiftUI

#32

SwiftUI shines because you get to write Swift code and embrace the DSL You'll never be able to write that kind of code with Zig, or C or C++, it's impossible: https://github.com/amosgyamfi/open-swiftui-animations So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application, and that does look interesting, so you could write your crossplatform app logic in Zig, and only…

The downside of this kind of strategy is that for an engineer to work on it, they need to be proficient in iOS, Android, and zig/c/c++. It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack. Another issue is maintenance and debugging - even something trivial like not being able to set breakpoints in the shared code can be a significant slowdown to an engineer. Not to me…

> It’s somewhat uncommon to have engineers known just iOS

This is very common in the iOS world. Not sure about other areas.

Re: Integrating Zig and SwiftUI

#33

Earlier quoted context omitted.

The main benefit of declarative UI frameworks is that they remove the need to manually reconcile changes in state with changes in the representation of that state (with the caveat that it often becomes difficult to do so if the DSL doesn’t cover the behaviour you want). UIs inherently have a hell of a lot of state that is constantly in flux, so it can become very difficult to manage those transitions correctly and ef…

DSL stands for Domain Specific Language, not declarative. It is possible to be declarative without a hybrid DSL like JSX. Angular is declarative, but it doesn't mix html structures and js in the same way.

I wonder if you responded to the wrong comment.

Re: Integrating Zig and SwiftUI

#34
post #33

Earlier quoted context omitted.

DSL stands for Domain Specific Language, not declarative. It is possible to be declarative without a hybrid DSL like JSX. Angular is declarative, but it doesn't mix html structures and js in the same way.

I wonder if you responded to the wrong comment.

It's the one I intended to respond to. React isn't declarative in a new way. Backbone.js popularized declarative event bindings long before it. It is a bit of a unique DSL though.

Re: Integrating Zig and SwiftUI

#35
post #33

Earlier quoted context omitted.

I wonder if you responded to the wrong comment.

It's the one I intended to respond to. React isn't declarative in a new way. Backbone.js popularized declarative event bindings long before it. It is a bit of a unique DSL though.

It was odd because the comment you were responding to does not make the point that you seem to be debating against.

Re: Integrating Zig and SwiftUI

#36

SwiftUI shines because you get to write Swift code and embrace the DSL You'll never be able to write that kind of code with Zig, or C or C++, it's impossible: https://github.com/amosgyamfi/open-swiftui-animations So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application, and that does look interesting, so you could write your crossplatform app logic in Zig, and only…

React native and all these similar DSLs always seemed like a bad idea to me. I can forgive it on the web as you have no other choice than to use the 3 broken pillars which is html, css, and js and build your sand castles on top of that. I wonder though, was the development of swift UI influenced by the abundance of react developers or is this what peak UI development looks like?. In the history of GUI applications do…

I suspect it would be influenced more by QML than React. Why jump to the conclusion that it's React?

Re: Integrating Zig and SwiftUI

#37
post #30

IMHO that’s one of the main benefits of following the Model-View-ViewModel architecture pattern for GUIs. You can have all the models and viewmodels defined in a platform agnostic library, and your views are the only thing to implement in a platform specific way. The core library can be implemented in any language, you just need a way to call methods and setters when the user interacts, and handle update events to up…

This seems like a really good idea! But at second glance, won’t differences between the UI designs on different platforms require subtly different viewmodels for each platform? Not if you make the exqct same UI on each platform I bet, but if you do that, you might as well use something like Flutter or React Native and only code the whole thing once, no?

Yes, there are differences between platforms, complicating the picture a bit. There is a bit of a trade off/judgement calls when deciding what needs to be in the core library and what to keep on the platform specific code. You can always wrap a shared view model with a more specific one if you have to account for a few differences, or just decide to keep a bit of logic in the view. If you have >80% of your viewmodels that can be shared between platforms, MVVM can be really useful (just my own rule of thumb). If you have more differences between platforms I guess you will want to try something else.

Regarding Flutter, then yes I agree with you, their approach is different, it’s more adapted if you want to design a single UI that will be rendered the same on every platform, without relying on native controls.

Re: Integrating Zig and SwiftUI

#38
post #32

Earlier quoted context omitted.

The downside of this kind of strategy is that for an engineer to work on it, they need to be proficient in iOS, Android, and zig/c/c++. It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack. Another issue is maintenance and debugging - even something trivial like not being able to set breakpoints in the shared code can be a significant slowdown to an engineer. Not to me…

> It’s somewhat uncommon to have engineers known just iOS This is very common in the iOS world. Not sure about other areas.

Why did you break off mid-sentence? If you continue reading the rest of the sentence, you will see that they are saying the opposite of what you think they are:

> It’s somewhat uncommon to have engineers known just iOS and Android, let alone a 3rd language / stack.

Re: Integrating Zig and SwiftUI

#39
this approach gets me really interested. What are the improvements i should expect in zig compared to C ? And how does zig stdlib compare to something like the go stdlib ( which to me remains the gold standard)

Re: Integrating Zig and SwiftUI

#40
post #39

this approach gets me really interested. What are the improvements i should expect in zig compared to C ? And how does zig stdlib compare to something like the go stdlib ( which to me remains the gold standard)

>What are the improvements i should expect in zig compared to C ?

https://ziglang.org/learn/overview/

>And how does zig stdlib compare to something like the go stdlib

the stdlib is still work in progress and not the current focus of development. right now things get added to it organically (ie things needed by the compiler itself, the toolchain, or as a proof of concept for other important functionality, like an event loop). as we move forward we will have a phase where we make a final decision on what should stay in, what should be improved, and and what should be cut.

In the meantime you can quickly get a feel for what's in the stdlib by browsing the online docs:

https://ziglang.org/documentation/master/std/

Post reply on HN