Show HN: Polished – A lightweight toolset for writing styles in JavaScript
github.com
github.com
The idea that "globals" in CSS are bad is counter intuitive to my experience that globals in CSS encourage consistency
Maybe when you're facebook size and you have many product teams all expected to produce something that all works together - I can see how the global namespace would be impossible to manage. For your average website or app? Not even close. It'll be awhile before you run into the limitations of CSS that Facebook is running into.
You just handle it the same way you handle any shared code. You can keep files in a file scope, in a package / folder scope, or in the top-level global scope (in a small app that's totally fine). But removing globals-by-default removes a lot of "gotcha's" from working with CSS.
Why don't you write all your applications code in a global scope and just use a BEM-like naming scheme for your functions?
[0]: http://getbem.com/
[1]: https://medium.com/@jdan/css-is-fine-its-just-really-hard-63...
The framework scope has all the composeable classes and standard forms like lists, shadows, colors, grids, cards etc.
Then, when the framework doesn't cover everything, I use component scoped css to complete it, without having to worry about a naming scheme like BEM. It just makes things easier when you have css that is really only relevant to one component. Just like programming, I can always make the code abstract and move it up to the framework.
I do the exact same thing (I don't use BEM either) by isolating specific component styling to it's own SASS file.
As for css-in-js, there isn't much of an advantage to using it vs importing sass files as scoped.
With Sass you get:
- Familiare Syntax
- Avoids inline styles
- All benefits of the Sass community
vs with css-in-js you primarily gain:
- Dynamic and regular styles together
- One less compiler dependency
- Benefits of full JS for style generation
So I think this really depends on the project and your preference, I don't think there's a massive benefit either way.
You can totally create a style library and include pieces of it as mixins for the styles of each component.
Or until your designer wants the corporate website and the internal dashboard to have buttons that look different.
At first I though this is for those situations where you find yourself urged to modify the css in your javascript. But looking at the documentation, this seems to be a way to write the complete CSS in JS, and then to have it compiled into CSS. Do I understand that wrong? If not: Why would one want that?
The main goal with writing styles in JavaScript is to make CSS work in the context of component-based systems. The language is magnificent, but it was made in an age where the web consisted of documents.
These days we're building rich, interactive, client-side user interfaces with the same language, but it's standing in our way. That's why there has been a lot of exploration, especially in the React ecosystem, around putting styles in JavaScript.
I'd encourage you to take a look at these magnificent resources which I cannot do justice in a single comment:
- The talk that kicked it all off: "CSS in JS" by vjeux[0] (made React Native, works at Facebook)
- "Rendering Khan Academys Learn Menu Whereever I Please" [1]
- "Scale FUD and style components" [2]
and a bunch of other talks and articles if you google "CSS in JS".
[0]: https://speakerdeck.com/vjeux/react-css-in-js [1]: https://medium.com/@jdan/rendering-khan-academys-learn-menu-... [2]: https://medium.learnreact.com/scale-fud-and-style-components...
Maybe add a "How to use this" section describing possible workflows to the Readme?
Also I run into situations where my js produces inline css, and a lodash style lib for that could be useful. Thanks for the answer, congratz for launching!
Definitely will work on improving the README, just needed to finally get this out of the door ;)
Cheers!
That isn't what this is although I also had to poke around the source code to figure out what it is exactly.
It's a set of mixins and utility functions that return a js object that is then used as input for either inline styles, or for one of the may CSS in JS libraries that convert do a JS object to CSS.
As for how useful? Well, the color utilities seem to replicate what color.js does, so nothing new there. The mixins seem to be mostly about prefixing, and you're going to need to prefix the rest of your CSS-in-JS anyway - for which there are various standalone libraries, and plugins to the aforementioned libraries.
The shorthands let you do things like:
borderWidth('12px', '24px', '36px', '48px')
=>
{ 'border-top-width': '12px', 'border-right-width': '24px', 'border-bottom-width': '36px', 'border-left-width': '48px' }
Thing is, I can already do that without the expansion:
{ 'borderWidth': '12px 24px 36px 48px' }
As much as I respect the guys behind this, I'd question how useful it is overall.
Basically, there is lots of styles in JavaScript libraries floating around, especially in the React ecosystem. The issue is that many people need Sass utility functions and mixins like lighten/darken/clearfix to be productive with their styling, and no real comprehensive "Compass for styles in JavaScript" exists—so this is it.
We looked at a lot of existing JavaScript color libraries, but most of them have some sort of fluent API that is very different from the way CSS preprocessors handle these functions. This confuses people and makes the API hard to learn, so we decided to build our own that mimics the Sass API as closely as possible. (apart from being all curried functions that are composeable, which means switching some argument orders around)
I did look at the docs, but that doesn't have an explanation of what value this is trying to offer either.
If designers are being asked to write CSS-IN-JS, I can get where there the difficulty comes from, but I'd still argue that most of these functions are just moving the chairs around.
This [1] IMHO is the defacto JS color lib, but again can see how, if the only thing you know is SASS, it looks a bit to much like real code.
I remember attending NodeJS meetups in the local Engine Yard office buildings around 2012 before there was an extant local NodeJS community, so most of the attendees were coming from non-JS programming backgrounds. There was the odd Ruby and PHP dev, but the vast majority of the initial local NodeJS community here were Java people for some odd reason. I didn't really know much about the Java community, but my general impression of the Java-backgrounded presenters demoing NodeJS apps they'd cobbled together with libraries they didn't care to understand the internals of didn't give me good impressions.
I've never noticed any other strong connections between Java & JS communities online or elsewhere, this was a just general one-off (but strong) impression from local meetups.
var addCSS = (css) => { window.document.styleSheets[0].insertRule(css, window.document.styleSheets[0].cssRules.length); };
addCSS('.x { color: red; width: 5px; }');
It's basically a JS version of SASS mixins (kinda).
Most of my objections to CSS-in-JS are they are all poorly architected high-level abstractions taking a bad solution to a lower level problem.
This feels like a good basis for a higher level tool that doesn't suck.
And like I said - I say that as someone broadly skeptical of the whole topic.
I really dislike writing styles as JavaScript objects, so styled-components let's you write actual CSS in JavaScript. We have also added support for a bunch of editors, so you don't miss out on syntax highlighting just because of that.
I'd encourage you to check it out!
I'll probably steal the approach for my own CSS-in-JS lib (j2c).