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

https://css-tricks.com/the-debate-around-do-we-even-need-css-anymore/

by logn • 11 years ago

77 65 11 years ago

aboodman• 11 years 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• 11 years 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• 11 years ago

Two words. Reader mode. It strips all the cruft out and gives you the text with a sensible set of styles.

jack92• 11 years 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• 11 years 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.

Roboprog2• 11 years 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• 11 years 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• 11 years 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• 11 years 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.

Roboprog2• 11 years 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)

adrusi4• 11 years 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• 11 years 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.

adrusi4• 11 years 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.

afarrell• 11 years ago

If a user doesn't like something about how your page is presented, they can fix it using userstyles

I'm actually curious what percentage of people could do so in under an hour.

DanBC• 11 years ago

Or on mobile.

adrusi4• 11 years ago

Not a huge amount of people will make custom styles, but they can be shared on sites like userscripts.org, for people who wouldn't bother making them or don't know css to use. Knowledge of basic HTML and CSS is more widespread than you might think.

If you're using inline styles, you're likely to end up with a lot of elements that don't have classes or ids to target for styling, so userstylers will have to use complex selectors using :nth-of-type and such, which is harder, more fragile, and not even always possible. And every line of the userstylesheet will need !important annotations, which makes composing multiple userstylesheet on the same page more likely to break.

threatofrain• 11 years ago

I believe there are extensions for this, and places where users submit their own stylesheets and rules. A few experts can do the work of many.

timq2• 11 years 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-future2• 11 years 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...

timq2• 11 years 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.

JimDabell• 11 years 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

Principle of Least Power – http://c2.com/cgi/wiki?PrincipleOfLeastPower

matchu5• 11 years 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• 11 years 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).

hollerith• 11 years 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".

robgibbons• 11 years 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• 11 years ago

You can get around this by using compilation tools, just like Compass does.

mangeletti• 11 years ago

So, create a problem, and then solve it?

matchu5• 11 years 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• 11 years 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• 11 years ago

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

jasode• 11 years 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.

muzmath3• 11 years 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.

TimJYoung4• 11 years ago

Here's an example of a JS application that dynamically animates DOM properties using requestAnimationFrame:

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".

cm2187• 11 years ago

Well, one potential downfall is that a lot of people like me browse the web without javascript enabled. When we arrive on a page which is unviewable without scripts, unless it is something we are really keen on accessing we just browse away.

ufo• 11 years ago

Alternatively, people could organize things using theri programming language of choice in the serverside, when they generate the HTML. No need to force an universal standard on everyone.

TimJYoung4• 11 years ago

That's what our product, Elevate Web Builder, does. It uses special JSON control interface files to describe the element styling:

http://www.elevatesoft.com/manual?action=viewtopic&id=ewb2&t...

The benefit of using JSON is that a JS compiler can include it in the HTML loader for the JavaScript application, minimizing any more round-trips to the web server, and can treat the JSON as a "resource" that can be manipulated in an easier fashion than CSS at runtime. Furthermore, the JSON can be compressed/uncompressed using identifier compression, making it tiny compared to CSS.

CSS is perfect for web sites that primarily use static/dynamic HTML organized as pages. It's a bad fit for single-page JS applications that act more like traditional desktop/mobile applications.

erikb2• 11 years 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.

namuol3• 11 years 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.

TimJYoung4• 11 years ago

I don't know why this comment is being down-voted. Your comments are spot-on. See my reply below about our product Elevate Web Builder - I came to the exact same conclusions as you. In fact, version 1 of EWB did use CSS, and then I got rid of it this year in version 2. In a component-based architecture, all UI updates are typically dynamic, and pre-defined styles simply don't fit as well, other than to define the various default "states" of controls/elements. CSS is complete overkill.

ExpiredLink• 11 years ago

In what universe did SQL ever go away?

In the blogosphere - admittedly, a rather narrow 'universe'.

erikb2• 11 years ago

Yes, what you say is all correct. You can also say that TCP and HTTP are not good for how the web works nowadays. But until now optimizing the bad solution to our current needs seemed to have beaten replacing it with something else. Remember SPDY? I think even Google doesn't use it as often any more. Remember how Facebook wrote a PHP compiler? I think just a few months back they found that optimizing the interpreter can gain them just as much as optimizing a compiler.

In the same vein people will try different things and then come back to CSS and optimize the heck out of it. For example, if the global nature of CSS is a problem, maybe they simply add namespaces in CSS4 (I don't know CSS well enough to even make up a good example, sorry. But I hope it's still clear what I mean).

No matter how bad it is for what it's used, people will continue to use it and the smart, creative people who try to change it will end up optimizing it instead of replacing it.

EGreg• 11 years ago

The global nature of CSS is mitigated by its ability to work with nearly any naming scheme you choose.

A javascript framework can enforce a naming scheme. And then you can have your cake and eat it too.

Why wouldn't you WANT to have a naming convention for reusable components that are supposed to live on the page?

vonklaus• 11 years 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.

iandanforth2• 11 years 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.

muzmath3• 11 years 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?

iandanforth2• 11 years 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.

namuol3• 11 years 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

(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/mast...

indubitably• 11 years 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• 11 years 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

ilaksh• 11 years 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.

namuol3• 11 years 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.

jack92• 11 years 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• 11 years 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• 11 years 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.

muzmath3• 11 years 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• 11 years 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?

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

Related Stories