Hacker News Reader

Comment by aphextron | Hacker News Reader

Having tried every alternative imaginable, component based CSS is the way to go. There's a legacy in web development of viewing CSS as something separate from structure and logic because of what the web used to be; a collection of static pages with style sheets for typography and layout. But as soon as you start building any kind of non-trivial application, this model breaks down. The only way to do it is small, atomic, composable components with fully self contained styles and minimal inheritance.

View on HN

because of what the web used to be

You make it sound like a bad thing.

The web is a lot of things for a lot of different use cases. There may be a use case for stuffing all JS into javascript, and base64 encoding all images inline, and maybe even for cramming web fonts into a page via JS, if that's possible. But that's not "the modern web." That's just hype.

The modern web is the right tools and strategies for the job.

Many of my sites are focused to low-education, low-ability, and marginalized people. That means accessibility, semantic coding, standards compliance, and clarity are paramount.

The "model breaks down" only when you're not organized, or fail to document properly.

Your sites may be games or whiz-bang SPA's, and JS is good at those things, and maybe shoveling everything into JS works for you.

But to say that "the only way" to do anything on the web is the height of hubris, and closed-mindedness. How will you know when the next great thing comes along, if you've already committed yourself to an "only way?"

I think his point was more that we're developing the web building over foundations set with the idea of static documents in mind, for far different use cases that were originally intended. It does raise a point over whether we should consider a new design.

>But to say that "the only way" to do anything on the web is the height of hubris, and closed-mindedness. How will you know when the next great thing comes along, if you've already committed yourself to an "only way?"

It's not the only way to do web development. But it's the only way to structure UI for an application. It's the pattern native developers have settled upon and used for decades. That's why it's been so frustrating for me waiting to see this paradigm come to web development. It's what iOS/Android/MacOS developers have enjoyed for years.

The tooling is finally mature now, and it's actually fun to develop for the web these days. But before the modern React/Babel/Webpack development environment, it was really tough to build large scale maintainable SPAs without massive expertise. There were things like GWT, Closure, Backbone, etc. But the sort of "batteries included" UI frameworks and IDEs that developers enjoyed in native development was nonexistent on the web until recently.

> it's the only way to structure UI for an application

No, it's not. Want consistency in all your text boxes/links/buttons? Are you going to copy/paste or inherit from a base button component or define the general common styles in one place and have the browser automatically apply them with 0 thought.

Need a button to be different - then do inline styles or more specific selector(incl. CSS in JS) or use !important.

As parent poster said, definitively stating there is only one true™ way to do something is the height of hubris.

> That's why it's been so frustrating for me waiting to see this paradigm come to web development

Inline styles were the norm for quite a long period of time...

In fact inline styles came first!

Here's roughly how I do it[1] ...

    import Button from '@material-ui/core/Button';

    export MyComponent = ({actions}) => (
      <Button 
        variant="outlined" 
        color="primary" 
        onClick={actions.save}
      >
        Save
      </Button>
    );

[1] https://material-ui.com/demos/buttons/

> Many of my sites are focused to low-education, low-ability, and marginalized people. That means accessibility, semantic coding, standards compliance, and clarity are paramount.

Those are nice! But they don't require that it be easy to swap out one global CSS for a completely different one. Which is what is accused of "breaking down" in the post you replied to.

I think the real issue is people ignore CSS while building applications. You see the same issue when people try and the database or other critical component. That always results in a hacky mess that gets worse over time.

Know your tools.

Netscape had CSS in Javascript in 1996

https://en.wikipedia.org/wiki/JavaScript_Style_Sheets

And they had server-side JavaScript a year before that: https://hacks.mozilla.org/2012/01/javascript-on-the-server-g...

Could you elaborate on what component-based CSS is for the uninformed? A cursory Google search indicates that it's a technique for using CSS in JS, but I'm not sure how I would go about doing it. Does it imply some web component framework?

Perhaps something like Styled Components?

https://www.styled-components.com/

Instead of having files that apply styles globally to your application, the styles live down in files or data structures as close as possible to the component it applies to, where it belongs.

It's not super complicated, just apparently controversial.

In your $complex_app you probably have JS generating most (if not all) of the HTML seen on the page. CIJ just says that the JS should generate the styles as well so that each component in your page is self-contained.

Not a FE dev, so this may be naive but CSS cascades which means these components may rely on external css state. How is that handled and still qualify as self-contained?

When you render your components, you do so in a Shadow DOM where CSS neither enters nor leaves.

https://developers.google.com/web/fundamentals/web-component...

In practice nested behaviors, or class/id selectors will conflict. The more you rely on generalized stylesheets the harder it is to maintain. I've been developing mostly web based applications for 23 years now (started before CSS).

Centralized/shared CSS can work great in a content focused site. It works horribly in an application where component behaviors might share common terms, and potentially clash with natural naming for styles or nested definitions in particular. You only have to look at how most developers create hacky patches on top of Bootstrap, as opposed to using the source the way it was meant to be.

CIJ is a much more sane approach to application components. Look at the material-ui component library for a great example (which uses react-jss). Being able to reuse configuration from a swappable theme has worked great in an application that may have differing configurations based on deployment.

I've been developing mostly web apps for a long time too, 17 years, and I disagree. Well, I agree that a single, massive stylesheet file becomes difficult to maintain very quickly, but that or component based CSS that eschews inheritance are not the only ways to go.

Personally, I prefer to use Sass, logically separated into files - one with variables, another with global and general styles that are inherited, and then one for all buttons, one for all forms, one for all modals etc.

I find this middle ground works well, keeps styles consistent, is DRY 'enough', and is easily maintainable.

There are also CSS modules that are a middle road between CSS in JS and classic Sass stylesheets.

Right now, the application I'm working on supports the following feature in terms of styling/colors. Baseline settings, per-deployment/client settings (app deployed to different clients with a differing configuration), app configuration post-deployment configurable settings application wide, and post-deployment configurable settings per user.

With CSS in JS, I just have to deepmerge some objects (from JSON), and poof, it all just works. Without this it's either a rube-goldberg contraption that builds from styling on demand either from sass, or monkey patching styling.

I've done large projects with JSS and CSS/SCSS. I'll take CSS in JS (JSS). Yes, the syntax is slightly more annoying, having to wrap selectors as strings, and wrap values as strings (mostly). Though, I can pass in values from both a theme (injected with the options above) as well as handle manipulation of values at the component (ex: padding: theme.spacing.unit * 2). It's got all of the advantages of SCSS and more. The difference is mostly syntax for keys. paddingLeft vs padding-left.

>Does it imply some web component framework?

Not particularly. You can use pretty much any modern framework, they are all using a component based architecture for the most part. Vue, React, Polymer, even native web components are usable now. Here's an example of how Ember does it:

https://github.com/ebryn/ember-component-css

It's just about breaking down your pages and views into small components which can be reused and maintained separately. Instead of having one giant stylesheet with a deep inheritance of cascading classes, you just have a a bunch of components that are imported and namespaced by the compiler. That extra layer of abstraction gives you the ability to organize your project in a way that isn't beholden to the specific quirks of CSS, and removes the mental burden of things like SMACSS from the developer.

This is easily done using SASS components as well. No framework needed.

It depends on how you want to structure your app.

If you want all stylesheets living under src/stylesheets or if you would rather have them each live inside a component folder.

The latter allows for better portability of components but you generally will need a build system.

All of our components are contained in a folder specific to that component, and include the JS (Vanilla ES6), SASS, and template markup.

I prefer material-ui [1], a material design component implementation for react. It uses react-jss with some plugins under the covers. It's been very intuitive to use the global theming combined with some options.

[1] https://material-ui.com/

I've been trying to tell this to people for years:

https://news.ycombinator.com/item?id=14804175

Our product, Elevate Web Builder, has been using component-based visual controls with no CSS since 2014. It's modeled on the traditional way of doing components/controls in Delphi's VCL and .NET's WinForms, with a splash of WPF in terms of how control interfaces work.

Component-based CSS using Interoperable CSS + Sass, importing your CSS into JS but then using a build system to extract all of your component CSS into it's own set of files to allow for caching.

It's a complicated pipeline but it's pretty unbeatable when it comes to writing DRY, reusable, maintainable code. Everything is namespaced automatically and you can go from writing unweildly BEM class names to short, succinct and descriptive classes.

The only way to do it is small, atomic, composable components with fully self contained styles and minimal inheritance.

I think this may be the best way, yes. It's not the only way but it feels like a well formed statement otherwise.

Is this what ghci-hs and the like might be giving us? Hard to learn, hard to apply but composition is a given and typing and inheritance come along to help?

What about sass modules? Independent .scss files per component, with no class name clashes. Or are you counting that as css in js?

Do you class your sass like `.fooco-app-area-feature-component {...`? Because you have to be extremely judicious when you do. You also have to be very careful of nested behaviors.

Personally, I love react-jss as it's integrated with the material-ui library. Theme configuration flows in easily for reusable options, while behaviors are completely isolated. IMHO it's a far more natural experience overall.

I will say that having to mix selectors and strings is slightly harder than writing direct CSS, and using the camelCaseOption over css-case-option takes getting used to. It's been so worth the tradeoff in the couple applications I've used this approach with so far. Managing and injecting separate style paths, inheritance from a configuration sheet, themes, etc was always more difficult with scss/less.

> Do you class your sass like `.fooco-app-area-feature-component

No, that’s the whole point of modules, use whatever class names you want, when compiled the actual class name has a small randomly generated string appended to it to prevent clashes with styles for other components.

> I will say that having to mix selectors and strings is slightly harder than writing direct CSS

I just use interpolation, e.g.: className={‘btn-sm ${styles.whateverClass}’}

And when you want one color for one deployment of your application, vs a different color for another deployment?

Or you want to reuse Configuration values across A and B components, but C and D components are a different variant. All of which are configured differently on different deployments (application deployed to different clients with different themes).

> And when you want one color for one deployment of your application, vs a different color for another deployment?

Easy, have the build process select a different variables file to be imported by the entry point, with different colour variables per deployment. You ask the question in an accusatory manner as if you think this is difficult.

> Or you want to reuse Configuration values across A and B components, but C and D components are a different variant. All of which are configured differently on different deployments (application deployed to different clients with different themes).

What exactly do you think is stopping you from programmatically selecting styles in this situation? I’m not getting where you think the difficulty is arising.

And when the variables are configurable in the application? then the options are...

    a) setup the entire build toolchain for SCSS in the application

    b) deepmerge some JSON, and have the app use that.

I've had to do it both ways... B is far easier to manage.

So when you have user configurable sass variables, css in js might make things easier. That seems like a fairly narrow use case, I’m not willing to sacrifice separation of styling everywhere in every component in every react app because it makes user defined style variables somewhat easier.

Indeed, I’d be willing to put in the extra work to keep it if I did require such functionality - probably this is as simple as loading the scss variables from json, so I doubt there’s a significant workload involved.

You can still inherit baseline styles via a common theme that gets injected... See material-ui[1] which uses react-jss[2] configured with appropriate plugins, being able to customize components using said theme is far easier than any SCSS setup I've used. It's really, really nice to use in practice. It's just a slightly different syntax, and if you REALLY want to, you can still put your styling config in a different file from your component rendering.

[1] https://material-ui.com/ [2] https://www.npmjs.com/package/react-jss

I use SASS in my React app, but it runs with CSS modules in webpack so you have no worries about class name collisions. It will rewrite a class name like 'wrapper', to 'MyComponent_wrapper_<shortHash>'.

The SASS is still sort of a parallel codebase in a sense, and doing things like defining constants in SASS that also need to be consumed by the Javascript isn't easy like it would be in pure Javascript.

Another issue is constants that need to be different based on deployment, or configurable in an admin section of the application.

This is exactly what we do, and suffer zero issues. You have the globals (color scheme, typographical rules), and then you have the component-based, scoped SASS.

I don't see any reason to do it any other way, and it scales just fine for the systems we build.

Reply on news.ycombinator.com