Descartes – An experimental library for writing CSS in JavaScript
descartes.io
descartes.io
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.
The web is so much more pleasant without.
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
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 :)
JSSS failed as a practical competitor to CSS, which would be better if only we could generate it via javascript.
https://msdn.microsoft.com/en-us/library/dn384050(v=vs.85).a...
CSS was converted to JSSS internally which had the annoying effect that disabling JavaScript disabled CSS support for Netscape 4.
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.
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.
That said, the main advantage for writing CSS in JS is being able to rewrite styles in runtime, where changing values in Javascript automatically reflects in style changes. The most direct way to do this today is setting variables as data-attributes in a DOM node and targeting specific true/false values for that attribute in your stylesheet.
Native CSS Variables will make life much easier in this respect, but it will still take a couple of years before all major browsers implement it.
It'd definitely be much slower but that's irrelevant so long as it's still fast enough.
- how do I make this element the same size as this other element?
- how do I make this element the same size as this piece of unwrapped text?
To be fair, these are both require multipass layout, which (IIRC) CSS is explicitly specced not to do. But it's still necessary for complex layouts. Unfortunately it doesn't look like Descartes can help with this.
...way back when there was a thing called famo.us, which was a pure Javascript layout engine; it claimed to be faster (and more flexible) than traditional HTML and CSS. The company that wrote it went bust, and it seems to have turned into http://famous.org. But I've never heard of anyone using it...
Sure, but do we need it though? You already have media queries, keyframes, mixins, and you can already build meaningful abstraction using SCSS partials, Web Components, and probably a myriad of other tools and technologies.
Why try to reinvent the wheel when you already have the tools, the documentation and the conventions? No need to pollute the landscape of front-end development tech more than it already is.
to add to the points in the parent post, i'd add that the word "powerful" is being tossed around w/o much consideration here. GOTO is a "powerful" statement in the sense that it lets you "do more" w/ you programs. otoh, it can make programs a lot harder to read about.
that example is probably hyperbole here. i can see the use of mixing "styles" w/ "code" (this is pretty standard in cljs). however, does a decoupled design team really need more than sass/less -- or another way, do the time-savings from the cases where something else would be useful offset the potential complications of the cases where it could muck with other parts of the process?
tl;dr JS "power" may shoot foot
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.
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.
It was just a very lazy approach to handle something they lost control for.
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; } }
Its a worstcase probably, but i also do not find any sitations where it would make more sense to traditional methods.
I'm joking. I actually think the idea of incorporating a simple subset of JS functionality into CSS could be super powerful. There are lots of times when you want a little JS to help with styling, or maybe even basic data fetching and binding. It would be a lot simpler to just keep it in your CSS files. I'd love to hear more about what you're working on.
I've been using this for the past year and its been a life saver!
Dont picture it being gross, picture it like this: http://codepen.io/tomhodgins/pen/RrEpjo
This CSS gives you a sticky header, a page with a min-height of 100% - whatever the footer happens to be, and then if the page expands it just pushes the footer out of the way.
Normally you would either need to know the exact height of the footer in CSS, or you would need to write a little bit of JavaScript to measure the height of the footer.
But keep in mind that if youve got a lot lf content in your footer, its probably going to get very tall at phone width, medium height for tablet users, and be the shortest for desktop users.
So now, how can we write CSS that is able to use this changing value of the footer height on the page? The simplest way is to allow CSS to access the measurement of that element as it has rendered on the page.
If this plugin can help others too, that makes it all the more worthwhile!
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.
https://medium.com/front-end-developers/css-modules-solving-...
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.
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.
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.
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.
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
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...
I am still looking for a way how to make this idea more usable.
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/ — but for CSS... So like:
>>> from csssempai import magic
>>> import stylesheet
>>> stylesheet
<module ‘stylesheet’ from ‘stylesheet.json’>
>>> stylesheet.html.body.section[‘max-width’]