Picking a front-end framework

Before we start, a little history about our technology stack.

Some of the first Rufus demos we built internally were built using a MEAN Stack. This worked for us because our front-end developers were familiar with the technology seeing as Angular 1.X is built using augmented HTML templates. This allowed us to quickly iterate and move forward without having the technology be in the way. But as progress was made to Rufus, we quickly realized that Angular 1.X would not be our front-end framework of choice.

We wanted to move to a framework that allowed us to use a component based approach. Seeing as this would be a web application and not a standard web page, a component based architecture would allow us to save time and be able to reuse components multiple time instead of having to recode them time and time again.  We also liked the advantages of having all the logic for a component in a single place.  By it’s very nature, Rufus is a complex application, and having to hunt down functionality hidden in the different layers of a traditional MVC or multitiered application would slow us down.  As mobile also entered the conversation, we knew we also wanted to find a solution that would work for all our needs.

As we moved forward, we knew we wanted to stay within the confines of Node.js, our developers loved it. This left us with two main options, React and Angular 2. We knew we wanted to pick a more popular framework, as this tends to provide the most support, most updates, and usually the most features. We ended up picking React as our framework of choice.

Which CSS framework?

Now that we had finally decided on our front-end framework, we were left with another decision. Which CSS framework should we pick for Rufus? We wanted something that still offered all the possibilities of a modern CSS framework: mixins, variables, etc, but still be simple, and not have to use a module to a module to a module, as is sometimes common.

The first option we looked into was inline-styles. React natively supports it, and it would have been quick and easy to implement. But this implementation would also be severely limiting. It quickly would have become a nightmare to implement something simple such as a breakpoint.

The second option we started to look into was JS styles. This is when standard CSS is embedded into a Javascript file, see css-modules. But once again, this was a let down, as this would have required us to also use SASS, LESS, or something similar to get the features we wanted ( we’re still trying to avoid having an add-on to an add-on to an add-on ).

The options that we ultimately chose was writing CSS in JS using the Aphrodite framework. This allowed us to leverage the power of Javascript and not have to rely on a library for injecting CSS, and then another for the features we wanted.

So far, we’ve loved using Aphrodite. We can write CSS quickly and without much difficulty, and we sidestep the add-on to an add-on to an add-on madness. We’ve see web projects fail far too often due to completely mismanaged dependencies.

Below is an example of the password field used in Rufus. We use three different states to capture user activity. From changes to those states we use the different capabilities of Aphrodite to animate the password field.