Skip to content

Instantly share code, notes, and snippets.

@satya164
Created May 12, 2017 02:01
Show Gist options
  • Save satya164/d23b0031c24098c409fa01a396ac37ac to your computer and use it in GitHub Desktop.
Save satya164/d23b0031c24098c409fa01a396ac37ac to your computer and use it in GitHub Desktop.

JavaScript Style Library Wishlist

  • Familiar CSS syntax: Using CSS syntax makes it easier to copy/paste code from devtools and the internet, and a huge productivity boost.
  • SCSS like & shorhand: Super nice to write things like &:hover without having to write selectors again.
  • Nesting media queries: Nice to nest media queries inside a style block instead of having to declare it like plain CSS.
  • Support for CSS animations: CSS animations are great :)
  • No coupling to HTML tag: HTML tags have semantic meaning, and coupling styles to HTML tags makes it harder to re-use the same styles, for example, sometimes some of my buttons and links have similar styles and I don't wanna repeat them.
  • Easy to override styles: Overriding styles is one of the main pain points. Many libs don't do anything special and just produce different class names for the styles I declare. Due to no class name having higher specificity, the styles depend on the declaration order which can produce inconsistent results.
  • Easy theming support: Theming is not super-common, but can be very important for some apps. Some libraries require you to declare 2 different class names, and build own theming architecture, which is not very nice.
  • Statically analyzable: Makes it possible to statically analyze CSS makes it possible to avoid JS for the CSS entirely. However, it's still nice to use declared constants etc, or things like theme === dark ? 'black' : 'white', where the library could do some static analysis to include the constant, produce separate class names etc.
  • Flow support: Some libraries break Flowtype. It'll be nice if types flow naturally even if you need to wrap the component in something.
  • Correctness - Libraries should verify that my CSS is properly terminated etc. Many times I forget to write a semi-colon etc. and break the styles.
  • Linting: No-one does it, but it'd be super-helpful to lint CSS properies to verify there are no typos. So many times I accidentally use camel case where I should've used hyphens.
  • Auto-completion: CSS should get auto-completed just like CSS files.
  • Syntax highlighting: It's important to have a good syntax highlighter just like CSS files.
@satya164
Copy link
Author

satya164 commented May 14, 2017

For browsers, but what about React Native? React VR? Etc.

I don't really care about using a CSS in JS library for React Native. It doesn't solve a problem I have and RN has it's own styling API. The problems with web are different as you are copying styles from the web and dev-tools, which is not true for RN. The main pain-point is browser's CSS which I want to optimize the DX for. I don't mind if the same DX is there or RN.

That's probably how Angular was born.

It's not about angular or any template language. Why do you use JSX instead of React.createElement? Also it's not a template language. There are no custom control flow or anything. It's just a plain string. This is just a preference IMO. I despised CSS in strings initially until I actually got to use one. Despite the lack of maturity, I loved it because of the familiarity and convenience of being able to paste styles from devtools, and I don't think JS objects can convince me otherwise.

And not to mention, when writing media queries, CSS keyframes etc. you now need to learn a completely new thing while you could have used your previous knowledge. Each library does things differently, so you don't even know what's valid.

Also even though it doesn't make a difference for me, folks who only work with CSS and not JS will have a better time with CSS syntax than JS. I get confused with style props in JS all the time, (is it '--webkitRadius' or '--webkit-radius' or webkitRadius)?

There's a tooling issue regarding linting the syntax, but it's solvable. Syntax highlighting already works for styled-components, styled-jsx etc. Autocomplete is a problem with JS objects too. Though I'm sure we'll solve these someday. We could reuse lots of existing data from the CSS linters and autocomplete plugins.

Example?

.header {
  margin: 20px;
  margin: 2rem;
}

This is just one example, but depends on browser support etc. I remember doing such things.

Nuclide, because it's JavaScript with Flow

I'm talking about CSS properties. I'm not aware of any editor plugin which will autocomplete CSS properties right now. It will certainly be super useful in RN or libraries like aphrodite.

Flow

Are there Flow types defined for each CSS property? I'm talking about a linter which actually validates the CSS properties, like display: iline-block won't be valid.

Every style prop is default, so it can be overriden

So my question was, since themes are based on context which is dynamic, how does it work if the CSS is static? Or you just use inline styles for theming and overriding.

I strongly believe that style props are better than CSS strings.

I'd say that's a personal preference. I don't like to mix my styles with other props.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment