6 ms·

[Edit: I might be the worst developer on the planet, so take it all with a grain of fine salt] Yup, hot take: SwiftUI is hot garbage. Declarative rendering is

[Edit: I might be the worst developer on the planet, so take it all with a grain of fine salt] Yup, hot take: SwiftUI is hot garbage. Declarative rendering is the worst rendering: it's code written that doesn't have to be written. The beautiful thing about UIKit, NSLayout, and Storyboards, is that when used effectively, not much UI code has to be written, and when it does, it matters. Now everything has to be written to hells end. And not only do I need a mental diagram of my UI in rendered state, I need it in code state as well. If someone could enlighten me, I would gladly take the lesson. Edit: I'm very happy I posted this to learn. I used UITextViews extensively in my only app development, and was extremely frustrated with SwiftUIs readiness on that front. That said, I still like that my code can reflect the 'flow of thought' rather than the strictness of the UI when developing. I guess a lot of the property wrappers got to me too And all the improvements given to declarative rendering could be embodied in updates to Storyboards and the like.

ironmagma 5y ago
I think declarative rendering has definite value. When you aren’t using it, you end up having to track your own dirty flags, and often that means you will neglect to update them properly, leading to inconsistent UI. CPUs are fast now, there is no reason to not be doing a few extra tree comparisons if it eliminates bugs and speeds up the development process. The criticisms I’ve heard of SwiftUI come from a guy who absolutely loved React. I think the problems are unrelated to the overall idea of declarative rendering being flawed.
- whizzter 5y ago
  100% Agreed, I have one desktop program I wrote that has something approaching the same kind of complexity level as a 3D modelling/animation program and with plugins and concurrent updates coming in from the network the state management was just a tedious AND complex mess that caused a ton of bugs. Since I wrote it (about 10 years ago), I've spent a fair bit of time writing React(and Vue) code and about 90% of the issues would've gone away (and no, this isn't just hindsight, I would've probably re-created many of the same issues and spent a big chunk of time on tedious code if I used the same framework again). Sadly, the options for something that supports OpenGL and works with declarative rendering are slim on the desktop.
bjtitus 5y ago
I'm a bit confused by this take so my apologies if I'm missing the point. SwiftUI leans far more in the direction of declarative layouts with very little actual code required. It defaults to bottom up sizing so that view sizes are based on their contents and automatically uses default system spacing for basic layout tasks. The only comparable thing in UIKit is UIStackView. In fact, UIStackView was clearly added to reduce the explicit constraint layout code required for simple layouts. While you don't "write" UI code with Storyboards, it's certainly there, just encoded into a non human readable format. SwiftUI has many problems (mainly bugginess and missing APIs) but I don't see how the old APIs required "not much UI code ... to be written". If anything, this is one of the primary benefits of SwiftUI: getting to remove most of the explicit layout code and complex type system required to do basic layout tasks with UIKit or AppKit.
skohan 5y ago
Declarative rendering has a lot of advantages in terms of composability. My main issue with SwiftUI is that the tooling just doesn't seem ready at all. I tried a small project recently, and the preview feature basically doesn't work. Also I think the decision to make combine a core building block of Apple UI development is a huge mistake. FRP is a plague on the industry, and everyone is going to figure that out in a couple years.
- mlajtos 5y ago
  > FRP is a plague on the industry, and everyone is going to figure that out in a couple years. Why is FRP/Combine bad? What is better?
  - skohan 5y ago
    It's bad because it obscures flow-of-control from the programmer and surrenders it to a large opaque system. In some cases it makes things a little bit easier, but when things go wrong it's a nightmare because your stack traces are no longer meaningful and flow of control is at arm's length and it's not easy to trace who's calling what. Not that it can't be handled well or used to good effect, but the idea of wandering into an unfamiliar FRP-based codebase which has been in the hands of multiple non-expert maintainers over a couple years is really the stuff of nightmares. edit: answering what's better Normal flow of control is better. You want to be able to look at a function, and see which functions are called from inside that function. And you want to be able to search all instances and see every place where a function is used. You don't want to have some black-box scheduler who's calling all your functions for you. That's how you end up with mysterious action at a distance, becuase you didn't know about the extra subscriber your colleague put on a publisher somewhere else in the codebase, or something strange happening because of an order-of-operations issue which is difficult to understand.
    - mlajtos 5y ago
      Aren't result builders just function calls with implicit do-notation? I kinda agree that SwiftUI runtime uses a lot of opaque magic and documentation is still under-par. However, I am very glad Apple went the React way – I tried UIKit after I was writing React for few years and it felt very dated and laborious. Yeah, React isn't FRP, but declarative UI with code FTW.
woah 5y ago
If you don't have declarative rendering, you have imperative rendering with stuff like `canvas.drawLine()` etc. (just a made up example). This code tends to be very annoying to write and maintain because you need to do a lot of building up of elements and tracking the state of them yourself. What you are referring to with UIKit, NSLayout, and Storyboards is in fact declarative rendering, but the layout code can only be modified with a point and click editor. In most people's opinions, editing code directly is much more controllable and works better for systems like Git.
- deleted 5y ago
  [deleted]
Eric_WVGG 5y ago
I found “the old way” of doing things to be a mess. Despite building one of the first apps in the App Store, NSLayout just never became “second nature.” Instead of the native app world, I stuck to web front ends and managed that awkward transition from jQuery to Angular to React. These models for UI made increasing amounts of sense — instead of fiddling with weird lines a slop gui, I could just tell the system what I want and get it! Then SwiftUI came along, and lo, I get all the goodness of React in iOS and even MacOS! My first native app in years is coming along swimmingly, and it’s even cross platform! (yes, I did do an app in React Native, and found it gross for reasons that I can’t put my finger on)
- skohan 5y ago
  Did you ever try going all the way and using graphical layouts (Nibs/Storyboards)?
  - Eric_WVGG 5y ago
    Yup. Storyboards were of course a huge improvement, but I could never get the hang of constraints.
    - skohan 5y ago
      Yeah fair enough - constraints can be really powerful, but they really do take some time and practice to wrap your head around.
      - anonymouse008 5y ago
        I'm still looking for a full web frontend framework that uses constraints -- because yes, they are the best version of 'responsive' layouts ever.
        nodemaker 5y ago
        Yeah one of the reasons I refuse to do SwiftUI is I want to do my layout in constraints. Its also how my head thinks when I think about layouts, and also probably why I never enjoyed web dev and got into it.
newaccount74 5y ago
I've recently attempted to use Swift UI for a very simple Mac app, and I have to concur: Swift UI is garbage. The syntax is incomprehensible and inconsistent, the documentation is ridiculous, the feature set is severly lacking, and worst of all it's unbelievably slow. I have the fastest processor that Apple sells and a proof-of-concept app that I made in a few hours that consists of three Swift files takes 30 seconds to compile. I can't imagine what building non-trivial apps with it wouldbe like.
- andrekandre 5y ago
  > I can't imagine what building non-trivial apps with it wouldbe like. lets just say you will be making quite a few pots of coffee...
krzat 5y ago
Declarative UI works amazingly well when done properly (see Flutter). But Apple has a tendency to half-ass development tools, so it is what it is.
nodemaker 5y ago
Couldnt agree more with your core argument. Declarative rendering is way more mental overhead than procedural rendering. Designing a system is more about the "how" than the "what".
- ironmagma 5y ago
  That seems crazy to me. When designing a window, the first thing you decide is what you want on it -- a button, a text box. It's the most obvious thing about the program. How you do it, that's a completely different matter, and definitely not the most important part until and unless you are dealing with performance limitations (which should typically not pop up until later).

ironmagma 5y ago

I think declarative rendering has definite value. When you aren’t using it, you end up having to track your own dirty flags, and often that means you will neglect to update them properly, leading to inconsistent UI. CPUs are fast now, there is no reason to not be doing a few extra tree comparisons if it eliminates bugs and speeds up the development process. The criticisms I’ve heard of SwiftUI come from a guy who absolutely loved React. I think the problems are unrelated to the overall idea of declarative rendering being flawed.

whizzter 5y ago
100% Agreed, I have one desktop program I wrote that has something approaching the same kind of complexity level as a 3D modelling/animation program and with plugins and concurrent updates coming in from the network the state management was just a tedious AND complex mess that caused a ton of bugs. Since I wrote it (about 10 years ago), I've spent a fair bit of time writing React(and Vue) code and about 90% of the issues would've gone away (and no, this isn't just hindsight, I would've probably re-created many of the same issues and spent a big chunk of time on tedious code if I used the same framework again). Sadly, the options for something that supports OpenGL and works with declarative rendering are slim on the desktop.

bjtitus 5y ago

I'm a bit confused by this take so my apologies if I'm missing the point. SwiftUI leans far more in the direction of declarative layouts with very little actual code required. It defaults to bottom up sizing so that view sizes are based on their contents and automatically uses default system spacing for basic layout tasks. The only comparable thing in UIKit is UIStackView. In fact, UIStackView was clearly added to reduce the explicit constraint layout code required for simple layouts. While you don't "write" UI code with Storyboards, it's certainly there, just encoded into a non human readable format. SwiftUI has many problems (mainly bugginess and missing APIs) but I don't see how the old APIs required "not much UI code ... to be written". If anything, this is one of the primary benefits of SwiftUI: getting to remove most of the explicit layout code and complex type system required to do basic layout tasks with UIKit or AppKit.

skohan 5y ago

Declarative rendering has a lot of advantages in terms of composability. My main issue with SwiftUI is that the tooling just doesn't seem ready at all. I tried a small project recently, and the preview feature basically doesn't work. Also I think the decision to make combine a core building block of Apple UI development is a huge mistake. FRP is a plague on the industry, and everyone is going to figure that out in a couple years.

mlajtos 5y ago
> FRP is a plague on the industry, and everyone is going to figure that out in a couple years. Why is FRP/Combine bad? What is better?
- skohan 5y ago
  It's bad because it obscures flow-of-control from the programmer and surrenders it to a large opaque system. In some cases it makes things a little bit easier, but when things go wrong it's a nightmare because your stack traces are no longer meaningful and flow of control is at arm's length and it's not easy to trace who's calling what. Not that it can't be handled well or used to good effect, but the idea of wandering into an unfamiliar FRP-based codebase which has been in the hands of multiple non-expert maintainers over a couple years is really the stuff of nightmares. edit: answering what's better Normal flow of control is better. You want to be able to look at a function, and see which functions are called from inside that function. And you want to be able to search all instances and see every place where a function is used. You don't want to have some black-box scheduler who's calling all your functions for you. That's how you end up with mysterious action at a distance, becuase you didn't know about the extra subscriber your colleague put on a publisher somewhere else in the codebase, or something strange happening because of an order-of-operations issue which is difficult to understand.
  - mlajtos 5y ago
    Aren't result builders just function calls with implicit do-notation? I kinda agree that SwiftUI runtime uses a lot of opaque magic and documentation is still under-par. However, I am very glad Apple went the React way – I tried UIKit after I was writing React for few years and it felt very dated and laborious. Yeah, React isn't FRP, but declarative UI with code FTW.

woah 5y ago

If you don't have declarative rendering, you have imperative rendering with stuff like `canvas.drawLine()` etc. (just a made up example). This code tends to be very annoying to write and maintain because you need to do a lot of building up of elements and tracking the state of them yourself. What you are referring to with UIKit, NSLayout, and Storyboards is in fact declarative rendering, but the layout code can only be modified with a point and click editor. In most people's opinions, editing code directly is much more controllable and works better for systems like Git.

deleted 5y ago
[deleted]

Eric_WVGG 5y ago

I found “the old way” of doing things to be a mess. Despite building one of the first apps in the App Store, NSLayout just never became “second nature.” Instead of the native app world, I stuck to web front ends and managed that awkward transition from jQuery to Angular to React. These models for UI made increasing amounts of sense — instead of fiddling with weird lines a slop gui, I could just tell the system what I want and get it! Then SwiftUI came along, and lo, I get all the goodness of React in iOS and even MacOS! My first native app in years is coming along swimmingly, and it’s even cross platform! (yes, I did do an app in React Native, and found it gross for reasons that I can’t put my finger on)

skohan 5y ago
Did you ever try going all the way and using graphical layouts (Nibs/Storyboards)?
- Eric_WVGG 5y ago
  Yup. Storyboards were of course a huge improvement, but I could never get the hang of constraints.
  - skohan 5y ago
    Yeah fair enough - constraints can be really powerful, but they really do take some time and practice to wrap your head around.
    - anonymouse008 5y ago
      I'm still looking for a full web frontend framework that uses constraints -- because yes, they are the best version of 'responsive' layouts ever.
      - nodemaker 5y ago
        Yeah one of the reasons I refuse to do SwiftUI is I want to do my layout in constraints. Its also how my head thinks when I think about layouts, and also probably why I never enjoyed web dev and got into it.

newaccount74 5y ago

I've recently attempted to use Swift UI for a very simple Mac app, and I have to concur: Swift UI is garbage. The syntax is incomprehensible and inconsistent, the documentation is ridiculous, the feature set is severly lacking, and worst of all it's unbelievably slow. I have the fastest processor that Apple sells and a proof-of-concept app that I made in a few hours that consists of three Swift files takes 30 seconds to compile. I can't imagine what building non-trivial apps with it wouldbe like.

andrekandre 5y ago
> I can't imagine what building non-trivial apps with it wouldbe like. lets just say you will be making quite a few pots of coffee...

krzat 5y ago

Declarative UI works amazingly well when done properly (see Flutter). But Apple has a tendency to half-ass development tools, so it is what it is.

nodemaker 5y ago

Couldnt agree more with your core argument. Declarative rendering is way more mental overhead than procedural rendering. Designing a system is more about the "how" than the "what".

ironmagma 5y ago
That seems crazy to me. When designing a window, the first thing you decide is what you want on it -- a button, a text box. It's the most obvious thing about the program. How you do it, that's a completely different matter, and definitely not the most important part until and unless you are dealing with performance limitations (which should typically not pop up until later).