I have two things to add to your comment. Firstly, you're right, CSS in JS is a really great fit for the component model. It's also worth noting that that splitting a UI into small reusable components isn't a trend that is going away anytime soon. Not only is it great for simple blogs, it's nearly essential for larger more complicated apps. The semantic web is alive and well in the modern world of development. CSS in JS is a tool which ultimately ends up producing CSS that the browser interprets. If it is the right tool to solve a problem, why be so quick to shoot it down?
Secondly, I've been writing CSS in a professional capacity for the best part of a decade, so I don't think I've "got CSS wrong". CSS has limitations and choosing vanilla CSS over some other tool will have advantages and trade offs.
I guess my point is that as engineers, our job is to pick the best tool for the job. If that happens to be CSS, great, if not, pick something else that works. For me, recently, CSS in JS has been the right tool.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I guess I see people on Twitter demoing things using javascript objects to represent the style for (say) a button inside a widget. It's not usually doing anything more than you would using normal CSS, and I think it has a lot of drawbacks:
There are usually no consistent hooks so regular stylesheets will have a very difficult time affecting the way something looks. Why is that a problem? It's a problem for accessibility - if I want to add a custom stylesheet or use userstyles or anything, suddenly it's a whole lot harder if not impossible.
If I want to re-skin my site for a temporary christmas takeover, I'm out of luck, unless I import all the base styles and colours from a separate source, like a common javascript module or other kind of data store.
If you want to use the same component in multiple places, like in a sidebar, on a tablet, in a header, on someone's desktop with customised colour profiles, in print or as part of an app... you're either going to have to make new components or you're going to have to recreate media queries or the cascade, in javascript. I don't know why anyone would do that, but feel free to ELI5!
The "day job" project I'm working on is made up of about two thousand non-library JavaScript files, with a component based structure. It's not bloat, just gigantic; those files are not just sitting around taking up space. Managing the JS alone is work, so keeping a separation of JS and CSS ended up taking up more management time than development time.
We ended up doing a minimal baseline CSS that's very rarely modified these days, and then going component-based for the rest of the styles. It turned out to be the right tool for the job. Development is fast and flexible and performance is good. Not to say there aren't drawbacks, but for this project they definitely are overshadowed by the benefits.
When I'm doing a small personal project, I end up usually defaulting to a purer CSS based approach and not going for inline styles, since they're not so difficult to manage.
First of all, somehow this whole comment mostly read like how a politician would answer a question. That is, not actually provide insight, but talk meta. I'm not trying to be ad hominem, I'm just saying how it felt to me.
Splitting UI into small reusable components
From my experience it almost never actually works out like that. Write something reusable and next time it won't actually be usable like that.
One of your original points was that the browser only gets to interpret something it actually needs... Which brings me to the question: How does it save anything if now, instead of getting CSS rules by a .css file, it now gets CSS rules in a .js file? Also, how is your filtering logic on what CSS to actually present to the browser better than the browsers logic of parsing a CSS file, picking out what it actually needs?
I am inclined to trust the browser with being able to pick apart CSS that I wrote in a performant way (it's written in C++ too, and had hundreds of pairs of eyes on it in it's lifetime) rather than trusting me being able to present the right css to the browser at the right time. Also, I'm not sure but I assume it sets style attributes on the fly? Which would also not allow the browser to pre-parse and optimize CSS that was given to it in advance.
Why shoot it down when it's the right tool for the job?
Honestly, this way of phrasing it basically implies that it's a non-discussable given that it's the right tool and that critics are just trying to shoot down something they're ignorant about.
Wrote CSS for the better part of a decade, so I don't think "I've got CSS wrong"
I don't know, I've been writing CSS for like 13 years and while I do think I am quite proficient in it (by now), it doesn't mean this knowledge is a hard overwrite of everyone who disagrees with me. I mean, I disagree and think you've got CSS wrong, but more on the technical side. I elaborated above why.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey Ben,
I have two things to add to your comment. Firstly, you're right, CSS in JS is a really great fit for the component model. It's also worth noting that that splitting a UI into small reusable components isn't a trend that is going away anytime soon. Not only is it great for simple blogs, it's nearly essential for larger more complicated apps. The semantic web is alive and well in the modern world of development. CSS in JS is a tool which ultimately ends up producing CSS that the browser interprets. If it is the right tool to solve a problem, why be so quick to shoot it down?
Secondly, I've been writing CSS in a professional capacity for the best part of a decade, so I don't think I've "got CSS wrong". CSS has limitations and choosing vanilla CSS over some other tool will have advantages and trade offs.
I guess my point is that as engineers, our job is to pick the best tool for the job. If that happens to be CSS, great, if not, pick something else that works. For me, recently, CSS in JS has been the right tool.
I guess I see people on Twitter demoing things using javascript objects to represent the style for (say) a button inside a widget. It's not usually doing anything more than you would using normal CSS, and I think it has a lot of drawbacks:
There are usually no consistent hooks so regular stylesheets will have a very difficult time affecting the way something looks. Why is that a problem? It's a problem for accessibility - if I want to add a custom stylesheet or use userstyles or anything, suddenly it's a whole lot harder if not impossible.
If I want to re-skin my site for a temporary christmas takeover, I'm out of luck, unless I import all the base styles and colours from a separate source, like a common javascript module or other kind of data store.
If you want to use the same component in multiple places, like in a sidebar, on a tablet, in a header, on someone's desktop with customised colour profiles, in print or as part of an app... you're either going to have to make new components or you're going to have to recreate media queries or the cascade, in javascript. I don't know why anyone would do that, but feel free to ELI5!
Just have to say loved how you replied this question.
The "day job" project I'm working on is made up of about two thousand non-library JavaScript files, with a component based structure. It's not bloat, just gigantic; those files are not just sitting around taking up space. Managing the JS alone is work, so keeping a separation of JS and CSS ended up taking up more management time than development time.
We ended up doing a minimal baseline CSS that's very rarely modified these days, and then going component-based for the rest of the styles. It turned out to be the right tool for the job. Development is fast and flexible and performance is good. Not to say there aren't drawbacks, but for this project they definitely are overshadowed by the benefits.
When I'm doing a small personal project, I end up usually defaulting to a purer CSS based approach and not going for inline styles, since they're not so difficult to manage.
First of all, somehow this whole comment mostly read like how a politician would answer a question. That is, not actually provide insight, but talk meta. I'm not trying to be ad hominem, I'm just saying how it felt to me.
From my experience it almost never actually works out like that. Write something reusable and next time it won't actually be usable like that.
One of your original points was that the browser only gets to interpret something it actually needs... Which brings me to the question: How does it save anything if now, instead of getting CSS rules by a .css file, it now gets CSS rules in a .js file? Also, how is your filtering logic on what CSS to actually present to the browser better than the browsers logic of parsing a CSS file, picking out what it actually needs?
I am inclined to trust the browser with being able to pick apart CSS that I wrote in a performant way (it's written in C++ too, and had hundreds of pairs of eyes on it in it's lifetime) rather than trusting me being able to present the right css to the browser at the right time. Also, I'm not sure but I assume it sets style attributes on the fly? Which would also not allow the browser to pre-parse and optimize CSS that was given to it in advance.
Honestly, this way of phrasing it basically implies that it's a non-discussable given that it's the right tool and that critics are just trying to shoot down something they're ignorant about.
I don't know, I've been writing CSS for like 13 years and while I do think I am quite proficient in it (by now), it doesn't mean this knowledge is a hard overwrite of everyone who disagrees with me. I mean, I disagree and think you've got CSS wrong, but more on the technical side. I elaborated above why.