Hacker News Reader

Comment by WhereIsTheTruth | Hacker News Reader

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 use Swift the UI

That's the advantage that should be advertised, Kotlin tried with Kotlin-Native, seems like a good strategy

View on HN

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 mention the extra wrapping layers your native code needs to smooth out the interactions between the shared and native layers.

For sure there are settings where it makes sense to take this approach, especially if code is shared across more than two platforms. But just for iOS and Android I wouldn’t necessarily say it’s a more efficient solution.

Working on such shared code is also pretty stressful. In a pure native codebase I can simply make the change and test it, but with shared code I have to worry about consequences across many platforms - did I just fix something on one platform only to introduce an issue on another?

  > Working on such shared code is also pretty stressful. In a pure native codebase I can simply make the change and test it, but with shared code I have to worry about consequences across many platforms - did I just fix something on one platform only to introduce an issue on another?

this is one of the biggest downsides

the other big one is the code → write → test → deploy scenario is extremely slow to the point of extreme frustration (at least for kotlin multiplatform anyways) with these kinds of tools

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

> If you continue reading the rest of the sentence

who stops reading a sentence in the middle?

I did not include Android or other stacks because I don't know about them (as I said, "not sure about other areas"). But for iOS it is not uncommon for developers to solely specialize in it, yet the comment claims it is uncommon. I wonder if you misread my comment or the one I replied to? Or perhaps the original comment is grammatically ambiguous.

They were saying that it's uncommon for a single developer to specialize in both iOS and Android

My wording could have been better - I meant that it’s uncommon for engineers to know both iOS and Android at a deep level. Sharing code can let you share a lot of your logic, but you still need to understand the native host environment well, in fact maybe even deeper than normal since you are using unconventional approaches.

So you need engineers that have this deep iOS experience, deep Android experience, and deep C++/rust experience. If you are a solo dev with this skillset then maybe it’s a good choice. But in a team / big company setting such an unconventional stack will always be a drag chute on your velocity in all stages of the project

> even something trivial like not being able to set breakpoints in the shared code

I think your overall point still stands, but you can setup breakpoints in Zig and have the normal tooling work correctly with it.

Second paragraph in OP:

> One approach to building a native GUI for a cross-platform application is to write all of the business logic in a cross-platform language (C, Rust, Zig, etc.) and then write the platform-specific GUI code. This is the approach I take with my my terminal emulator and it works really well. As of the current date writing this post, 93% of my repository is business logic in Zig and C, and 4% is macOS-specific GUI code in Swift.

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 does react represent the best we have managed to come up with?. I've used it as to me it kinda sucks but I have never worked on the UI side of anything except for small web frontends

I always just assumed that in the 40+ years there were some better UI libraries but apparently not?.

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 efficiently. By providing a description of how an interface should look given some program state, the developer only need be concerned with the flow of data, and the framework can automatically create and apply the delta to update the UI in the most efficient way. For example, there’s no possibility to forget to re-enable a button in that rarely-used code path, because the “enabled” state is derived from the rest of your app state and any changes to that automatically cascade downwards.

I’m not saying these things are a silver bullet (and I don’t even really do much UI stuff anymore), but when my job involved frontend web stuff, moving from jQuery to Vue was both an unbelievable jump in both productivity and a massive decrease in UI bugs (and LoC!).

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.

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

> In the history of GUI applications does react represent the best we have managed to come up with

tl;dr, yes.

Ignore the DSL syntax of React (or SwiftUI or whatever), and understand that React's model is that UI is a function of state. In my experience, being able to declare how your application should look given it's current state (and just let the engine figure out how to get there) is a significantly more productive.

This works very well with React on the Web because the primitives there are pretty basic, and there's a well understood way to break out back down to the imperative DOM APIs. Others (SwiftUI, WinUI XAML from my experience) haven't quite seem to have gotten the mix right yet, so you have a harder time once you need to do more complicated things.

SwiftUI (like React Web) has some really neat benefits from this - views can be serialized down and rendered without your application running. This is how lock+home screen widgets, and watch complications work - the app is intermittently asked to provide snapshots at certain points in time, which the OS serializes and shows later. This is easily possible with SwiftUI because it fundamentally is data.

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

Are you suggesting that Zig never lets you just think about the problem? That's some terrible preoccupation with an idealized concept of a DSL.

The swift code examples look kinda slick but it isn't a different paradigm any more than JSX is for building HTML.

It seems like a form of The Bipolar Lisp Programmer. https://www.marktarver.com/bipolar.html

> Lisp is like wielding an air gun with power and precision.

Those Swift examples you show are very exciting, but it's best not to get carried away. It's the same as those that say that vim is terrible because it's modal and don't believe that vim programmers can think about the problem while they're typing because their brain is distracted with switching between modes.

>"So the main advantage here would be to be able to consume your Zig code/libraries with your Swift application"

I've heard that BS from MS reps when they visited our company sometime in 90s. They were telling us how we should have monkeys drawing forms in VB and gurus making main code in C/C++. Then I showed them Delphi. You had to see how sour their faces turned.

>"You'll never be able to write that kind of code with Zig, or C or C++"

Your statement looks totally wrong. Looking at code seems like simple "fluent" notation that is quite possible in languages you mentioned.

"you could write your crossplatform app logic in Zig, and only use Swift the UI"

The UI glue code would be nothing special, and not improved by Swift vs Java. The UI would be designed in a design tool. I like open source, so perhaps Penpot.

Reply on news.ycombinator.com