7 ms·

The argument here is that CSS should be kept seperate because it is just the design and doesn't affect the behaviour. But this really isn't true. Want to create

The argument here is that CSS should be kept seperate because it is just the design and doesn't affect the behaviour. But this really isn't true. Want to create dropdown menus or tabcontrols? HTML just isnt enough, you need a whole set of styles in order to even create these controls. Additionally why am I able to do animation in CSS? Or insert new HTML elements?? This thing has grown far beyond simple colour switching and changing font sizes. In fact the seperation causes so much mental overhead, that we need interactive browser dev tools just to be able to find what styles are applied to what element. So ultimately the idea of putting everything in one spot, per component, is actually pretty reasonable.

ballenf 9y ago
Agreed. To take the author's metaphor a step further: the reason the screwdriver was broken is because we're trying to use it as a hammer. So replacing it with an actual hammer makes sense. And the thing is, we still have a fully functional screwdriver at our disposal (for global styles, e.g.).
- jerf 9y ago
  The metaphor is fundamentally broken anyhow. Hammers and screwdrivers are the same class of things. CSS and JS are not. One is a non-Turing-complete [1] language for declaring properties based on matching criteria. The other is a full programming language. Since metaphors are worse than useless when you already understand the thing, and I think we all understand the things in question, I won't find a better one. I'll just point out the original one is useless. I've considered JS taking over CSS more and more thoroughly inevitable for about four years now. The pressures on CSS are just too intense for non-Turing completeness to be anything but a leftover remnant of the dream of the "Semantic" web, doomed to fade the same way [2]. People want what only hooking a programming language up to the layout engine is going to give them. You can see it in CSS itself, as it grows ever more "declarative" styles that involve introspecting into the elements themselves, at their content, at their position in the tree, at their siblings.... CSS has long since let the camel into the tent. (In fact per my earlier comment today, https://news.ycombinator.com/item?id=15218359 https://news.ycombinator.com/item?id=15218359 , I would consider even CSS-in-JS to still be an intermediate phase to where we're truly going.) As for the fact that it will be a mess... well... yeah, it will. Welcome to the web. [1]: I know about the "Turing complete" CSS. It requires user interaction. Cute, but nothing more. [2]: "What? The semantic web is stronger than ever! Just look at what Google does with its search results!" ... which is a mix of some ad-hoc tags that are rarely the RDF tags the Semantic Web vision was based on, and a whole whackload of machine learning and language analysis. The Semantic Web vision was fundamentally that we can just hand tags out and everybody in the world will eagerly and accurately classify their stuff for you. It has failed (for reasons meditating on the previous sentence will make abundantly obvious), and what today seems to be the "Semantic web" is even moreso a repudiation of the original ideas, rather than confirmation.
  - wwweston 9y ago
    "RDF" != "Semantic Web". It's certainly one vision but it's not the vision. And the Google example is relevant because the primary reason it became so useful was that the semantics of the anchor tag lent themselves well PageRank, which was useful well before they had a "whackload of machine learning and language analysis" in play. It's probably fair to say the semantic web is about trying to make your data accessible. It includes considering that you don't know what the user agent is going to be, what degree of separation there is between that user agent and the user, how the people behind it might find whatever data you're presenting to be useful, what the capabilities of the user themselves is. So you make some effort to produce a resource that's legible to person or machine guided with reasonable direction. If you know there's an existing convention for expressing semantics that overlap with your domain, sure, use that, but if not, any thoughtful reflection of the underlying data will probably be useful. This does take some effort, and there's the question of whether or not it's worth it, particularly in a business context, because the unexpected uses of your data are often opportunities for others to not only add value but capture it. The Google example is relevant here. But the other thing is, in my experience, it's useful to you. There's a dictum attributed to Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." I've observed that when a web application project is oriented around thinking about relevant data and its semantically-accessible representation (that "R" in URL), the overall legibility of the project improves from an engineering perspective. Right now, with the approach of treating the browser as The VM That Lived™, it seems to me the gestalt is very much about worrying about the code. None of this is to say, though, that CSS is THE way to style documents. There's nothing about semantic resource oriented thinking that precludes using JavaScript or something else to control visual presentation. There's a lot of ways to use JS to do things worse than CSS, and CSS despite some serious warts does have a couple of decades of good thinking put into it as well, but I think there's a case to be made for examining approaches from JavaScript or another DSL (or DSSSL, heh).
    - jerf 9y ago
      "And the Google example is relevant because the primary reason it became so useful was that the semantics of the anchor tag lent themselves well PageRank, which was useful well before they had a "whackload of machine learning and language analysis" in play." I'm talking about how Google now knows business hours and addresses and other such things about local businesses. It isn't because local businesses went in and labeled their HTML semantically. I was interacting with one business a couple of months ago that literally left the stock photos of restaurants up on their webpage that look nothing like their current location, and didn't care, because as far as the business owner was concerned, if the menu was up, the website was basically done. "It's probably fair to say the semantic web is about trying to make your data accessible." I'm not just using the Semantic Web in a vague way. I'm using it in the way in which the term was used ~2005 (and a few years in each direction), when the religiousity around declarative CSS and such was at its fever pitch. It was not just a vague desire that somebody find something useful; people literally thought someday you'd be able to do things like import semantic print semantic.Website("http://www.chilis.com/").Get("CEO") and that the "semantic" would not require what it does today, which is "a whackload of ML and online services", but would all work with glorious web standards. It failed. It failed hard. It failed so hard and so big that there's still people who haven't processed its failure, because they still think something like "it hasn't been tried", without realizing that that's how hard it failed... it was such a failure that it wasn't even a thing that could be tried because it was too impractical. But every once in a while the idea still pops up like a shambling zombie that doesn't realize it's been made dead twice over. CSS itself isn't vestigial, but a lot of aspects of its design are, including a lot of people's vague hopes about how maybe someday it'll sort of kinda become "Semantic" someday if we just keep hoping hard enough, despite its decade+ record of failure on that front. If somehow the web had been nothing but style tags until today, and we set out to replace CSS, I seriously doubt the result would be CSS again; it would probably be a JS extension.
- talmand 9y ago
  It's more like a screwdriver with a fancy attachment that makes the screwdriver look cool but harder to use.
look_lookatme 9y ago
By far the most elegant solution I've found for this is TypeStyle [0]. Composable typed JS objects-as-CSS are a revelation and lend themselves to the kind of abstraction/extraction that most devs do everyday. In contrast, inline parsed CSS such as styled-components seems nuts to me. [0] https://typestyle.github.io https://typestyle.github.io
- charrondev 9y ago
  I’ve very glad you posted this. After trying and hating styled-components, this seems like exactly the solution I was looking for.
  - cmbsw 9y ago
    What do you hate about styled-components?
    - choxi 9y ago
      Not the op, but the big thing is that the styles are just strings instead of a JS object so you lose a lot of the modularity and composability benefits of writing it "in" JavaScript. The syntax was also awkward to me at first: const StyledLink = styled(Link)` color: palevioletred; font-weight: bold; `; I thought in JS you couldn't invoke a function without the parenthesis, but apparently you can if you interpolate the string with backticks first? I've done a lot of JS development and I've never seen that before, so while it's nice that it's cleaner it just got in my way of understanding what's going on. I'd rather just do: const StyledLink = styled(Link)({ color: "palevioltred", fontWeight: "bold" }) It looks basically the same but is immediately intuitive and much more powerful since the styles are objects instead of a string. (Edited for some formatting)
      - cmbsw 9y ago
        Styled components uses tagged template literals so they aren't just strings and are very flexible. This blog post is a great explanation http://mxstbr.blog/2016/11/styled-components-magic-explained/ http://mxstbr.blog/2016/11/styled-components-magic-explained.... For example const Button = styled.button` font-weight: {props => props.active ? 'bold' : 'none'} `; <Button active > This will be bold </Button> I've found it to be very handy.
bitexploder 9y ago
Just to add on here, I think you are exactly right. The author is pretty vague and doesn't provide any concrete examples. I always think, whenever working with JS/CSS/HTML to build a UI is just like any other UI system in terms of separating concerns and good programming practices. If the browser is what I have to work with then I am going to be writing JavaScript to manipulate HTML / CSS. No amount of CSS wizardy is going to really help. At the end of the day my logic is in JSS and I have to update a UI somehow. This is where and why design patterns like MVC are so popular. You can do all the ugly integrated JS/HTML/CSS in UI components just like in any native UI toolkit and then you update these thru your more pure "controller" logic that tries its best to just shove some data at the UI later and let it do its thing. Somewhere, if not MVC, but still with some separation between UI and your app logic you still have code that says "Okay, some state has changed, anyone that cares, here is the state that has changed." I think what the author laments is that is is extremely easy/tempting and common to just dig into those always available globals to solve design problems. This is why so many JS template and other frameworks exist, everyone is trying to find a nice way to do this that makes sense to them. So, I don't care what you do in your UI layer. If you want to make a rats nest of CSS in JS, go for it. If you want to create some beautiful HTML+CSS+JS design that minimizes JS and CSS weirdness, go for it. As long as you give me an API to deal with your thing and not some ass-ugly encapsulation breaking thing that makes me deal with the UI I can separate out the coding effort into better conceptual parts. This is where people get frustrated with modern JS. As an experienced programmer I can often get things done quickly in most environments and figure out the key parts pretty quickly, even when you are doing things like dependency injection or I have to go through your abstracted bi-bidirectionally dependent class hierarchy hell, I am okay with this. Drop me into a modern JS stack where in order to "do things right" I have to basically completely relearn CSS and figure out a dozen new esoteric and new JS micro frameworks and I just get annoyed. So far the only antidote I have found to this was Vue. It seems to support this more immediate dirty style of scribbling with DOM globals or the fancier modern things advanced JS/CSS UI folks know how to do that take days of `npm install` and packing and minifying and JSXing and whatever the heck else is going on in the JS world these days. Anyway, my point was, deal with it. CSS/HTML/DOM kind of suck as a UI layer, but they work. Hide it in your basement. Don't let it infect the rest of your code using well tread design and programming practices. Get on with your life. edit: Just to add, my one real criticism for the topic of discussion here is that it takes a LOT of esoteric, bleeding edge knowledge to "do the right thing" in JS/CSS these days. CSS is always adding new things and it creates a compatibility nightmare. As a casual occasional person that wants to write a UI using CSS/DOM I am never going to a.) reach the complexity where this matters and b.) have time to learn all that stuff to do it right. I am not convinced big teams with people dedicated to this chore can learn quick enough to keep up while still building a system that plays well with development teams and their speed of knowledge consumption/learning while trying to ship code. Old school things still work, are reliably, and solve the problem 80-90% of the time.
marksomnian 9y ago
I mean, HTML5/CSS3 has literally been shown to be Turing-complete. I think it's beyond the realm of "just styles"
codedokode 9y ago
The problem that you have described (relation between pieces of HTML, JS and CSS code) is solved by using components/widgets (for example: using BEM). I think the problem is that developers do not understand that CSS should be treated like other languages, and developers should organize it rather than let anyone write it as they wish. You don't write your server code in a single file without functions, using global variables and introducing side effects, you don't let a trainee edit important code without reviews, why do you do it with CSS? I remember reading that Github had something around 9000 CSS rules on a single page. Github developers are talented, but somehow they didn't pay proper attention to CSS code too. CSS code should be split into components, should be easy to analyze, and should be written so that minor edit of one widget won't break something else on another page. > In fact the seperation causes so much mental overhead, that we need interactive browser dev tools just to be able to find what styles are applied to what element. That means CSS is not well organized.
- gaastonsr 9y ago
  Agreed most problems can be solved by CSS only. My argument would not be we're solving something in CSS, we're simply removing the friction by having the HTML and CSS separate. I was one of the skeptics and felt CSS, SASS, or Less.js was good enough for me until one I day I was tired of setting up my loader in Webpack and I just dropped in styled-components. And then my JSX was more beautiful because my tags now had its purpose in the name. And I didn't need to worry about class names anymore. And adding variations (modifiers in BEM) was a breeze. And I didn't need to go back a forth between the CSS and the component to style it. It was just so much better that now I'm a convert. I still can work with CSS only but the convenience that styled-components brings to my components is invaluable. I hope this sheds some light as to why we prefer to write CSS in JS than writing good old CSS.
- batmansmk 9y ago
  "it's because you don't know the tool and don't use it properly" it is likely more a problem of CSS ergonomics more than a global developer and designer population problem, don't you think? We don't have heated debates at this level around SQL, HTML for instance. Granted, people complain about JS a lot as well.
bigbugbag 9y ago
I really disagree with your take on this for a simple obvious reason: disabling scripts means the page does not work anymore while disabling css means the page looks plain and basic but it retains functionality.
- batmansmk 9y ago
  If you do server side rendering, and you have to if you want your page to display with no script on, you can safely put your style in your JS with most of the techs around and have proper display.
ads1018 9y ago
THIS! CSS-in-JS just makes so much sense to me and it's a joy to use. Especially solutions such as Glamourous and Styled Components. I have a hard time relating to people who don't see its obvious advantages.

ballenf 9y ago

Agreed. To take the author's metaphor a step further: the reason the screwdriver was broken is because we're trying to use it as a hammer. So replacing it with an actual hammer makes sense. And the thing is, we still have a fully functional screwdriver at our disposal (for global styles, e.g.).

jerf 9y ago
The metaphor is fundamentally broken anyhow. Hammers and screwdrivers are the same class of things. CSS and JS are not. One is a non-Turing-complete [1] language for declaring properties based on matching criteria. The other is a full programming language. Since metaphors are worse than useless when you already understand the thing, and I think we all understand the things in question, I won't find a better one. I'll just point out the original one is useless. I've considered JS taking over CSS more and more thoroughly inevitable for about four years now. The pressures on CSS are just too intense for non-Turing completeness to be anything but a leftover remnant of the dream of the "Semantic" web, doomed to fade the same way [2]. People want what only hooking a programming language up to the layout engine is going to give them. You can see it in CSS itself, as it grows ever more "declarative" styles that involve introspecting into the elements themselves, at their content, at their position in the tree, at their siblings.... CSS has long since let the camel into the tent. (In fact per my earlier comment today, https://news.ycombinator.com/item?id=15218359 https://news.ycombinator.com/item?id=15218359 , I would consider even CSS-in-JS to still be an intermediate phase to where we're truly going.) As for the fact that it will be a mess... well... yeah, it will. Welcome to the web. [1]: I know about the "Turing complete" CSS. It requires user interaction. Cute, but nothing more. [2]: "What? The semantic web is stronger than ever! Just look at what Google does with its search results!" ... which is a mix of some ad-hoc tags that are rarely the RDF tags the Semantic Web vision was based on, and a whole whackload of machine learning and language analysis. The Semantic Web vision was fundamentally that we can just hand tags out and everybody in the world will eagerly and accurately classify their stuff for you. It has failed (for reasons meditating on the previous sentence will make abundantly obvious), and what today seems to be the "Semantic web" is even moreso a repudiation of the original ideas, rather than confirmation.
- wwweston 9y ago
  "RDF" != "Semantic Web". It's certainly one vision but it's not the vision. And the Google example is relevant because the primary reason it became so useful was that the semantics of the anchor tag lent themselves well PageRank, which was useful well before they had a "whackload of machine learning and language analysis" in play. It's probably fair to say the semantic web is about trying to make your data accessible. It includes considering that you don't know what the user agent is going to be, what degree of separation there is between that user agent and the user, how the people behind it might find whatever data you're presenting to be useful, what the capabilities of the user themselves is. So you make some effort to produce a resource that's legible to person or machine guided with reasonable direction. If you know there's an existing convention for expressing semantics that overlap with your domain, sure, use that, but if not, any thoughtful reflection of the underlying data will probably be useful. This does take some effort, and there's the question of whether or not it's worth it, particularly in a business context, because the unexpected uses of your data are often opportunities for others to not only add value but capture it. The Google example is relevant here. But the other thing is, in my experience, it's useful to you. There's a dictum attributed to Torvalds: "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." I've observed that when a web application project is oriented around thinking about relevant data and its semantically-accessible representation (that "R" in URL), the overall legibility of the project improves from an engineering perspective. Right now, with the approach of treating the browser as The VM That Lived™, it seems to me the gestalt is very much about worrying about the code. None of this is to say, though, that CSS is THE way to style documents. There's nothing about semantic resource oriented thinking that precludes using JavaScript or something else to control visual presentation. There's a lot of ways to use JS to do things worse than CSS, and CSS despite some serious warts does have a couple of decades of good thinking put into it as well, but I think there's a case to be made for examining approaches from JavaScript or another DSL (or DSSSL, heh).
  - jerf 9y ago
    "And the Google example is relevant because the primary reason it became so useful was that the semantics of the anchor tag lent themselves well PageRank, which was useful well before they had a "whackload of machine learning and language analysis" in play." I'm talking about how Google now knows business hours and addresses and other such things about local businesses. It isn't because local businesses went in and labeled their HTML semantically. I was interacting with one business a couple of months ago that literally left the stock photos of restaurants up on their webpage that look nothing like their current location, and didn't care, because as far as the business owner was concerned, if the menu was up, the website was basically done. "It's probably fair to say the semantic web is about trying to make your data accessible." I'm not just using the Semantic Web in a vague way. I'm using it in the way in which the term was used ~2005 (and a few years in each direction), when the religiousity around declarative CSS and such was at its fever pitch. It was not just a vague desire that somebody find something useful; people literally thought someday you'd be able to do things like import semantic print semantic.Website("http://www.chilis.com/").Get("CEO") and that the "semantic" would not require what it does today, which is "a whackload of ML and online services", but would all work with glorious web standards. It failed. It failed hard. It failed so hard and so big that there's still people who haven't processed its failure, because they still think something like "it hasn't been tried", without realizing that that's how hard it failed... it was such a failure that it wasn't even a thing that could be tried because it was too impractical. But every once in a while the idea still pops up like a shambling zombie that doesn't realize it's been made dead twice over. CSS itself isn't vestigial, but a lot of aspects of its design are, including a lot of people's vague hopes about how maybe someday it'll sort of kinda become "Semantic" someday if we just keep hoping hard enough, despite its decade+ record of failure on that front. If somehow the web had been nothing but style tags until today, and we set out to replace CSS, I seriously doubt the result would be CSS again; it would probably be a JS extension.
talmand 9y ago
It's more like a screwdriver with a fancy attachment that makes the screwdriver look cool but harder to use.

look_lookatme 9y ago

By far the most elegant solution I've found for this is TypeStyle [0]. Composable typed JS objects-as-CSS are a revelation and lend themselves to the kind of abstraction/extraction that most devs do everyday. In contrast, inline parsed CSS such as styled-components seems nuts to me. [0] https://typestyle.github.io https://typestyle.github.io

charrondev 9y ago
I’ve very glad you posted this. After trying and hating styled-components, this seems like exactly the solution I was looking for.
- cmbsw 9y ago
  What do you hate about styled-components?
  - choxi 9y ago
    Not the op, but the big thing is that the styles are just strings instead of a JS object so you lose a lot of the modularity and composability benefits of writing it "in" JavaScript. The syntax was also awkward to me at first: const StyledLink = styled(Link)` color: palevioletred; font-weight: bold; `; I thought in JS you couldn't invoke a function without the parenthesis, but apparently you can if you interpolate the string with backticks first? I've done a lot of JS development and I've never seen that before, so while it's nice that it's cleaner it just got in my way of understanding what's going on. I'd rather just do: const StyledLink = styled(Link)({ color: "palevioltred", fontWeight: "bold" }) It looks basically the same but is immediately intuitive and much more powerful since the styles are objects instead of a string. (Edited for some formatting)
    - cmbsw 9y ago
      Styled components uses tagged template literals so they aren't just strings and are very flexible. This blog post is a great explanation http://mxstbr.blog/2016/11/styled-components-magic-explained/ http://mxstbr.blog/2016/11/styled-components-magic-explained.... For example const Button = styled.button` font-weight: {props => props.active ? 'bold' : 'none'} `; <Button active > This will be bold </Button> I've found it to be very handy.

bitexploder 9y ago

Just to add on here, I think you are exactly right. The author is pretty vague and doesn't provide any concrete examples. I always think, whenever working with JS/CSS/HTML to build a UI is just like any other UI system in terms of separating concerns and good programming practices. If the browser is what I have to work with then I am going to be writing JavaScript to manipulate HTML / CSS. No amount of CSS wizardy is going to really help. At the end of the day my logic is in JSS and I have to update a UI somehow. This is where and why design patterns like MVC are so popular. You can do all the ugly integrated JS/HTML/CSS in UI components just like in any native UI toolkit and then you update these thru your more pure "controller" logic that tries its best to just shove some data at the UI later and let it do its thing. Somewhere, if not MVC, but still with some separation between UI and your app logic you still have code that says "Okay, some state has changed, anyone that cares, here is the state that has changed." I think what the author laments is that is is extremely easy/tempting and common to just dig into those always available globals to solve design problems. This is why so many JS template and other frameworks exist, everyone is trying to find a nice way to do this that makes sense to them. So, I don't care what you do in your UI layer. If you want to make a rats nest of CSS in JS, go for it. If you want to create some beautiful HTML+CSS+JS design that minimizes JS and CSS weirdness, go for it. As long as you give me an API to deal with your thing and not some ass-ugly encapsulation breaking thing that makes me deal with the UI I can separate out the coding effort into better conceptual parts. This is where people get frustrated with modern JS. As an experienced programmer I can often get things done quickly in most environments and figure out the key parts pretty quickly, even when you are doing things like dependency injection or I have to go through your abstracted bi-bidirectionally dependent class hierarchy hell, I am okay with this. Drop me into a modern JS stack where in order to "do things right" I have to basically completely relearn CSS and figure out a dozen new esoteric and new JS micro frameworks and I just get annoyed. So far the only antidote I have found to this was Vue. It seems to support this more immediate dirty style of scribbling with DOM globals or the fancier modern things advanced JS/CSS UI folks know how to do that take days of `npm install` and packing and minifying and JSXing and whatever the heck else is going on in the JS world these days. Anyway, my point was, deal with it. CSS/HTML/DOM kind of suck as a UI layer, but they work. Hide it in your basement. Don't let it infect the rest of your code using well tread design and programming practices. Get on with your life. edit: Just to add, my one real criticism for the topic of discussion here is that it takes a LOT of esoteric, bleeding edge knowledge to "do the right thing" in JS/CSS these days. CSS is always adding new things and it creates a compatibility nightmare. As a casual occasional person that wants to write a UI using CSS/DOM I am never going to a.) reach the complexity where this matters and b.) have time to learn all that stuff to do it right. I am not convinced big teams with people dedicated to this chore can learn quick enough to keep up while still building a system that plays well with development teams and their speed of knowledge consumption/learning while trying to ship code. Old school things still work, are reliably, and solve the problem 80-90% of the time.

marksomnian 9y ago

I mean, HTML5/CSS3 has literally been shown to be Turing-complete. I think it's beyond the realm of "just styles"

codedokode 9y ago

The problem that you have described (relation between pieces of HTML, JS and CSS code) is solved by using components/widgets (for example: using BEM). I think the problem is that developers do not understand that CSS should be treated like other languages, and developers should organize it rather than let anyone write it as they wish. You don't write your server code in a single file without functions, using global variables and introducing side effects, you don't let a trainee edit important code without reviews, why do you do it with CSS? I remember reading that Github had something around 9000 CSS rules on a single page. Github developers are talented, but somehow they didn't pay proper attention to CSS code too. CSS code should be split into components, should be easy to analyze, and should be written so that minor edit of one widget won't break something else on another page. > In fact the seperation causes so much mental overhead, that we need interactive browser dev tools just to be able to find what styles are applied to what element. That means CSS is not well organized.

gaastonsr 9y ago
Agreed most problems can be solved by CSS only. My argument would not be we're solving something in CSS, we're simply removing the friction by having the HTML and CSS separate. I was one of the skeptics and felt CSS, SASS, or Less.js was good enough for me until one I day I was tired of setting up my loader in Webpack and I just dropped in styled-components. And then my JSX was more beautiful because my tags now had its purpose in the name. And I didn't need to worry about class names anymore. And adding variations (modifiers in BEM) was a breeze. And I didn't need to go back a forth between the CSS and the component to style it. It was just so much better that now I'm a convert. I still can work with CSS only but the convenience that styled-components brings to my components is invaluable. I hope this sheds some light as to why we prefer to write CSS in JS than writing good old CSS.
batmansmk 9y ago
"it's because you don't know the tool and don't use it properly" it is likely more a problem of CSS ergonomics more than a global developer and designer population problem, don't you think? We don't have heated debates at this level around SQL, HTML for instance. Granted, people complain about JS a lot as well.

bigbugbag 9y ago

I really disagree with your take on this for a simple obvious reason: disabling scripts means the page does not work anymore while disabling css means the page looks plain and basic but it retains functionality.

batmansmk 9y ago
If you do server side rendering, and you have to if you want your page to display with no script on, you can safely put your style in your JS with most of the techs around and have proper display.

ads1018 9y ago

THIS! CSS-in-JS just makes so much sense to me and it's a joy to use. Especially solutions such as Glamourous and Styled Components. I have a hard time relating to people who don't see its obvious advantages.