Followers of my blog may remember my microservice period. There was a time I could not shut up about them. Now, several blogs and not a peep. Am I over microservices? Not by a long stretch.
For us, microservices are gravity now. I remember an interview with Billy Corgan of The Smashing Pumpkins where, when pressed about his choice of guitar strings, he answered: “I use them”. That’s how I feel about microservices – now that we live and breathe them every day, they are not exciting, they are air. The only people who get exited about air are SCUBA divers, I suppose, particularly if they are running low.
ReactJS, on the other hand, is interesting to us because we are still figuring it out. For years we were trying to have our cake and eat it too – merge the benefits of server and client side rendering. I guess my answer to ‘vanilla or chocolate ice cream’ is ‘yes please’, and with React, I can have my chocolate sundae for breakfast, lunch and dinner.
The problem with ninja rock star unicorns
The magical creature from the title is of course the sought after 10x developer. He/she knows all the modern frameworks, sometimes reads about the not so modern ones just for laughs, and thrives where others are banging their heads against their desks repeatedly.
Rock star developers not only do not shy away from frameworks with high barrier of entry such as Angular, they often write there own, even more sophisticated and intricate. Nothing wrong with that, except that you cannot hire a full team of them, and even if you could, I doubt team dynamics would be particularly great. The reality of today’s developer job market is that you will likely staff a team with great, competent and potentially passionate developers. I say potentially because in many cases their passion will depend on you as a leader and your ability to instill it.
The React connection
What kept me away from Angular for the longest time was the opinionated nature of it, and the extent to which it seeks to define your entire world. Angular is a cult – you cannot be in it part time.
“Angular is a cult – you cannot be only a part time member.”
Not an Angular cult member
I have already written about why I got attracted to React from a technical point of view. There are great things you can do with isomorphic apps when you combine great React libraries. But these are all technical reasons. The main reason I am attracted to React is its philosophy.
We are all idiots at times
This complexity may not be a big deal while you are in the thick of it, coding like a beast. You may be a great developer. The problem is that the moment you turn your head away from that code, you start the ‘idiot’ clock – until that time when you no longer remember how everything fits together.
Now, if you are looking at your own code and cannot figure out how it works, what are the chances another team member will? I long ago proclaimed that dumb code is good and smart code is bad. Not bad code, just straightforward, easy to understand, ‘no software patent here’ code. Your future self will be grateful, future maintainers doubly so.
React allows us to write boring code
Let me summarize the key React philosophy in one sentence:
“Something changed in my application’s state. Better re-render it.”
React in a nutshell
I cannot emphasize enough the importance of this approach. It does not say “watch 50 variables and do surgically change DOM elements and properties when something happens in one component, then cascade those surgical changes to other components also watching those components”. Behind this, of course, is React’s ingenious approach of using a virtual DOM and only updating the real DOM with the actual changes between the two. You can read about it on React’s web page.
Increase velocity without increasing bug rate
The key design goal of React was to help real world projects running code in production. Developers of modern cloud applications are under constant pressure from product management to increase velocity. The same product management of course expects you to maintain quality of your apps, which is very hard. It is not hard to imagine that shortening the cycles will increase the bug rate, unless the code we write is simplified. Writing ‘surgical’, intricate code in less time is asking for trouble, but React is easy to understand. There is uniformity in its approach, a repeatability that is reassuring and easy for people who didn’t write the code originally to understand when they pick it up.
Developers take great pride in their work, and sometimes they get carried away by thinking that code is their deliverable. They are wrong. What you are delivering are user experiences, and code is just means to an end. In the future, we will just explain what we want to some more powerful Siri or Cortana and our app will come to existence. Until then, we should use whatever allows us to deliver it with high velocity but without bugs that would normally come with it.
For my team, React is just the ticket. As is often in life, YMMV.
© Dejan Glozic, 2015
Thanks for the nice series of articles Dejan! Especially the PayPal article (at last, after reading allot of blog and tutorials!) showed me a real life complete example of a ReactJS webapp.
In this article you recommend the use of ReactJS for making a more-than modestly interactive site.
But what would you recommend to create a modestly interactive site?
I’m not talking about a small single page website but a heavy content website. I really like the way of componetizing everything in ReactJS but it feels to overkill for a non-interactive site*. The focus in my components would be more HTML/CSS than JS. A template language like Handlebars (more HTML-isch?) seems more suited for this job it looks to me.
Any ideas/ways/links/frameworks (I’d rather not…)/… to help me find a solution for my use-case?
Thank you for the kind words. As for the suggestions, my qualification is always that you need to use the right tool for the job. JSX has its quirks, and React itself adds overhead (something around 30kb minified gzipped). I always think that each tool needs to earn its place at the table, and for lightly interactive sites, something like Dust.js (what we recommend and use extensively) could simply be the ticket. I would normally not bother with vanilla JS unless really critical – jQuery would work nicely in this context. We like Dust.js because it has been proven in production and used by companies such as LinkedIn, PayPal, Yahoo, Netflix. Of course, Handlebars is fine too (very similar actually).
My point is that you probably don’t need anything beyond Dust/Handlebars and jQuery. The moment you start finding yourself wanting a more formal structure – events, models, views etc., you are in the frameworks territory, at which point I recommend React for all the reasons already mentioned.
We are trying to keep our development environment as small as possible. No extra frameworks, no jQuery, etc…
A “feature” we’re looking for is actually “client-side web components”*. Although most of our websites are unique, some parts (small components, not pages) can be reused. For now, reuse equals copy/paste the HTML template, CSS and JS files.
I already used DustJS for a small hackathon project, do you know any methods of creating such small components (template file, CSS, JS) that are easily used in a bigger template? If possible with vanilla Node.
I’d love to npm install a component and use this in my website.
* isomorphic would be a very nice extra
Of course, you can always go without jQuery. As for Dust, you can compile Dust views into JS and load them on the client, pass JS data into them and render like that. Of course, you will at that point develop your own component model, which may or may not result in a ‘custom’ framework of your own :-).
As far as I know, Web Components is the only ‘native’ component model that was supposed to do what you need, but as you know their support is spotty across the browsers, and shims are as heavy (if not heavier) as frameworks you are trying to avoid. Using npm to install a component is unfortunately not possible as far as I know without something like React + WebPack to handle the workflow, which does not seem to be what you want.