SurviveJS

  • react-game-kit – Make games with React – Interview with Ken Wheeler
  • In the background, Glamor treats CSS rules as
  • Glamor also tries hard to allow
  • PureScript – Strongly Typed Programming Language Compiling to JavaScript – Interview with Phil Freeman
  • , the author of an inline CSS solution known as Glamor.

If you ask multiple React developers their styling approaches, you will also get multiple differen…

@survivejs: Interview of @threepointone, the author of Glamor, a css-in-js styling solution

#reactjs

If you ask multiple React developers their styling approaches, you will also get multiple different answers. One trend is clear, though, the movement towards inline styling.

This is something that was considered an anti-pattern before React, but as React has become more popular, we are also more open to question our earlier beliefs.

I’ve discussed various approaches myself. Each solve similar problems in different ways. Today I’m interviewing Sunil Pai, the author of an inline CSS solution known as Glamor. Read on to learn more.

Hi! My name’s Sunil Pai, and I wrote the css-in-js library Glamor. In the past, I have built a bunch of websites for Myntra, Yahoo, Visa etc. I now write JavaScript libraries for fun and/or world domination.

The official line is Inline CSS for Components, but in my opinion it’s THE missing CSS piece for React. I wrote a longer piece on how React solves ‘writing’ web pages in a natural way, and Glamor is the css companion to that piece.

In the background, Glamor treats CSS rules as ‘values’, generates an identifier corresponding to that rule (similar to Clojure hashes for their data structures). It attaches this id to a DOM element with a data-attribute, while also adding the rule to a real stylesheet. Glamor also dedupes rules, manages universal shims, adds vendor prefixes, all the boring stuff you don’t want to do by hand.

I really like this css-as-values abstraction. It enables a bunch of nice properties, like not having to name a rule unless preferred, and letting the developer choose how to compose/modularize their code. Glamor also tries hard to allow all possible CSS features, with no compromises on selectors and what not. And it works hard at being efficient, so you shouldn’t worry about it being a part of your stack.

I’m also happy with the abstraction this library offers; it’s low level enough that it’s mostly invisible, but allows for some higher order programming. Indeed, Glamor itself ships with shims for Aphrodite and jsxstyle APIs, and I’m totally on the lookout for other interesting options.

There’s some other technical stuff like super efficient css insertion, precise server side rendering, a plugin system, etc, but I think the css-as-values abstraction is the nicest.

It started off as an exploration of a browser API I’d never used. I was also checking out other css-in-js libraries at the time, and none of them really ticked off all the things I wanted from such a library.

One week of furious coding later, Glamor was born, tests and all. Since then, I’ve been tweaking and polishing away at the thing, with help from some nice online folks who are using it as well. There might be many css-in-js libraries, but this is the one I like.

Well, there a bunch of fun enhancements planned. React Native support would be nice too, I guess? In the slightly more distant future, I’m curious to see how React itself deals with CSS / alternative styling systems (like terminals, WebGL, etc).

by hand after having used something like Glamor. I think this trend will continue, particularly around using ‘components’/JSX to represent other stateful parts of your system.

I also see some movement towards micro-transpilation; adding a plugin or two to get some compile time powers for your code. This already exists for most compile-to-js languages, and it’s also how devs use new JavaScript features in places without support for the same.

I think developers will further add their own tiny compiler transforms with Babel/whatever to their apps and unlock new functionality (I’m told the LISP folks have had this for decades with macros).

I think the internet is really noisy right now; trying to listen to everybody and doing everything will probably overwhelm most (all?) people. Don’t get distracted by them, and don’t try to learn everything at once. Focus on what you want to build, and having some fun while doing so. Otherwise, it’s really not worth it, no matter what your stack looks like.

Could you find _why for me? I think the world could use him right now. I’d love to hear what @jingc’s working on, and how @tjholowaychuk’s startup journey’s going.

Thanks for the interview Sunil! It’s cool to see innovation around this area. Incidentally I had to work with the StyleSheet API as well and I ended up writing some helpers to make it easier to use. StyleSheet API might not be the most developer friendly API, but the performance is there. Let the browser do what it does the best.

To learn more, check out the GitHub project page of Glamor. The API is beautifully simple.

If you enjoyed this blog post, consider subscribing to the mailing list below or following @survivejs for occasional updates. There is also RSS available for old beards (no pun intended).

SurviveJS