Web Application Architecture from 10,000 Feet, Part 3 – Frontend Development

In part 2 of this series, I focused on the basics of back end development. Here, I’m going to talk about developing client-side code.

Building Blocks

The front end of a Single Page Application (SPA) is composed of three major things:

• HTML: a markup language that’s parsed by the browser to create the Document Object Model—a tree representing the structure of your page
• CSS: another markup language that applies styling to the DOM
• JavaScript: a programming language, parsed and interpreted by browsers, that can respond to users’ actions, manipulate the DOM, and make requests of your server

They generally work together as follows:

1. JavaScript uses AJAX to fetch information from the server.
2. JavaScript manipulates the DOM to display all of the information it received from the server.
3. The user interacts with the application in some way.
4. JavaScript responds to this interaction by making a request to the server, and manipulates the DOM again to fit the new application state.

JavaScript’s Dirty Secret

There’s an unfortunate truth when it comes to frontend development: HTML, CSS, and JavaScript were not designed for creating GUIs; they were designed for laying out virtual documents. Everything built since then has been a bit of a hack on top of a hack to get this web application ball rolling, and it’s turtles all the way down.

JavaScript is infamous for not being a particularly well designed language, and the DOM was meant for structuring documents, not user interfaces. Using plain JavaScript to do all the work the front end needs to do ends up with… a less than elegant code base, especially if you want your app to work in every browser (triple that if you want to support IE 8 or below). Writing an SPA using nothing but your own, hand-rolled JavaScript is a painful process with a huge amount of time being spent on the specifics of manipulating elements in the DOM instead of business/application logic.

Frameworks: a Blessing and a Crutch

Which is where the frameworks and the libraries come in. There are hundreds of JavaScript frameworks and libraries out there that serve to abstract the nitty-gritty of manipulating particular snippets of HTML away from you so that you can focus on writing the basic logic behind your application. The (current, as of the time of this writing) big contenders are AngularJS, React, and EmberJS. My colleague, Jeanette Head, gave a particularly good talk at Codemash 2014 comparing three of the major JavaScript frameworks and how they each solve problems.

If you want to make an application in a reasonable amount of time, and if you want to avoid reinventing the wheel for a bunch of solved problems (showing/hiding a particular element based on a variable’s state, for example), I’d recommend picking up a solid framework and using that as a foundation for your app.

There’s a definite downside with this for the beginning developer, though. Since a good framework abstracts the details away from you, you never learn the underlying logic that the framework is hiding from you—and, because of this, you learn how to make a web application using a particular framework, and that framework only. And unfortunately the shelf life of these frameworks is relatively short, and the list of them is absurdly long.

Learning higher-level abstractions instead of the bare metal isn’t inherently bad as a general rule—there are clear benefits, otherwise everyone would still be using Assembly—but your knowledge of a particular framework has a definite expiration date. And odds are you will run into bugs that require you knowing what your JavaScript is actually doing, on a detailed level, to fix.

Libraries as Building Blocks

There is a halfway point between adopting a monolithic framework and hand-rolling all your own code: pick out a variety libraries, each one of which handles a particular problem, and then knit them together to make an application without wasting your time fixing solved problems or getting locked in to a particular framework’s structure.

I’d recommmend beginners to take the time to make a tiny SPA (something along the lines of TodoMVC) in vanilla JavaScript. And then do the same thing with a few different frameworks/libraries to get a feel for how each tackles the problem. Then use that (and some informed reading) to make a decision for your actual application, when the time comes.

Conclusion

Hopefully you can use this general knowledge to give you a couple more keywords for Google as you learn—and some foundations so that you don’t go into any future tutorials completely blind. Happy coding!

This is the third in a series on understanding SPA architecture:

1. Client-Side vs. Server-Side
2. Persistent Data & Relational Databases
3. Frontend Development