2 ms·

I'm unconvinced. For one thing, it's not CSS in Javascript... there's no cascade and no sheet, so it's just "styles in Javascript". (And, actually, this articl

by jmull 8y ago

I'm unconvinced. For one thing, it's not CSS in Javascript... there's no cascade and no sheet, so it's just "styles in Javascript". (And, actually, this article is only about a specific implementation.) The benefits listed are: - "confidence" - but I think that's a matter of understanding and mastering the tool, whether it's CSS or this library. As the co-creator of "styled-components" the author is no doubt a master of it. For for the general developer, perhaps a roughly equal effort would provide a similar level of mastery in each. So why not invest in the standard? "Painless Maintenance" - I would have to use it deeply before I could say too much about this. But I would guess that the danger of creating spaghetti code and a spaghetti of .css are pretty much the same and have the same root causes. "Enhanced Teamwork" - I don't see the connection here. The discussion in this section seems to be about mastery of the tools again. The team can learn how to manage styles though CSS-based techniques or they can learn through techniques based on coding Javascript and the capabilities of this library. Not that CSS doesn't have its issues. IMO, it's too low-level to use directly for many cases. There are two main problems: (1) missing the tools to manage complexity, like scoping, variables, and modules. (2) allows you a lot of freedom to do bad things. But there are libraries that address these that don't throw out the fundamental design of CSS, as styles-in-code does. To me it seems like a better approach to build on CSS to address its weaknesses rather than throw it out. The design of CSS itself came out the recognition that the tight coupling of style and content has drawbacks, and this is signing back up for those drawbacks. And you better neatly divide your presentation code from your business logic code and data access code or you'll get all that coupled tightly as well. I'm not dismissing this out-of-hand -- I haven't dug into styles-in-code approach so I don't have a deep understanding of it. But I'm not convinced it's worth the time to look more closely at it. Really, not even close.

jancsika 8y ago
> "Painless Maintenance" - I would have to use it deeply before I could say too much about this. But I would guess that the danger of creating spaghetti code and a spaghetti of .css are pretty much the same and have the same root causes. But as you pointed out, there is no cascade and no sheet. The styles apparently just apply to the stuff they are near in the code. No twisted logic to unwind, hence no spaghetti. The potential problem I could see is that changes which would have been easy with a cascade would require lots of changes to copypasta in this approach. Like, "take the spinach out of this ravioli and replace it with mushrooms." Everything is scoped properly and the task is obvious at a glance-- it's just annoying.
- wccrawford 8y ago
  Copying and pasting code multiple times creates spaghetti code. Why does copying CSS multiple times (once for each component) not also create spaghetti code? Many elements share style in a normal webpage. Font, for example. Having to specify the font in every file seems crazily redundant. And if you separate that out into a separate file that gets included in many places, you lose all the other benefits like "painless maintenance".
- jmull 8y ago
  > But as you pointed out, there is no cascade and no sheet. The styles apparently just apply to the stuff they are near in the code. No twisted logic to unwind, hence no spaghetti. Ah, well, things are not that simple. In a project of any complexity at all, the style of any individual element is typically dependent on a number of things which collectively make up the context of its presentation. E.g, the site theme, the component, and the individual element (at least -- usually there's an app-subsection and components are usually grouped into modules, etc.). Note that this is inherent to the problem space and is true whether you're specifying styles in code or styles in cascading style sheets or any other way. CSS provides a basic mechanism for dealing with this -- the cascade (though as I mentioned, IMO it is lacking some necessary features). Styles in code needs an answer as well. If you were to simply hard-code styles at the element-level (which you can do using either mechanism BTW though its probably easier with style-in-code), you'll have a hard time finding all the places in the code you need to update if you want to make a change. You'll be doing a lot of full code searches, reading code, and trying to put yourself into the mind of the person who wrote the code in the first place. The "spaghetti" in the metaphor are the lines of dependencies. We have spaghetti code when those lines are disorganized, entangled with irrelevancies, obscured, and otherwise unnecessarily difficult to deal with. In fact, if you hard-code a style on an element that is dependent on the site theme, app section, component module, and component, you'd be hiding those dependencies, which creates spaghetti code rather than avoids it. Now, I expect most developers would naturally try to avoid doing something like that. I'm just trying to point out why style-in-code doesn't really help you avoid spaghetti code.

by jmull 8y ago

jancsika 8y ago

> "Painless Maintenance" - I would have to use it deeply before I could say too much about this. But I would guess that the danger of creating spaghetti code and a spaghetti of .css are pretty much the same and have the same root causes. But as you pointed out, there is no cascade and no sheet. The styles apparently just apply to the stuff they are near in the code. No twisted logic to unwind, hence no spaghetti. The potential problem I could see is that changes which would have been easy with a cascade would require lots of changes to copypasta in this approach. Like, "take the spinach out of this ravioli and replace it with mushrooms." Everything is scoped properly and the task is obvious at a glance-- it's just annoying.

wccrawford 8y ago
Copying and pasting code multiple times creates spaghetti code. Why does copying CSS multiple times (once for each component) not also create spaghetti code? Many elements share style in a normal webpage. Font, for example. Having to specify the font in every file seems crazily redundant. And if you separate that out into a separate file that gets included in many places, you lose all the other benefits like "painless maintenance".
jmull 8y ago
> But as you pointed out, there is no cascade and no sheet. The styles apparently just apply to the stuff they are near in the code. No twisted logic to unwind, hence no spaghetti. Ah, well, things are not that simple. In a project of any complexity at all, the style of any individual element is typically dependent on a number of things which collectively make up the context of its presentation. E.g, the site theme, the component, and the individual element (at least -- usually there's an app-subsection and components are usually grouped into modules, etc.). Note that this is inherent to the problem space and is true whether you're specifying styles in code or styles in cascading style sheets or any other way. CSS provides a basic mechanism for dealing with this -- the cascade (though as I mentioned, IMO it is lacking some necessary features). Styles in code needs an answer as well. If you were to simply hard-code styles at the element-level (which you can do using either mechanism BTW though its probably easier with style-in-code), you'll have a hard time finding all the places in the code you need to update if you want to make a change. You'll be doing a lot of full code searches, reading code, and trying to put yourself into the mind of the person who wrote the code in the first place. The "spaghetti" in the metaphor are the lines of dependencies. We have spaghetti code when those lines are disorganized, entangled with irrelevancies, obscured, and otherwise unnecessarily difficult to deal with. In fact, if you hard-code a style on an element that is dependent on the site theme, app section, component module, and component, you'd be hiding those dependencies, which creates spaghetti code rather than avoids it. Now, I expect most developers would naturally try to avoid doing something like that. I'm just trying to point out why style-in-code doesn't really help you avoid spaghetti code.