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.
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.
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.
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.
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.
> 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.
Well it is true that CSS preprocessers are getting all these JavaScript like features they are still compiled down to plain old CSS. The fact that users can disable js and ruin most if not all of your styles is just a little off putting to me. Seems like a cool idea though and I agree with most your points but I think pre processers fill a need for people who want just normal CSS on their sites.
Agreed — I've always admired how extensive Sass/LESS have become, but I do think having advanced logic inside your stylesheets makes no sense. Not necessarily because of separation of concerns, but because Javascript does a much better job at this (and already has the remaining logic of the application), so there's really no need to reinvent a slightly less functional version of the wheel here.
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.
Like you, I see this like a natural evolution. Instead of adding stuff to CSS to become it more like a true programming language, we adapt a programming language to do the job of CSS.
The only problem that i see to this particular situation, is that I don't see a way to generate static CSS files like does Less/Sass . This like calling less.js on production...
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.
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.
The two things I find myself persistently wanting to do in CSS, which I've never found a way to do, is:
- 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...
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.
I didn't mean the viewport. I meant the page eg the full height of the rendered window content including everything outside of the viewport's scroll region.
I think this makes perfect sense. JS is a much more powerful language than the normal preprocessors, so it will allow more meaningful abstractions. I can't predict where it will go, but it seems clear to me that there are situations that we currently describe with multiple styles (wrappers and containers and their inner parts), which would make sense to abstract away.
> JS is a much more powerful language than the normal preprocessors
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 me, replacing SCSS or the like with JS would feel like a refactoring/streamlining of my build pipeline. I'd rather stick to one language unless there is a compelling reason to choose another. In this case, it looks like the JS syntax is just as easy to comprehend as LESS or SCSS but with added power, so I think that it would make sense. Of course, I haven't actually used it yet and I know from experience that problems tend to appear that I never thought of, so I am the first to admit that I could be wrong.
>> JS is a much more powerful language than the normal preprocessors
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?
One thing I appreciated about Clojure's Garden library is you build your CSS in Clojure itself. A Clojure dev can learn Garden in about 5 minutes, then apply the entire power of Clojure as they see fit. I wouldn't mind an equivalent to that in JavaScript. Server side though, so not Descartes.
Managing state in CSS is not that good. I would have to add/remove class names from a DOM element. Styling in JS allows you to manage that in one place keeping the component intact with a few dependencies like external colors, fonts and images.
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.
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.
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.
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;
}
}
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.
Sure. Most of the time they used it to trigger jQuery fadeIn/fadeOut or move boxes which would have moved if the CSS would have followed a basic grid system other than a <div> construct reassembling tables.
Its a worstcase probably, but i also do not find any sitations where it would make more sense to traditional methods.
Theres actually three types of developers. You forgot about ones who have been building stuff for a decade and a half, run up against the limitations of their tools, and personally set out to extend them. Thats more the type I am :)
sadly it seems the css v3 spec was written by the latter developers, with transforms violating cascading principles, pseudo elements not readable from the model and keyframe animations being a shit to control all around, so we're stuck with patchwork bridges to make it all work reasonably.
Wait, I'm really curious about your plugin. Do you have a public repo somewhere? Writing JS in CSS, on the face of it, sounds, well, kinda perverse. I'm picturing something where you apply "float": "left" to a JS function, and every line where that function is called is moved to the top of its containing block.
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.
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.
Thanks, I just came up with a syntax that solved the problems I had with CSS and hired a brilliant JavaScript programmer, Maxime Euziere, to build me a plugin so I could use these features in my work :)
If this plugin can help others too, that makes it all the more worthwhile!
stylus? LESS and SASS are definitely limited, but Stylus is what I've been using and it's been amazing. 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.
I still don't see a clear path on when to use class, id or element selectors and whether to mix multiple simple styles on an element (.bold, .link, .green) or make it more complex like "#loginLink".
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.
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.
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.
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.
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.
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.
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/ — 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.
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/) and SASS (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).
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.