8 ms·

The Debate Around “Do We Even Need CSS Anymore?”

77 points by logn 11y ago

aboodman 11y ago
I've done this in a few applications. It's really great. You of course want to build up abstractions within your codebase to keep things DRY, but you get to use the normal tools for that (variables, functions, objects, classes) etc, rather than CSS.
SeldomSoup 11y ago
> The idea is you apply styles to elements through JavaScript. Great. Now simply reading a page without JS will become impossible, let alone interacting with it.
- JupiterMoon 11y ago
  Two words. Reader mode. It strips all the cruft out and gives you the text with a sensible set of styles.
- jack9 11y ago
  So what? Reading a page without HTML5 will also mangle some pages, some pages in the 90's required vbscript. Technology isn't bad. It's been years since I've heard someone suggest that non-js support is something to design against. Laughable, really.
PhrosTT 11y ago
I've been using inline everything since templates (ejs) came into existence. Once you have templates you're only editing one location anyway. The biggest problem with CSS is it's really easy to add, and close to impossible to delete (detecting potential repercussions is hard). Sure there's performance issues, but most of the time your developer/maintenance time is worth the the extra bytes.
- Roboprog 11y ago
  Sounds like an opportunity for IDE makers. Add plugins to track CSS/HTML/templating, "where used" tools, and refactoring to push frequently repeated styles up into a main CSS file, or rarely used styles down into the few elements using it. Hopefully, there are few enough classes and styles injected from a long js code chain that you can manually check the things the IDE misses. JetBrains IDEs are surprisingly good at finding things connected via common libraries in code, so I'm hopeful that IDE makers could recognize common patterns in libraries such as React and Angular (e.g. - ng-class)
  - overgard 11y ago
    I doubt IDE's could really do much with it -- adding and removing classes dynamically means it can answer the question "is this used?" but it can never answer the question "is this unused?" Plus there's about 4000 template languages being invented every second, that the IDE would need to not just highlight, but intelligently parse.
- Dillybob 11y ago
  But, is that extra development time worth the time your visitor loses whilst page rendering? If it's a significant amount, I would say no.
- dcherman 11y ago
  It's not actually that terrible, but then again it depends on what you're building I suppose. Where I work, I made a fairly robust image diffing utility that runs using Selenium/WebDriver on all browsers that we support. Combined with a robust test suite of many different scenarios, we can make changes to our stylesheets with a pretty high amount of confidence that if anything changed, it'll fail the build.
  - Roboprog 11y ago
    That sounds like a lotta work, but that's a good thing to have when the appearance is an important part of what you are doing. (cost-benefit, risk management and all that)
brottle 11y ago
The content of the page is some simple text. Nothing more. Yet, I can barely read it on my iPad 2. It lags like mad when I try to scroll. As a user, I say: Please less fancy tricks and more standard html and css.
adrusi 11y ago
The separation of concerns argument is dogmatic here. Just because it used to be that you should keep presentation in your CSS and behavior in your javascript, doesn't mean that's a universal truth. It's a good abstraction to separate presentation from behavior, but that doesn't mean one has to be done in one language and the other in a different one. Separating the concerns just by partitioning them within your codebase is just as good for organization. There are two real reasons to use CSS for your styles. One is that your page should work without javascript, and doing your styles in javascript is a completely stupid reason to break support for no-javascript environments. The other is user choice. If a user doesn't like something about how your page is presented, they can fix it using userstyles. Maybe some text is too small for them to comfortably read but when they zoom in the layout breaks or other text gets too big. It's hostile to break this standard feature of the web just for whatever silly gains you get from doing your styles in javascript.
- lowboy 11y ago
  > One is that your page should work without javascript Universal rendering would send straight HTML with inline styles to the browser. And plenty of web applications need JS to function properly.
  - adrusi 11y ago
    True. Doesn't address the userstylesheet problem though. Also, sending prerendered pages with inline styles causes a bandwidth problem. Your prerendered page is probably dynamic and uncacheable, but your stylesheet isnt. By using inline styles, you send tons of repetitive uncacheable styles over the network where you could have just used a stylesheet. If you need the power that a full general purpose programming language gives you for some of your stylesheet, go ahead and use inline styles where needed, that's why they exist. But there's no reason that you should then decide that all of your styles ought to be inline.
    - matchu 11y ago
      If they're really that repetitive, then gzip should eliminate almost all of the bloat. We also need to think about number of round-trips. If you're on an old phone on a 3G connection in India, the extra round-trip from requesting the HTML then requesting the CSS makes a difference. I'm super interested about the performance aspect, too, but I feel like we need numbers to really go into detail. There's way too many factors at play here for the correct answer to be obvious.
needs 11y ago
CSS preprocessors are fine. Processors only understand binary but noone programs in binary today. If CSS become the binary of tomorrow, it's fine. Inlining CSS is stupid, it makes your page bigger, less flexible, doesn't use browser caching technics, and didn't solve the problem at all (or make it worse...). CSS with Javascript is even worse, as it will be slow as fuck, hard to maintain, and equivalent to directly write CSS by hand anyway. flex-boxes, box-model, table display, and more... solve most of problems you will ever had.
- rational-future 11y ago
  So many wrong statements. The performance differences, between CSS styles applied from a JS file and a CSS file are very small on modern browsers, with JS being faster sometime. JS files are cached. Preprocessors are not fine, they complicate and slow down the development process. Inlining CSS is not stupid, OP discusses the numerous advantages it brings...
  - needs 11y ago
    > The performance differences, between CSS styles applied from a JS file and a CSS file are very small on modern browsers, with JS being faster sometime. False, JS have to be interpreted and you have issue with document not being fully loaded. And CSS is easy to parse, faster to parse and "run" than JS. No, saying that JS is faster than CSS is just false. > JS files are cached. CSS too, and even can be prerendered. And CSS works when JS is disabled. > Preprocessors are not fine, they complicate and slow down the development process. That's not an argument at all because with the right tool its just like using a compiler. See "make" for example. Also you have to see how much you gain with the preprocessor, maybe loosing 0.01ms per "make" is worse it since you write code 1.2 times faster... > Inlining CSS is not stupid, OP discusses the numerous advantages it brings... And do not highlight the obvious disadvantages.
    - rational-future 11y ago
      You have NO idea what you're talking about. >> JS have to be interpreted Yeah, because the Bible, the Quaran and the Declaration of Independence say so ...
JimDabell 11y ago
Representing styles as executable code is a very poor idea. Suddenly you go from data you can inspect and play with to something you can just execute and take what you are given. The principle of least power is an incredibly important axiom of the web's architecture, and when people break it, lots of things become more difficult or impossible. If you don't like CSS, then by all means, propose a replacement – but please don't propose replacing it with executable code. See: Rule of Least Power – https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power Principle of Least Power – http://c2.com/cgi/wiki?PrincipleOfLeastPower http://c2.com/cgi/wiki?PrincipleOfLeastPower
- hollerith 11y ago
  >Representing styles as executable code is a very poor idea. Suddenly you go from data you can inspect and play with to something you can just execute and take what you are given. Continues to be true if we replace "styles" with "documents".
- matchu 11y ago
  Check out the format for an inline style: { background: "red", fontWeight: "bold" } It's just a Javascript mapping from strings to strings. That's a very un-powerful language, and that's what React consumes. Sure, you could generate this mapping with all sorts of arbitrary code, just like how you could generate CSS with all sorts of arbitrary code. But that doesn't make the style declaration itself any more powerful, much less an arbitrary executable.
  - davidkpiano 11y ago
    There is a difference, though. The above code is still executable in that it renders the proper styling via JS at run-time, rather than at "compile" time (i.e. when it is preprocessed).
    - matchu 11y ago
      That's true, but I don't feel like it's relevant. React's inline styles API satisfies the principle of least power: you can only pass to it a mapping from string keys to string/number values. It's possible that the input data might be compiled from some other more powerful format, and it's possible to argue that this compilation step is a violation of the principle of least power, but that feels like a separate issue. It's very possible to use inline styles without adding unnecessary power to the declaration language - heck, you could declare them in JSON and load them during the build step if you want. How you use inline styles is your decision.
robgibbons 11y ago
You lose the benefits of style caching with inline or dynamically applied styles, and inlining makes each HTML payload larger. Also, applying virtually all of your styles with JavaScript, after the DOM has already finished loading, wastes CPU cycles and just feels like going against the grain of CSS to me. You make a few arguable gains with this technique, but I feel it might be throwing the baby out with the bathwater.
- dclowd9901 11y ago
  You can get around this by using compilation tools, just like Compass does.
  - mangeletti 11y ago
    So, create a problem, and then solve it?
- matchu 11y ago
  The payload probably won't increase as much as we'd think thanks to gzip, and you can apply the styles via server-side rendering rather than waiting for the JS to load. We also need to consider the time from request to a ready page: if you're on an incredibly slow connection, then having the styles immediately rather than waiting on a second round-trip is a huge win. I agree that there are pros and cons, but some of the pros are actually in performance; it's not immediately clear which technique is more performant overall in what contexts.
michaelchisari 11y ago
CSS for content is great, but for applications, I've moved into applying styles using javascript, with a base css file to prime the application.
amorphid 11y ago
I haven't played with React yet. Does this CSS in your JS approach work with SASS, too?
jasode 11y ago
>What is the alternative to CSS then? The alternative is inline styles. ... The idea is you apply styles to elements through JavaScript. But if you have a non-trivial app with thousands of elements across hundreds of pages, people will inevitably want to "tame", "organize", "consolidate", etc those inline styles into some coherent taxonomy to enforce consistency. Wherever and however the programmers decide to store this "consistency taxonomy" (e.g. into special .json files instead of .css files), they've just reinvented "CSS" by another name. The 3 complaint bullet points at the top of the essay would then apply to the adhoc-this-is-not-CSS-but-it-acts-like-CSS system.
- muzmath 11y ago
  There's still some key differences between what this new JSON declared and Javascript distributed stylesheets would work. Mainly is that there is no more CSS Selector madness. You no longer need to have concepts such as selector specificity, nor the entire syntax around grabbing the correct selectors. Also you could then be able to logically follow the flow using traditional debugging methods rather than this mess which we have for debugging CSS currently. Lastly this removes the need for a lot of the additional syntax introduced into CSS for animations/transitions (though I have no idea what the performance would be inbetween these two methods). To be fair I haven't actually implemented this form of styling yet but it's something that interests me and I'd be interested in any potential downfalls before I commit to it on a project.
  - TimJYoung 11y ago
    Here's an example of a JS application that dynamically animates DOM properties using requestAnimationFrame: http://www.elevatesoft.com:8081/panels/panels.html http://www.elevatesoft.com:8081/panels/panels.html It's a little slow on mobile, but pretty good on desktops, and could probably use some optimizations. The DOM transitions are animated at the of end of each change management cycle for a given UI element. That allows for layout management that occurs independently of what is going on in the DOM, treating the DOM updates as only a "controlled repaint".
    - 11y ago
erikb 11y ago
In human history we always went through development loops. And I can tell you this: I was there when there was not much CSS, and certainly no preprocessors. CSS was the Next Big Thing on the table (not even 10 years ago, and div was the next big thing instead of table). There are reasons for CSS. Now that it's everywhere young people think it sucks. Because old code always sucks. But often it's not the technology that sucks. It's just that code bloats when it gets older. Now when we take CSS away we'll do that for 5 years and then we'll miss it, so we reintroduce it, maybe using another name, or a competing technology from back then that didn't make it. Both will happen, I'm quite sure of it. Just for you, dear reader, if you want to be the cool guy that knows the technology before the other kids know it, start doing CSS now and wait 5-10 years. The last thing I remember we've seen such a loop was SQL. Now they are slowly reintroducing it. So if you stayed with MySQL and Postgres over the last 5-10 years, you'll probably earn a lot of money now. Good luck.
- namuol 11y ago
  In what universe did SQL ever go away? The growth of popularity of non-relational databases was a reflection of the emergence of a different applications and a different approach to development. The "hate" for SQL was indeed often misplaced, but the need for different kinds of databases was real. The schemas of SQL were powerful but sometimes cumbersome to developers who need to rapidly iterate on their applications. The relational structure of SQL is sometimes ill-suited for the sort of graph queries needed in large social networks. SQL is sometimes the wrong tool for the job. Other times it's a powerful tool; maybe even most of the time. In short, there probably isn't any "one-size-fits-all" solution for databases. But the need for non-relational databases was very real; just ask Facebook, LinkedIn, or Twitter. --- CSS is another example of a tool that's "going out of fashion" for a real reason: it was never designed for the modular, component-oriented pattern that many developers are using for complex applications on the web. There need not be a "one-size-fits-all" solution for ALL styling on the web, but CSS is hardly ideal for web applications that are a composition of modular components. CSS probably won't go anywhere, as it is still useful for the more page-like content that it was originally designed for, but we still need something different for modular front-end application development.
vonklaus 11y ago
It makes a lot of sense to programstically generate css because all of what the author said is true: global namespace, difficulty to trace specificity, modularity, etc. I am not convinced inline styles are the way forward. You can just as easily write (manually or programmatically)your styles using css/sass/less and optimize and serve them. You can just do it server side. You can create global classes for objects and elements and include the However you want. You can optimize on your own server FOR THE CLIENT, and serve the best result. It is dogmatic, but I don't like inline styling. I think it should really be limited to values that are expected to regularly fluctuate during a session. This would be your height or width resizing on an animation or something where the x or y moves. These usecases make sense because you directly apply animation to an element. Can you imagine what the dom would look like with html, javascript, css, sass, markdown and haml/ruby all on a page? I hope there is a way to demonstrate your page to Search Engines, because eventualu they may stop believing the alternate robots files if they just cant tell what is going on. Also, writing your own tags and attributes, I like it think it's helpful, but DOMs don't make sense anymore.
iandanforth 11y ago
I'd propose the following distinction, especially for React users: If your components will only ever be used by you or a small, internal team of programmers, then inline styles can work. If, however, your components are meant to be re-usable, public and accessible then CSS is still a must. To pick on one project react-datagrid is a super useful, public component for displaying data, but they use inline styles, which makes integrating the component into any other design a nightmare. You have to fork their codebase to update a style because you can't over-ride it and there's no way they'd pull in a PR for your preferred style.
- muzmath 11y ago
  How about if you design the styles so you can pass in a styles object via the parent element, and the style-elemnt gets merged in to overwrite the defaults? is there a reason this wouldn't work?
  - iandanforth 11y ago
    They tried that in react-datagrid, but they forgot to expose a bunch. It's easy to use inline styles and hard to go back and add the layers of exposed properties you need to make sure they are accessible.
- namuol 11y ago
  Yes! Why aren't more people making this observation? One of the huge selling-points of React is the modularity of components, and yet styles frequently ruin that modularity. Anyway, I got so frustrated with the state of things that I created a library aiming to provide a solid interface for third-party component authors: https://github.com/namuol/react-declarative-styles https://github.com/namuol/react-declarative-styles (Still very early stages/not published on NPM) And yeah, I stress the same points you just made about the problems of using inline styles with third-party components: https://github.com/namuol/react-declarative-styles/blob/master/CSS_OR_INLINE.md#conclusions https://github.com/namuol/react-declarative-styles/blob/mast...
indubitably 11y ago
The people complaining about this are programmers who don't understand CSS anyway. Their sites will still look like crap even if they do everything via Javascript.
mambodog 11y ago
I think CSS Modules[1] (mentioned toward the end of the article) provides a starting point to finding a good compromise. It deals with the scoping issues, as well as interoperability between Javascript modules and the defined style classes. As it stands, the CSS Modules approach doesn't yet provide the same level of expressiveness which can be achieved with the styles-in-JS approach, but perhaps there is still value in evolving CSS-the-language to provide enough expressiveness while still providing an optimal syntax for style definition and facilitating static analysis and transformation specific to the domain of styling. [1] https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules
ilaksh 11y ago
Its weird because I remember when no one knew about CSS, amd then suddenly everyone had to do it. I also remember separating JS and HTML being really important for everyone for many years, but now everyone is doing the opposite. It just goes to show that people can make a cargo cult about any general approach.
- namuol 11y ago
  Separating JS and markup was important when we were imperatively mutating the DOM by hand. Writing "inline" JS is necessarily global, and therefore makes writing modular code a lot harder. In other words, separating JS from the markup allowed us to write more modular (and therefore less error-prone) code, but was sometimes harder to think about. Components capture the markup with the JS behavior that corresponds with it in a modular fashion; it's the best of both worlds. It really is a step forward.
- jack9 11y ago
  > Its weird because I remember when no one knew about CSS, amd then suddenly everyone had to do it. That year was 1999. 1998 it was "a huge improvement" still being standardized. It was formalized in 1999 (iirc) and eventually we saw HTML4.01 which assumed it was ubiquitous.
spankalee 11y ago
Shadow DOM scopes CSS, removing the global problem and allowing smaller, encapsulated CSS. Scopes styles are much easier to maintain and reason about, and faster to boot.
wruza 11y ago
I find it ironical that I can barely scroll this site on my omg-4-years-old smartphone. Yeah, we need more js and emulation, definitely.
- muzmath 11y ago
  On a webpage that already uses client side javascript, do you know if this would actually slow it down any real amount (more then 10ms)?
JonoW 11y ago
It only got one short mention in the article, but doesn't lack of media query support for inline styles kill this approach for any site that needs to be responsive?

77 points by logn 11y ago

I've done this in a few applications. It's really great. You of course want to build up abstractions within your codebase to keep things DRY, but you get to use the normal tools for that (variables, functions, objects, classes) etc, rather than CSS.

SeldomSoup 11y ago

> The idea is you apply styles to elements through JavaScript. Great. Now simply reading a page without JS will become impossible, let alone interacting with it.

JupiterMoon 11y ago
Two words. Reader mode. It strips all the cruft out and gives you the text with a sensible set of styles.
jack9 11y ago
So what? Reading a page without HTML5 will also mangle some pages, some pages in the 90's required vbscript. Technology isn't bad. It's been years since I've heard someone suggest that non-js support is something to design against. Laughable, really.

PhrosTT 11y ago

I've been using inline everything since templates (ejs) came into existence. Once you have templates you're only editing one location anyway. The biggest problem with CSS is it's really easy to add, and close to impossible to delete (detecting potential repercussions is hard). Sure there's performance issues, but most of the time your developer/maintenance time is worth the the extra bytes.

Roboprog 11y ago
Sounds like an opportunity for IDE makers. Add plugins to track CSS/HTML/templating, "where used" tools, and refactoring to push frequently repeated styles up into a main CSS file, or rarely used styles down into the few elements using it. Hopefully, there are few enough classes and styles injected from a long js code chain that you can manually check the things the IDE misses. JetBrains IDEs are surprisingly good at finding things connected via common libraries in code, so I'm hopeful that IDE makers could recognize common patterns in libraries such as React and Angular (e.g. - ng-class)
- overgard 11y ago
  I doubt IDE's could really do much with it -- adding and removing classes dynamically means it can answer the question "is this used?" but it can never answer the question "is this unused?" Plus there's about 4000 template languages being invented every second, that the IDE would need to not just highlight, but intelligently parse.
Dillybob 11y ago
But, is that extra development time worth the time your visitor loses whilst page rendering? If it's a significant amount, I would say no.
dcherman 11y ago
It's not actually that terrible, but then again it depends on what you're building I suppose. Where I work, I made a fairly robust image diffing utility that runs using Selenium/WebDriver on all browsers that we support. Combined with a robust test suite of many different scenarios, we can make changes to our stylesheets with a pretty high amount of confidence that if anything changed, it'll fail the build.
- Roboprog 11y ago
  That sounds like a lotta work, but that's a good thing to have when the appearance is an important part of what you are doing. (cost-benefit, risk management and all that)

brottle 11y ago

The content of the page is some simple text. Nothing more. Yet, I can barely read it on my iPad 2. It lags like mad when I try to scroll. As a user, I say: Please less fancy tricks and more standard html and css.

adrusi 11y ago

The separation of concerns argument is dogmatic here. Just because it used to be that you should keep presentation in your CSS and behavior in your javascript, doesn't mean that's a universal truth. It's a good abstraction to separate presentation from behavior, but that doesn't mean one has to be done in one language and the other in a different one. Separating the concerns just by partitioning them within your codebase is just as good for organization. There are two real reasons to use CSS for your styles. One is that your page should work without javascript, and doing your styles in javascript is a completely stupid reason to break support for no-javascript environments. The other is user choice. If a user doesn't like something about how your page is presented, they can fix it using userstyles. Maybe some text is too small for them to comfortably read but when they zoom in the layout breaks or other text gets too big. It's hostile to break this standard feature of the web just for whatever silly gains you get from doing your styles in javascript.

lowboy 11y ago
> One is that your page should work without javascript Universal rendering would send straight HTML with inline styles to the browser. And plenty of web applications need JS to function properly.
- adrusi 11y ago
  True. Doesn't address the userstylesheet problem though. Also, sending prerendered pages with inline styles causes a bandwidth problem. Your prerendered page is probably dynamic and uncacheable, but your stylesheet isnt. By using inline styles, you send tons of repetitive uncacheable styles over the network where you could have just used a stylesheet. If you need the power that a full general purpose programming language gives you for some of your stylesheet, go ahead and use inline styles where needed, that's why they exist. But there's no reason that you should then decide that all of your styles ought to be inline.
  - matchu 11y ago
    If they're really that repetitive, then gzip should eliminate almost all of the bloat. We also need to think about number of round-trips. If you're on an old phone on a 3G connection in India, the extra round-trip from requesting the HTML then requesting the CSS makes a difference. I'm super interested about the performance aspect, too, but I feel like we need numbers to really go into detail. There's way too many factors at play here for the correct answer to be obvious.

needs 11y ago

CSS preprocessors are fine. Processors only understand binary but noone programs in binary today. If CSS become the binary of tomorrow, it's fine. Inlining CSS is stupid, it makes your page bigger, less flexible, doesn't use browser caching technics, and didn't solve the problem at all (or make it worse...). CSS with Javascript is even worse, as it will be slow as fuck, hard to maintain, and equivalent to directly write CSS by hand anyway. flex-boxes, box-model, table display, and more... solve most of problems you will ever had.

rational-future 11y ago
So many wrong statements. The performance differences, between CSS styles applied from a JS file and a CSS file are very small on modern browsers, with JS being faster sometime. JS files are cached. Preprocessors are not fine, they complicate and slow down the development process. Inlining CSS is not stupid, OP discusses the numerous advantages it brings...
- needs 11y ago
  > The performance differences, between CSS styles applied from a JS file and a CSS file are very small on modern browsers, with JS being faster sometime. False, JS have to be interpreted and you have issue with document not being fully loaded. And CSS is easy to parse, faster to parse and "run" than JS. No, saying that JS is faster than CSS is just false. > JS files are cached. CSS too, and even can be prerendered. And CSS works when JS is disabled. > Preprocessors are not fine, they complicate and slow down the development process. That's not an argument at all because with the right tool its just like using a compiler. See "make" for example. Also you have to see how much you gain with the preprocessor, maybe loosing 0.01ms per "make" is worse it since you write code 1.2 times faster... > Inlining CSS is not stupid, OP discusses the numerous advantages it brings... And do not highlight the obvious disadvantages.
  - rational-future 11y ago
    You have NO idea what you're talking about. >> JS have to be interpreted Yeah, because the Bible, the Quaran and the Declaration of Independence say so ...

JimDabell 11y ago

Representing styles as executable code is a very poor idea. Suddenly you go from data you can inspect and play with to something you can just execute and take what you are given. The principle of least power is an incredibly important axiom of the web's architecture, and when people break it, lots of things become more difficult or impossible. If you don't like CSS, then by all means, propose a replacement – but please don't propose replacing it with executable code. See: Rule of Least Power – https://en.wikipedia.org/wiki/Rule_of_least_power https://en.wikipedia.org/wiki/Rule_of_least_power Principle of Least Power – http://c2.com/cgi/wiki?PrincipleOfLeastPower http://c2.com/cgi/wiki?PrincipleOfLeastPower

hollerith 11y ago
>Representing styles as executable code is a very poor idea. Suddenly you go from data you can inspect and play with to something you can just execute and take what you are given. Continues to be true if we replace "styles" with "documents".
matchu 11y ago
Check out the format for an inline style: { background: "red", fontWeight: "bold" } It's just a Javascript mapping from strings to strings. That's a very un-powerful language, and that's what React consumes. Sure, you could generate this mapping with all sorts of arbitrary code, just like how you could generate CSS with all sorts of arbitrary code. But that doesn't make the style declaration itself any more powerful, much less an arbitrary executable.
- davidkpiano 11y ago
  There is a difference, though. The above code is still executable in that it renders the proper styling via JS at run-time, rather than at "compile" time (i.e. when it is preprocessed).
  - matchu 11y ago
    That's true, but I don't feel like it's relevant. React's inline styles API satisfies the principle of least power: you can only pass to it a mapping from string keys to string/number values. It's possible that the input data might be compiled from some other more powerful format, and it's possible to argue that this compilation step is a violation of the principle of least power, but that feels like a separate issue. It's very possible to use inline styles without adding unnecessary power to the declaration language - heck, you could declare them in JSON and load them during the build step if you want. How you use inline styles is your decision.

robgibbons 11y ago

You lose the benefits of style caching with inline or dynamically applied styles, and inlining makes each HTML payload larger. Also, applying virtually all of your styles with JavaScript, after the DOM has already finished loading, wastes CPU cycles and just feels like going against the grain of CSS to me. You make a few arguable gains with this technique, but I feel it might be throwing the baby out with the bathwater.

dclowd9901 11y ago
You can get around this by using compilation tools, just like Compass does.
- mangeletti 11y ago
  So, create a problem, and then solve it?
matchu 11y ago
The payload probably won't increase as much as we'd think thanks to gzip, and you can apply the styles via server-side rendering rather than waiting for the JS to load. We also need to consider the time from request to a ready page: if you're on an incredibly slow connection, then having the styles immediately rather than waiting on a second round-trip is a huge win. I agree that there are pros and cons, but some of the pros are actually in performance; it's not immediately clear which technique is more performant overall in what contexts.

michaelchisari 11y ago

CSS for content is great, but for applications, I've moved into applying styles using javascript, with a base css file to prime the application.

amorphid 11y ago

I haven't played with React yet. Does this CSS in your JS approach work with SASS, too?

jasode 11y ago

>What is the alternative to CSS then? The alternative is inline styles. ... The idea is you apply styles to elements through JavaScript. But if you have a non-trivial app with thousands of elements across hundreds of pages, people will inevitably want to "tame", "organize", "consolidate", etc those inline styles into some coherent taxonomy to enforce consistency. Wherever and however the programmers decide to store this "consistency taxonomy" (e.g. into special .json files instead of .css files), they've just reinvented "CSS" by another name. The 3 complaint bullet points at the top of the essay would then apply to the adhoc-this-is-not-CSS-but-it-acts-like-CSS system.

muzmath 11y ago
There's still some key differences between what this new JSON declared and Javascript distributed stylesheets would work. Mainly is that there is no more CSS Selector madness. You no longer need to have concepts such as selector specificity, nor the entire syntax around grabbing the correct selectors. Also you could then be able to logically follow the flow using traditional debugging methods rather than this mess which we have for debugging CSS currently. Lastly this removes the need for a lot of the additional syntax introduced into CSS for animations/transitions (though I have no idea what the performance would be inbetween these two methods). To be fair I haven't actually implemented this form of styling yet but it's something that interests me and I'd be interested in any potential downfalls before I commit to it on a project.
- TimJYoung 11y ago
  Here's an example of a JS application that dynamically animates DOM properties using requestAnimationFrame: http://www.elevatesoft.com:8081/panels/panels.html http://www.elevatesoft.com:8081/panels/panels.html It's a little slow on mobile, but pretty good on desktops, and could probably use some optimizations. The DOM transitions are animated at the of end of each change management cycle for a given UI element. That allows for layout management that occurs independently of what is going on in the DOM, treating the DOM updates as only a "controlled repaint".
  - 11y ago

erikb 11y ago

In human history we always went through development loops. And I can tell you this: I was there when there was not much CSS, and certainly no preprocessors. CSS was the Next Big Thing on the table (not even 10 years ago, and div was the next big thing instead of table). There are reasons for CSS. Now that it's everywhere young people think it sucks. Because old code always sucks. But often it's not the technology that sucks. It's just that code bloats when it gets older. Now when we take CSS away we'll do that for 5 years and then we'll miss it, so we reintroduce it, maybe using another name, or a competing technology from back then that didn't make it. Both will happen, I'm quite sure of it. Just for you, dear reader, if you want to be the cool guy that knows the technology before the other kids know it, start doing CSS now and wait 5-10 years. The last thing I remember we've seen such a loop was SQL. Now they are slowly reintroducing it. So if you stayed with MySQL and Postgres over the last 5-10 years, you'll probably earn a lot of money now. Good luck.

namuol 11y ago
In what universe did SQL ever go away? The growth of popularity of non-relational databases was a reflection of the emergence of a different applications and a different approach to development. The "hate" for SQL was indeed often misplaced, but the need for different kinds of databases was real. The schemas of SQL were powerful but sometimes cumbersome to developers who need to rapidly iterate on their applications. The relational structure of SQL is sometimes ill-suited for the sort of graph queries needed in large social networks. SQL is sometimes the wrong tool for the job. Other times it's a powerful tool; maybe even most of the time. In short, there probably isn't any "one-size-fits-all" solution for databases. But the need for non-relational databases was very real; just ask Facebook, LinkedIn, or Twitter. --- CSS is another example of a tool that's "going out of fashion" for a real reason: it was never designed for the modular, component-oriented pattern that many developers are using for complex applications on the web. There need not be a "one-size-fits-all" solution for ALL styling on the web, but CSS is hardly ideal for web applications that are a composition of modular components. CSS probably won't go anywhere, as it is still useful for the more page-like content that it was originally designed for, but we still need something different for modular front-end application development.

vonklaus 11y ago

It makes a lot of sense to programstically generate css because all of what the author said is true: global namespace, difficulty to trace specificity, modularity, etc. I am not convinced inline styles are the way forward. You can just as easily write (manually or programmatically)your styles using css/sass/less and optimize and serve them. You can just do it server side. You can create global classes for objects and elements and include the However you want. You can optimize on your own server FOR THE CLIENT, and serve the best result. It is dogmatic, but I don't like inline styling. I think it should really be limited to values that are expected to regularly fluctuate during a session. This would be your height or width resizing on an animation or something where the x or y moves. These usecases make sense because you directly apply animation to an element. Can you imagine what the dom would look like with html, javascript, css, sass, markdown and haml/ruby all on a page? I hope there is a way to demonstrate your page to Search Engines, because eventualu they may stop believing the alternate robots files if they just cant tell what is going on. Also, writing your own tags and attributes, I like it think it's helpful, but DOMs don't make sense anymore.

iandanforth 11y ago

I'd propose the following distinction, especially for React users: If your components will only ever be used by you or a small, internal team of programmers, then inline styles can work. If, however, your components are meant to be re-usable, public and accessible then CSS is still a must. To pick on one project react-datagrid is a super useful, public component for displaying data, but they use inline styles, which makes integrating the component into any other design a nightmare. You have to fork their codebase to update a style because you can't over-ride it and there's no way they'd pull in a PR for your preferred style.

muzmath 11y ago
How about if you design the styles so you can pass in a styles object via the parent element, and the style-elemnt gets merged in to overwrite the defaults? is there a reason this wouldn't work?
- iandanforth 11y ago
  They tried that in react-datagrid, but they forgot to expose a bunch. It's easy to use inline styles and hard to go back and add the layers of exposed properties you need to make sure they are accessible.
namuol 11y ago
Yes! Why aren't more people making this observation? One of the huge selling-points of React is the modularity of components, and yet styles frequently ruin that modularity. Anyway, I got so frustrated with the state of things that I created a library aiming to provide a solid interface for third-party component authors: https://github.com/namuol/react-declarative-styles https://github.com/namuol/react-declarative-styles (Still very early stages/not published on NPM) And yeah, I stress the same points you just made about the problems of using inline styles with third-party components: https://github.com/namuol/react-declarative-styles/blob/master/CSS_OR_INLINE.md#conclusions https://github.com/namuol/react-declarative-styles/blob/mast...

indubitably 11y ago

The people complaining about this are programmers who don't understand CSS anyway. Their sites will still look like crap even if they do everything via Javascript.

mambodog 11y ago

I think CSS Modules[1] (mentioned toward the end of the article) provides a starting point to finding a good compromise. It deals with the scoping issues, as well as interoperability between Javascript modules and the defined style classes. As it stands, the CSS Modules approach doesn't yet provide the same level of expressiveness which can be achieved with the styles-in-JS approach, but perhaps there is still value in evolving CSS-the-language to provide enough expressiveness while still providing an optimal syntax for style definition and facilitating static analysis and transformation specific to the domain of styling. [1] https://github.com/css-modules/css-modules https://github.com/css-modules/css-modules

ilaksh 11y ago

Its weird because I remember when no one knew about CSS, amd then suddenly everyone had to do it. I also remember separating JS and HTML being really important for everyone for many years, but now everyone is doing the opposite. It just goes to show that people can make a cargo cult about any general approach.

namuol 11y ago
Separating JS and markup was important when we were imperatively mutating the DOM by hand. Writing "inline" JS is necessarily global, and therefore makes writing modular code a lot harder. In other words, separating JS from the markup allowed us to write more modular (and therefore less error-prone) code, but was sometimes harder to think about. Components capture the markup with the JS behavior that corresponds with it in a modular fashion; it's the best of both worlds. It really is a step forward.
jack9 11y ago
> Its weird because I remember when no one knew about CSS, amd then suddenly everyone had to do it. That year was 1999. 1998 it was "a huge improvement" still being standardized. It was formalized in 1999 (iirc) and eventually we saw HTML4.01 which assumed it was ubiquitous.

spankalee 11y ago

Shadow DOM scopes CSS, removing the global problem and allowing smaller, encapsulated CSS. Scopes styles are much easier to maintain and reason about, and faster to boot.

wruza 11y ago

I find it ironical that I can barely scroll this site on my omg-4-years-old smartphone. Yeah, we need more js and emulation, definitely.

muzmath 11y ago
On a webpage that already uses client side javascript, do you know if this would actually slow it down any real amount (more then 10ms)?

JonoW 11y ago

It only got one short mention in the article, but doesn't lack of media query support for inline styles kill this approach for any site that needs to be responsive?