This repository contains all the front end code for the current ustwo.com website and the toolset required to build and deploy it.
Our content management system behind this is a Wordpress instance which doesn't actually render the pages itself, but instead serves content up via WP API through a mixture of standard and customised JSON REST API endpoints, making the vast majority of the content editable.
With the current set of challenges and available browser features we found React.js to be a great solution to templating and events on the UI. The composability of components with the one way binding and "queryless" event handling offered by JSX templates is solving the right problems, without trying to do too much and become a framework. The easy to implement server side rendering combined with the ability to prevent rerendering on client side (by internally doing a comparison to the virtual DOM) is also a great feature to make it a viable solution on mobile.
To make it a single-page application we put Flux Routes and Store behind the React front end, so that it can take over the navigation from the browser and load data from Wordpress by itself.
As for the CSS, we're using Sass to be able to split our styles and store them together with the components. But in general we're trying to minimise the reliance on Sass language specific features and instead write as much pure CSS as possible, getting ready for a CSS Next / PostCSS world just as we did with ES6.
For the animated illustrations on the site we use SVG sequences, controlled by a small React component. This is unfortunately only possible with inlining SVGs, but all the static vector symbols are stored in one, external SVG sprite, polyfilled for old Internet Explorers with SVG for Everybody.
Since all the heavy content work is done for is in Wordpress, our Node / Express app is kept as light as possible. The only two main responsibilities are delivering fully baked HTML files through running React rendering on the prefetched content and responding to the same routes as the front end app does.
As we had quite a lot of components (or microservices if you will) to tie together – multiplied by production + staging + dev environments – we didn't want to overburden our Node server and decided to put an Nginx proxy in place.
While we started out using Gulp for our frontend builds which was a very convenient start point for quickly iterating different combination of tools, in the end we settled on shell scripts using the fastest command line builds of libraries.
To get the Docker environment up and running and to tie all of the above together, we created a fleet of Makefiles to get some extra flexibility with shared variables and task composition on top of shell scripting.
We have everything served up from a CDN, and by that we mean that ustwo.com is pointed at the CDN URL on a DNS level! Needless to say this guarantees great load speeds across the globe and at very little cost. Call it the "CDN first" approach if you will – check out our blog post about this here.
Unless you have a lot of user dependent dynamic content (and it's not feasible moving these areas to subdomains) the trick is to remove caching from all layers of the stack, while keeping the client side cache / expiry short (we're using only 1 hour or effectively one session).
This way the only place you need to worry about and manage cache is the CDN. Of course for this you need to have a decent CDN which has an API to purge and prefetch content. At this point all the servers and applications behind can be scaled down to no cache and minimum resources as they'll only be accessed by the CDN network for an occasional update.
So here's how all this fits together and creates a working setup with our WordPress backend and CDN.
We're aiming to support all evergreen browsers (Chrome, Firefox, Edge and Opera on all platforms), Safari on Mac and iOS, Internet Explorer 10-11 and Android Browser 4.2-4.4.4.
In case you were wondering, we've chosen these as we wanted to be able to use Flexbox, and they also happened to conveniently overlap our historical visitor profiles from Google Analytics.
If you see any misbehaviour with one of these browsers please open an issue!
Being a studio which is passionate about delivering a great user experience everywhere and early champions of mobile, we kept performance in the front of our minds throughout the process of building the websites.
This means that we are continuously reviewing both hard metrics and perceptual performance. To get reports and keep an eye on things, we found GTmetrix to be a great tool with a generous free tier. It calculates both PageSpeed and YSlow scores, generates a network waterfall, renders a filmstrip view and sends an automated report of all these regularly.
There are too many things to list here, but we mentioned a lot of optimisations throughout this README and might cover some of them specifically in blog posts later.
Officially supporting only modern browsers doesn't mean that we ignore people (and browsers) with special needs.
The project is managed via Docker containers. Right now we're using Docker version 1.9.0 with Docker Machine version 0.5.0.
Commands below assume OS X and preference to install libraries via Homebrew. You can of course install Docker Machine and Virtualbox in any other way you want (like Docker Toolbox / Kitematic).
Install Docker Machine
$ brew install docker-machine
Install Docker Engine
$ brew install docker
Note: Beware, the version might matter. Our latest known working version is 5.0.4.
Create Docker host VM
$ docker-machine create --driver virtualbox dev
Set up Docker environment to VM – needs to be done for every new shell session
$ eval "$(docker-machine env dev)"
192.168.99.100 local.ustwo.com 192.168.99.100 staging.ustwo.com
Note: The IP number above depends on your local instance. Check
docker-machine ip dev.
Note 2: You need the environment to be set to dev to use Make commands!
The easiest way is to load the vault image from a tar. If you receive the image tar from someone in the team just do:
$ make vault-load VAULT_PATH=path/to/vault-2015.tar
If you do not have access to this tar then you can proceed by generating your own self-signed certificates.
$ make vault-generate-cert $ make vault-build
Note: If you use self-signed certificates you probably want to use your
docker IP (e.g.
docker-machine ip dev) instead of a custom
Note: Check the MAKE.md for an explanation of how the Make tasks are structured.
Prepare a new environment:
$ make compiler-build build
Compile the assets (you can use only this when you're only recompiling on front end stuff):
$ make stuff
Or target specific subtasks:
$ make css # compiles SASS files $ make spa # compiles the React app $ make vendors # compiles app dependencies
spa combined with
VERBOSE=true will create sourcemaps.
vendors combined with
FLUSH_CACHE=true will skip any
cache created by browserify. Ex:
$ make spa VERBOSE=true FLUSH_CACHE=true
Deploy app (when you need to restart services):
$ make -i love LOCAL_FS=true VERBOSE=true
Note: Add the flag
LOCAL_FS=true if you want to use your local files instead
of the ones inside the containers.
Note: Add the flag
VERBOSE=true if you want the JS and CSS expanded and more
log output on the services.
As long as
LOCAL_FS=true is set a convenient way to refresh the environment
$ make -i love stuff LOCAL_FS=true
As it will rebuild the assets (
stuff) and recreate the containers (
remounting all necessary files from the host environment.
Clean the environment:
$ make clean
See Node app logs with:
$ make app-log
And Nginx logs with:
$ make proxy-log
CSS has extra tasks to speed up the development cycle.
css-watch starts a
fswatch process in the host machine watching any scss or css file under
$ make css-watch
brew install fswatch to install
fswatch in your machine.
sync starts a dockerised
browser-sync proxy listening by default to port
3000. So you can combine the two:
$ make -i sync css-watch
https://192.168.99.100:3000 in your browser and start editing scss and
let the toolchain compile and push changes to the browser.
browser-sync uses a self-signed certificate so using
or the raw IP will make the browser complain. If you need to overcome this
please add a forward rule to Virtualbox so you can use
Run all tests:
$ make test
We believe that every component should hold a single responsibity, and which functionality must be working independently from the context the component is instantiated in.
To enforce best practices – like storing functionality and styles in the component they belong to – we created a sandbox to test components in an isolated environment.
To prepare the sandbox run:
$ make sandbox-build
And start the sandbox server with:
$ make -i sandbox LOCAL_FS=true
The sandbox will be available at https://local.ustwo.com:9443/sandbox
We're using Mocha + Chai + Sinon to run unit tests against JSDOM as this setup works well with React and executes fast.
Run the unit tests:
$ make assets-unit-test
To keep setup simple and still be able to test Internet Explorer and mobile
browsers running on real devices, we're running integrations tests using Sauce
Labs with a Sauce Connect tunnel. This unfortunately means that if you want to
be able to run these tests, you'll need to create an account and set up
SAUCE_ACCESS_KEY as environment variables.
Also to minimise context switching, we're running our simple sanity testing suite using Mocha + Chai + Chai Promises + WD.js.
Run the integration tests:
$ make assets-integration-test
If you need more info on what's happening with the tests, you can either log in to the Sauce web UI to see the Selenium logs to understand more details about the browser interactions or run verbose mode locally for more info on the API requests and their results:
$ make assets-integration-test VERBOSE=true
TODO: add flow diagram about git branches -> CI, etc
We're using Docker Hub and Docker Machine to tag and deploy Docker images, for more info see RELEASE.md.
To read up on our coding style and general contribution guide, have a look at CONTRIBUTING.md.
ustwo.com website front end and tools Copyright (C) 2015 ustwo
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.