5 ms·

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 s

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.

weberc2 8y ago
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?
- matte_black 8y ago
  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.
- arethuza 8y ago
  Perhaps something like Styled Components? https://www.styled-components.com/ https://www.styled-components.com/
- Spivak 8y ago
  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.
  - JustSomeNobody 8y ago
    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?
    - Spivak 8y ago
      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-components/shadowdom#styling https://developers.google.com/web/fundamentals/web-component...
    - tracker1 8y ago
      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.
      - GordonS 8y ago
        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.
- deleted 8y ago
  [deleted]
- aphextron 8y ago
  >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 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.
  - vanadium 8y ago
    This is easily done using SASS components as well. No framework needed.
    - kakarot 8y ago
      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.
      - vanadium 8y ago
        All of our components are contained in a folder specific to that component, and include the JS (Vanilla ES6), SASS, and template markup.
- tracker1 8y ago
  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/ https://material-ui.com/
TimJYoung 8y ago
I've been trying to tell this to people for years: https://news.ycombinator.com/item?id=14804175 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.
Retric 8y ago
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.
reaperducer 8y ago
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?"
- kace91 8y ago
  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.
- aphextron 8y ago
  >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.
jf- 8y ago
What about sass modules? Independent .scss files per component, with no class name clashes. Or are you counting that as css in js?
- tracker1 8y ago
  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.
  - jf- 8y ago
    > 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}’}
    - tracker1 8y ago
      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).
      - 8y ago
kakarot 8y ago
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.
hackthemack 8y ago
Netscape had CSS in Javascript in 1996 https://en.wikipedia.org/wiki/JavaScript_Style_Sheets https://en.wikipedia.org/wiki/JavaScript_Style_Sheets
- smacktoward 8y ago
  And they had server-side JavaScript a year before that: https://hacks.mozilla.org/2012/01/javascript-on-the-server-growing-the-node-js-community/ https://hacks.mozilla.org/2012/01/javascript-on-the-server-g...
ggm 8y ago
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?

weberc2 8y ago

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?

matte_black 8y ago
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.
arethuza 8y ago
Perhaps something like Styled Components? https://www.styled-components.com/ https://www.styled-components.com/
Spivak 8y ago
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.
- JustSomeNobody 8y ago
  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?
  - Spivak 8y ago
    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-components/shadowdom#styling https://developers.google.com/web/fundamentals/web-component...
  - tracker1 8y ago
    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.
    - GordonS 8y ago
      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.
deleted 8y ago
[deleted]
aphextron 8y ago
>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 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.
- vanadium 8y ago
  This is easily done using SASS components as well. No framework needed.
  - kakarot 8y ago
    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.
    - vanadium 8y ago
      All of our components are contained in a folder specific to that component, and include the JS (Vanilla ES6), SASS, and template markup.
tracker1 8y ago
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/ https://material-ui.com/

TimJYoung 8y ago

I've been trying to tell this to people for years: https://news.ycombinator.com/item?id=14804175 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.

Retric 8y ago

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.

reaperducer 8y ago

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?"

kace91 8y ago
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.
aphextron 8y ago
>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.

jf- 8y ago

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

tracker1 8y ago
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.
- jf- 8y ago
  > 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}’}
  - tracker1 8y ago
    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).
    - 8y ago

kakarot 8y ago

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.

hackthemack 8y ago

Netscape had CSS in Javascript in 1996 https://en.wikipedia.org/wiki/JavaScript_Style_Sheets https://en.wikipedia.org/wiki/JavaScript_Style_Sheets

smacktoward 8y ago
And they had server-side JavaScript a year before that: https://hacks.mozilla.org/2012/01/javascript-on-the-server-growing-the-node-js-community/ https://hacks.mozilla.org/2012/01/javascript-on-the-server-g...

ggm 8y ago

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?