
The Debate Around “Do We Even Need CSS Anymore?” - logn
https://css-tricks.com/the-debate-around-do-we-even-need-css-anymore/
======
JimDabell
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)

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

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

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

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

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

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

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

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

~~~
exodust
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!

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

------
robgibbons
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
You can get around this by using compilation tools, just like Compass does.

~~~
mangeletti
So, create a problem, and then solve it?

------
SeldomSoup
> 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
Two words. Reader mode. It strips all the cruft out and gives you the text
with a sensible set of styles.

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

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

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

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

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

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

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

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

~~~
dcherman
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
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)

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

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

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

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

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

