There is always software development work to be done at Cruited, and we would like to share some details about how we do it. Not all our code uses the technologies listed below, but the recent code does.

CMS: WordPress & the Sage starter theme

The content-heavy part of the website is based on WordPress. We recently redesigned it, and created a custom WordPress theme in the process. Our custom theme is based on the Sage starter theme. It took a little while to understand Sage’s inner workings, but it was worth it in the end: the resulting code is higher quality as a result. It’s not only more maintainable, but we’re also taking advantage of the best development and build workflow currently available for WordPress projects.

Server-side application framework: Play Framework (Scala)

Java has always been a powerful server-side language, but was plagued with crappy web frameworks for what seemed like an endless winter (do you remember Struts?). Play Framework came as a very effective solution, inspired by modern frameworks such as Ruby on Rails. And this is what we are using on web pages containing a good deal of application logic.

We love Play’s high performance, simple and modern architecture, and rapid pace of evolution. Furthermore, using it with Scala makes the server-side architecture all the more powerful and modern.

Play Framework has been constantly evolving, unafraid of sometimes breaking compatibility with previous versions. A bit like when Facebook changes their layout, with people complaining for fifteen minutes, and then never looking back. Every time we start a new web project based on the latest version of Play, we have to relearn a few things, but always end up feeling that it’s more efficient than ever.

For the upcoming “app” pages of Cruited.com, we are using Play with the default modules: Anorm for DB connection, and Twirl for template engine.

Database: PostgreSQL & MySQL

We have a preference for SQL databases. SQL is a great language, both for the structure of its tables, and the power of its queries. SQL databases just scale better, both in terms of code maintenance and performance.

Whenever we create new web projects we choose PostgreSQL because it evolves fast. Native JSON support in PostgreSQL is an example.

CSS: Sass

Writing stylesheets in Sass is now a no-brainer, and we consider it a game changer in stylesheet coding.

In addition, we are also using Bourbon for its collection of very useful mixins. Compass is an alternative Sass library – the most widely used – but Bourbon is smaller and does just what we need.

JavaScript

We don’t feel like committing to JavaScript MVC frameworks (such as Backbone) for web projects which aren’t single-page web apps, as they seem a bit overkill.

For this reason we ruled out even bigger JS frameworks such as Angular or Ember. The main reason being that two-way data binding, which is the killer feature of both Angular and Ember, is something rarely useful in practice. Also, the bigger the framework, the longer the learning curve (Angular has a particularly steep learning curve), and the more it hurts when that framework gets replaced by the next big thing.

So rather than a JavaScript framework, we’ve been using a collection of libraries, and we are satisfied with that approach so far. Our frontend stack is therefore made up of components, each taking different responsibilities. And it leaves the door open for replacing any component by a better alternative if need be.

jQuery

Some smart developers do without jQuery, but that library is just too incredibly useful for DOM manipulation.

There are several jQuery features that we don’t use, though. For example, all animations are taken care of by GSAP, or in CSS.

Client-side templating: React

A client-side templating engine always ends up being useful. And Facebook’s React has gained a lot of traction, so we had to check it out. We currently use it instead of the more traditional Handlebars template engine. What makes React special is its exceptional performance when you need to update only parts of a web page’s DOM (via a technique called Shadow DOM).

We’ve been using React a fair amount now, it’s great! The only drawback I find is that each template needs to have a wrapping tag. If you use sub-templates, you’ll likely end up generating more markup than would have been needed for your component, due to those wrapping tags.

LoDash

LoDash is the most powerful JavaScript utility library in the world. Trying is adopting.

GSAP

We love GSAP because so very often, it’s more logical to code animations in JavaScript than in CSS. It provides the same level of performance as CSS3.

Bootstrap

Bootstrap is fantastic for quickly building prototypes that don’t look completely awful. Its collection of standard UI components is a very convenient vocabulary to pick from when designing UIs ‒ it’s also a good base for communication between UX designers and web developers.

Since we are writing our stylesheet in Sass, we are using Bootstrap Sass. Bootstrap 4 looks very promising and will come with Sass as a first-class citizen.

Build system: Gulp

Using the Sage starter theme introduced us to Gulp, a young alternative to the Grunt frontend build system. One need to go with the times, so we’re using Gulp now to build our frontend assets.

Header image licenced under Creative Commons