4 ms·

You're right -- No one should have to learn React! I'm personally not even a React fan. However standards-driven web components[0] are progressing rather slowly

You're right -- No one should have to learn React! I'm personally not even a React fan. However standards-driven web components[0] are progressing rather slowly (as they should be, arguably), so frameworks like React/Vue/Polymer/Mithril exist to get you some of that goodness faster than is otherwise possible in a cross-platform way. My more subtle point was that HTML and CSS despite all their warts have solved these problems -- I've expressed the sentiment here before -- design languages with their use of XML or more constricted DSLs or whatever else are just subsets of HTML + CSS, except I never find that they're engineered to minimize conceptual reuse. Both platforms make their own thing, claim it's good/the best from their own rooftop, and call it a day, expecting app developers to join the cult. I don't like that, and I know it makes me a worse mobile developer (I sacrifice the ability to relatively immediately solve some really deep UI layout bug in the native platform), but I'd gladly be able to write "good enough" cross platform apps two times quicker than being able to right a top performing/fully native optimized application two times quicker. Most app these days are as simple as webpages. Also just for posterity I don't necessarily want every platform to take HTML/CSS wholesale (though I thought FFOS was perfect, RIP) and implement a completely by-the-spec implementation, because at that point you'd just have a browser. Make your own subset and make your own choices, but don't re-solve problems HTML and CSS have already solved. For example, take the structural layout concepts from CSS Flexbox but maybe throw out the cascading if you want. BTW, I think Flutter is a trojan horse that's going to very likely be successful. Google was crazy enough to draw every pixel, then start building combinatorically from there. Right now it "embeds" in Android and iOS and also Fuscia (!!). Eventually It'll get a QT embed (because Google can afford to throw devs at it, just like they threw devs at the ridiculous-on-its-face "draw every pixel" approach), and whatever else and might actually be the first thing to be usable for all platforms without much worry. From what I understand JavaFX is one of the only similar UI frameworks to Flutter in application land and people who use it seem to love it. [0]: https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components

skohan 8y ago
> My more subtle point was that HTML and CSS despite all their warts have solved these problems I am so glad that CSS is not the dominant design/layout solution on mobile. CSS may seem natural to work with after years of experience, but it is very unintuitive and sub-optimal for solving basic design problems, and I'm glad they started fresh on mobile platforms. I mean it's only relatively recently that there is a somewhat easy way to center a div vertically and horizontally on screen which does not seem like a total hack. CSS is basically a tool designed for the simple formatting styling of text documents which has been patched to the point of absurdity to support modern design needs. The iOS tools in particular are extremely powerful and purpose-built for the task.
- hardwaresofton 8y ago
  Could you be more specific about which part of CSS you find the most un-intuitive and sub-optimal for solving basic design problems? I want to remind you that the basics of CSS are targeting some piece of layout and applying styles to it, separate from the element itself. Basic HTML + CSS is like an hour or two worth of learning for an absolute beginner (especially with the simplicity of HTML5), and after that you're mostly limited by your imagination, for simple things. I'm just assuming you mean cascading and/or specificity as the thing that's unintuitive and sub-optimal, but other than that I'm having trouble differentiating basic CSS (e.x. using only element ids and styling rules) and how you end up styling components on mobile now... Maybe where we're differing is on a more fundamental level as far as whether styling should be separate from layout in the first place? But even then you have access to `style` attributes in HTML...
  - skohan 8y ago
    Just look at the CSS spec (or collection of specs): https://www.w3.org/TR/css-2017 https://www.w3.org/TR/css-2017 It's enormous! How could anything be intuitive when there are hundreds of keywords? To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear: #MyDiv { clear: both; } "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. 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.
    - hardwaresofton 8y ago
      > Just look at the CSS spec (or collection of specs): > https://www.w3.org/TR/css-2017 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: #MyDiv { background-color: black; } 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.

skohan 8y ago

> My more subtle point was that HTML and CSS despite all their warts have solved these problems I am so glad that CSS is not the dominant design/layout solution on mobile. CSS may seem natural to work with after years of experience, but it is very unintuitive and sub-optimal for solving basic design problems, and I'm glad they started fresh on mobile platforms. I mean it's only relatively recently that there is a somewhat easy way to center a div vertically and horizontally on screen which does not seem like a total hack. CSS is basically a tool designed for the simple formatting styling of text documents which has been patched to the point of absurdity to support modern design needs. The iOS tools in particular are extremely powerful and purpose-built for the task.

hardwaresofton 8y ago
Could you be more specific about which part of CSS you find the most un-intuitive and sub-optimal for solving basic design problems? I want to remind you that the basics of CSS are targeting some piece of layout and applying styles to it, separate from the element itself. Basic HTML + CSS is like an hour or two worth of learning for an absolute beginner (especially with the simplicity of HTML5), and after that you're mostly limited by your imagination, for simple things. I'm just assuming you mean cascading and/or specificity as the thing that's unintuitive and sub-optimal, but other than that I'm having trouble differentiating basic CSS (e.x. using only element ids and styling rules) and how you end up styling components on mobile now... Maybe where we're differing is on a more fundamental level as far as whether styling should be separate from layout in the first place? But even then you have access to `style` attributes in HTML...
- skohan 8y ago
  Just look at the CSS spec (or collection of specs): https://www.w3.org/TR/css-2017 https://www.w3.org/TR/css-2017 It's enormous! How could anything be intuitive when there are hundreds of keywords? To give a more specific case, I would argue that CSS is eminently un-guessable. Take for example the CSS property clear: #MyDiv { clear: both; } "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. 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.
  - hardwaresofton 8y ago
    > Just look at the CSS spec (or collection of specs): > https://www.w3.org/TR/css-2017 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: #MyDiv { background-color: black; } 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.