Live data from Hacker News

SwiftUI Defaults Considered Harmful

tonsky.me

11–20 of 135 posts

Re: SwiftUI Defaults Considered Harmful

#11
post #7

This website's background color is considered harmful, and "considered harmful" essays are considered harmful.

Site is also non-responsive with , looks horrifying on the 12.9’’ iPad Pro even without taking color scheme into account. I know complaining about blog design is out of scope, but if @tonsky is reading this thread, please consider fixing your meta viewport tag.

I always see people complain about the narrowness of Medium and think they're overreacting, but this site is pretty extreme. I could fit 3 of these side-by-side across my 13" MacBook Pro's screen.

Re: SwiftUI Defaults Considered Harmful

#12
post #7

Earlier quoted context omitted.

Site is also non-responsive with , looks horrifying on the 12.9’’ iPad Pro even without taking color scheme into account. I know complaining about blog design is out of scope, but if @tonsky is reading this thread, please consider fixing your meta viewport tag.

> I hope you have a wide enough monitor to read this. Perhaps they're merely unaware of how their website looks?

Or they use some special monospace font where 157 characters at 16px could somehow fit into a 544px wide column (well, that still got nothing to do with monitor width, though).

Re: SwiftUI Defaults Considered Harmful

#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 place. And if they change in the future, which they have on occasion due to new iOS versions or hardware (iPhone X, anyone?) you might end up off even if you didn't change anything in your code.

SwiftUI intentionally abstracts all of these things away from you so you don't have to deal with it, or even know about it. You're used to programming on the web? Well, the web has no standard. And anyways, people looking for magic defaults is how "8" and "44" show up seemingly randomly in iOS apps. Let the system decide for you…if you really need to override it, you can add your own explicit value.

Re: SwiftUI Defaults Considered Harmful

#14
post #7

Earlier quoted context omitted.

Site is also non-responsive with , looks horrifying on the 12.9’’ iPad Pro even without taking color scheme into account. I know complaining about blog design is out of scope, but if @tonsky is reading this thread, please consider fixing your meta viewport tag.

> I hope you have a wide enough monitor to read this. Perhaps they're merely unaware of how their website looks?

That refers to a
 block with no carriage returns, which ordinarily wouldn't wrap.

Re: SwiftUI Defaults Considered Harmful

#16
There are definitely a few things it does that are weird, and this article hits on a few of them.

But, I'll call special attention to the whole "adaptive padding thing" as a broader signal for something I feel that SwiftUI does very, very right and more UI frameworks need to start thinking about. Its made to design iOS apps. iOS has a design language that (1) is relatively consistent, (2) changes over time, and (3) changes across the many devices Apple supports.

In this era of many, many devices (don't just think Apple here; think any device; think VR, think TVs, etc), we need to operate at a higher layer of abstraction than most UI systems operate at. Most websites are pure garbage on 35" ultra-ultra-wide displays. It took a decade before mobile web entered the "generally useable" state it is in today. Ever tried to enable an ultra-high DPI setting on, say, Ubuntu or Windows?

All of these are getting better, but they only get better because the underlying technologies are becoming more generic.

> If I forgot to put padding between HStack elements, well, shame on me, there should be no padding! All mistakes are mine.

Wrong, and Apple has the data to prove it. When you release a poorly designed app to the App Store, the mistake is your's; your customers suffer because of it; and, it hurts the optics of application quality on the App Store, and thus Apple suffers.

This is relatively easy to draw a comparison to, say, manual memory management in C++. "If I forgot to properly bounds check a memory segment, well, shame on me, there should be no bounds checking! All mistakes are mine". Sure; and now your customers are vulnerable to hackers. You have a higher responsibility than just your Pride.

The defaults should be Safe. There should be options to override them when I feel confident I know what I'm doing (and SwiftUI has this, not the least of which being, you don't have to use SwiftUI, you can mix-and-match SwiftUI components with traditional iOS components).

Re: SwiftUI Defaults Considered Harmful

#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 and compiler– aren't even ready yet. Apple should've put a big warning notice on any SwiftUI related website to set the correct expectations.

Re: SwiftUI Defaults Considered Harmful

#19
The “X considered harmful” trope for deliberately strident technical screeds that quibble about what are mainly niche concerns has tired me out.

“‘X considered harmful’ considered harmful”, I guess.

Re: SwiftUI Defaults Considered Harmful

#20
post #16

There are definitely a few things it does that are weird, and this article hits on a few of them. But, I'll call special attention to the whole "adaptive padding thing" as a broader signal for something I feel that SwiftUI does very, very right and more UI frameworks need to start thinking about. Its made to design iOS apps. iOS has a design language that (1) is relatively consistent, (2) changes over time, and (3) c…

Haven't we been going in the other direction in recent years?

With integrated title bars in browsers, custom css, fonts etc.. Chrome on Windows, Mac, Linux etc. always looks like chrome but not native. Similarly webpages look "exactly like the designer intended" even if it is a very bad fit for your device.

We used to do things generically, but changed to prescribing every little detail and this now breaks when our assumptions change.

Post reply on HN