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.
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.
Writing stylesheets in Sass is now a no-brainer, and we consider it a game changer in stylesheet coding.
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.
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.
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 and Webpack
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, together with tried and tested Webpack, to build our frontend assets.
Header image licenced under Creative Commons