Architect Front End Applications - Planning

Front end applications are invariably complex nowadays. With the onslaught of new JavaScript frameworks and libraries being released everyday, it’s quite overwhelming just to stay on the bleeding edge.

However, there are concepts that are always the same between all applications. Every application is going to have to grapple with the holy trinity of CSS, HTML, and JavaScript. Now balance that with ecosystem you’re working in and the constraints involved. Factor in the team you’re working with and their skill sets.

Modern day applications also have a supporting structure that involves using automatic testing, version control, code linting, and continuous integration. Let’s start small and build our way up.

Planning out your application #

A simple front end application is a barebones application. It’ll involve a static HTML page with CSS and javascript, either inlined or linked to. It does not involve using a templating system or a build system. If it is not dependent on anything other than a web server to serve the HTML and assets, try using a static html generator.

A complex application involves several items:

• A templating language or language that renders and eventually serves HTML
• Some sort of state management
• Browsers an application should support
• A way of compiling or loading modules
• Any type of preprocessing
• Uses a build process

You should also consider any newer CSS or JavaScript technologies you’ll be using, and whether they have support for your targeted browser versions. If they don’t, you’ll need to polyfill it.

Rendering Views #

Nowadays it’s common for a templating language to be used rather than abstracting out the language yourself. A good example of this would be handlebars in the JavaScript world.

React and Vue.js abstract HTML templating with modularizing code into components, and they have options for allowing HTML to be output on the server. This means we can usually reuse code between the server and browser JavaScript. However, for now we’ll just concentrate on the front-end.

State Management #

State refers to anything that needs to be stored and then referenced later. The old way of doing this was with data- attributes in HTML, or referencing current state within the window object.

Nowadays, we have some better solutions that don’t rely on mutating the window or entangling JavaScript state with HTML. Some of these include redux and MobX. This are often designed for complex applications.

Browser Support #

You need to know what browsers your application should run on. Browserslist can be used to allow your build process to build against certain browser versions.

Tying Code Together #

Often code in one file needs to reuse code in another. We can do this through a module loader. There are several ways of doing this:

• AMD (Asynchronous Module Definition
• CommonJS (Node.js flavor)
• ES6 Module Imports

I recommend the new ES6 module import syntax, since it’s now native to JavaScript. It’s still not supported everywhere, so there will need to be compiled down to usable code.

Preprocessing #

Preprocessing in this case refers to optimizing images and compiling a stylesheet language into pure CSS. Usually, this will be done in the build process, but basically, we want a way to minimize the footprint of our assets, so that they’re smaller and load faster in a user’s browser.

Build Process #

We need a build process so that all our assets are preprocessed, our CSS minimized, our JavaScript compiled down to working state for it’s supported browser, etc.

The build process should hopefully handle this all in one place, so that on the other end, you have a folder of optimized assets ready to go.

Some recommended builders are webpack, browserify, gulp. I personally recommend webpack if you want extensive control over your build process, however, it does have a steep learning curve.

You’ll also more than likely need to combine those builders with babel in order compile down modern JavaScript syntax, so it’s usable browser version.

Conclusion #

These are some of the most important considerations to keep in mind when first planning out your application. Ultimately, we want an application that is fast to develop on and keeps us productive. If we’re building for a team, we want something that will be familiar to members, or easy to pick up.

Planning is the most important phase for architecting a front end application. There is often a lot of nuance that is unforeseen, so expect roadblocks to happen.

Photo by Sergey Zolkin