The Debate Around “Do We Even Need CSS Anymore?” | Hacker News Reader

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

css-tricks.com

77 pointslogn65 comments

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

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.

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

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.

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

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.

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

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.

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.

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

If your stylesheets are properly versioned, they can be cached forever, which means exactly the same number of requests as inline styles with much less bandwidth use.

Not on first load. The cache needs to be populated somehow.

I agree that it's a special case, but it's one we shouldn't just ignore.

And the number of roundtrips can be helped by using Keep-Alive.

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

Or on mobile.

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.

All of this.

I resort to a set of brute force or reset stylesheets which pretty much explicitly override everything.

If you're going to use inline styles then basically fuck you.

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.

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.

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.

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.

> In what universe did SQL ever go away?

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

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.

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?

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

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.

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

That's pretty cool. Performance on mobile is of course important, but perhaps it can be improved.

I like CSS, but I also like having other options and ideas available. As others have said, for special one page web apps, the scripted layout might be a good choice.

And then we have CSS grids coming soon too. Choice is good!

Mobile is a tough nut to crack, due to some hard constraints on the CPU/power consumption, but it's getting better. A new iPhone 5s does a pretty good job with something like that app I linked to, whereas an older Samsung Galaxy Tab 2 does not. A lot also depends upon the browser, since there is a big difference between the JS engines in Chrome (best, by far) and FF/IE when it comes to things like requestAnimationFrame() execution performance. The linked-to example is a dog when run on IE 11/Windows 8 on a practically-new Dell laptop/tablet convertible with an i3, but works nicely in Chrome on the same device.

Re: CSS grids - totally agree. But, what I've learned over the last 4 years of developing a web application IDE is this: CSS is great if you want to set the layout and leave it alone (for the most part). In other words, when the JS is decorative, things are great. When the JS becomes the primary actor, things start to break down due to lack of control over how/when the reflows/repaints occur.

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.

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.

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.

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.

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

So, create a problem, and then solve it?

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.

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

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

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.

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

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.

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.

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?

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.

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.

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)?

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.

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?

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.

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

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.

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)

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.

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.

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.

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)

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.

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.

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

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.

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.

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

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

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

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

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.

Reply on news.ycombinator.com