8 ms·

Show HN: Polished – A lightweight toolset for writing styles in JavaScript

106 points by mxstbr 10y ago

onli 10y ago
I'm not 100% what this is exactly... Care to clear it up a bit? 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?
- kej 10y ago
  I imagine it's the same appeal as wanting to run JavaScript on the server. The more things you can do in one language, the fewer times you have to switch from thinking in one language to another.
  - scaryclam 10y ago
    To me, this is like trying to use a hammer for nails, screws and painting. Use the right tools for the job at hand. Don't know how to hang dry wall? It's ok to get help!
    - nilliams 10y ago
      Not really that simple. People like myself learnt CSS back in the day, and modern CSS systems like BEM, and Sass/LESS and friends, (I love Sass), yet still see the benefits of CSS-in-JS for certain kinds of 'component-based apps' (not every site). See [0] for some of the reasonings behind CSS-in-JS. [0] https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js
    - kej 10y ago
      I think that's a fair point, but I'd say it's more like wanting to use the tools in your pocket knife instead of getting an actual screw driver or set of pliers. No, it's not as good as the real thing, but you can save time by using the slightly inferior version that's already at hand.
- mxstbr 10y ago
  Yes, this is kinda like the "lodash" for writing styles in JavaScript. 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 https://speakerdeck.com/vjeux/react-css-in-js [1]: https://medium.com/@jdan/rendering-khan-academys-learn-menu-wherever-i-please-4b58d4a9432d#.w9nshye05 https://medium.com/@jdan/rendering-khan-academys-learn-menu-... [2]: https://medium.learnreact.com/scale-fud-and-style-components-c0ce87ec9772#.kzjba8lcg https://medium.learnreact.com/scale-fud-and-style-components...
  - onli 10y ago
    The idea of writing CSS in JS is horrible to me. But I'm coming from a completely different developer camp, and find the vjeux talk completely unconvincing, so that does not mean much :) And with your comment it is clearer now where this might be useful. 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!
    - mxstbr 10y ago
      Thanks for the kind words, totally understand that this isn't for everybody. Definitely will work on improving the README, just needed to finally get this out of the door ;) Cheers!
- mbrookes 10y ago
  > this seems to be a way to write the complete CSS in JS, and then to have it compiled into CSS. 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.
  - mxstbr 10y ago
    Sorry it isn't clear to you, we could definitely do a better job with the README. If you look on the website[0] you'll see actual examples of usage. (I just announced this project on stage at ReactLondon during my talk, so it's very fresh and we haven't had a lot of time to clean up the docs yet) 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) [0]: https://polished.js.org https://polished.js.org
    - pygy_ 10y ago
      This was a big missing piece of code in the CSS-in-JS world. Thanks for providing the stdlib (following SASS is definitely a great approach).
michaelmior 10y ago
Perhaps Show HN would be more appropriate than "just launched"?
- mxstbr 10y ago
  Good call, will update!
  - mxstbr 10y ago
    Updated, thanks!
gibbitz 10y ago
I found that the killer application for Javascript would be to write github repos for Javascript wrappers for typescript. Seriously, why is CSS as Javascript objects a thing? Are we so bored with the stack we've been using that we can only make things interesting by cross compiling everything? It makes me think of this video: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- mxstbr 10y ago
  That's exactly why we made styled-components![0] 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! [0]: https://www.styled-components.com https://www.styled-components.com
  - pygy_ 10y ago
    I just discovered http://typestyle.io/ http://typestyle.io/ which should make it much easier to write CSS in JS... Auto-completion everywhere... I'll probably steal the approach for my own CSS-in-JS lib (j2c).
    - roboguy12 10y ago
      +1 for typestyle. My team and I have been using it for the past few weeks in trying to clean up a rather monolithic css project, and it's been really cool to work with.
hmans 10y ago
No.
- sctb 10y ago
  We've asked you already to please stop posting unsubstantive comments. We have to ban accounts that won't. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
tobltobs 10y ago
The current state of the JS world is getting closer every day to the J2EE craziness about 10 years ago. As an outsider it was nearly impossible to understand for what all those frameworks with funky names were required at all. For an insider every of those new frameworks looked like the solution to a fundamental CS problem. However, those fundamental CS problems where nothing else then some shortcomings introduced by the latest framework before.
- lucideer 10y ago
  The J2EE comparison is an interesting one. 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.
rattray 10y ago
Mods: consider linking to the project homepage, https://polished.js.org/ https://polished.js.org/ which appears to give much more context
- nik-graf 10y ago
  Thanks for the hint. We forgot about it and I just added it.
- deleted 10y ago
  [deleted]
debaserab2 10y ago
This tool seems useful if you buy into the philosophy, but I'm just not sold yet - component based styling leads to a lot of style duplication and makes it very easy for a developer to go "off the playbook" when it comes to enforcing a consistent styleguide throughout an app. 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.
- pygy_ 10y ago
  CSS-in-JS doesn't mean you have to inline everything in the component file.. You can totally create a style library and include pieces of it as mixins for the styles of each component.
- clay_to_n 10y ago
  >This tool seems useful if you buy into the philosophy, but I'm just not sold yet - component based styling leads to a lot of style duplication and makes it very easy for a developer to go "off the playbook" when it comes to enforcing a consistent styleguide throughout an app. 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.
  - mdahlstrand 10y ago
    What are these gotchas if I may ask? Have you got experience with BEM?
    - mistersys 10y ago
      Uhm.. Having to use BEM is a gotcha. Why don't you write all your applications code in a global scope and just use a BEM-like naming scheme for your functions?
analogmemory 10y ago
I'm coming around slowly but I still have a hard time with css being embedded in JS components. I have used SCSS for so long I am used to style and function being separate concerns and separate files. I like the idea of being able to use 'mixins' for js components.
juandazapata 10y ago
Can somebody explain how this approach affects the style caching by the browser? It seems that this will just throw away all the caching optimizations built around that.
- pygy_ 10y ago
  It is replaced by script caching. Loading the styles from JS rather than CSS is a bit slower, but not much.
  - juandazapata 10y ago
    I mean more like the AST behind parsing/rendering the styling rules, not caching the downloaded file.
    - pygy_ 10y ago
      I didn't know it was a thing... Some CSS-in-JS libs support isomorphic apps, but I don't know how well they take advantage of the caching abilities of browsers.
k__ 10y ago
Also interesting, for people who fear style duplication: http://styletron.js.org http://styletron.js.org
- pygy_ 10y ago
  Automatic atomification of styles meshes badly with conditional at-rules. You can end up with conditional rules that are ignored.
abritinthebay 10y ago
I'm a massive CSS-in-JS skeptic but this is a very nicely thought out low-level tool for that stack. 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.
osoba 10y ago
Wouldn't these two lines of code do the same thing? var addCSS = (css) => { window.document.styleSheets[0].insertRule(css, window.document.styleSheets[0].cssRules.length); }; addCSS('.x { color: red; width: 5px; }'); Test examples (+ another version that can add multiple selectors in the same line): https://jsfiddle.net/xkLnj9st/ https://jsfiddle.net/xkLnj9st/
jlebrech 10y ago
i'd like a relative positioning framework for css, to clamp anchors point relative to each other. that stuff is HARD in CSS

106 points by mxstbr 10y ago

onli 10y ago

I'm not 100% what this is exactly... Care to clear it up a bit? 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?

kej 10y ago
I imagine it's the same appeal as wanting to run JavaScript on the server. The more things you can do in one language, the fewer times you have to switch from thinking in one language to another.
- scaryclam 10y ago
  To me, this is like trying to use a hammer for nails, screws and painting. Use the right tools for the job at hand. Don't know how to hang dry wall? It's ok to get help!
  - nilliams 10y ago
    Not really that simple. People like myself learnt CSS back in the day, and modern CSS systems like BEM, and Sass/LESS and friends, (I love Sass), yet still see the benefits of CSS-in-JS for certain kinds of 'component-based apps' (not every site). See [0] for some of the reasonings behind CSS-in-JS. [0] https://speakerdeck.com/vjeux/react-css-in-js https://speakerdeck.com/vjeux/react-css-in-js
  - kej 10y ago
    I think that's a fair point, but I'd say it's more like wanting to use the tools in your pocket knife instead of getting an actual screw driver or set of pliers. No, it's not as good as the real thing, but you can save time by using the slightly inferior version that's already at hand.
mxstbr 10y ago
Yes, this is kinda like the "lodash" for writing styles in JavaScript. 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 https://speakerdeck.com/vjeux/react-css-in-js [1]: https://medium.com/@jdan/rendering-khan-academys-learn-menu-wherever-i-please-4b58d4a9432d#.w9nshye05 https://medium.com/@jdan/rendering-khan-academys-learn-menu-... [2]: https://medium.learnreact.com/scale-fud-and-style-components-c0ce87ec9772#.kzjba8lcg https://medium.learnreact.com/scale-fud-and-style-components...
- onli 10y ago
  The idea of writing CSS in JS is horrible to me. But I'm coming from a completely different developer camp, and find the vjeux talk completely unconvincing, so that does not mean much :) And with your comment it is clearer now where this might be useful. 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!
  - mxstbr 10y ago
    Thanks for the kind words, totally understand that this isn't for everybody. Definitely will work on improving the README, just needed to finally get this out of the door ;) Cheers!
mbrookes 10y ago
> this seems to be a way to write the complete CSS in JS, and then to have it compiled into CSS. 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.
- mxstbr 10y ago
  Sorry it isn't clear to you, we could definitely do a better job with the README. If you look on the website[0] you'll see actual examples of usage. (I just announced this project on stage at ReactLondon during my talk, so it's very fresh and we haven't had a lot of time to clean up the docs yet) 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) [0]: https://polished.js.org https://polished.js.org
  - pygy_ 10y ago
    This was a big missing piece of code in the CSS-in-JS world. Thanks for providing the stdlib (following SASS is definitely a great approach).

michaelmior 10y ago

Perhaps Show HN would be more appropriate than "just launched"?

mxstbr 10y ago
Good call, will update!
- mxstbr 10y ago
  Updated, thanks!

gibbitz 10y ago

I found that the killer application for Javascript would be to write github repos for Javascript wrappers for typescript. Seriously, why is CSS as Javascript objects a thing? Are we so bored with the stack we've been using that we can only make things interesting by cross compiling everything? It makes me think of this video: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

mxstbr 10y ago
That's exactly why we made styled-components![0] 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! [0]: https://www.styled-components.com https://www.styled-components.com
- pygy_ 10y ago
  I just discovered http://typestyle.io/ http://typestyle.io/ which should make it much easier to write CSS in JS... Auto-completion everywhere... I'll probably steal the approach for my own CSS-in-JS lib (j2c).
  - roboguy12 10y ago
    +1 for typestyle. My team and I have been using it for the past few weeks in trying to clean up a rather monolithic css project, and it's been really cool to work with.

hmans 10y ago

No.

sctb 10y ago
We've asked you already to please stop posting unsubstantive comments. We have to ban accounts that won't. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

tobltobs 10y ago

The current state of the JS world is getting closer every day to the J2EE craziness about 10 years ago. As an outsider it was nearly impossible to understand for what all those frameworks with funky names were required at all. For an insider every of those new frameworks looked like the solution to a fundamental CS problem. However, those fundamental CS problems where nothing else then some shortcomings introduced by the latest framework before.

lucideer 10y ago
The J2EE comparison is an interesting one. 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.

rattray 10y ago

Mods: consider linking to the project homepage, https://polished.js.org/ https://polished.js.org/ which appears to give much more context

nik-graf 10y ago
Thanks for the hint. We forgot about it and I just added it.
deleted 10y ago
[deleted]

debaserab2 10y ago

This tool seems useful if you buy into the philosophy, but I'm just not sold yet - component based styling leads to a lot of style duplication and makes it very easy for a developer to go "off the playbook" when it comes to enforcing a consistent styleguide throughout an app. 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.

pygy_ 10y ago
CSS-in-JS doesn't mean you have to inline everything in the component file.. You can totally create a style library and include pieces of it as mixins for the styles of each component.
clay_to_n 10y ago
>This tool seems useful if you buy into the philosophy, but I'm just not sold yet - component based styling leads to a lot of style duplication and makes it very easy for a developer to go "off the playbook" when it comes to enforcing a consistent styleguide throughout an app. 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.
- mdahlstrand 10y ago
  What are these gotchas if I may ask? Have you got experience with BEM?
  - mistersys 10y ago
    Uhm.. Having to use BEM is a gotcha. Why don't you write all your applications code in a global scope and just use a BEM-like naming scheme for your functions?

analogmemory 10y ago

I'm coming around slowly but I still have a hard time with css being embedded in JS components. I have used SCSS for so long I am used to style and function being separate concerns and separate files. I like the idea of being able to use 'mixins' for js components.

juandazapata 10y ago

Can somebody explain how this approach affects the style caching by the browser? It seems that this will just throw away all the caching optimizations built around that.

pygy_ 10y ago
It is replaced by script caching. Loading the styles from JS rather than CSS is a bit slower, but not much.
- juandazapata 10y ago
  I mean more like the AST behind parsing/rendering the styling rules, not caching the downloaded file.
  - pygy_ 10y ago
    I didn't know it was a thing... Some CSS-in-JS libs support isomorphic apps, but I don't know how well they take advantage of the caching abilities of browsers.

k__ 10y ago

Also interesting, for people who fear style duplication: http://styletron.js.org http://styletron.js.org

pygy_ 10y ago
Automatic atomification of styles meshes badly with conditional at-rules. You can end up with conditional rules that are ignored.

abritinthebay 10y ago

I'm a massive CSS-in-JS skeptic but this is a very nicely thought out low-level tool for that stack. 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.

osoba 10y ago

Wouldn't these two lines of code do the same thing? var addCSS = (css) => { window.document.styleSheets[0].insertRule(css, window.document.styleSheets[0].cssRules.length); }; addCSS('.x { color: red; width: 5px; }'); Test examples (+ another version that can add multiple selectors in the same line): https://jsfiddle.net/xkLnj9st/ https://jsfiddle.net/xkLnj9st/

jlebrech 10y ago

i'd like a relative positioning framework for css, to clamp anchors point relative to each other. that stuff is HARD in CSS