Hacker News Reader

Comment by ironmagma | Hacker News Reader

I don’t have any hope for the incumbent OS players. They clearly can’t get their priorities straight, and it’s sad that even within these OS vendors the native application development platforms are rotting in favor of cloud and web investments. Think about it, .NET is being sunsetted in favor of .NET Core, but the latter still doesn’t have desktop support and shows no signs of it. SwiftUI is a total letdown from what I’ve heard. It is ripe for disruption, that’s why I’ve been studying OSDev ceaselessly of late and hope I can find some more OS-minded people to collaborate with.

View on HN

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

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.

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.

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.

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.

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

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.

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.

I'm not familiar with this, so googled it, and the third hit was skohan giving dire prophecies about it two years ago: https://news.ycombinator.com/item?id=21011917

You may be able to tell I am not much of a fan of FRP ;)

But to be fair, the comment you linked is not a prophecy it was a lamentation

How many years counts as the "couple in which everyone will figure this out" though?

Many people have already figured it out.

I would imagine a few years after SwiftUI becomes the primary UI stack used by iOS developers, many of them will be cursing Combine's name, as it will be clear most of the problems making iOS developers' lives difficult will be coming from FRP.

I'm sure the App Store, code signing, and bad dev docs will find a way to retain the lead.

Those are things you have to deal with once in a while, and largely cease to be issues once you get over the learning curve. Bad code is something you have to deal with day in and day out.

It’s a classic solution-looking-for-a-problem. Async/await is perfectly fine for state reaction, and the learning curve for FRP is enormous, especially for something as straightforward as exponential backoff.

https://github.com/alex-okrushko/backoff-rxjs

What is FRP?

Edit: Is it Factory Reset Protection?

https://en.wikipedia.org/wiki/Functional_reactive_programmin...

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.

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)

Did you ever try going all the way and using graphical layouts (Nibs/Storyboards)?

Yup. Storyboards were of course a huge improvement, but I could never get the hang of constraints.

Yeah fair enough - constraints can be really powerful, but they really do take some time and practice to wrap your head around.

I'm still looking for a full web frontend framework that uses constraints -- because yes, they are the best version of 'responsive' layouts ever.

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.

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.

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

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.

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

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

> NET is being sunsetted in favor of .NET Core, but the latter still doesn’t have desktop support and shows no signs of it.

What do you mean? You can build desktop Windows WPF or Winforms apps with the new .NET. There's also MAUI for cross-platform desktop apps.

I think parent is thinking of .NET Core 3 and doesn't realize that v5 and 6 add back many missing features and .NET Core is now just called .NET again.

Thanks for informing me. I hadn’t heard this so I’ll check these out.

You're welcome!

Yep. Probably the confusing name change threw him off the scent.

What would have been ".NET Core 5" is just ".NET 5", and that's when the bulk of the desktop framework compat came online.

Yeah. Someone could make a case study out of this for why marketing should not have final say on the names of technologies.

I think marketing was not involved there. I think some manager made the decision after talking to some CTO of customers. Same for the unfortunate MAUI naming. Both cases could have been prevented by a week of proper field research.

Reminder that Microsoft is trying to steal the name MAUI from an existing open source project.

Microsoft <3 Linux

https://github.com/dotnet/maui/issues/34

Reply on news.ycombinator.com