Skip to content

Instantly share code, notes, and snippets.

Last active August 29, 2015 14:15
What would you like to do?

A Weekend With React

I spent Saturday doing another dive into React 0.12 and ES6. I just wanted to share some of the experience since it's a stack that we're strongly considering adopting (for at least some) of our future work.

Once you get past the weirdness of writing HTML in your JS, it's actually really nice to control your template so directly. Part of it maybe that I'm learning ES6 syntax at the same time, but I'm no longer weirded out by JSX. I'm using the 6to5ify browserify transform, so nearly the full spectrum of ES6 is available, and it feels great. Highlights are destructing and the class syntax (I was surprised!). This is legit code:

  // named fuction for free! Don't even need to use the function keyword!
  , getInitialState(){
    var deadline = moment([2015, 8, 6])
      , timeRemaining = this.getTimeRemaining(deadline)

    // oooo… JS just does the right thing here!
    return {
      , timeRemaining

The React API also removes a lot of the boilerplate that we're used to writing. There's really not much need for the ribcage generator that we've developed because React just works out of the box. This might change if we standardize on some mixins though.

Server rendering was silly easy. I've fought this battle a number of times before, React just did the right thing. So. Much. Wow.

Things I know I still need to play with

  • ReactRouter. This looks like an excellent way to easily enable deep links and have server and client routes match up.
  • Any sort of data passing. I've read into Flux heavily, and despite initial indications, Relay has not replaced Flux at Facebook, so it's really worth learning. I watch a selection of talks from the first React conference the other week and the consensus is that just like in our app, passing data between components is still a pain.
  • Immutable.js looks like The Right Answer™ for data handling. Especially when combined with shouldCommonentUpdate, but I'm still not totally sure how that works with a realtime pipe.
  • Inline CSS is broken (see below). Is there a way to combine inline CSS and global styles while style maintaining the "component" feel? Atomify might be the answer here. It might also be possible to pull out the styles into a separate stylesheet?

What did not work

Slow to load

React.js is big. Like 100k big. It also bundles in a bunch of error checking with is really nice in development, but I've not seen a way to remove it from production builds. I noticed a significant lag in downloading and initializing the JS. You can change user perception by having the server send down the rendered HTML and that helps a lot, but it's still worth noting that the JS is not going to be ready very quickly on page load.

Inline CSS

I was skeptical from the start, and I'm now sure that it's not ready. At a minimum it's not ready. More likely, it's fundamentally flawed. It’s no good at vendor prefixes, abstraction, media queries and performance.

I will say, once you get used to JSX, it's actually really nice be able to write styles in the same file. It feels like a real "component". But, there are far to many restrictions to make this practical.

There's no way to override a style on the same selector. This is impossible to do:

div {
    display: -webkit-flex;
    display: flex;    

Because you can't declare two display styles. That makes flexbox impossible because iOS needs the webkit prefix. My workaround is to add a .flex class to the global CSS and apply that classname in React, but that's a kludge, and gets away from "component" feel of React.

Next up: "media queries" are broken. You have to use JS to detect widths and update inline styles accordingly. I was initially excited by this, because it means that element queries are the default! But, it also means that you have to use .offsetWidth and window.resize all over the place. That's crap for performance. All the global resize event listeners will slow you down, and offsetWidth is a good way to cause a recalc-style and kill performance.

Similarly, other "global" CSS rules are out. One of the first things I wanted to do was use normalize.css. There's no way to that, you have to have a stylesheet. Re-usable animations with @keyframes are out too.

After all this, you're still stuck with the fundamental flaws that are inline styles: additional initial download times because of all the additional markup, and the ongoing performance hit as the the browser needs to parse all the style tags instead of a single CSS rule.

Sigh As expected, CSS is just better at some things than JS. There's a reason for the two different technologies.

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