5 ms·

I really really don't like the idea of having 3 different runtime libraries (or maybe even the same library with slightly different versions) loading at the sam

I really really don't like the idea of having 3 different runtime libraries (or maybe even the same library with slightly different versions) loading at the same time. It's quite unanswered how are they dealing with styling. There's always a specific percentage of styles being shared between components. Should we duplicate these styles? I see they are going to talk about it soon (Isolated CSS / Coherent User Interface / Style Guides & Pattern Libraries). One of the biggest joys that I had recently in front-end development is the idea of a one-way, cross-application shared state. This goes away, too. Maybe I'm just being hyper-conservative. I need examples of the benefits of this approach in something that it's not a simple product picker.

deleted 9y ago
[deleted]
pedalpete 9y ago
I'm assuming they've taken the example to the n-th degree. You're right to question why you would want 3 libraries, but it does happen. I'd think, the "right way" would be to have each feature's logic built as a micro-service and styling as a service. That way you have consistency where necessary, but divide up feature needs into more manageable chunks.
- hectorlorenzo 9y ago
  I agree, that's a nicer solution, but still one that could be solved working on a agreed set of principles on a shared "monolithic" framework. Part of the appeal of React and Vue is that you can think of components as black boxes with a sound API. Different teams can be mostly unaware of other teams' components, and this concept makes the chunks already manageable.
Kiro 9y ago
> There's always a specific percentage of styles being shared between components. I used to think that but nowadays I very seldom come across a situation where sharing styles make sense. I'm trying to make my components completely isolated, styles included. I'm doing CSS-in-JS and if I really need to share something (say a primary color) I import it from an explicitly shared module called "colors". This leads to some duplication but when I change something I know it will only affect that component.
- bartread 9y ago
  That might make sense in your case but, honestly, it runs entirely counter to the reason CSS exists. A big motivation for the development of CSS was to get away from the situation in the 90s where elements would have their own styling - complete with duplication - embedded in them using (sometimes non-standard) attributes. The situation back then made it a nightmare to apply a consistent style across a site, as well as bloating pages at a time when most people accessing the internet at home were doing so using a modem. Most people don't use modems any more, but many of them do use mobile devices, often with high latency connections depending upon network coverage and contention. In other words unnecessary bloat is still a problem, and that original motivation for CSS is still valid.
  - Kiro 9y ago
    I disagree. I don't care what the motivation was since I believe CSS with cascading styles and global declarations was a failure to begin with. I've built many sites using both traditional CSS, with standards like BEM and now CSS-in-JS and this is the first time it actually makes sense. I have yet to encounter a case where I miss the old way of writing CSS. I think applying "consistent styles" is a fallacy. It sounds like something you want but in the end it becomes a nightmare to maintain once you start sharing styles all across your app. What happens is that you overwrite stuff instead of rewriting because you don't know what rewriting a certain style declaration will affect. My main point however is that there are very few styles that actually make sense sharing between components. I gave one example; colors, but what else? Take stuff like padding and margin for example. It feels like they are something you want to be standardized but usually in big projects they become extremely context dependent and as soon as you need to deviate from the standard it becomes a headache. The bloat argument is invalid if you use a proper CSS-in-JS lib which compiles the styles to CSS classes.
- barryhoodlum 9y ago
  After using tachyons (http://tachyons.io/ http://tachyons.io/) I've gone the complete opposite direction. While tachyons takes it to an extreme, I found having many small classes that (generally) do one thing, then composing those classes in the HTML, is much nicer than giving each element one "semantic" class name and hiding all the complexity in the CSS, with the large file size and many duplicate rules that approach brings. You are then not scared of changing existing classes, as they are so simple. In fact you rarely have to change them after writing them the first time. Often you can build a whole new component without writing any new CSS. It works especially well with components, as it's OK if the HTML is "noisy" with many class names, as generally you're not dealing with large chunks of HTML at once.
juanuys 9y ago
> It's quite unanswered how are they dealing with styling. There are ways to deal with this in a large organisation. E.g. at GOV.UK we had a frontend toolkit: https://github.com/alphagov/govuk_frontend_toolkit https://github.com/alphagov/govuk_frontend_toolkit

deleted 9y ago

[deleted]

pedalpete 9y ago

I'm assuming they've taken the example to the n-th degree. You're right to question why you would want 3 libraries, but it does happen. I'd think, the "right way" would be to have each feature's logic built as a micro-service and styling as a service. That way you have consistency where necessary, but divide up feature needs into more manageable chunks.

hectorlorenzo 9y ago
I agree, that's a nicer solution, but still one that could be solved working on a agreed set of principles on a shared "monolithic" framework. Part of the appeal of React and Vue is that you can think of components as black boxes with a sound API. Different teams can be mostly unaware of other teams' components, and this concept makes the chunks already manageable.

Kiro 9y ago

> There's always a specific percentage of styles being shared between components. I used to think that but nowadays I very seldom come across a situation where sharing styles make sense. I'm trying to make my components completely isolated, styles included. I'm doing CSS-in-JS and if I really need to share something (say a primary color) I import it from an explicitly shared module called "colors". This leads to some duplication but when I change something I know it will only affect that component.

bartread 9y ago
That might make sense in your case but, honestly, it runs entirely counter to the reason CSS exists. A big motivation for the development of CSS was to get away from the situation in the 90s where elements would have their own styling - complete with duplication - embedded in them using (sometimes non-standard) attributes. The situation back then made it a nightmare to apply a consistent style across a site, as well as bloating pages at a time when most people accessing the internet at home were doing so using a modem. Most people don't use modems any more, but many of them do use mobile devices, often with high latency connections depending upon network coverage and contention. In other words unnecessary bloat is still a problem, and that original motivation for CSS is still valid.
- Kiro 9y ago
  I disagree. I don't care what the motivation was since I believe CSS with cascading styles and global declarations was a failure to begin with. I've built many sites using both traditional CSS, with standards like BEM and now CSS-in-JS and this is the first time it actually makes sense. I have yet to encounter a case where I miss the old way of writing CSS. I think applying "consistent styles" is a fallacy. It sounds like something you want but in the end it becomes a nightmare to maintain once you start sharing styles all across your app. What happens is that you overwrite stuff instead of rewriting because you don't know what rewriting a certain style declaration will affect. My main point however is that there are very few styles that actually make sense sharing between components. I gave one example; colors, but what else? Take stuff like padding and margin for example. It feels like they are something you want to be standardized but usually in big projects they become extremely context dependent and as soon as you need to deviate from the standard it becomes a headache. The bloat argument is invalid if you use a proper CSS-in-JS lib which compiles the styles to CSS classes.
barryhoodlum 9y ago
After using tachyons (http://tachyons.io/ http://tachyons.io/) I've gone the complete opposite direction. While tachyons takes it to an extreme, I found having many small classes that (generally) do one thing, then composing those classes in the HTML, is much nicer than giving each element one "semantic" class name and hiding all the complexity in the CSS, with the large file size and many duplicate rules that approach brings. You are then not scared of changing existing classes, as they are so simple. In fact you rarely have to change them after writing them the first time. Often you can build a whole new component without writing any new CSS. It works especially well with components, as it's OK if the HTML is "noisy" with many class names, as generally you're not dealing with large chunks of HTML at once.

juanuys 9y ago

> It's quite unanswered how are they dealing with styling. There are ways to deal with this in a large organisation. E.g. at GOV.UK we had a frontend toolkit: https://github.com/alphagov/govuk_frontend_toolkit https://github.com/alphagov/govuk_frontend_toolkit