Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SwiftUI After 7 Years

ykvm.com

Post reply on HN
Print view View original

211–220 of 343 posts

Re: SwiftUI After 7 Years

#211

Post by stasomatic »

brnt wrote: post #42
rayiner wrote: post #3

The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't. Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is…

I only have to look at the iPhone fucking 17 to know Apple is long gone.

Where?

Re: SwiftUI After 7 Years

#213

Post by ransom1538 »

rayiner wrote: post #3

The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't. Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is…

"ship a true successor to Win32 suggests that Microsoft"

Because it was good.

Re: SwiftUI After 7 Years

#215

Post by mbishop »

sirwhinesalot wrote: post #165
rayiner wrote: post #3

The problem with complex systems is that you can be dead long before you realize you're dead. Things can continue to seem "pretty good" for a long time just from the inertia of past good decisions and built-up infrastructure. You see some fraying or cracks but everything looks fundamentally sound, until it isn't. Apple's inability to deploy a new UI framework that's better than the previous one is troubling. This is…

The problem with ObjC was mainly syntax, bolted on over many years on top of a C core. It was grown rather than designed, and it shows. But there's nothing wrong with the runtime. Swift should have just been a much improved syntax over that same runtime. It would have avoided so many headaches. For one they wouldn't have made the awful decision to have return-type overloading and completely ruin the typechecker's per…

Gotta take issue with the characterization of “bolted on”. That’s a design feature and it’s huge. It made interoperability trivial. You can write C, C++, and Objective-C within the same source file.

Re: SwiftUI After 7 Years

#216

Post by dminik »

torginus wrote: post #203
dminik wrote: post #186

Earlier quoted context omitted.

Stuff like virtualization (if we're talking about stuff like virtualized lists) is hard not because of React, but because there just isn't any support for it in browsers. React doesn't really help here, but in my experience, it's usually the browser that starts choking on high element counts, not React. Async is just difficult in general though. It's not really a surprise that most libraries/frameworks converged on s…

I am talking about virtualized lists. And it should be a framework feature. I used to use WPF on desktop, and it had pretty good virtualization support (though the framework in general was more like Angular) - most containers had virtualization support, and you only had to implement the logic on the data source, and they framework created and managed physical UI elements for you, and managed the mapping so it seemed…

I mean, it's not quite that easy. The web is a lot more dynamic than WPF. If you just want virtualized homogeneous lists, there are libraries for that (and grids).

But, once you start hitting things like differently sized elements, search and so on, you start running into platform limitations that you won't be able to resolve in React land.

Re: SwiftUI After 7 Years

#217

Post by dminik »

il-b wrote: post #164
mintflow wrote: post #115

As a solo app developper for two years mainly for apple platform(previously do networking infra software using C/Go) After two many trial and fail, now it's quite clear to me that for simple UI I will use swiftUI(such as help sheet or simple toggles), for complex and performance first, I will just use UIKit instead, it save a log of time and actually the imperative UIKit is also quite easy to read and review the feas…

Somehow, we’re still failing to realize that the most complex UIs - think CAD software, 3D editors, etc - are imperative, object-oriented, and written in C++. Their core development teams are usually very small. Yet you need a 20-person frontend team to deliver a primitive e-commerce app. It’s as clear as day that the promise of declarative and reactive programming is failing its users.

How much of this is that most of these tools have been around for 20+ years and come from a time where OOP was the holy grail coming to save humanity?

Re: SwiftUI After 7 Years

#218

Post by dminik »

cosmic_cheese wrote: post #12

I'm sure many will disagree, but I have doubts that pure declarative-reactive is the "right" shape for an all-purpose native UI framework. In my experience, Kotlin+Compose shares many of the same warts… its main redeeming quality is that it's better than Android Framework (most of the time), which is low bar to clear. These frameworks have a number of good ideas but they don't necessarily combine in a way that transc…

To make complex layouts (flex, ...) and have them run performantly you need some form of a retained backing state anyways.

The main difference between various retained, OOP, functional, immediate, declarative, ..., approaches is how they treat this state.

For imperative/retained/OOP libraries, you operate on this state itself. Your nodes/widgets know their own state, how to render themselves, their place in the hierarchy and so on.

For immediate/functional(?) libraries, this state is a cache. It's not something you work with directly.

Despite not really liking React itself, I think it has found the best model.

You take a retained core, possibly OOP, maybe ECS or whatever, and you write a declarative wrapper around it. This lets you escape the easy-mode declarative landscape when needed, but most UI can still be simple to write.

Re: SwiftUI After 7 Years

#220

Post by steve1977 »

iainmerrick wrote: post #175
steve1977 wrote: post #156

Earlier quoted context omitted.

At least for me, it just had/has the right mix of abstraction and simplicity. It just "ticked" in a way that for example MFC didn't. But I also really liked Objective-C.

Cocoa and Objective-C are both great, but I think there's one huge problem that they never managed to solve well: responsive layouts. Classic iPhone apps have fixed layouts, and classic Mac apps have a big dynamic document in the centre with mostly fixed toolbars around the sides, and dialogs with fixed layouts. Making a really dynamic layout with OS widgets is a huge pain, so most apps sidestepped it. As Apple gradu…

Maybe responsive layouts are part of the problem?

I get their appeal (in the sense of only having to develop one layout), but IMHO, in many cases more strict layouts would be the better choice.

You mention classic apps having a fixed layout, I think that's a good thing.

Not every user interfaces makes sense in portrait AND landscape mode for example.

And the slightly different sizes of iPhones are not really that problematic with something like autolayout.

Post reply on HN