Comment by archagon | Hacker News Reader

Comment by archagon | Hacker News Reader

Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would need explicit state and imperative code at the center of it all, and that a declarative approach would require hacks and workarounds at every turn. In my humble opinion, some of the most interesting, ground-breaking, and creative software has these properties; whereas this reactive stuff seems tailored to bog-standard utility software.

However: I've never used React or any of its derivatives, so this is mostly inference. Is this take accurate or not? In theory, could you scale SwiftUI to build something like Logic, Blender, or Photoshop (for example)?

Also, have any declarative UI frameworks been released that feature a "platform" layer, where you get to define how your declarative code actually turns into UI, widgets, and behaviors? It seems that SwiftUI relies on (encoded) assumptions of what an ideal UIKit or AppKit app is supposed to look and feel like, and it would be really powerful if we could mess with this foundation or even swap it out entirely.

(It's very possible I'm mixing up reactive/declarative/reactive-UI concepts since I'm not too familiar with the territory.)

I can only speak for React, but the declarative component model doesn't eliminate state or imperative code, it just nudges you towards separating your stateful code from your layout/rendering code. In the React/Redux convention, your application is one big state machine with transitions encoded in reducers, and your state -> view data transformations in "selectors". View components are composed into one big pure function of state. Putting barriers between those classes of functionality makes it much easier to compose complex behavior from small, focused functions. Obviously you can write code with those properties in any context, but conventional React/Redux architecture makes the lines more explicit, which is why I like it. Lots of people hate it.

"However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing"

Honestly, this is something I've been struggling with coming to terms to for a while.

Really, what mobile app isn't just a CRUD thing? Literally every 3rd party app I can think of on my phone talks to some REST service in some way. Even the video games, photo editors, notes apps, etc. They all use the cloud where the cloud contains most of the business logic and the app is a thin visual client proxying the data.

You could argue that, for example, a first person shooter is not CRUD heavy. But after the match, when you're looking at leaderboards or sending friend requests or chatting with your friends in the lobby...guess where that UI is updating from?

Yep, another CRUD API. It's everywhere. I really want someone to prove me wrong because I want to expand my horizons - what the hell isn't a CRUD thing these days, other than completely offline apps?

I feel like CRUD can be a simplistic categorisation at times. Take a look at the Slack app, for example. It's got chat messages. Also rich media. And threading. And user profiles. And notifications. But each of those is "just" CRUD. That doesn't mean it's a walk in the park. By broad definition just about every piece of software ever created is CRUD.

"The dirty secret:

We’re all just building CRUD apps."

https://twitter.com/iamdevloper/status/455409190505562112

I’m working on a realtime video conferencing service. Lots of long running connections with state updated by streamed events. React works pretty well for this use case imho. Not a lot of CRUD there.

Adobe uses a declarative UI system, and what they call a 'property model', which apparently successfully reduced their UI code by a factor of over 500. The system is available here:

https://stlab.adobe.com/group__asl__overview.html

Fascinating! (And on reflection, Blender probably does something similar, since it's super modular and practically every field is in perfect sync with the view and the data.)

It's very interesting! The 'property model' was apparently a real research project, which adds an additional ingredient over and above most systems in common use:

> The combination of procedural and declarative program code has found success in, for example, GUI element layout. The most familiar example is perhaps HTML, CSS, and DOM combined with JavaScript. The QTk library [12] in Mozart/Oz, Glade [7],XUL [16], XAML [34], and XForms [5] serve as further examples. Some of these systems, along with rule-based systems such as Drools [27], Jess [11], and R++ [14], also support concisely specifying declarative rules for maintaining consistency across values in user interfaces. Property models are distinguished from these systems by not only providing the ability to create rules that assist introducing a valid result but also by providing an explicit model of the dependencies these rules create. Inspecting the state of the model enables generic algorithms (e.g., for widget enablement) for user interface.

http://www.emarcus.org/papers/gpce2009-marcus.pdf

Every software needs explicit state. If React is any indication, it tells us that the management of this explicit state can be made much more pleasant when written in a declarative way.

I disagree. I'd argue React is most useful when doing something highly interactive.

There's nothing stopping you from writing imperative, side-effect heavy code. But it's something you deliberately opt into, usually on the edges of the program, rather than something you have to deal with by default. Absolutely nothing about React discourages this.

Take most of the Adobe creative suite as an example. Different paradigms will fit different aspects of the UI design. Nobody wants to expend the same effort to build CRUDs as they would when they're working on "groundbreaking" stuff. Reality is a bit more nuanced: you want to abstract as much as possible and make it trivial, so that you can focus most energy where it matters. Patterns/Language/Frameworks all come into play here, and SwiftUI is a beautiful addition.

SwiftUI has state. The idea is that all layout code is defined as a pure function of the state. Basically you can annotate properties with `@State` and each time one of those properties is updated, your view `body` function is re-run to produce an updated view.

SwiftUI tries to do clever stuff under the hood to only update the portions of the view hierarchy affected by the state change for performance.

If you combine a declarative UI like SwiftUI and a reactive logic like RxSwift, you can get very far, while keeping things separated and simple. Not only for CRUD apps, but for big complex apps too.

Don’t use it with RxSwift, use it with Swift Combine! https://developer.apple.com/documentation/combine

Agreed... especially in React Native. You quickly run into a wall for some more advanced things because of how it's designed. (Mostly imperative actions/animations, etc)

Xcode Previews are written in SwiftUI; you can definitely write real apps with it.

Reply on news.ycombinator.com