How can we help?

Design? Check. Strategy? Check. Bulletproof code? Check! People who can manage it in an agile and efficient manner? Check. Someone to help you create your next big product? Of course.


- 1201 18th St. Suite 250, Denver, CO 80202

Grand Rapids

- 125 Ottawa Ave NW Suite 270, Grand Rapids, MI 49503


BLOG:React.js: A Designer’s Perspective

React.js: A Designer’s Perspective

As a designer, I feel that my designs do not live in a Photoshop comp or Sketch file — they come alive when they become code. With the rapid emergence of so many new JavaScript frameworks over the past few years, it can be difficult to review them all to discover which ones are best suited to translating mockups into interactive prototypes. That kind of work poses unique challenges, favoring frameworks that are flexible enough to support rapid iteration, but offer enough guidance to keep things from spiraling of control. In this article, we will discuss one framework I think is up the challenge: React.js.

When React first hit the scene, I was less than impressed and was using Angular for everything. React had some unfamiliar approaches so it didn’t demo as well as Angular, and I was skeptical of using JSX to put your HTML in your JavaScript, or creating JavaScript style objects to describe your CSS.

Although many people shared my initial reservations, React has gained traction quickly, likely because of the following key features:

  1. React.js is a library, rather than a framework, so it plays well with others., You can pair it with other frameworks such as Angular or Backbone (as my colleague Kevin Kazmierczak has previously mentioned).
  2. It’s fast by default, allowing you to describe what the view should render without needing to worry about how to update the DOM to get there. It does this without requiring magical 2-way bindings. This is accomplished by only updating the parts of the view that change, instead of re-rendering the entire content, or using dirty-checking as is seen in some frameworks.
  3. It promotes component-oriented development. This leads to better isolation of code and styles, and simplifies code reuse.

Since I am a designer first and developer second, I have a different set of criteria when evaluating a framework. When I’m building prototypes, I need tools that allow me to quickly emulate basic interactions and manipulate non-persistent data. I also need the code to be flexible enough that I can adjust styles and labels without worrying about breaking the entire system’s layout.

Having become more familiar with React, I’ve realized it has been able to solve the following problems I’ve run into with other frameworks in the past:

  1. When you don’t use components, everything can get complicated, very quickly.
  2. When you have a large code base, CSS will get away from you.
  3. Performance slows down for reasons ranging from to much data being bound in a view, to using the wrong tool for the wrong job.

Often, if a designer or developer can’t find the piece of code they want to work on in CSS and Javascript, or it doesn’t fit their needs, they will quickly get frustrated and end up either copying and pasting code or just re-writing a new component that does nearly the same thing. Either one will ultimately lead to vicious code-bloat, which no one wants.

To encourage designers and developers to avoid creating this code-bloat, many solutions exist and are used (like Angular Directives and SMACSS), but they require a good bit of discipline to implement.

React discourages code-bloat by encouraging designers and developers to think in terms of isolated components where all the JavaScript, CSS and HTML (via JSX) is bundled into a single source file. JSX makes it easy to import and compose these components, so that building more complex components or views is just like stacking legos.


It turns out, JSX isn’t so bad after all. Most JavaScript frameworks try to put some of your JavaScript in your HTML; React just flips this by putting your HTML in your JavaScript. And the browser is just one place to render your application. React’s engine is not limited to controlling the browser DOM. With the introduction of React Native, we are getting closer to one codebase, delivering a Native Android, iOS and Web experience.

Universal Mind sponsored this month’s meeting of Denver Code Club, where we discussed React.js. While I wasn’t a huge fan of React before, after the discoveries I’ve made since my first encounter with it, and learning how it has been helpful to other designers and developers who participated in the conversation at Denver Club Code, I am now a believer. React should not be the only tool in your toolbox, but I feel it is a great addition to a Javascript project, especially where large teams are working in one code base.


At Universal Mind, we endeavor to choose the best tools for each project, and we’re very excited about React’s potential for interactive prototypes and production applications. We even have people contributing to the React community. I look forward to watching React’s popularity grow, other alternatives emerge (as they always do) and seeing how other designers feel about its more controversial aspects (i.e. JSX and inline CSS) and its applicability to their own prototyping work.