There are a lot of Javascript MVC style frameworks out there. Lately I’ve been publicly cooing about ReactJS the latest templating engine on the scene from the guys at Facebook. I’ve had a lot of queries about it, ones that I imagine are quite common so thought I’d try to go through a few there.

Nothing too code related (there are already plenty out about that and some suggestion at the end) this is more about the why’s and the should you’s rather than the how to’s. I’ll happily expand on any points you want to know more about in future posts - yep I said future, because we intend to be working on this ReactJS stuff for quite a while, thats a good sign straight away.

What the heck is ReactJS?

ReactJS is a javascript library that allows you to build re-usable components that consistently render the same HTML for a given chunk of data (that data being in JSON format, string or numbers).

Components can be nested and you pass data down from parent to child. If you change the data then the component redraws automatically so you don’t have to worry about updating it, just poke in different data and it will render the way you told it to for those settings. If you poke data into the parent then the children get redrawn automatically.

This simple change of mind set allows you to just focus on initially building the components and then changing the data they use to render rather than all the different states any one component (or page) might be in, you just worry about the top most parents data and how to poke that in.

Its written in javascript and is dependant on no other frameworks.

Its relatively simple to use yet very powerful, currently powering the whole of the Facebook chat UI so its battle tested and actively developed.

It can run/render in the browser or on the server (yes even in .net as we do here) more on this in a bit.

It is blazingly quick at what it does. All that redrawing goes against all our web developer training, we should only be updating what has changed right? Grab the DOM and update it or some such? ReactJS takes care of all of this and is very very performant at it. It updates only what is needed, only what has changed, more on this in a bit.

Oh so its like ?

Erm...I normally love comparing things, it can greatly help with getting an understanding quickly. In this case though I’ve found that NOT trying to map it to an exist knowledge base helps more than trying to.

I had the same problem with getting my head around the move from SVN source control to Mercurial (other brands of DVCS are available), if I tried to use Mercurial in a SVN way I just tied myself in knots so I’d suggest not doing that with ReactJS, lets just start with a blank slate and some knowledge of Javascript.

ReactJS is a way of creating components/tags/widgets that will render the exact same mark up for a given chunk of data. That chunk of data is passed into the component at the time of rendering. Think of it like that and you’ll find it much easier.

Why not just use AngularJS?

Theshockingly handled announcement of Angular 2 and resulting fall out from it hit just at the point where we needed to make a choice on our front-end tech for a project we expect to be around for a good 5+ years (yep not everything is digital landfill in 18 months time). We chose to look around at our options and after some prototypes we when with something that was smaller, simpler and nicer to code with: ReactJS.

Why are you using it?

I loved its simplicity and cleanliness. With that simplicity comes great power when you started building up a library of components that you can reuse and started nesting them.

It. just. felt. right.

Is it difficult to learn?

Assuming you know javascript and JSON you should be good to go.

One of the biggest parts of it that I like but which I think so far has been greatly overlooked (other than in the talks from Facebook) is its ease of comprehension for a developer. Easy to pick up, easy to come back to. There is very little "magic" occurring or boilerplate required.

As the owner of the company of web developers this is music to my ears. I don’t want to invest in complex, difficult to learn, expensive to support tech at the core of my company especially when they are obsolete/dropped/out of fashion every 6 months as most JS frameworks appear to be. That sounds like a great way to burn money and time. I want the simplest solution that solves the problem. The fact you can drop someone into a ReactJS setup (as we have done with Jack here in the office) and they can sort of "get it" within a hour and start making "real stuff"straight away is fantastic especially when the stuff is super fast, easy to understand and bloody good fun to do. Yep, fun, real fun. When did you last have fun coding?

ReactJS actually helps you when you step off the path too by firing helpful warnings and course corrections into the console window of your dev tools of choice. This really helps you rather than punishing you or making you have to keep jumping on the forums for help. There are very few blocking issues that stop you getting things done.

It has a small rule thats easy to remember/learn (the docs are currently about 20 pages in total and easy to digest), the mindset needed to "get it" does not require months of late night reading/hacking or a lack of social skills and aversion to sun light.

The hardest part is trustingthe ReactJS way of building and letting go of old habits picked up from other frameworks and years of hacking for the web. Such as getting an element from the DOM and messing with it directly, you should just be changing data pass to it to get it re-rendered not changing it directly. That said you can still do those btw if you want to, ReactJS is not an all or nothing thing, you can mix and match if you like/need.

Can I run ReactJS on windows or IIS or do I need node.js?

We probably lose all the none .net readers at this point... :)

Running javascript on the server is nothing new (I’ve been doing it in Classic ASP via JScript for over a decade, stop laughing at the back!) but it can initally be a scary prospect especially if you've come from a strongly typed background like .net. It need not be though. ReactJS.net is a great asp.net MVC library that lets you run your ReactJS goodies on IIS no problem at all. However you don't need it for playing around, just do that in browser.

Here at Offroadcode we’ve all got Node.js installed locally and I’d recommend if you are a Windows .net developer to do the same and learn some new stuff. The tools they have available on that platform are great, free and aimed at web development. You are missing out by shunning only things that run in Visual Studio. I’d especially recommend you check outwebpack which compiles all your JS files into one bundle (it does so much more btw).

The ReactJS.net project has a post on how to do it with everything to get up and running.

What is with all this JSX stuff? Why is there raw HTML in my javascript?

JSX is some syntactic sugar that Facebook have added into ReactJS to make it more declarative which in turn makes it easier for your head to understand what it is seeing.

ReactJS converts this to vanilla javascript via either another chunk of JS in browser (for initial lunchtime playing around develoment only) or ideally a pre-processor ala SASS or LESS but not like CoffeeScript which to me butchers the language with a whole new set of syntax and quirks you have to learn. With JSX we already know HTML so mixing it in pretty quickly feels fine and soon becomes normal. We use webpack to do our pre-processor goodness which does the job in about 0.5 of a second, faster than I can click refresh.

Having your components defined as tags makes it so much easier to get the meaning of the code at a glance rather than technical ins and outs that you would see if it was the raw vanilla javascript commands that the JSX pre-processor will generate. This has some amazing advantages in time saved or brain CPU cycles as I like to call them. You can scan a script file and "get" what its doing once you train your brain to not flip out when you see unquoted HTML tags in a return statement.

It is not a requirement to use it however personally I strongly suggest you do. There are many die hards who say they hate it and won’t use it (to be fair even my ears pricked up when I heard it was optional "give me the raw JS damn it I know what I’m doing").

However I doubt they are on a mixed dev team or have even actually tried using it in anger. It saves keystrokes, mental effort and the pre-processors let you know real fast if you messed up (shhhhh...kind of like a compiler), I can’t see how any of that is a bad thing.

What about designers? Do they get it?

James our Creative Director does not code yet he's comfy enough with React to modify the JSX and apply classes etc. As the JSX looks a lot like HTML he simply gets its. I doubt he will be building any new components up from scratch any time soon (although I think he should) but he'll happily add in markup and edit what we already have built to flesh it out. JSX is not a million miles away from what he's used to.

A simple cheat sheet with 4 rules on it is all he needs to get motoring. The compiler tells him if he messed up, the console explains why and the 'edit > refresh > edit' development cycle is so fast that he can work out what he's done wrong if anything real quick. No need for Visual Studio (woot).

How is ReactJS so fast?

I’ve talked about the speed of ReactJS. You have to build something and see it in action to truly get just how fast it is. How does it do it? Surely redrawing all the DOM again would cause flicker and be massively wasteful?

ReactJS works with two representations of your app:

• The real DOM in the browser, this is what the user is actually seeing, the one we all know and love.
• A virtual DOM, this is what ReactJS thinks it should be rendering according to your code.

If you’ve ever inspected an element in your browser dev tools you’ll see that a DOM node can have 100’s of properties. Its pretty heavy lifting and the kind of thing left to...well the browser really.

As a result the virtual DOM stores or cares about only a fraction of these and rebuilds them every time you change the data for a component. This means its not as crazily slow or expensive to do as you might think. Javascript in modern browsers are officially in the "bonkers fast" bracket. Messing with the real DOM though is still expensive so how to get around that?

Thats the really magic bit, ReactJS does a diff between the real DOM and the virtual DOM and builds up a list of javascript DOM commands that would be needed to sync the real DOM with the virtual one. This might only be a handful which it applys to the real DOM which updates the display. All this is super optimised and happens in a blink of the CPU. Its really quite amazing to see.

As a result of this sleight of hand the front end is super responsive yet your mental model of the application, the bit you need to worry about day to day, is greatly simplified.

You change the data at the top of the app, it trickles down to the components via ReactJS which just updates itself in the most optimised way. You stop having to worry about keeping track of things like which element is data binding this to that, instead you spend your time building the data that will drive it, poking it in the top and making it look pretty in small re-usable components.

If it helps, think of it like doing a full page refresh everytime you want to change something but without the waiting, the lack of content, the flickering. You are redrawing the entire screen every time you change the data.

ReactJS on the server?

Yep, you can render your React output (from your initial page data) as HTML and then send it down the wire. The browser is obviously optimised to parse HTML and builds up a DOM for it so the initial page load is as fast loading any other server-side template output.

Then behind the scenes the client-side version of React kicks in and can handle any DOM updates from then on (via Ajax, user-interactions, etc.). This gives you the best of both worlds, a fast first load and snappy page interactions after that all with the same templates/code base.

This also gets around the usual query of "what about SEO?". By rendering the HTML server side your page is like any other. You can view source and see the inital HTML used to render the complete page.

Again, .net folks should checkout ReactJS.net once you've got the hang of it (its not required to get started so leave it be at first) which handles a lot of this for you. We’ve even got a fork and some pull requests coming for getting React-Router working too.

Should I switch to ReactJS from ?

In short if heavily invested in another framework, probably not. That was a quick one.

If you’ve invested lots of time and effort learning another framework (lets just say AngularJS and be done with it) and have plenty of code you need to support why bother muddying the waters of your mind any more than you need. If it does the job stick it out. Don’t fall for "oh its written in whatever was the favour of the month was" style of dev.

However, its always good to broaden your horizons and see how the other half live. You can certainly "have a play" with ReactJS in the meantime. If you’ve committed that much time to learn one framework enough to not want to give it up then I’m sure you can spare the odd lunch time on something new rather than fine tuning your skillset in the other. I for one think ReactJS is well worth a look.

I can't currently see it going away anytime soon and I like how it does one job well rather than trying to be all things to all people. Give it a whirl and make up your own mind.

I want to learn more, where is a good start?

The best place for ReactJS is the Facebook ReactJS website, its small and says enough but strangly everyone thinks there must be better stuff else where. Once you’ve got your head around it a little I highly recommend Pete Hunts posts Thinking in ReactJS from the same site.

Other helpful stuff includes:

More about the "how" then the "why": blog.andrewray.me/reactjs-for-stupid-people

While reading some of these you might hear about Flux (or Reflux or Fluxxor) and React-Router. Don’t get side tracked looking into those yet. Cut your teeth on some ReactJS bits first and then look into these other goodies, they are all fine bits of kit but run before you can walk. I’d advise avoiding any "starter kits" too which tender to have 101 bits in there doing magic you have no idea about.

Oh last tip: everytime you see any mention of "browserify" in blog posts about ReactJS mentally swap it out in your head for "webpack", its a better and easier to use bundler/jsx compiler/minification tool in our experience (and Facebooks too).

Tap me up on twitter if you have any questions and if you are in the states don't miss my talk about ReactJS in Umbraco at uWestFest in March.