Flexbox was proposed in 2009, and it hasn't been widely available until years after that. The iOS and Android layout systems are functionally older than the "good" parts of CSS you speak of (I would agree FlexBox and Grid are actually fine, although not as complete of a solution as constraint-based layouts).
Moreover, if mobile did just use a subset of CSS for it's layout system, you'd just worsen the fragmentation problem that CSS currently suffers from: in order to write "cross-platform" css, which you cited as one of the benefits of this approach, you would need to account for _even more_ platforms with slightly different APIs. To make a layout which works on, say, IE 9 and Android you would still have to implement twice, or resort to workarounds like polyfills.
> Could you de-jargon these sentences?
If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them.
The point is that with autolayout, the total number of things you can do could be written on one page. You have a hand-full of general-purpose building blocks, and you compose them together to do whatever layout you want. That's compared to CSS where there's a large collection of tools, each of which has holes.
And when was AutoLayout introduced? Even with that, it's evolved and been improved over time -- I bet you wouldn't want to use AutoLayout from 2016 today if you could avoid it. Either way, Apple could have introduced AutoLayout as a private extension of CSS that doesn't worry about being spec-compliant, without completely rebuilding their own framework for styling.
Are you implying the android layout systems are older than CSS itself? Because one of the "good" parts of CSS I was talking about was basic targeting and separation of concerns between styling and layout. That's fundamental CSS, and long predates any mobile platforms.
People writing mobile apps, especiallly native ones don't give a shit about cross-platform anything, I don't understand why you'd all of a sudden start worrying about that if you used CSS. I keep repeating this, but they can make their own private subset of the CSS spec that only their developers have to care about.
You've framed the burden of cross-platform support as a bad thing, but it's a good thing -- whatever that cost is, you pay it once, for everyone -- you prefer a world where cross-platform support is just impossible?
> If that seems like jargon to you, I would have the suspicion that you have never put the time in to learn the basic auto-layout concepts. If that's the case I'm not sure how you can compare them.
This a common mindset that I've never agreed with. If you can't explain the simplest uses of your abstraction without a sentence full of jargon, this is a red flag for me, it's a shitty abstraction. Jargon is calcified complexity that is so burdensome to try and explain/analogize that you just pick a word and say it instead. This is like what people say who build ridiculous Java class/pattern riddled sand castles all day, then say that if I don't understand why they needed a AbstractThingFactoryMakerService then I didn't learn the basics.
This is precisely why I will never willingly enter the quagmire that is fully native development, there are people like you in the wild waiting to justify any bad design decision the native platform makes once they've paid the cost of learning a subpar abstraction/re-engineering of a mostly solved problem that's been foisted upon them. You'll to shout how good AutoLayout is from the rooftops while devs flock to alternatives because of the BS.
NativeScript and Flutter are gaining popularity because the platforms have issues. You can ignore it for however long you want.
Actually you seem to be the one who is guilty of exactly this. I am speaking from experience with CSS _and_ mobile layout systems, and _you_ seem to be the one who is afraid to step out of your CSS comfort zone, and assume that the system which is familiar to you is the best system without trying (or apparently reading up on) the alternatives. Your entire argument against AutoLayout seems to be that other people don't like AutoLayout. If you haven't bothered to learn about the basic concepts, how can you possibly know it's so bad? And frankly the level of projection and vitriol in your comments is disappointing to see on Hacker News.
> Are you implying the android layout systems are older than CSS itself?
No, I'm implying that it would have been a bad decision for the mobile UI systems to have been built around CSS before it had decent layout solutions like flex-box and grid.
> And when was AutoLayout introduced?
It's not relevant. AutoLayout is an evolution of the iOS UI system, so comparing the origin of AutoLayout to the origin of FlexBox is orthogonal to my point.
You've also assumed that because I think CSS is better at solving basic problems these days that I haven't used used AutoLayout. I have used AutoLayout and it wasn't a good experience. I've also used Android's XML soup based layout, neither is fun and they solve problems CSS has already solved. I write both android and ios apps and have moved off native development because of frustrations with the little differences between both of the platforms.
> No, I'm implying that it would have been a bad decision for the mobile UI systems to have been built around CSS before it had decent layout solutions like flex-box and grid.
Yeah except like I've said roughly 5 times now, they didn't have to take ALL of CSS. They could have built extensions to it, possibly benefiting the whole ecosystem, or anyone else -- at the very least, leverage what CSS has already solved well and then build upon it.
> It's not relevant. AutoLayout is an evolution of the iOS UI system, so comparing the origin of AutoLayout to the origin of FlexBox is orthogonal to my point.
Of course it isn't relevant -- because you don't have a choice. I was comparing the origin and evolution of AutoLayout to the origin and evolution of CSS -- CSS might move slow, but it's pushed forward by entities that do exploratory work, contribute back and improve things for everyone.
AutoLayout does not improve on the basics that CSS offers -- targeting and styling an element is basically the simplest it gets, and it's straight-forward to understand. CSS has iteratively gotten better over the years, steered by a bunch of groups, and is sufficiently extensible to contain AutoLayout's functionality. A world where CSS could be worse than AutoLayout basically doesn't exist, because you could literally make a CSS, strip whatever you don't like out, and implement AutoLayout.
> https://www.w3.org/TR/css-2017
> It's enormous! How could anything be intuitive when there are hundreds of keywords?
But I covered this though -- you don't have to take the whole HTML/CSS spec, because if you did you'd just be making a browser.
Even if there are hundreds of keywords, you generally don't have to know (or support, as an implementer) every single one.
> To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear: [example]
The example you gave is pathological -- a more reasonable one for a "basic design problem", which is what you said CSS was bad for:
Your very next sentence betrays how pathological the case is:> "clear" is a magic word I just have to know when I'm dealing with float layouts so that my elements end up the place I want them to. It's not a concept that flows naturally from the way designers think about layouts, it's essentially a special case , an implementation detail which has been sloppily bubbled up to the CSS API. CSS is full of these special cases.
"clear" isn't magic, it requires knowing what a float layout is, and having used a float layout before. It is a special case reserved for building float layouts, that is necessary because of how they work.
I don't disagree with you that float layouts are terribad and shouldn't be used these days, but that's the beauty all those keywords in the CSS spec -- you don't have to use it. These days we have Flexbox & Grid, decently engineering solutions for layouts.
> By contrast, a constraint-based layout is built on a few extensible contexts. Essentially you have a hand-full of layout anchors on each object, and you have a short list different possible relationship types between anchors. From those core principals you can build up any kind of layout you want.
Could you de-jargon these sentences? Maybe this is where we differ, I think what you just described is more complex than CSS from principles. Also, I want to note that not many in this thread have stuck up for the simplicity/ease of use of AutoLayout.