[sktrdie]

To me an evident thing in UI development is that separating stylesheet from layout isn't really a thing anymore and the benefits of this separation aren't really that clear.

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.

So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?

[danShumway]

I work as a web developer for an enterprise-level software company.

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.

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't fall into the Facebook category, even if they think they do.

I've also taken some time to reflect on older companies I'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.

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 unlikely you will ever have a legitimate reason to duplicate a component name in multiple places.

Take it or leave it, just my experience, I'm sure other people would advocate different things. But it's by no means a settled debate, different people/orgs have come to different conclusions. It's just that one side writes a lot more blog posts.

[vlz]

BEM seems to be "Block Element Modifier"[1] if anybody wonders.

[1]: http://getbem.com/introduction/

[steve_taylor]

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

* naming of classes

* creating components whose sole purpose is styling

* eliminating unused stylesheets

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.

[tracker1]

I'm with you... Also, with theme context(s) it's easy enough to re-use theme values while keeping actual component styling with the component and in isolation... you remove a component, and the styling goes with it.

I've found it much easier to not have left over or unused cruft with component styling JSS/StyledComponents etc.

[mmorris]

I've never loved CSS-in-JS, but I do love CSS modules, which allows you to use proper CSS, while solving the biggest flaw in CSS - its global nature.

We import shared styles for typography, color, and some layout basics, but each component gets its own CSS file.

Used to be a hardcore Sass lover, and CSS modules took a small amount of getting used to, but worth it in the long run.

[frosted-flakes]

Do you use Sass with CSS Modules? I've found it to be an excellent pairing. I put shared styles/variables (like colours) in top-level Sass partials that individual component styles can import if they need them.

The only part I dislike about CSS Modules is having to use camelCased class names, or string references (styles['class-name']), which always feel awkward. I prefer kebab-case for CSS because it's a lot more flexible (more word separators: "-", "--", "_", "__", etc.), but I'm sure I'll adapt.

[emp_]

Agree with this smaller pain point in the vast peace of mind that CSS Modules bring.

I try to simplify as much as possible to a single word and repeat them a lot since there’s no collision, so you can usually expect a .container, .items, .item in most components, all top level but SASS helping with other annoyances like pseudo selectors, parents and nesting where it makes sense.

[evan_]

You just have to remind yourself that you aren’t writing css class names, even though it looks like css class names you’re picking js identifiers. Once I made peace with that it got a lot easier to write camelCase class names- and even switch back to kebab-case when necessary.

[bryanrasmussen]

I have two problems with BEM -

1. naming rules almost always lead to verbose inelegant names that humans would not really use at some point. (I said almost to ward off a war)

2. The part of CSS that I am generally better at than most developers is specifically in understanding the cascade. BEM, in order to help the people who are not good at the part that I am good at, pretty much makes it impossible to use what I am good at. I feel like I'm being Harrison Bergeroned every time I use BEM. But also the names I have to give things rankle.

[Blaiz0r]

I'm not a fan of BEM, I think it neuters one of the strongest parts of CSS

[8lall0]

I agree on the "inelegant" and "verbose", but the tradeoff is that every block became "obvious", so manteinance is much much easier than ever before.

[karaokeyoga]

As a front-end dev working on the web for roughly twenty years, I concur. I was late to the game with BEM and initially bristled since it goes against patterns I thought were working for me. Plus, it's not exactly terse. But, it won me over. I also agree with your comments on CSS-in-JS ... in practical terms, I feel BEM, properly executed, can handle the CSS portion of a large majority of projects.

[danShumway]

I always stuck BEM in the same category as other more dogmatic software approaches -- nice in theory, but not particularly practical for everyday development.

Then I tried in a practical, everyday development setting and found out I was just wrong :)

[wyqydsyq]

Despite trying using it a few times I've never seen the appeal in BEM, it's just bringing excessive and redundant verbosity to CSS class names as well as introducing unnecessary complexity in maintenance (e.g. if you change a class's name you need to also need to apply the change to any derivative class names)

[have_faith]

The appeal of BEM is that it offers module scoping through naming convention (because we had no other way to do it). And it stops you accidentally styling something you didn't intent to. If you have a .box with a .title inside and you write some css like .box .title { color: red; } You're telling the browser to find any title in box and make it red. But that's not what you wanted to do, you wanted to style box titles, not anything that happens to be in box with a .title, there could be sub-components with titles that you don't want to target. So instead you could write .box > .container > .left-panel > .title and maybe you've been explicit enough to get your intentions across, or you could write .box__title, which only titles scoped to box will contain if conventions are followed. This will also target the title no matter how you refactor the markup inside of box, if the title moves from the left panel to the right etc.

In the hundreds of projects I've used it on it has only make maintenance easier and intentions much more clear. Having a flatter css structure is much easier to work with too. The classes do look ugly though, and was a point of contention when I first looked at it. It was the same when I first saw JSX in React too. I hope a native scoped css solution becomes commonplace so we can avoid having to use a naming convention to achieve the same thing.

[wyqydsyq]

Sorry I meant I don't see the appeal in contrast to using CSS in JS solutions, BEM clearly offers better separation of concerns compared to traditional CSS, but this problem is already solved when using CSS in JS, because you explicitly import the styles you want to apply to an element, having to line up class names in your CSS and DOM is a non-issue as the classnames are autogenerated

[meerita]

Show us a pastebin of your compiled CSS. I can tell you from now your CSS is bloated with the uncountable properties and classes that repeat the same fixes and structures. You can program functional CSS and get better in way.

[danShumway]

My experience has been that the extremely minor performance benefits of functional CSS are not worth the extra time and energy you will spend on a multi-person team trying to mitigate duplicated class names and conflicting CSS functions.

You're welcome to disagree of course, I held a somewhat similar view to you until I tried BEM in a production setting.

And of course, different products call for differing methodologies. I haven't yet switched my personal blog over to BEM, for example.

[meerita]

I did many BEM projects. The idea behind Functional CSS is precisely that: let entire teams work without having to deal with naming. The project becames ultra-maintainable with the best legacy support.

My experience and all the data I've gathered about performance, even coding the equivalent in UCSS was shocking: 400% render speed improvement. 600% loading resources improvements and radical painting speed. To set you in context: one corporate website from a bank, had an average of 230kb resource loading, we lowered it to 33ms. 650ms rendering, we lowered to 90ms. Painting speed avged 90ms, we lowered to 12ms. If you plan things properly, you can radically improve the speed.

It's true that UCSS doesn't make that much sense for very small websites. Although you will render close to a plain HTML doc for sure. It makes sense when you need to repeat and componetize many things. There's when you gain true power. For example, in our tests, we made another equivalent 590kb uncompressed CSS file to 32kb total code need in UCSS. Compressed was about 12kb against 190kb compressed file. That's how you make great improvements.

[btbuildem]

I've discovered functional CSS some months ago, and I don't think I'll ever look back. Building everything with simple classes makes it easy to keep things consistent, appearance concerns live firmly in the style layer, and once patterns of classes used together start to appear, I can break the rules a little with SCSS and make classes like "button" ("ps ts cap rc2 box1") for the shorthand convenience.

[sheriffderek]

Once you add all of those classes, it's nearly impossible to add a developer who isn't used to it. It's also really hard for me to read. Tailwind / bootstrap etc - is a total deal breaker for me. I'll just get a different client. https://www.browserlondon.com/blog/2019/06/10/functional-css... I just can't imagine not writing CSS like this: https://maintainablecss.com/chapters/introduction

[meerita]

Specially if you work with reactive HTMl, like VUE or React. It's a win. Even with old MVC frameworks you can work confortably and have inmeasurable performance and development speed. The CSS becomes so easy to read, mantain. Changing things is way faster. Back then I needed to watch so many things to do the job. That's why I lost my OO CSS bias.

[BurningFrog]

But does bloated CSS matter?

If a human isn't going to read the CSS and the computer handles it without performance problem, I say no.

Those are of course two quite important ifs!

[meerita]

It matters.

First, not all users need your huge CSS file, in terms of downloading. Specially when they're on mobile phones and cache is crap.

A ~9000 rules CSS file will load and become COSSM slower than one that has 1000 or 10. It is linear increment. Make a test to see it for yourself.

A bloated CSS is more network time. Therefore, slower loading.

A bloated CSS will contain slower selectors, therefore slower rendering time and painting speed.

When you count all these things, you will see radical speed performance.

[BurningFrog]

Maybe. You need to measure these things and get a feel for the actual performance impact to make informed decisions.

Rule 1 of performance: Your intuitions are not reliable.

[saidajigumi]

Upthread, this commenter did post specific measurements from production projects.

[sk0g]

Does download size matter? Why bother with compression or minification?

https://jakearchibald.com/2019/f1-perf/

[sheriffderek]

No. No way. If you're CSS is a problem - then you are doing something really really wrong.

[GlennS]

I agree. While I'm in theory in favour of alternatives to CSS, my experience with css-in-jss using the React Material-UI framework has been pretty painful.

Definitely worse than my usual approach of writing some LessCSS and trying to be quite specific.

CSS is decent enough for overall theming, but quite bad for actually laying things out.

I think CSS's cascading and inheritance are bad design choices for most of the things that people actually use CSS for.

The alternatives need to do better. Or, I need to find out which alternatives are already better.

[jammygit]

I’ve been using BEM for about a week now and my first impression is that the readability of my code has improved a lot. It’s only a small project though.

[Waterluvian]

What made CSS in js harder for you?

[danShumway]

So obviously, all of this is just opinion me.

To start with, the only good way to do CSS in JS is to use a library that compiles your styles at runtime and inserts them into the document under a style tag. If you're not doing that, you lose the ability to use pseudo-elements and pseudo-selectors like hover. Probably 95% of the time, using CSS will be easier than setting up an event system to monitor all of this stuff yourself.

React's default tutorials will almost always tell you to pass styles manually into components, and ironically this reintroduces a lot of the problems with cascade that we're trying to avoid, because it's very easy to apply multiple styles in the wrong order or forget that some style is getting overridden. It can also make it very difficult to figure out where styles are coming from in code. So definitely don't follow that advice -- at the very least use a runtime compiler that doesn't spit out any inline styles.

There are plenty of libraries that will handle runtime compilation, but many of them come with performance costs. Enterprise software has a reputation of being slow, for good reason -- it usually is slow, because it's framework heavy and handles weird edge cases, and it's developed by multiple people over multiple years. I worry about performance more at work than I do on personal projects.

Aside from performance, I was finding that it was irritating to track class prefixes for dynamically compiled styles. One advantage of BEM is that it's really, really easy to debug. You always know exactly where a style is coming from, you always know where in code to find it, and you always know what class to use in the (hopefully rare) case that you need to hack together some selectors someplace in your code.

On the ecosystem side of things, there are a number of tiny annoyances if you're using React -- Webpack can handle live style updates if you're compiling a stylesheet. If you're compiling your CSS in Javascript though, Webpack can only reload the entire page. I found this made iteration and design a lot slower. Maybe there's some setting someplace to fix that behavior, but I couldn't find it and I didn't want to waste the time trying to build my own solution.

Finally, on a personal level, I was finding that putting my CSS in the same file as my component logic was making it very hard to organize everything and quickly grep sections of the code. This is probably personal preference for a lot of people, but I've found that disorganization is one of the biggest risks for large applications. Everyone tells me that you can still keep your JS-styles in a single file, and people will be good, and they won't split it across multiple sections of code or files -- I don't think that reflects the reality of most software development. I want the people I'm working with (and myself) to fall into a "pit of success" where organization is concerned.

Putting all of that together, the biggest thing was that I was messing around with all of this technology, finding that it was not as tightly integrated or as seamless as everyone said it was, was spending a lot of time debugging stuff, and I asked myself -- why?

IMO the biggest problems to solve with external CSS is style cascade, it's conflicting class names, it's selectors that apply across multiple components. BEM solves all of these problems for most codebases I've encountered, and doesn't require any extra libraries or frameworks. I hate debugging third-party code, and I can count on one hand the number of third-party libraries I've used on the web that I've never needed to debug. So a solution that solves all of the problems we face at work without introducing edge-case behaviors or extra dependencies is nearly always the right choice to make.

There is a rare case where you want to make your own custom CSS behavior that can only be handled through Javascript, but this is usually a bad idea because of performance concerns, and it's usually better to handle that as a separate, global polyfill anyway.

[Waterluvian]

Thanks for taking the time to share all of this. Definitely something for me to review a few times and think about.

For me the argument for was: maintaining a component tree and a style tree is a non-start. Too much for me to keep sense of.

But admittedly I didnt think too much further than that.

[untog]

I don't think CSS is outdated, it was just never that suited for the purpose people are using it for.

It still remains a fantastic way to style a document. The cascading nature of CSS works great in that context. But styling UI components is something quite different.

[wwweston]

I'll bite: what's different about styling a UI?

UIs are presumably more consistent/less varying than documents, so special cases and cascade overlaps should be less of a thing?

[dmitriid]

You accidentally apply a global style, and your entire UI is broken.

You need a different styling inside a specific visual component? You need to fight specificity and override a parent ir a grandparent or a global style.

In most UI systems this is not a concern.

[wwweston]

Those are certainly everyday concerns for people doing UI work, but I'm not sure I see how they're specific criticisms of CSS.

Global is going to mean global, regardless of whatever's managing the appearance, and the only UI systems I can imagine that wouldn't have a problem like this would be those with an entirely uncustomizable global UI presentation.

And for differing stylings inside a specific visual component -- generally, specificity is on your side here, most of the time the selectors involved in component-specific rules will naturally override global styles and you'd only fighting specificity if there's another component specific rule. If that's the case, though, what system would save you from conflicting rules applied to a specific component?

[geezerjay]

> You accidentally apply a global style, and your entire UI is broken.

That's only a concern if your UI elements depend on global styles, right?

Meanwhile, UI toolkits such as Qt use CSS (actually, Qt Style Sheets) to style UIs

[dmitriid]

> That's only a concern if your UI elements depend on global styles, right?

No.

   div {
      padding: 15em;
   }

This will affect all of your styles. CSS is a flat global namespace where you fight to style your local components by overriding rules with increasing specificity.

[HelloNurse]

Given the abundance of div elements in modern HTML, a CSS rule to set padding in all of them can only make sense in an unlikely minority of abnormally simple and constrained pages. Setting a huge, fixed 15em padding is also highly suspect.

You need to "fight" only in poorly designed systems; UI elements can pretend to have a hierarchical namespace and avoid all interference with other components, and pages can be designed systematically (e.g. box-sizing border-box vs. content-box, padding vs. margin, flex...) to simplify CSS rules.

div.arbitrary-ui-library-prefix-radio-button-group { padding:0.5em; border: 0.1em dotted rgba(0,0,0,0.3); }

div.arbitrary-ui-library-prefix-huge-padded-box-container { padding:15em; }

[geezerjay]

> This will affect all of your styles.

Your example affects all div elements which are not styled. If you also include class and/or ID specific definitions then your padding setting doesn't cascade and those are not affected. That's the point of CSS.

> where you fight to style your local components

That's not true. Style changes do cascade but they only cascade where the designer intends them to cascade. If a designer specifies that all div components shall use the same padding then you can't complain that all div components are using the same padding.

[majewsky]

> UI toolkits such as Qt use CSS (actually, Qt Style Sheets) to style UIs

This statement makes it sound like every Qt application uses CSS. That's not true. CSS is offered as a way to apply corporate branding to an application. I'm not aware of any FOSS Qt applications using CSS.

[geezerjay]

> This statement makes it sound like every Qt application uses CSS. That's not true.

The applications that are ok with the default style don't need to specify style. Nevertheless Qt is an UI toolkit that supports CSS styling.

> I'm not aware of any FOSS Qt applications using CSS.

And that's ok. Nevertheless I've already worked on a couple of Qt projects that used Qt Style Sheets extensively. In fact, that's pretty much the norm in any non-desktop project.

[Ambele]

That's a design decision by the ReactJS. Some consider this a flaw of ReactJS. Usually all CSS stylesheets are not included globally in all pages.

Also, if you need to apply a different style, you can just include your custom stylesheet after the global or base stylesheet. As long as you use either the same selectors or more specific selectors, you will be able to override the previous styles. This is assuming the previous developer didn't make the bad design decision of using !important which usually can't be overwritten.

[oefrha]

Separation of structure/content and presentation is great for textual content splintered with a few images, so it shines in blogs, news sites (in theory) and other types of informational sites (like documentation). I can give my blog a brand new look without touching any HTML markup, which is awesome.

This separation does get in the way in certain modern web apps, where content is basically scrambled garbage without proper presentation.

[Bahamut]

This is not quite necessarily true - I work at a tech giant and we've opted for using scss still & are quite happy with our choice.

[sktrdie]

Is your company actually building a platform for developers to build apps? Because that's what Apple is doing and they shifted away from using paradigms like CSS.

[Bahamut]

I work for Apple.

[jxub]

One of HN's wonderful moments :)

[ohrus]

CSS is not a paradigm. Whatever workflow you have for styling your pages and apps, it's all CSS in the end.

[orf]

CSS can certainly be described as a paradigm. It's a model you follow to style things on the web.

It also doesn't matter if it's all CSS in the end. At one particular end it's all manipulating assembly instructions, but I wouldn't call styling pages writing assembly. That is to say the underlying model or paradigm (styling in this case) doesn't really matter if you build an abstraction on top of it that hides that paradigm.

[ohrus]

Sure, you're right in that sense, thought I do not agree with the comparison to writing assembly.

The phrase "shifting away" from CSS is what I was addressing my initial comment towards, and I don't believe that using a paradigm on top of CSS would constitute a shift away from CSS... you're still using plenty of CSS rules whether you use styled-components, modules, SCSS, etc.

[underwater]

CSS is absolutely a paradigm. Not the specific style rules that exist in browsers, but the idea of selectors, specificity and stylesheets.

The fact that it's possible to define layout and styling using just style properties is the giveaway.

[rukuu001]

CSS that affects a components internal layout should be with the component.

CSS that affects the components appearance (colours, type etc should be with the document).

Of course, communication across teams will affect how successful this is. I’ve seen it go both ways.

PS - read ‘should’ as ‘makes my life easier’

[tracker1]

If using JSS, you can use a theme for common appearance settings, and use a context that carries that to all components. For example, material-ui uses this approach and I've found it works incredibly well in practice. I've added additional values as needed to my theme and this carries all the way down.

This includes additional/adjusted fonts, colors, etc.

[tannhaeuser]

CSS definitely can get in the way with far-distance effects in MVw apps. It tends to not being particularly representative of how you think about and modify the app during development, nor during maintenance. Though you still need media queries since you can't use these and eg :visited etc as inline styles. The reasoning behind this asymetry isn't entirely clear to me; it seems to be a syntactic accident.

Actually, I think CSS sucks at most things. Now CSS grid and flexbox are sold as solutions for long-standing layout deficiencies - and they undoubtly are a progress over grid frameworks using floats. But the real question is what is gained by pretending we're editing a hierarchical document (using HTML envisioned for casual academic publishing like it's 1999) when we layer a layout engine on top of it complicated enough to abstract that 1999s HTML into a grid and constraint-based layout? Why not just write markup representing that conceptual layout in the first place? We now have an enormous syntax proliferation of a markup language with an additional, redundant, and idiosyncratic item-value syntax (CSS) but still can't specify layout constraints in their more natural form as systems of inequalities.

[dragonwriter]

> separating stylesheet from layout isn't really a thing anymore

It never was, layout is part of stylesheets. Do you mean separating content from presentation?

[lmm]

I've been saying this for over ten years. Glad the world is kind of coming around to it.

Almost all HTML is generated these days, and the information that's useful for styling is available in the same place as the information that's defining HTML. So generate the styling inline in the same place. If your address display component use a 14 point font, put that inline in the code that generates HTML for an address display component. If you need to change it for all addresses, you can change it in that code. If you need one address display to be special, use a subclass or whatever mechanism you would normally use for one special address display. Compress your HTML in transit if you're worried about the inline styles wasting bandwidth.

[chrshawkes]

Already addressed earlier but inline styles ignore media queries so you may have missed the entire Web 3.0/4.0/responsive web design etc which occurred in 2012.

[lmm]

You mean changing the layout to be less useful on mobile (or occasionally making the layout less useful on desktop and changing to a better one on mobile)? Yeah, I'm pretty happy to have avoided that one.

[chrshawkes]

I don't blame you lol

[jjcm]

Personally I prefer a mix of both. For reusable components, I prefer inline styles. These are things that shouldn't be mutable without creating an exception to the design language. For basic page layout, standard stylesheets all the way. I shouldn't have to know react to make a marketing page that has nothing dynamic on it, but I'd still like to be able to reuse existing components on that page easily.

Recently I've been using webcomponents a lot for this, mainly because it makes the code accessible for those who don't know javascript and don't have an environment set up - just load the script at the top of the page and you can use <my-component> wherever you want in the html with the styling/functionality already taken care of. With those in place anyone can update a css file to lay things out appropriately.

[thrower123]

I don't think it ever made sense.

The biggest problem with CSS is that it is essentially global state, and you can get tricky action-at-a-distance effects that you never considered if you happen to wrrite some ids that something else is expecting to own and their selectors are poorly written. Or you can monkey-patch over it and break other things.

Tightly scoping things can make CSS workable, but requires discipline. And things that require discipline to do right don't scale well.

[karaokeyoga]

I agree. I have moved away from using IDs for CSS, though, as have a lot of other front-end developers. I use IDs strictly for JavaScript now. I was a happy user of IDs for CSS for probably twenty years but the transition away from that was largely painless and I don't feel like I lost anything along the way.

[reaperducer]

to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?

As with anything in technology, it depends on the task and what you're trying to achieve.

The size of the site is a major factor, as is how optimized the owner wants it to be.

Saying that "big companies are definitely moving away" from anything is always going to be a gross and inaccurate generalization.

[otabdeveloper4]

HTML isn't about UI. Never has been and never will.

The pain will continue until people understand.

[majewsky]

HTML/CSS/JS is arguably the most successful UI platform in the world, so this is obviously wrong. You just want HTML to not be about UI.

[otabdeveloper4]

Something can be "not about UI" and "the most successful UI platform in the world" at the same time.

Many such cases. :)

Point is, HTML is a document format, not a UI toolkit. That's how it was designed and that's how it continues to evolve.

This is probably not a ideal situation, but trying to change it now probably won't do any good.

[contravariant]

Well like it or not but the rise of REST APIs suggests that HTTP is extraordinarily well suited to use as a general interface so it's not too surprising that the related markup language HTML has found similar use as a user interface.

[sureaboutthis]

> Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout

That's what we call JavaScript and CSS. You can do that without React and my company has been doing that for 15 years quite successfully--with separation of the elements and styling.

How do you think SwiftUI and React do such things? With JavaScript and CSS!

(Sorry if I have factual errors about SwiftUI cause I really don't know anything about it.)