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

SwiftUI Defaults Considered Harmful

tonsky.me

Post reply on HN
Print view View original

51–60 of 135 posts

Re: SwiftUI Defaults Considered Harmful

#51

Post by ken »

Just when I thought Lisp had been ransacked for every last feature that language designers were willing to steal, the "War on commas" pops up -- complete with discussion of the essential differences might exist between "(" and "{", the pain of needing another way to say "if", and the lack of support for the rest of the language.

And the last couple interesting Swift libraries I saw had .gyb files and #if directives.

Apple tried really hard to make a fully static language that was visually elegant (and looked like C), but in the end we need so many dynamic features that what we ended up with seems much more complex than just having had well-designed macros from the start.

The cynic in me suspects that they know this would be worse, but has the advantage that only Apple can add such features, not the common programmer. OTOH, the cynic in me knows that staying far away from Lisp is par for the course, and every new language needs their code to look like an example from the designer's tattered copy of "K&R".

At least they managed to drop C-style for-loops in a mainstream language, so next time a company decides to design a new language, we can hopefully start there. I predict we're about 3 generations of corporate languages away from seeing macros get "invented" again.

Re: SwiftUI Defaults Considered Harmful

#52

Post by 5cott0 »

madeofpalk wrote: post #30

Reading through the syntax changes they made makes me really appreciate the decisions made around JSX and how that works, syntactically. It's just javascript , and none of these weird constructs need to be added into some DSL to support it. There's the reasonably minimal html-ish syntax, then "escape to javascript" to add in conditionals or loops or whatever. I wonder if there was (or still is) a way to do something…

.nib & .storyboard files are XML based so one could conceivably write a dsl to represent interface builder xml in swift if one doesn't already exist.

SwiftUI is a definite move away from interface builder.

Re: SwiftUI Defaults Considered Harmful

#53

Post by tayistay »

Would it be possible to wrap SwiftUI such that we don't have to use that DSL, don't have that 10 child limit (how many hours wasted figuring that one out?), and don't have bizarre non-localized error messages?

My guess is the answer is no because SwiftUI builds view hierarchies using parameterized types, so you're always stuck with `some View` and the associated complexity.

Re: SwiftUI Defaults Considered Harmful

#54

Post by nwienert »

madeofpalk wrote: post #30

Reading through the syntax changes they made makes me really appreciate the decisions made around JSX and how that works, syntactically. It's just javascript , and none of these weird constructs need to be added into some DSL to support it. There's the reasonably minimal html-ish syntax, then "escape to javascript" to add in conditionals or loops or whatever. I wonder if there was (or still is) a way to do something…

It’s hard to claim that JSX is more “just JavaScript” than SwiftUI. If anything I’d say it’s the opposite.

Swift evolved the language hand in hand with SwiftUI so everything you see is standard there.

And in my humble opinion they did a knockout job. And this is coming from someone whose spent a ton of time evangelizing React.

SwiftUI is far more beautiful, pleasant to write, and well thought out. It does have a couple awkward points but it’s not the “DSL” or it’s defaults (it’s just Swift) which is fine, it’s all on the dev tooling, performance, debugging, random bugs, and error messaging side of things (ie, maturity).

Re: SwiftUI Defaults Considered Harmful

#55

Post by cmauniada »

bouke wrote: post #18

Observing the launch of SwiftUI as a bystander (I'm not developing for any Apple platform), it seems that people are very excited about SwiftUI, but also get burned by it a lot. This is mostly Apple's fault by releasing this framework without any caveats. But the framework is more like an early alpha, not to be used in production. Tooling is not yet ready, documentation is not yet ready, heck even Swift –the language…

As someone who is a bit more involved in iOS development, I am also standing on the sidelines. Mainly because any apps that I am developing for, I can still keep on using NS Layout Anchors that work wonderfully. One of the biggest reasons I have decided not touch it is because of problems like these, until there is a v2 or v3 for swiftUI, its just not worth it to include it in any projects. (imho)

Re: SwiftUI Defaults Considered Harmful

#56

Post by rkapsoro »

While I don't yet have great confidence in my mental model of SwiftUI's type system, my understanding is that the DSL builders exist for more reasons than just to eliminate commas.

The new Function Builder and `some` return type features of Swift allow you to return a complex, nested type describing not just that it's a View but rather also all the structure within.

This means that at runtime you can have a (non-erased!) type describing the contents of your `var body` like this:

    Button>>
This particular body displays a Text if a state boolean is true, and an image if not.

Super interesting - and having types this descriptive can potentially enable a host of interesting features and optimizations. For example, across evaluations of your UI SwiftUI needs to track the identity (and location in your view graph) of all of your views, in order to keep their state, bindings, and other stuff that needs to remain consistent across time. The position if your view in a type hierarchy is the default way SwiftUI does so. This starts to blur the line between code and the type system, which I think the Functional Programming folks have been exploring for years.

One more nitpick: the use of View Modifiers on children noticed by parents (like the `navigationBarTitle` example he uses (as discussed in the "Child Privacy Invasion" section), is to allow for children to specify metadata that the parent might care about. This is actually pretty nice, because then you can nicely compose together the various parts of your app without having to spread around the configuration for your tab bars and such (which is a bit messy in UIKit).

edit: formatting. I always trip up with it on HN due to the lack of a Preview feature.

Re: SwiftUI Defaults Considered Harmful

#57

Post by nwienert »

saagarjha wrote: post #13

SwiftUI has defaults because nobody knew what UIKit's were supposed to be. Some of them were fiddly secret layout guides in Interface Builder, and some were accessed through the magic "-" in a VFL constraint, but overall it was very difficult to actually know how much spacing things should have. And on Apple's platforms, this matters: users know what things should look like, and if you're off you just look out of pla…

Yea, well said. There are some awkward bits, but if I were writing an article on my first 4 months with SwiftUI it would look totally different.

There are tons of bugs, random issues, and a lack of controllable properties in areas. There’s a lack of documentation, performance, etc.

But the language, defaults, components? All wonderfully done.

In fact I’d spend years building a UI kit in React attempting to standardize on things like that, and on seeing and using SwiftUI I was constantly impressed by how well done it all feels when the language (Swift) is robust and designed to work alongside the framework.

Count me as basically optimistic, just hoping they iron out all the beta-y aspects quick!

Re: SwiftUI Defaults Considered Harmful

#58

Post by jimbokun »

madeofpalk wrote: post #47
thu2111 wrote: post #40

Earlier quoted context omitted.

Surely JSX is ... well it's something that looks a lot like XML, hence the name. It's not just JavaScript, is it? It's pretty much the definition of embedding a DSL. I've not used SwiftUI but I've used TornadoFX which is similar, but with Kotlin instead of Swift. There's no weird syntax or DSLs (even though they call it that). It's all just functions and lambdas, so the language is always there and the syntax is alwa…

JSX is 'just' an XML-like syntactic sugar for making nesting function calls nicer in Javascript. Yes, its a DSL, but it keeps the "domain" extremely small and it transpiles in a very straightforward way down plain javascript madeofpalk // is syntactic sugar for React.createElement(Container, null, React.createElement(Text, { weight: "bold" }, "madeofpalk"), React.createElement(Image, { src: profilePic }) ); Whenever…

So it's reinventing PHP and Java Server Pages?

Re: SwiftUI Defaults Considered Harmful

#59

Post by K0nserv »

rkapsoro wrote: post #56

While I don't yet have great confidence in my mental model of SwiftUI's type system, my understanding is that the DSL builders exist for more reasons than just to eliminate commas. The new Function Builder and `some` return type features of Swift allow you to return a complex, nested type describing not just that it's a View but rather also all the structure within. This means that at runtime you can have a (non-eras…

> One more nitpick: the use of View Modifiers on children noticed by parents (like the `navigationBarTitle` example he uses (as discussed in the "Child Privacy Invasion" section), is to allow for children to specify metadata that the parent might care about. This is actually pretty nice, because then you can nicely compose together the various parts of your app without having to spread around the configuration for your tab bars and such (which is a bit messy in UIKit).

I wouldn't say it's too messy in UIKit but I agree with the motivation. To add some more context here's how you configure the title of the navigation bar in UIKit

    navigationItem.title = "My Title"
    navigationItem.largeTitleDisplayMode = .always
This does not happen in the class that renders the navigation bar(UINavigationController) nor does it happen in the navigation bar view itself(UINavigationBar) it happens in the view controller that is currently on screen and is the "active" child of UINavigationController.

Re: SwiftUI Defaults Considered Harmful

#60

Post by travisgriggs »

epaga wrote: post #31
saagarjha wrote: post #17

Earlier quoted context omitted.

Yes.

That said, current iOS 13 adoption rate is already at 93%...

Citation?

I just checked " rel="nofollow">https://mixpanel.com/trends/#report/ios_13> and it shows iOS at 85%.

About a month ago, I started releasing versions of our app on iOS 13 in TestFlight (I wanted to use the new SF Symbols) only to discover there are a lot of iPhone6 models out there. My first reaction, was "c'mon, that's a 6 year old iPhone, time to move on!" until I found that Apple kept selling the 6 all the way through 2017. A lot of "budget" buyers purchased iPhone 6's up through that period. So I've come to be skeptical about these claims of adoption rate. I subsequently reverted to iOS 12. :(

Post reply on HN