
Descartes – An experimental library for writing CSS in JavaScript - lolptdr
https://descartes.io/
======
userbinator
_Descartes is just over 30KB when minified and just over 300 lines of code._

For comparison, there's 12KB of text on the page.

There's something about writing 30KB+ of code, plus chunk of CSS-in-JS-syntax,
and then using the energy of every single visitor's machines to duplicate the
work at a massive scale to generate another chunk of CSS that the browser then
has to parse, _after_ executing that JS, which you could've just generated
once on the server, that feels fundamentally wrong. IMHO this flagrant
disregard for resource consumption is one of the reasons why the "Modern
Web(tm)" is as unpleasant as it is.

~~~
JoeAltmaier
Its called 'scaling'. There are 1B personal devices and only 1 server. So
anything that unloads the server is a good thing?

~~~
userbinator
How about just serving the CSS directly? It could even be generated from JS
with a tool like this one. Now you don't even have to serve the JS that
generates it.

~~~
err4nt
It would seem that Descartes allows you to change the values of the CSS
_after_ page load, which no amount of precompiling can do!

This is what plugins like Descartes are trying to solve - how do we inform CSS
of values on the page which may be different between different browsers or
users, or may change on the page after it loads as users interact with it.

[http://elementqueries.com/demos/variables.html](http://elementqueries.com/demos/variables.html)

Here's an example using EQCSS of accessing JavaScript Variables from CSS - I'd
__~LOVE~ __to see what CSS you could prepare and send in advance that would
produce the same thing.

It can't be done :)

~~~
herbst
Thats not was CSS is supposed to do. I am happy its not possible, else even
more people would exploit it.

------
DHowett
It seems like we've come full circle by reimplementing JSSS, Netscape's
disused Javscript Style Sheets
([https://en.wikipedia.org/wiki/JavaScript_Style_Sheets](https://en.wikipedia.org/wiki/JavaScript_Style_Sheets)).

JSSS failed as a practical competitor to CSS, which would be better _if only
we could generate it via javascript._

~~~
userbinator
Also notable is IE's "CSS expressions", which let you embed JS in CSS property
values, but they were deprecated and then removed completely:

[https://msdn.microsoft.com/en-
us/library/dn384050(v=vs.85).a...](https://msdn.microsoft.com/en-
us/library/dn384050\(v=vs.85\).aspx)

------
lf-non
Writing styles in javascript is a very natural consequence of web applications
becoming more and more dynamic. It is unfortunate that they are not more
mainstream.

We have pushed CSS pre-processors to the extent that they now have variables,
loops, modules, interpolation, conditions etc. which have always been present
in javascript.

It makes a lot more sense to just fully embrace all these features from
standard javascript instead of building entire ecosystems of css pre-
processors with superficial syntactical differences.

~~~
aikah
> Writing styles in javascript is a very natural consequence of web
> applications becoming more and more dynamic. It is unfortunate that they are
> not more mainstream.

It's ironic that graphic tool kits for desktop or mobile apps are adopting CSS
and declarative approach, when the front-end is desperately pushing for
javascript everywhere.

~~~
devishard
It's a natural consequence of the former being typically written by more
experienced developers than the latter.

------
Fiahil
Despite being a nice experimentation, I don't think there will be any
practical use in a real project. CSS preprocessors already allow us to style
things with minimal structure and complexity. We already have a large set of
tools to do exactly that, and if you want to add JavaScript to your CSS, just
don't. It doesn't add value to anything apart from making it slower.

~~~
onion2k
One advantage that a JS system could have over a preprocessor is the ability
to use real values from the browser; for example you could set things to be
equal to page height.

It'd definitely be much slower but that's irrelevant so long as it's still
fast enough.

~~~
juandazapata
To set an element height to the full viewport height, you can use `height:
100vh`. That unit is available since 2011. Please do your homework.

~~~
prezjordan
No need to be pedantic, onion2k's original point that you can use values from
the browser is spot-on. If you've ever tried to interact with CSS
transitions/animations with JavaScript you'll find rather quickly that doing
the entire thing in JS is the only reasonable approach.

~~~
majewsky
Okay, but then, since you're already animating individual elements, what's the
benefit over jQuery's $.fn.css?

------
err4nt
This is REALLY cool stuff. There's currently a gap between CSS and JS that
currently forces us to abuse HTML as an intermediary to get JS and CSS to
communicate with each other.

I've been doing some experiments with closing the gap between JS and CSS from
the opposite perspective of Descartes: writing JS from within CSS using a CSS-
like syntax..

My take is that Descartes is the inversion of my plugin - Descartes lets you
easily write CSS from JS and JS-style syntax.

Either way - being able write your responsive styles all in one place (whether
entirely in JS, or entirely in CSS) is a lot better than cobbling together
responsive support using a bunch of custom CSS + JS carefully duct-taped
together.

I believe this plugin will help build modular (atomic design) elements that
can be re-used on different templates/sites without much re-tooling once
they're built the first time.

~~~
devishard
The "gap between CSS and JS" you are describing is called "decoupling" and it
exists because the designers of CSS/HTML/JS have generally been experienced
enough developers to know how bad of an idea it is to couple your styling and
your business logic.

There are two kinds of developers: ones who think this is a reasonable idea,
and ones who have written UIs in languages that allow this kind of coupling
and learned from their mistakes.

~~~
herbst
Agreed. I was forced to work with JS-in-CSS and i still dont get their
reasoning behind it at all. All use cases in their examples were easily
solveable with CSS if you fixed up a bit of the bad CSS they shipped with.

It was just a very lazy approach to handle something they lost control for.

~~~
err4nt
Can you give an example where somebody used JS inside CSS for a solution CSS
alone could have provided?

EDIT: I can't seem to reply down below, but in my plugin for example we've
implemented a few responsive conditions:

\- min-scroll-x

\- max-scroll-x

\- min-scroll-y

\- max-scroll-y

So if you needed to trigger a style (or a whole block of styles) when the
page, or any element you specify has a scroll position meets the conditions
above.

By combining these conditions with other conditions, it makes it DEAD simple
for CSS-only designers to be able to write responsive JavaScript!

@element 'body' and (min-width:900px) and (min-scroll-y: 100vh) { header {
position: fixed; } }

~~~
herbst
I cant simply provide a solution for your edit thats true. But i assume this
to create massive overhead just to enable CSS do something it never was
supposed to? It maybe just does not fit into my world view, but thats simply
wrong to my eyes CSS is not supposed to know that much about the view.

------
proc0
stylus? LESS and SASS are definitely limited, but Stylus is what I've been
using and it's been amazing. [http://stylus-lang.com/](http://stylus-
lang.com/)

I'm not sure why you would want to go all the way and create fully dynamic
styles. I think that's just the wrong way to think about styles... If we take
a design software like InDesign, you have a style palette, in which you create
styles, for example 'red fill; black stroke 2pt; drop-shadow black 2pt fade'.
You can then asign this style to almost anything, be it text, or a shape, or
something else. CSS is supposed to work like this. You create your classes in
CSS that are styles in a style palette of sorts, and then you assign these
classes to your HTML structure with your JS Views (if you really need dynamic
styles). I really see no point in Descartes other than to avoid CSS
alltogether for whatever reason.

------
cel1ne
After doing research on how to improve CSS I settled on css-modules. They are
the mid-term solution and improvement I've seen so far.

[https://medium.com/front-end-developers/css-modules-
solving-...](https://medium.com/front-end-developers/css-modules-solving-the-
challenges-of-css-at-scale-85789980b04f)

[https://github.com/css-modules/css-modules](https://github.com/css-
modules/css-modules)

~~~
true_religion
Where do you think they fall short?

~~~
cel1ne
Addendum: I checked out tachyons now, which solves my abstraction-problems:
[http://tachyons.io/](http://tachyons.io/)

------
codingdave
How often does everyone change CSS, and how complicated is your resulting
product?

Because on our product, we tend to redesign the look and feel every couple
years, and try to keep things simple. So just writing raw CSS is really not
that painful.

I can see the use of tools like this if you are a design firm that churns out
prototypes on a regular basis. But for a stable company with a product that
has been around for years... CSS authoring just isn't a pain point.

~~~
err4nt
I don't think it's as much about authoring CSS faster - if your goal is to
output a large amount of CSS you can just use a precompiler like SASS to
amplify a shorthand into thousands and thousands of lines in a few seconds.
We've got that covered.

What Descartes seems to be doing rather is allow you to build modular elements
which don't require all that CSS to be output in the first place, while at the
same time ALSO writing the styles that CSS can't reach, all in one spot.

My take is that if it can be written in CSS alone, that's best.

Descartes and other plugins are here to help you write the styles you _cant_
write with CSS alone.

------
skewart
So, it looks like at the moment Descartes is basically SASS or LESS, but in
JavaScript. My reaction to that is, 'uh, okay, sure, why not.'

However, where Descartes starts to get really interesting, is if it began to
provide a substantially higher abstraction layer over CSS. I'm probably not
the only person who finds CSS pretty annoying. I would love to be able to do
layout styling at a level closer to the way that I think about page design.
That's not necessarily an easy thing to implement, but a little bit of
functionality in that direction would go a long way.

------
moonchrome
Every time I see something like this JSX and whatnot I wonder why these people
don't just give up on JS and move on to some LISP - in the React world that
would be clojure(script) but frankly whatever sexp language with macros for
creating DSL would fix a lot of the pain points caused by annoying web
standards designed decades ago.

You could say "legacy code" and what not - but frankly you're making a huge
effort when you introduce something like this or React anyway - so you might
as well go a little further and do it right.

------
oleg009
Hi

I think its great that you try new ideas in this area. Don't listen to those
who didn't event try to create better tools, but rather just crying around
that all the "css in js" solutions are bad, ignoring the fact that the current
traditional CSS is bad for lots of cases too.

I am biased because I am author if jss
[https://github.com/jsstyles/jss](https://github.com/jsstyles/jss)

What I understood from descartes is that you are trying to make styles dynamic
by allowing listeners. So that when user interaction happens, styles can
change accordingly, while the logic for it is contained in the style itself.

I had the same idea in jss too and ended up with this api for dynamic styles:
[https://github.com/jsstyles/jss/blob/master/docs/js-
api.md#s...](https://github.com/jsstyles/jss/blob/master/docs/js-api.md#set-
or-get-a-rule-property-dynamically)

I am still looking for a way how to make this idea more usable.

------
despinozist
Gives me a reason to put CSS as JSON into Openchain.

I was also thinking that CSS Documents in this way could be scaffolded as
JSONAPI. Or maybe we need a CSSAPI — etiquette for sending small bits of CSS.
My work on Openchain makes this relevant — where your CSS is loaded
dynamically based on Unitary Reference Architecture that is expressed in the
cryptographic ledger.

Then I was thinking "css-sempai" where the CSS file is imported like a Python
or JS Module, like here [https://github.com/kragniz/json-
sempai/](https://github.com/kragniz/json-sempai/) — but for CSS... So like:

    
    
        >>> from csssempai import magic
        >>> import stylesheet
        >>> stylesheet
        <module ‘stylesheet’ from ‘stylesheet.json’>
        >>> stylesheet.html.body.section[‘max-width’]
    

Would be neat for server-side variable loading of dynamic CSS Sekizai
conditionings in Django.

------
herbst
I used to work with a CMS that supported Javascript within CSS, i dont know
whats worse.

------
adwf
Classic inner-platform anti-pattern?

[https://en.wikipedia.org/wiki/Inner-
platform_effect](https://en.wikipedia.org/wiki/Inner-platform_effect)

------
Retr0spectrum
As a side note, the scrolling on that site is very buggy. It looks like they
tried to add momentum scrolling.

------
shaunrussell
I don't get it. CSS is easy. Why make it more complicated?

------
cm3
Isn't this a step back from declarative CSS?

------
oliv__
What's wrong with CSS, exactly?

~~~
saquibhafiz
There isn't anything wrong with it per se, however it's lacking in many ways.
To see them look at how libraries such as LESS
([http://lesscss.org/](http://lesscss.org/)) and SASS ([http://sass-
lang.com/](http://sass-lang.com/)) enhance the CSS experience. That being said
it seems as though the purpose of this library is to bridge the gap between
JavsScript and CSS that developers face when building moderately large systems
(I know I have).

------
GrumpyNl
to complicated and slows it down.

