<story><title>Relearn CSS layout</title><url>https://every-layout.dev/</url></story><parent_chain><item><author>danShumway</author><text>I work as a web developer for an enterprise-level software company.&lt;p&gt;Experimented a bit with CSS-in-JS, which is designed to get rid of this separation, and I found it to ultimately be harder to maintain than SCSS. This process was also what got me hooked on BEM after being initially pretty skeptical about whether it had any real value.&lt;p&gt;I now believe that BEM would meet the needs of most teams, with the exception of a few massive software houses like Facebook. And most companies don&amp;#x27;t fall into the Facebook category, even if they think they do.&lt;p&gt;I&amp;#x27;ve also taken some time to reflect on older companies I&amp;#x27;ve worked for, particularly some work I did at Oracle, which was for a reasonably large team spread across several continents. I think BEM would have been good enough for us there as well.&lt;p&gt;I would propose the following test: Is your front end in a monorepo? If so, BEM is probably good enough to solve any problems with scope and style conflicts. If your code can fit in a monorepo, I think its &lt;i&gt;unlikely&lt;/i&gt; you will ever have a legitimate reason to duplicate a component name in multiple places.&lt;p&gt;Take it or leave it, just my experience, I&amp;#x27;m sure other people would advocate different things. But it&amp;#x27;s by no means a settled debate, different people&amp;#x2F;orgs have come to different conclusions. It&amp;#x27;s just that one side writes a lot more blog posts.</text></item><item><author>sktrdie</author><text>To me an evident thing in UI development is that separating stylesheet from layout isn&amp;#x27;t really a thing anymore and the benefits of this separation aren&amp;#x27;t really that clear.&lt;p&gt;Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout and allow for much better accessibility, tooling, overall thinking of how UIs work.&lt;p&gt;So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?</text></item></parent_chain><comment><author>vlz</author><text>BEM seems to be &amp;quot;Block Element Modifier&amp;quot;[1] if anybody wonders.&lt;p&gt;[1]: &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;getbem.com&amp;#x2F;introduction&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;getbem.com&amp;#x2F;introduction&amp;#x2F;&lt;/a&gt;</text></comment>
<story><title>Relearn CSS layout</title><url>https://every-layout.dev/</url></story><parent_chain><item><author>danShumway</author><text>I work as a web developer for an enterprise-level software company.&lt;p&gt;Experimented a bit with CSS-in-JS, which is designed to get rid of this separation, and I found it to ultimately be harder to maintain than SCSS. This process was also what got me hooked on BEM after being initially pretty skeptical about whether it had any real value.&lt;p&gt;I now believe that BEM would meet the needs of most teams, with the exception of a few massive software houses like Facebook. And most companies don&amp;#x27;t fall into the Facebook category, even if they think they do.&lt;p&gt;I&amp;#x27;ve also taken some time to reflect on older companies I&amp;#x27;ve worked for, particularly some work I did at Oracle, which was for a reasonably large team spread across several continents. I think BEM would have been good enough for us there as well.&lt;p&gt;I would propose the following test: Is your front end in a monorepo? If so, BEM is probably good enough to solve any problems with scope and style conflicts. If your code can fit in a monorepo, I think its &lt;i&gt;unlikely&lt;/i&gt; you will ever have a legitimate reason to duplicate a component name in multiple places.&lt;p&gt;Take it or leave it, just my experience, I&amp;#x27;m sure other people would advocate different things. But it&amp;#x27;s by no means a settled debate, different people&amp;#x2F;orgs have come to different conclusions. It&amp;#x27;s just that one side writes a lot more blog posts.</text></item><item><author>sktrdie</author><text>To me an evident thing in UI development is that separating stylesheet from layout isn&amp;#x27;t really a thing anymore and the benefits of this separation aren&amp;#x27;t really that clear.&lt;p&gt;Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout and allow for much better accessibility, tooling, overall thinking of how UIs work.&lt;p&gt;So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?</text></item></parent_chain><comment><author>steve_taylor</author><text>I have the opposite experience. I’m in a React team that was doing BEM via Sass for a few years. Almost two years ago, we moved to Styled Components. The only real difference is that Styled Components automates&lt;p&gt;* naming of classes&lt;p&gt;* creating components whose sole purpose is styling&lt;p&gt;* eliminating unused stylesheets&lt;p&gt;It’s not like we became any less strict about specificity or used inline styles any more or less than we did with BEM. I find the differences to be purely logistical. Styled Components simply automates a lot of the grunt work and allows us to focus on more important things.</text></comment>