4 ms·

I looked a bit of the posts on Twitter, and wow, it’s really polarized. People seem to either love it or hate it. Is SwiftUI still that controversial, or is it

I looked a bit of the posts on Twitter, and wow, it’s really polarized. People seem to either love it or hate it. Is SwiftUI still that controversial, or is it just an effect of people posting on Twitter?

wussboy 4y ago
It’s not just the effect of Twitter. It’s the whole point of Twitter.
deleted 4y ago
[deleted]
draw_down 4y ago
ragnese 4y ago
> People seem to either love it or hate it. Or is that just an effect of people posting on Twitter? I'm sure that a big part of that is the effect of it being Twitter. How often do we feel the urge to post something online that we have no strong feelings about? More on topic, though: I'm a SwiftUI hater still. It's a cool concept, but there are two big problems with it, IMO: 1. It's totally out of place with the rest of the Swift programming language. They had to add new crap to the language to accommodate its declarative style, when Swift is (was) unapologetically imperative syntax-wise. It's an obvious bolt-on and leaves a really bad taste in my mouth. 2. It's still a very leaky abstraction, in that there's still a lot of stuff you have to reach into UIKit for, whether it's for uncommon UI design parts or for performance reasons. As a polyglot dev for my day job, I loathe leaky abstractions. I refuse to learn two "frameworks"/"paradigms"/whatever when I could just use one of them and ignore the other. I feel largely the same way about ORMs: it's guaranteed that I'm going to have to be considerate of the generated SQL queries regardless, so why do I have to be an expert at SQL and whatever complexity is in the ORM around caching, flushing, transactions, default values, etc? Ain't nobody got time for that.
- throwaway1777 4y ago
  Not to be super rude, but why are you a polyglot dev if you don’t like learning multiple frameworks?
  - ragnese 4y ago
    I don't find that to be a rude question at all. I love being a polyglot dev and I love learning and using different programming languages, frameworks, and app platforms. The issue I have is with learning redundant frameworks that don't actually give me more power. To continue berating ORMs, I am in charge of several different projects at work that communicate with SQL databases. The set of programming languages that span these projects is: Kotlin, PHP, Rust, and JavaScript (being phased out). I love getting to switch between these languages (just not too frequently, lest the context switching kills my brain), and I feel like it helps me to see the strengths and flaws in each, and it's just really fun to find effective patterns in each. Whether I use an ORM in all or none of those projects, I'm going to have to be competent with SQL. But if I decided to use an ORM for all four, I'd have to learn five different ways to get data in and out of our databases. Rather than learning four redundant, incomplete, data retrieval "languages" that sit on top of SQL, I rather learn... almost anything else. I have used lots of ORMs: The Symfony one for PHP whose name I can't recall, Magento's weird one for PHP, Hibernate (Java), Sequelize (JavaScript), and a few others in other languages. They all have subtle issues. And they are "issues" and not just different design choices- I'll never ever accept that Hibernate/JPA/JDBC returning a `(int) 0` when it encounters a null result from a nullable integer SQL value is anything short of lunacy when Java has a native null value. And they all have stupid things like that. Learning those gotchas, bugs, abstraction leaks, performance problems, etc, is not the fun kind of learning for me- it's just tedious and frustrating. So, to bring it back to SwiftUI, I love that I manage an iOS app. I like learning about how iOS works, and I like working with Swift. It's still required that we know how to use UIKit APIs for non-trivial stuff, so why would I learn SwiftUI (and its problems and gotchas) so that I can do 75% of my work with SwiftUI and 25% with UIKit APIs? It's possible that it would make me an even better iOS dev, but I doubt it (at this point). I think my time is better spent learning something that will allow me to accomplish tasks with computers that I don't already know how to do.
- 4y ago
ben_w 4y ago
My experience of SwiftUI is that all of the love and all of the hate is simultaneously correct. It makes some tasks much much easier, e.g. low vision users really benefit from variable font sizes, which Storyboards can do but it feels unnecessarily hard to do in a non-fragile way. I can also see the benefits of reactive UI over the Storyboard approach, especially with UICollectionView and UITableView. But… The code examples, even from WWDC slides and Apple docs, don’t even always compile; the widgets are different enough it’s not always clear how to get to the desired UI when you’re starting from UIKit, and the integration between UIKit and SwiftUI (in both directions) isn’t as easy as I’d like, and you have to keep resuming the canvas view because it’s not smart enough to figure out for itself when the code now represents a valid view.
- kitsunesoba 4y ago
  > It makes some tasks much much easier, e.g. low vision users really benefit from variable font sizes, which Storyboards can do but it feels unnecessarily hard to do in a non-fragile way. Code-only UIKit (no storyboards or XIBs) with autolayout handles this case pretty well in my experience. There’s a few gotcha’s but no more than with SwiftUI. You mainly just need to remember to use UIFont’s preferredFont(forTextStyle:) when setting up labels and controls.
viktorcode 4y ago
It's new and requires different mindset than UIKit. Many times I was thinking "it must be broken!" only to find out later that I was doing things wrong. I suspect many posts on Twitter follow the same pattern. My advise is to try it, and learn along the way. After a while the idea of going back to UIKit will become scary.

wussboy 4y ago

It’s not just the effect of Twitter. It’s the whole point of Twitter.

deleted 4y ago

[deleted]

draw_down 4y ago

ragnese 4y ago

> People seem to either love it or hate it. Or is that just an effect of people posting on Twitter? I'm sure that a big part of that is the effect of it being Twitter. How often do we feel the urge to post something online that we have no strong feelings about? More on topic, though: I'm a SwiftUI hater still. It's a cool concept, but there are two big problems with it, IMO: 1. It's totally out of place with the rest of the Swift programming language. They had to add new crap to the language to accommodate its declarative style, when Swift is (was) unapologetically imperative syntax-wise. It's an obvious bolt-on and leaves a really bad taste in my mouth. 2. It's still a very leaky abstraction, in that there's still a lot of stuff you have to reach into UIKit for, whether it's for uncommon UI design parts or for performance reasons. As a polyglot dev for my day job, I loathe leaky abstractions. I refuse to learn two "frameworks"/"paradigms"/whatever when I could just use one of them and ignore the other. I feel largely the same way about ORMs: it's guaranteed that I'm going to have to be considerate of the generated SQL queries regardless, so why do I have to be an expert at SQL and whatever complexity is in the ORM around caching, flushing, transactions, default values, etc? Ain't nobody got time for that.

throwaway1777 4y ago
Not to be super rude, but why are you a polyglot dev if you don’t like learning multiple frameworks?
- ragnese 4y ago
  I don't find that to be a rude question at all. I love being a polyglot dev and I love learning and using different programming languages, frameworks, and app platforms. The issue I have is with learning redundant frameworks that don't actually give me more power. To continue berating ORMs, I am in charge of several different projects at work that communicate with SQL databases. The set of programming languages that span these projects is: Kotlin, PHP, Rust, and JavaScript (being phased out). I love getting to switch between these languages (just not too frequently, lest the context switching kills my brain), and I feel like it helps me to see the strengths and flaws in each, and it's just really fun to find effective patterns in each. Whether I use an ORM in all or none of those projects, I'm going to have to be competent with SQL. But if I decided to use an ORM for all four, I'd have to learn five different ways to get data in and out of our databases. Rather than learning four redundant, incomplete, data retrieval "languages" that sit on top of SQL, I rather learn... almost anything else. I have used lots of ORMs: The Symfony one for PHP whose name I can't recall, Magento's weird one for PHP, Hibernate (Java), Sequelize (JavaScript), and a few others in other languages. They all have subtle issues. And they are "issues" and not just different design choices- I'll never ever accept that Hibernate/JPA/JDBC returning a `(int) 0` when it encounters a null result from a nullable integer SQL value is anything short of lunacy when Java has a native null value. And they all have stupid things like that. Learning those gotchas, bugs, abstraction leaks, performance problems, etc, is not the fun kind of learning for me- it's just tedious and frustrating. So, to bring it back to SwiftUI, I love that I manage an iOS app. I like learning about how iOS works, and I like working with Swift. It's still required that we know how to use UIKit APIs for non-trivial stuff, so why would I learn SwiftUI (and its problems and gotchas) so that I can do 75% of my work with SwiftUI and 25% with UIKit APIs? It's possible that it would make me an even better iOS dev, but I doubt it (at this point). I think my time is better spent learning something that will allow me to accomplish tasks with computers that I don't already know how to do.
4y ago

ben_w 4y ago

My experience of SwiftUI is that all of the love and all of the hate is simultaneously correct. It makes some tasks much much easier, e.g. low vision users really benefit from variable font sizes, which Storyboards can do but it feels unnecessarily hard to do in a non-fragile way. I can also see the benefits of reactive UI over the Storyboard approach, especially with UICollectionView and UITableView. But… The code examples, even from WWDC slides and Apple docs, don’t even always compile; the widgets are different enough it’s not always clear how to get to the desired UI when you’re starting from UIKit, and the integration between UIKit and SwiftUI (in both directions) isn’t as easy as I’d like, and you have to keep resuming the canvas view because it’s not smart enough to figure out for itself when the code now represents a valid view.

kitsunesoba 4y ago
> It makes some tasks much much easier, e.g. low vision users really benefit from variable font sizes, which Storyboards can do but it feels unnecessarily hard to do in a non-fragile way. Code-only UIKit (no storyboards or XIBs) with autolayout handles this case pretty well in my experience. There’s a few gotcha’s but no more than with SwiftUI. You mainly just need to remember to use UIFont’s preferredFont(forTextStyle:) when setting up labels and controls.

viktorcode 4y ago

It's new and requires different mindset than UIKit. Many times I was thinking "it must be broken!" only to find out later that I was doing things wrong. I suspect many posts on Twitter follow the same pattern. My advise is to try it, and learn along the way. After a while the idea of going back to UIKit will become scary.