Why You Don't Get React29 October, 2016
My coworker and friend Emad Ibrahim blogged recently about how he doesn’t really get the hoopla around ReactJs. (Are pingbacks even a thing anymore btw? They were a great way of keeping track of multi-blog discussions.)
This is the key paragraph
I responded in the comment section but want it written up here as well as I’ve seen similar sentiments even from React fans.
What the conversation is missing is that React is not a single thing.
What React is
When people talk about React, they’re really talking about two or three distinct things depending on how you’re counting.
This does not include Jsx. In fact, the default way of working with virtual-dom direct (this particular library was extracted from React, there are a few others) is to use hyperscript notation which…is just awesome and is basically what the last 10 years of template language evolution has been aiming towards.
h function is wierd, but look at how clean that is! Do you want components? Just make a function! It all looks even nicer in languages that support lightweight symbols like Clojurescript with Hiccup
(defn render  (let [other-systems '(haml pug emmet)] [:section [:ul.other-systems (for [name other-systems] [:li "Even more like " name " then before!"] )]]))
I actually strongly recommend for people to play around with the virtual-dom library directly to solidify the concept and distinguish it from React overall.
This is the other part of React-standard that people talk about when they talk of React.
ReactJs includes a very thin layer of Facebook-specific conventions around how to work with the virtual-dom system. This includes
- Their component structure, lifecycle and optimizations around this
- State, props and context distinctions
- The propTypes checker
- The way that React captures and routes DOM events
And thats about all that I can think of.
I think this is the area that contains the entirety of Emad’s complaints. And that’s fine, maybe Facebook’s conventions are not for you - I also do not care for most of these things (component optimizations and DOM event handling are cool, the rest can jump off a cliff) but this is only one part of React, and frankly its usually not the part that people are talking about when they say they love it.
It should be mentioned that most of these are lightweight enough that you can work in your own technique in fairly easily. For example Jsx can be supplanted by wrapping your components in
The Redux Thing
Finally, if you consider the React community as a whole, one of the big things that people will hail is this whole Redux/Flux/Reflux uni-directional dataflow thingy.
This is fine. I personally, think people love it because its different and they’re being introduced to a whole new paradigm that many haven’t really explored previously. Eventually it will become overused and we’ll be able to admit to ourselves that it’s not a great idea absolutely everywhere and that modelbinding and forms all have their place as well. But I’m perfectly willing to admit that its a great concept and possibly even one that should be considered the default.
Now, I am not super into Redux. I have no problem with the project itself, and I actually quite like the team’s messaging around it, but there’s just too much fanboyism around a library that can be implemented in like 5 lines of code for my taste. Personally, I would probably lean a bit more toward event-sourcing in an implementation, keeping around and aggregating all events on any interaction and using mementos to boost performance. I also feel like certain variations on this concept such as clojurescript’s re-frame tend to cut down on boilerplate and be easier to work with.
It’s About Concepts Not Syntax
So that’s what I think Emad is missing. I doubt very much that he dislikes virtual-dom, and it seems unlikely he unilaterally dislikes the entire concept of Redux. Sure, Facebook’s conventions might not be to his liking. And that’s fine. The category of React-style-system is a lot more than that and I don’t think that Facebook has necessarily hit on the best abstractions. In fact it seems doubtful that a single one-size-fits-all abstraction is even possible.
When people rave over React, they’re likely focused more on the broader ideas and not really talking about the React specific conventions. Of course these conventions might be all they know and they have no scope of reference for what else is possible within the arena, but it seems quite possible that they might not be talking about React in the same context as you are.
And this also explains the other part of Emad’s complaint. Why does every single React example look different? Well here we get this now-old chestnut
And now it almost even makes sense. The above isn’t a framework so much as a set of concepts that are useful for assembling your own framework. Yes there are some conventions that get you half way there, but you still have to complete the other half, and if you don’t like these conventions you’re free to pick and chose your own. So if you want true parity to compare with something like Angular or Ember you have to look beyond simply “React”.
But here’s the thing
And that’s the power and elegance that people are talking about and the thing that you might be missing if you don’t investigate the community further.