Making Web Apps

What it is

Frontend web development is a very broad field with many specialized skills. To make breaking it all down a bit simpler, lets divide it into two pieces: on one hand, you must learn how to make websites, which involves learning HTML & CSS, computer networking and more. Once you can make websites, you are prepared to lean about building web apps, software which is built out of the same technologies that power websites.

Making websites is specific to web development, while building web apps is closely related to UI programming for other platforms. It involves using javascript to hook up UI elements like buttons to manipulate your data and send it back and forth from the server. Essentially, making websites deals with what the website is, while making web apps deals with what the web app does.

Why it matters

If you look at listings for frontend developer jobs, you’ll see they usually include a list of skills required for the job. These always cover the basics such as HTML, CSS and Javascript, but from there can include an alphabet soup of javascript libraries and frameworks like Angular, React, Vue, or any of the dozens of other alternatives. What do you actually need to learn?

They do this because there’s not enough space to specifically list everything you’d need to know for the job. What employers actually want, obviously, is someone who deeply understands how to build frontend apps. That means understanding how frontend apps work regardless of framework or paradigm, and understanding how these different tools can be used to put them together.

Picking up a new popular framework becomes much easier once you have an understanding of frontend development as a whole, and it is possible to get hired without knowing the specific things an interviewer asks for if you can demonstrate your broader competence.

How to learn it

Getting that competence can be extremely intimidating when there are so many different things to learn. Once you have a handle on the basics and start building real UI’s, you’ll quickly discover that there is an endless dark forest of javascript libraries and tools that you could potentially use on your projects, and getting a grip on all of it can be quite difficult.

To digest it all, it is useful to rewind and think about what a frontend app does. All of these tools serve three basic ends:

  1. drawing stuff on the screen
  2. Loading in data and managing it
  3. hooking the two together

Any type of UI, from a mobile app to a smart TV’s menus, must solve these, and you’ll see the same patterns and solutions across software ecosystems. The web is the largest software ecosystem out there, which is why you see such a huge number of open source libraries and tools. This bounty of tools is making building powerful UI’s easier than ever. Unfortunately, it also means learning the whole ecosystem is more complicated than ever.

New libraries are constantly coming out to solve these same basic problems, and even though each one improves on the mistakes of its predecessors, it can become exhausting for a developer to seemingly relearn how to do the same things year after year, leading to what’s collectively being called javascript fatigue.

Drawing the UI

First of all, a GUI program needs to be able to draw something on the screen. Unlike a blog website whose fixed HTML can be predefined, a web app’s UI depends on its data and thus needs a way to dynamically create the UI elements programmatically.

For most UI’s, such if you were programming a video game, this starts with an API with basic commands like drawing a square. Web apps are built with HTML, so the basic commands in our case modify elements in the HTML document.

The structure of the HTML document is represented in Javascript as the DOM, or Document Object Model. The DOM API is the hook that every javascript-based web framework uses to draw things on the screen. For instance, if you wanted, you could call the DOM API in javascript to change the site’s background color every 5 seconds.

The DOM API is cumbersome to work with, so the first external javascript library that most developers learn to use is JQuery, which essentially just wraps the DOM api in something a little more convenient to use.

Any UI can be thought of a series of nested boxes, like a Russian doll. The sidebar you are reading is nested inside this page, which is nested inside your browser window, which is nested within your OS’s GUI. You can break up these nested boxes into individual functional components. For instance, on Hacker News, you can imagine that there is a “story” component with various nested components like the title, rank, author, link to the comments, etc.

This can be a bit inconvenient to build with just the DOM API, because it forces you to work with individual nodes. For each story you add, you’ll need to create a container element, append the title header, append the other links etc, and then append the entire nested structure to the document in the right place.

Doing this in javascript is verbose and annoying, so some of the most useful and simple libraries after JQuery are templating engines like Handlebars or Mustache. These allow you to define whole snippets of HTML for each component and use javascript to build your UI out of these instead of individual elements.

Taking the idea a step further, an individual component on a page is not just a snippet of HTML, but also the associated CSS and Javascript used to provide the behavior for that element. This is the core idea of modern component-based javascript frameworks like React and Vue.js.

Indeed, the DOM API itself is evolving to support these types of encapsulated web components, following’s these popular libraries’ lead. Web technology is constantly evolving as we learn more about how to build UIs. Game developers, frustrated with the constraints of HTML, wanted better primitives for drawing graphics, which led to the gradual adoption of graphics tools like SVG, Canvas and WebGL. Soon enough, we’ll hopefully have popular full-fledged 3d games in the browser. A good frontend developer needs to be aware of all of the emerging web technologies.

Widgets

With a grasp of how to build UI’s out of components in Javascript, you’ll uncover tons of libraries that provide handy widgets that you can drop into your apps. Big CSS frameworks like Bootstrap and Foundation often provide accompanying javascript libraries for widgets like modals and dropdowns. Other component libraries, like JQuery UI, stand alone. Some are bound to a particular JS framework, like React’s Material UI. There are also many tiny one-off libraries that provide specific widgets, like Progress.js.

The list goes on, but google can help you find libraries to assist with other widgets for charts, embedded maps, etc. The Atlas visualization was built with SVG using a charting library called D3.js.

Managing Data

When a web app loads, it needs two things: code and data. The code (the HTML, CSS and Javascript) is downloaded from the server when you open the site. As the code executes, the javascript figures out what data it needs to populate the screen and makes additional requests to the server.

The common way to pull data in from the server is through additional HTTP requests known as AJAX calls. Website backends will usually expose the data as a REST API, which means it follows a particular set of conventions for which URLS and types of HTTP requests correspond to what actions. To make an AJAX call, you use the browser’s javascript API to make an XMLHttpRequest.

Like the DOM API, this was considered unwieldy, leading to many javascript libraries like axios and Jquery’s $.ajax to make it easier to work with. Big frontend web frameworks like Angular have their own Ajax libraries built in. These libraries’ popularity spawned a new browser api called fetch which has become the new standard.

Creating REST APIs, or modern alternatives like GraphQL, is generally under the purview of a backend developer, but understanding how they work and how to use them is necessary for a frontend app. A good beginner project is to hook into a big public api like twitter's or facebook’s and make a UI with their data.

Both network calls and human interactions happen asynchronously, which fundamentally shapes how UI programming is done. Your code can’t just run sequentially from beginning to end, but must be able to pause and respond to events. Javascript as a language has been fundamentally influenced by it’s association with web UIs, leading to new language features for managing asynchronous actions like promises and async functions.

Just as with everything in the space, Javascript itself gradually evolves and improves. Modern browsers are gradually adopting new versions of javascript (also known as ECMAscript), and these modern features are gaining widespread adoption. Unfortunately, this also means that if you want to use the latest features, you’ll need to introduce tooling like babel in your projects build process to convert to an older version of javascript.

Once you are maintaining data in your frontend application, it is stateful, or rather, it remembers previous actions. HTTP, however, is stateless: each request has no memory of previous requests. Therefore, if you want to remember data across multiple sessions, such as staying logged in after you refresh the page, you need some for of persistence. Client-side persistence technologies include HTTP cookies, local storage, webSQL and indexedDB.

Notice how by and large, the hard part about learning frontend dev isn’t really figuring out HTML, CSS and Javascript, but learning all of these little bits and pieces that make it all work.

Tying it all together

So, with the ability to render components in the UI, and the ability to pull data in from the sever, the last step is to hook the two together. As it turns out, being stateful and asynchronous make UI programming fundamentally difficult.

Imagine you have a simple todo list app: you load in a list of todo's from the API and you need to render the list component in the HTML. It needs to be able map the data from the list saved in the javascript memory with what is on the screen so that changes to the data can update the screen and user actions on the screen can update the javascript. This is known as two-way data mapping.

Since it is all asynchronous, your javascript becomes in a tangled, unmaintainable mess of nested callback functions. Most popular javascript frameworks like angular, backbone, and many more implement the MVC design pattern in an attempt to organize the code and make it easier to use.

Newer tools, like React’s Redux, take novel approaches to achieve maintainable data mapping.

Whew!

If all of this feels overwhelming to you, that is because it is. Truly, nobody knows everything there is to know about frontend tech. There are many more things not covered in this list, but once you have learned a means of solving each of the three problems, you’ll know enough to make your own apps. Then, you can learn as you go.

It is best to start simple: If you are trying to learn React before you’ve ever made anything using the regular DOM API, you are in for a bad time. Don’t give up!

For some advice on how to break this down and learn it all in order, check out the guide How to learn frontend web development.