Hacker News Reader

Comment by iammrpayments | Hacker News Reader

I’m forking Shopify’s polaris-react library for my personal use and some of the components are clearly made to people who don’t know how to use CSS.

For example, there’s a component called “InlineStack” which is just a javascript wrapper for a div with flex. This stuff drives me nuts.

View on HN

You're leaving out the most important bit of a component like InlineStack: the props [0]. Yes you can just apply `display: flex` to the div you're working on, but like any proper abstraction these guardrails make using flexbox correctly the easiest path forward (the "pit of a success").

[0]: https://github.com/Shopify/polaris/blob/eb6161f6b4e02679b5e8...

Because sometimes you just need a flex wrapper. And it's easier to see InlineStack everywhere in your JSX than deciphering the layout from mixed CSS. Whereas plain CSS separates some concerns away from HTML, it also intermingles different concerns together, like layout, positioning, spacing, look & feel, etc. At least with structural or utility components like Stack, Group, Flex, or whatever it makes it more obvious what the intent is.

Then you are doing something wrong about the layout & components in the page.

I'm in good company with all the modern UI toolkits and css libraries that have utility classes and container components which make the code I write reusable and composable. It's way better than using classes as "hooks" to style the markup and end up with a nesting of selectors to specifically target elements. You could compare it to HTML actually, I use a <stack> the same you would a <table>, and not reinvent with some custom wrapper like <div class="basketball-scores"> just to have a name attached so I can style it.

It's a bit like the <center> tag. A codebase that's littered with stuff like "InlineStack" is harder to work with and parse because the resulting div soup still requires extra styling, which is now both markup and CSS.

Why is it harder to work with? It makes it immediately obvious what the visual layout is and what the purpose of the component is and a lot of time all you want to do is have a flex on a component and you don't need other CSS to warrant yet another CSS class. It's the same reason why utility CSS was created (eg <div class="flex">). It also saves you from having to come up with a semantic name in your CSS for every wrapper.

Compare the following:

    <Stack gap={2} direction="row">
       <Box>
         <Avatar />
       </Box>
       <Box>
         <Button />
       </Box>
    </Stack>

    -----

    <MyCustomWrapper>
        <InnerChild>
          <Avatar>
        </InnerChild>
        <InnerChild>
           <Button />
        </InnerChild>
     </MyCustomWrapper>

I think this looks way simpler

  <div className=“flex gap-2”>
   <Button/>
   <Avatar/>
  <\div>

Then just apply the box styles using *: selector or directly in the component

The benefit of components like InlineStack is that the components then have names that semantically describe their purpose in the layout.

The fragmentation this creates is not worth it, we're building the tower of Babel of web technologies. If you look at 'modern' web applications every html component is rephrased into something like this 'inlinestack' crap.

The tower of Web Babel was built 5 years ago during peak React. It’s gotten better tbh as more competition has creeped into the web space due to React dropping the ball and resting on their laurels.

While I understand the gut reaction to seeing something like InlineStack, it’s not any different than a utility class except the abstraction has been made on the component level instead of the CSS level within a bunch of different components. The other thing is that these types of components provide a layer for abstraction that extends beyond the web. If I’m writing a app that targets web and native mobile, I can let the compiler decide which version to place in the build to take advantage of native features of the platform.

At a certain scale, programming becomes about maintaining consistency at said scale and less about the craftsmanship of an individual component. As a developer who also enjoys writing CSS and building layouts myself by hand, I understand your frustration but it’s misguided towards a group of developers who are trying to solve different problems.

We don’t need to implement everything that FAANG comes up with in their “innovation labs” and I 100% believe that there is a place for handcrafted code in applications for decades to come. But let’s not lose site of the fact that table saws haven’t replaced hand saws. They serve different purposes for different audiences and that’s okay!

Don’t forget that components also add more runtime complexity.

Not to be pedantic, but I am legitimately confused about how the babel of tower metaphor is being used here. In biblical lore, the flaw of the tower of babel was that it too successful as a unifying project. Is this what you mean in regards to react? It seems that other comment meant the opposite.

I’d personally prefer to write markdown instead of html, especially when writing comments on sites like these.

But I have to know that stars represent html italic tags (and bunches of other stuff).

Thankfully this has been standardised and every markdown parser knows what stars mean. So I only have to learn this once.

Most frameworks haven’t been standardised and that’s where the frustration lies.

Abstraction is good when it becomes a commonality, bad when it remains niche.

Why is InlineStack any more semantic than say FlexDiv?

Semantics is at some point arbitrarily agreed upon and memorized.

It's not, FlexDiv is just another name for Stack, they are describing the same aspect. Eg. you can imagine one CSS library using Flex, one Group and the third one Stack for the same concept, eg. some other UI frameworks use VBox and HBox. But it is still different from TopSectionHeader, SectionHeaderInner, SectionBodyWrapper, or whatever other names you have to come up with to give your component "semantic" meaning according to their content.

> to give your component "semantic" meaning according to their content.

This is one of the biggest pros for Tailwind, is that it leads people away from this misbegotten mindset. The scare quotes around "semantic" are right. It's amazing how many of the same people stress separation of concerns to separate content from presentation, then turn around and name the presentation after the content.

I instead use <div class=“flex”><\div> now.

If the class name is not enough for me to guess, I just hover the class name and the LSP will show me the applied styles.

Another issue is that Shopify changes the name of these components for no reason, for example InlineStack was once called Inline, then HorizontalStack, then InlineStack, while the flex box model hasn’t change since 2012

Naming things is hard but I feel like there is something odd about a class name referencing a single CSS property as it is basically an inline style: <div style=“display: flex”></div>

Not sure why it matters, <b> is the same as <span style="font-weight: bold">... If you want, name it "stack" or "vbox" instead of "flex".

Because flex just references the layout engine, and div intentionally has no semantic meaning. Fwiw I don't think InlineStack is a particularly good name either, but the criticism of this needs more justification than just "it's not how we did things in the past".

Semantics evolve over time. This is true of natural language and coding practice.

Reply on news.ycombinator.com