Andrew Chalkley
writes on August 18, 2015
I haven’t been so excited since the early days of jQuery. React is a JavaScript library initially developed by Instagram/Facebook for building user interfaces. Since it has received a lot of attention recently with companies like Netflix, Walmart, Tesco, Airbnb and Flipboard moving significant amounts of their UI code over to it, it’s a good idea to see what all the fuss is about.
There’s other opinions out there that discuss pros and cons of JavaScript frameworks. In this particular article it discusses the lack of longevity in frameworks and includes this cheeky image:
What the author of the article doesn’t address is jQuery. jQuery isn’t “hot” right now but its usage dwarfs all of these frameworks. It’s been around longer than all of the frameworks that are discussed in the article.
For me, React is like the Second Coming of jQuery. I believe the primary driver for the adoption of a JavaScript framework is its philosophy.
Contents
JS Framework History 101
The Rise of jQuery
In the mid-2000s there was a tonne of excitement around the emergence of these amazing JavaScript frameworks. There was Prototype, MooTools and some others. When jQuery came along, it was different to the others in key ways. It heavily promoted the use of CSS selectors, which web developers at the time were getting to grips with and promoted the philosophy of progressive enhancement. Meaning if you switched JavaScript off your site is still indexed by search engines, read by screen readers and most importantly, the functionality of your site shouldn’t be broken. It encouraged the separation of content and behaviour like CSS did with content and style. People could get behind that.
These other frameworks started to implement some of the philosophies that jQuery introduced – but they were playing catch up, they didn’t have the same vision and focus from the get go.
History is Repeating with React
React applications are built up by using discrete components. You declare your components and add any functionality to them. They’re great for creating dynamic user interfaces and can be used over and over again.
Without going into too much detail, unlike it’s contemporary frameworks it focuses on one-way data-binding, meaning when the “state” of the application changes it re-renders the parts of the user interface that the state touched. It does this by using a Virtual DOM and comparing it to the DOM in the browser and only applying the differences. But that isn’t why you should be excited, you should be getting excited because React has allowed for the first time, a practical way to create “Universal” or “Isomorphic” JavaScript applications.
A Universal JavaScript app is where the client and the server code are the same and you no longer have to deal with a templating language for your Express or Rails app. Instead of using ERB, Jade or any other templating language, you just use React. You can get React to render out your components to a string. This string can be sent to a client via an HTTP response’s body. On the client-side React kicks in to add any event handlers, still using the same code that you used on the server for the components! This is an incredible time saver and should reduce code duplication, too. When I say code duplication, I mean you’re not creating the views in one language and then jumping into React to reimplement some of that functionality. The added benefit of rendering on the server is all the reasons why jQuery was good. Your pages will be indexed as they should, and you can always progressively enhance it with more JavaScript. As web developers and designers we should be more thoughtful for all of our users, not just the ones that have JavaScript enabled.
Conclusion
In the more modern era of frameworks, React is making similar ripples to what jQuery did back in the day. The way React has implemented the Virtual DOM to apply differences to the real DOM and how it’s being used on the server-side for rendering has not gone unnoticed. Several other frameworks are copying these principles for performance and allowing for graceful degradation of their frameworks with server-side rendering. Their APIs are changing to meet React’s API, like the frameworks of old emulating jQuery’s API. In the end, jQuery’s principles and philosophies won, it kept a generation of JavaScript developers from migrating to these modern frameworks. With React the jQuery developers can safely join the modern web development community and enjoy the productivity boost that React brings and keep true to the principles that they learned with jQuery. In other words, React is like jQuery, but better, your code isn’t duplicated on the server and the client, it’s the same code and logic.
With strong philosophies like these React here to stay!
so, you are a genius at javascript frameworks and code and you use wordpress???
Spot on. Says a lot. If forward thinking is the priority, why use a blogging CMS for websites?
On of the nicest features of React is that you can hold the entire application state in a single object and manipulate that object in a simple and efficient way (e.x. That object can be an immutable data structure that manipulated with Redux). This gives you beautiful features out of the box like: Undoing, State tracing, …
a global object that does everything is a good thing?
While I generally agree with the article I also see that things are moving on from React quickly. RxJS is starting to show up in many places, like cycle.js.org and in the new Angular2 and even in rx-react.
The new realization emerging is that interaction and events are what drives apps, even more than components. Facebook is on record for saying that RxJS is not beginner-friendly enough, so they ended up only providing a half reactive experience via React. For fully reactive and the future see cycle.js.org.
The author as far as I can tell never says jQuery is a framework
Explicitly no, but he sort of says it and he’s right.
Those commenting that “jQuery is not a framework” are missing the point. It’s not about it fitting precisely the definition of a framework or if it’s a simple lib, it’s about jQuery having you frame code in a certain way (philosophy, structure or lack thereof).
In that sense, jQuery and the old way of building apps with it is also a kind of framework, regardless if you can also use it along with Backbone as a plain lib.
A framework that does not render server side is a cute toy. React is able to render server side, so it’ll stay around just because of this simple fact. Its fills the gap that those backbones/embers/angulars are still missing. It provides the best of both worlds, hence the hype
What, javascript renders on the server side, use pretty much any modern template rendering engine, like mustache.
React really is a great library especially to build social networks and other user-centric apps. At stample.co, (a collaborative content curation tool), we first built our platform with Backbone in 2013 but then decided to migrate ALL our UI to React in 2015. That was a 6-month work but it totally worth it (you can check the results trying our new interface at stample.co). We also open-sourced our own React-library called Atom React that you can check out here: https://github.com/stample/atom-react
Feel free to give feedback or to contribute if you want to be part of the growing React community.
Thanks for your reply. How is your team integrating React into your application? You bundle everything up using a task runner and do you expose your components via the window and drop them in when necessary? Or do you have an isomorphic setup?
Just an FYI jQuery is a library not a framework. From their homepage:
“jQuery is a fast, small, and feature-rich JavaScript library.”
Just for your information. jQuery is not a framework; it’s a library. It exposes a set of utility functions, mostly DOM related. I can call AngularJS, Backbone as frameworks, as they lay out the structure of an application and decides its architecture.
I have a great feeling that you’re comparing apples with oranges. React is very different from that fact that it is for generating and maintaining views. It does not expose functions to manipulate DOM. Rather, it is self contained and has minimal utilities to manipulate itself. You can call react as the “V” in the MVC, for easy understanding.
React alone is not sufficient in most cases. People follow an architectural pattern to utilize React. Sometimes its Backbone combined with React. Or it might be Flux architecture based and frameworks such as Fluxxor, Reflux might be used.
For me, the real change in philosophy is the flattening of the View and Template layers (or view and controller layers). In React, components are self-contained units which control both logic related to that component and HTML-like UI code. This was uncomfortable at first but the field seems to be embracing it: it’s a pattern that relates well to way most web apps are built.
>In React, components are self-contained units which control both logic related to that component and HTML-like UI code. This was uncomfortable at first but the field seems to be embracing it: it’s a pattern that relates well to way most web apps are built.
This is not much different to how widgets work in native UI frameworks. The widget controls (transparently) how it’s drawn AND how it handles input etc (logic). This leaves the app to have higher level logic in higher level controllers.
The more clear-cut distinction we made in HTML (code vs templates) was madness, IMHO, as if HTML apps are static designs…
I think you missed the message in this article. He’s saying “React is to HTML what jQuery was to JavaScript” and I have to agree.
React is a game changing innovation, just like jQuery was. Nothing comes close to being as flexible for creating views, and it’s one of the easiest frameworks to learn and understand once you get past the initial shock of JSX.
>Just for your information. jQuery is not a framework; it’s a library. It exposes a set of utility functions, mostly DOM related. I can call AngularJS, Backbone as frameworks, as they lay out the structure of an application and decides its architecture.
Yeah, thank you for clarifying that, the author (and we) clearly don’t know those important distinctions
/s
The premise of this article seems solid, but I’m not sure the 2 points laid out are sufficient for proving it. *Why* are virtual DOM diffing and server-side rendering so important that they make React the new jQuery? Are those the only compelling, long-term benefits using React affords you? What other parallels are there between React and jQuery other than “big name companies use it” (the same could be said, of course, of Angular, Ember, and Backbone)?
This article really just states *that* React is serving a similar historical function to jQuery, but doesn’t really explain *why* that’s the case.
Will react have a course or workshop in treehouse?
Based on Andrew’s enthusiasm, it seems it’s safe to say “yes”.
I recently put in a request with Treehouse for some React content, but they said there were no plans to do this. It would be awesome if they did, it seems like the next logical step for the JS library.
I hope so!
Cast your vote here to show your interest! https://trello.com/b/r5R1JZNO/treehouse-javascript-content-roadmap