Saturday, 19 March, 2016 UTC


Summary

So you’ve got the React basics down, and you’ve decided to put together an app. Given that React runs on both the server side and the client side, it seems that making a Universal (or Isomorphic) app is a no-brainer. Or it did until you’d spend hours trying to figure out how to set up Node.JS and Express, and make it distinguish between requests for JSON and HTML. And that’s if you’re lucky enough to not already have a server written in Rails or Java – at which point you’re probably considering rewriting your entire backend. But wasn’t Universal supposed to be a no-brainer?
While rendering server-side certainly has its benefits, they are by no means… universal. So the question is: should your app be Universal?
And the answer is: probably not. Universal apps introduce a huge amount of complexity. They require you to spend more of your time on maintenance, and less on features. And this isn’t to mention the limitation of requiring your app to be served by Node.js.
Of course, there are cases where this complexity may be justified. In particular:
  1. If your app’s content needs to be indexed by Google, it is valuable to be able to control the HTML which Google sees. Rendering server-side allows you to do this.
  2. If you’re at the point where every millisecond of page load causes a measurable decrease in revenue, server-side rendering can make things appear on your user’s screens faster.
  3. If you have important users whose device is too under-powered to support JavaScript, Universal may be your only option.
In short, Universal apps make sense when they solve a real problem. They’re not the goal in and of themselves.
Common objection #1: But Facebook is Universal
Yes, and you’re (probably) not Facebook. What makes sense for them doesn’t necessarily make sense for you. Do you have millions of users and thousands of engineers?
Common objection #2: But my React starter kit is already Universal
Great, so you can save a few hours while setting things up. But you’ll also lose a few hours figuring out what all the extra code actually does. And that’s before you lose weeks on maintaining a completely superfluous Node.js app.
Common objection #3: But Universal apps are better
Sure, I’ll let you have this one. Universal apps load faster, support more devices, and provide a better user experience. But this all comes with an opportunity cost.
What other features could you have added with the time you spent on your universal app? What other performance tweaks could you have made? How much earlier could you have actually shipped?
I know it is a little cliche, but the best apps are the ones which actually exist. So if you’re thinking of creating a Universal app, do yourself a favour and make sure you actually have a bloody good reason. Otherwise, treat yourself to a beer or something. Given all the time you’re saving yourself, you deserve it.
And once you’ve done that, join my mailing list to make sure you hear about other beer-worthy time saving tips. You’ll also receive three bonus print-optimised PDF cheatsheets – on React (see preview), ES6 and JavaScript promises. Hell, that is worth a beer in itself!

I will send you useful articles, cheatsheets and code.

I won't send you useless inbox filler. No spam, ever.
Thanks! Please check your email for the link to your cheatsheets.
There was an error submitting your subscription. Please try again.
First Name
Email Address
I'd like to receive the free email course. Subscribe for free Unsubscribe at any time.
Have something to say? I love hearing your questions and offers! Leave a comment or send me an e-mail at [email protected]. I’m looking forward to hearing from you!
Other things you don’t have to do:
  • Why You Shouldn’t Style React Components With JavaScript
  • Why You Don’t Have To Use Push State
  • Learn Raw React – without JSX, Flux, ES6, Webpack
Related Projects
  • Start a non-Universal React project with Unicorn Standard Starter Kit
The post Universal React: You’re doing it wrong appeared first on James K Nelson.