Hacker News Reader

Comment by happytoexplain | Hacker News Reader

Swift UI makes simple UIs easier, moderately complex UIs harder, and very complex UIs impossible. The moment your UI is more complex than a stack of stacks, the elegance and comprehensibility falls apart compared to autolayout. It starts to feel like CSS all over again, using trial and error to try out combinations of elements and properties with unclear interactions.

The pattern it enforces is theoretically great, but you will get much more mileage out of learning to write in a "reactive" style manually (When state changes, update view to match. It doesn't need to literally be a function of state to make it a function of state. E.g. don't leave ifs without elses.)

A perfect combination would be a SwiftUI-style UI editor (sans bugs) to define UI, constraints included, but traditional layout management at runtime. Well, that or a ground-up redesign of SwiftUI's API.

View on HN

I’m a lot happier with UIKit/AppKit plus SwiftUI than with just SwiftUI alone.

I wrote a couple of small sized apps trying to use only SwiftUI “the right way” to learn the framework and as you say whenever I wanted to do something specific with a lot of control I’d hit a wall with SwiftUI and have to go crazy with wild work arounds and trial-error throw spaghetti at the wall or just give up.

Now I’m writing another app and making heavy use of NSViewRepresentable use AppKit from SwiftUI, and NSHostingView to embed SwiftUI in AppKit views. I’m using mostly SeiftUI at the “leafs” of the view hierarchy, and AppKit towards the root; all my windows use a NSWindow subclass and/or a view controller.

Much happier with this!

I like what you're describing, but still wonder if good ol' auto-layout for the leaves would have been equivalent and just as simple.

I find creative visual styling of views like drawing paths/shapes, drop shadows, quick stacks/rows, grid panels, etc all much easier and faster with SwiftUI and SwiftUI #Preview.

>Swift UI makes simple UIs easier, moderately complex UIs harder, and very complex UIs impossible.

Having tried to make a NavigationSplitView with multiple lists in the sidebar, I can fully agree with this sentiment.

> Swift UI makes simple UIs easier, moderately complex UIs harder, and very complex UIs impossible. The moment your UI is more complex than a stack of stacks, the elegance and comprehensibly falls apart compared to autolayout. It starts to feel like CSS all over again, using trial and error to try out combinations of elements and properties with unclear interactions.

Sadly, this has been my experience. I built a moderately complex app, only to bump into more and more problems, and I find myself fighting the framework, building hacks, and implementing workarounds. When you venture into more advanced UIs, the leaky abstraction comes back to haunt you.

I haven't used Swift UI, but I have used Elm, React (a bit), and Flutter (a fair amount). My understanding is that it's a similar model.

In those frameworks (particularly Flutter, which generally has less ceremony), I have found simple UIs easy, and complex UIs slightly harder to build, but then they're much more predictable (fewer surprising edge case bugs) and much much more maintainable.

The more I think about it, the more I think SwiftUI is inspired by Angular - two-way data binding and observables everywhere.

Two-way data binding makes for shorter demos, but it doesn't scale nearly as well as one-way data binding. I've found in SwiftUI the way state gets updated across components becomes very messy very quickly.

Jetpack Compose is definitely inspired by React, hooks and all. I much prefer working with Jetpack Compose for this reason.

I suppose it's a compromise; the lower you go, the more control you have.

I used to work on an app where we used the UI builder at the time (I forgot the name) at first, but my colleague asserted that building the UI in code resulted in a faster app, because (according to him) parsing and rendering the XML output took longer than interpreting the code. I don't know if he was right, but a while later Apple introduced devices with different sizes (iirc the iphone 5 which was a little taller and the ipad) and doing all the layouting became impossible.

Anyway when I rejoined later it was a (I believe) healthy mix of the UI builder tool and custom code for some graphic / coded elements (think a fancy progress indicator). I suspect it'll be the same for SwiftUI.

Apple has historically not cared about mid-level companies and above, and SwiftUI is just another example of that. Everything they do is geared towards absolute beginners / very simple projects, even Xcode itself becomes basically useless once you reach a certain level of complexity. I don't understand why they do that.

> Apple has historically not cared about mid-level companies and above

I wouldn't say that. I've worked for a couple of marquee corporations that did a lot of work with Apple.

They do things like assign direct contacts to larger corps. They don't really rely on their "popular" culture docs to support bigger companies.

It's pretty natural to use their popular front as an "onboarding" system for smaller acts, with the plan to integrate them more tightly, if they get successful enough.

That said, their App Store is quite restrictive, and can be a big fat pain to deal with; even as a bigger corporation.

Quite doable, though. I've released over 20 apps to the iOS/Mac App stores, over the last dozen years.

Myopic take. Major tech companies adopted SwiftUI. Vision Pro is all SwiftUI and mixed declarative and imperative RealityKit.

> Major tech companies adopted SwiftUI

Source? I haven't heard of any large company with complex projects fully adopting SwiftUI in their main product and not immediately regretting it. Successful adoption seems to be achieved only if the product is really simple or when using it in a very specific / isolated place of their main product (also simple). Everything else is UIKit because SwiftUI sucks at complicated logic.

How is CSS like trial and error?

Because, compared to some modern layout systems, it takes longer (to put it lightly) to internalize the exact logic behind the implementation of all CSS properties and be able to simulate how they interact in complex UIs in your head.

Can you provide some examples of modern layout systems? I’d be curious to see what’s on offer.

I have experience with various iterations of UIKit’s auto layout, Yoga, as well as CSS and some Swift UI. I’ve found CSS to be considerably easier to work with, particularly when using flexbox and grid.

Ok, then please implement the following in CSS:

   Outer
   +---------------------------------+
   |                                 |
   | Left        Middle        Right |
   |                                 |
   +---------------------------------+

Everything should be vertically centered. Left should stick to the "left" of the outer div, "middle" should be centered, "right" should stick to the right. Left/middle/right can have different widths and heights.

In AutoLayout this is achieved by 6 constraints:

- left.left = outer.left

- left.centerY = outer.centerY

- middle.centerX = outer.centerX

- middle.centerY = outer.centerY

- right.right = outer.right

- right.centerY = outer.centerY

I'd like to see how you implement it in CSS. (note: extra wrapper divs are not allowed)

Assuming your div has a class of outer it’s:

.outer { display: flex; justify-content: space-between; align-items: center; }

…and that’s it. (This is assuming your items are of equal width of course. It gets a little bit more complicated if not.)

I've literally told you the items can be of arbitrary width and height. `space-between` won't keep the middle item centered.

Chrome just added CSS Anchor Positioning this year. The other browsers also expressed interest in implementing it, with Firefox having announced an Intent to Implement. The feature would likely be available on all major browsers sometime next year.

So here's how your example would work using it:

.outer { width: 100%; height: 400px; background: aliceblue; anchor-name: --outer; }

.left { width: 100px; height: 100px; background: white; position: absolute; position-anchor: --outer; left: anchor(left); align-self: anchor-center; }

.center { width: 150px; height: 200px; background: pink; position: absolute; position-anchor: --outer; justify-self: anchor-center; align-self: anchor-center; }

.right { width: 160px; height: 150px; background: gray; position: absolute; position-anchor: --outer; right: anchor(right); align-self: anchor-center; }

Source: https://developer.chrome.com/blog/anchor-positioning-api

Cool! Is it going to be the sixth or the seventh positioning system in CSS?

.parent { display: grid; grid-template-columns: 50px 200px 80px; justify-content: space-between; align-items: center; }

An interesting thing you can do with grid is align the tracks.

I wrote about this here:

https://cssprinciples.com/3/grid/#justify-and-align

No. You're hardcoding the item widths in `grid-template-columns`. The left/middle/right items should be self-sizing. E.g. consider three divs with arbitrary text content.

Grid allows minmax(a, b) to specify the bounds of tracks. Possible values can be the remaining free space in the parent (fr), or the size of the content in the child.

There is also fit-content:

E.g: grid-template-columns: fit-content(150px) …

Sorry, but I don't understand what you're describing. Can you maybe show it in jsfiddle?

I am just saying the columns of the grid can be dynamically sized depending on their contents.

Tracks is a grid term for rows or columns, as it works in both dimensions.

I'd like you to demonstrate your approach with this jsfiddle: https://jsfiddle.net/nbdowrcm/

As you can see, the middle element is not centered.

I see.

https://jsfiddle.net/Lah5g3vb/

Changes:

- each col is now 1fr (3 cols, 33% each)

- the child elements align inside the col using `justify-self: start | center | end`

Not good, because now the elements are limited to 33% width of the container.

See: https://jsfiddle.net/e0un5Lxk/

The middle content is unnecessarily wrapped into two lines, even though there's plenty of space available.

You can also use `minmax(min-content, max-content)` for the center col: (https://jsfiddle.net/y193p2b6/).

But this does not keep the center col exactly centered, but it does allow the content to take the free white space and then wrap when needed.

In your original post with Swift, what happens?

I am not familiar with auto layout so I do not know the exact behaviour vs CSS. Do you have a few screen shots of how it would handle different sized content?

But now you just added `whitespace: no-wrap` to the middle element, with `overflow: visible`, to force it into a single line. That's hardly a generic solution, because it makes assumptions about the contained items... i.e. applying `whitespace: no-wrap` and `overflow: visible` will typically break the appearance of things.

Regarding AutoLayout: the six constraints from my original comment, don't say anything about the relationship between the left/middle/right items, so they will simply overlap if there isn't enough space. This can be remedied by adding two extra constraints:

1. left.right < middle.left

2. middle.right < right.left

It's just a bunch of equations. No weird tricks, no special cases, no hacks. You describe what you want with equations, and the solver spits out the solution.

Do you have an email? I am thinking of doing a blog post comparing css/auto layout, and would like your input?

Sure: gvjjdcnohdt@protonmail.com

Yeh, I edited my reply, I realised what you meant afterwards.

Auto layout does sound neat.

Either put left, right as absolute (like the following) and leave middle in the flex, or do the opposite. One may decide which option to use based on whether the centre or the left/right is more semantically important in the layout.

We did have to use some CSS "tricks" (transform for absolute centring), but once you've learnt those then CSS is indeed quite sane.

  outer {
          flex-direction: row;
          justify-content: center;
          align-items: center; }
  left, right {
          position: absolute;
          top: 50%;
          transform: translateY(-50%); }
  left {
          left: 0; }
  right {
          right: 0; }

(This kind of layout, which is common in eg top nav bars, is slightly deceptive. robin_reala's solution does not conform to requirements that left and right can be different widths, which would cause middle to be not centred under simple justify-content: space-between.)

Yes, this is the correct solution.

Which underlines the original point, that CSS is a hodgepodge of different ideas with no overarching system behind them. A simple task like this needed 3 different positioning systems:

1. flexbox for positioning the middle item

2. absolute positioning for left/right

3. and the translateY(-50%) trick for vertically positioning the absolute positioned items

Touché. Indeed, CSS forces one to recognise layouts that may not conform to a layout 'flow' in boxes.

In its defence, I suppose recognising this is important, as to make potential box overlaps explicit (which is typically unwanted).

CSS also handles a whole lot of things other than layout, which I'm not well informed of layout constraint systems being able to handle. Being a hodgepodge is an advantage, comparable to how its a great advantage that one can invoke any hodgepodge systems task from bash, as one single tool.

Maybe something like this, which relies solely on flex box for layout.

    .outer { 
      display: flex;
      justify-content: space-between;
      align-items: center;
    }

    .left {
      flex: 1;
      display: flex;
      justify-content: flex-start;
    }

    .middle {
      flex: 1;
      display: flex;
      justify-content: center;
    }

    .right {
      flex: 1;
      display: flex;
      justify-content: flex-end;
    }

Wrong. `flex: 1` will cause the items to have a max-width of 1/3rd the container width. E.g. if the left and right items are small icons, and the middle one is a longer text, then the text will be forced to wrap into multiple lines as soon as it tries to grow beyond 1/3rd of the available space, even though there's tons of wasted space on the left/right.

In this specific example, I am pretty sure margin-right: auto on left and margin-left: auto on right in a flex-box does what you want.

Wrong. The middle item will be misaligned from the center if "left" and "right" have different widths: https://jsfiddle.net/hxe8pcuf/

Does anybody know how you'd solve this in tex (not latex, tex) or in some other constraints-based layout system like Cassowary?

Reply on news.ycombinator.com