A Complete Overview of Front-End Development in 2021

Wasm, ESLink, Webpack, Serverless. Does this ring a bell? Do you know what these technologies are used for?

There are so many concepts and frameworks used by front-end developers, it’s hard to keep track when you don’t work on it every day.

I recently spent time brushing up my front-end knowledge and skills, and I wanted to share what I learned.

In this article, I give a concise yet complete rundown of all the main technologies used for front-end development, along with resources to dive deeper where needed.

Markup and Programming Languages

HTML and CSS are the markup and style languages that all web pages are built with.

The HTML page contains the DOM, Document Object Model, which describes the structure of the elements in a web document, for instance, paragraphs of text, headings, images, etc.

JavaScript is a scripting language that allows to dynamically change the DOM and style of a page, either by querying more information from the backend as needed or by performing computations and changes based on user input directly in the web browser.

TypeScript is a superset of JavaScript. It introduces the concept of a strongly-typed system to enable more verification to be done at compilation time, before the code is shipped to production and run in the client’s browser, which has the goal of minimizing bugs and errors. When you write code in TypeScript, it is being transpiled to JavaScript during the build process of your app and it’s getting shipped to users.

To learn more:

• https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction
• https://developer.mozilla.org/en-US/docs/Learn/JavaScript/First_steps/What_is_JavaScript
• https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html

Stylesheet Languages

CSS, or Cascading Style Sheets, is a language used to describe how an HTML document is going to be presented. For example, the font size, the color of headings, the type of layouts that should be applied to elements for a web page, and so on.

CSS has the reputation for being difficult to work with at scale. There exist other languages, such as Sass and Less, both preprocessor scripting languages, that can be interpreted or compiled into (CSS).

Those languages have features that CSS does not, such as variables, mixins, functions, and loops, which allows them to express the same logic but with less code, making it easier to maintain styling assets over time.

To learn more:
https://css-tricks.com/sass-vs-less/

CSS Frameworks and Web UI Frameworks

CSS frameworks offer an easier way to deal with styling. They often support grids and responsive web design, web typography, icons, and styling for tooltips, buttons, and so on.

Popular options are Bootstrap, Materialize, and Tailwind.

To learn more:
https://careerfoundry.com/en/blog/web-development/what-is-bootstra p-a-beginners-guide/

JavaScript Frameworks

Front-end development used to have the reputation of being messy, with code management rapidly getting out of control as an application grew and more developers were contributing to it.

JavaScript frameworks were created as a way to solve this problem by offering a consistent way to organize the logic of a front-end application, which makes its complexity manageable even as it grows.

Those frameworks do it each in their own way, and often it is a matter of preference and familiarity with the developer communities who built them.

There are many frameworks, and new ones are popping up almost every week. The majority of these frameworks never make it past the stage of pet projects.

However, three frameworks stand out, as they are widely used in the industry and power large commercial websites at scale: React, Angular, and Vue.

If you are a developer and looking at jobs, learning React will grant you the highest chances of employability in 2021. Vue is the most recent of the pack and many companies are still waiting for it to mature a bit.

If you are looking at what framework to pick for a new project, go for React or Vue.

To learn more:
https://www.codeinwp.com/blog/angular-vs-vue-vs-react/

Bundlers

A Bundler is a tool that looks at your entire application, which at scale can be composed of sub-projects and rely on many third-party dependencies, and it will bundle everything into a minimal set of files that can be deployed to production, often a single .js file to optimize performance for the client.

Another example is that you could have a serverless architecture with multiple services in a single repository. A bundler would allow you to bundle each service on its own and deploy them individually.

Bundlers also allow for setting up different environments, so you can have config files changing based on whether you’re testing locally or whether the application is in staging/pre-production, or production.

A couple of common options out there are Webpack and Parcel.js. Other notable options are Rollup, esbuild, and Lasso.

To learn more:
https://webpack.js.org/concepts/

Package Managers

A package manager is a tool that allows you to track the dependencies of your project to other packages  that will include the names and versions. Often, this is stored in a text file, which is handy to store next to the application code in the repository.

The advantage is that the dependencies for your application are getting shipped together with the code, and therefore you can rebuild your project in any environment if needed, without fighting which version of which libraries you have to install.

Popular options are npm and yarn.

Client-Side Storage

Web applications need to store data locally on the web browser of users for various reasons: customize UI feel and look, persist activity between sessions, save state for offline use, etc.

The old fashion way of doing so was via cookies. Nowadays, modem web browsers offer the Web Storage API, a key-value store for small data, along with the IndexedDB API, a database system to store complex data.

There is another form of client-side storage, the Cache API, meant to save HTTP responses.

Finally, there is also the concept of Service Worker API, which is a non-blocking thread that runs outside of the main JavaScript thread and is meant to act as a proxy between web applications and the network, enabling to cache resources at a very granular level.

To learn more:

• https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Client-side_web_APIs/Client-side_storage
• https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

Single-Page Applications (SPA)

A single-page application (SPA) is a web app that loads all the necessary HTML, CSS, and JavaScript in the initial page load, and then dynamically updates the DOM based on user interactions, giving the user the illusion that he is accessing different pages or paths.

SPAs differ from the traditional approach of requesting new web documents from the backend servers based on user actions, sometimes called Server-Side Rendering (SSR), or also Multi-Page Applications (MPA).

The intended benefit of SPAs over SSR is that only the needed assets, data, and images, are loaded, and the page is updated accordingly, which saves bandwidth and loading time, and also because there is no page reload, the user interface and interactivity of SPA is a smoother experience compared to SSR.

One major drawback of SPAs is search engine optimization (SEO). Indeed, as the pages of a SPA are not separate web assets like for a traditional website, web crawlers and search engines risk not finding all those subpaths, potentially making entire SPA-based websites non-findable on major search engines, except for the index page.

Note that Google implements client-rendered scraping and executes the JavaScript code, and therefore is not subject to this problem. However, executing the JavaScript code of SPAs takes time, which means SPAs might be penalized in rankings due to performance.

SSR + SPA Hybrid Frameworks

The best of both worlds is if you use an SSR approach to pre-render pages so they can be served quickly to users and web crawlers while keeping those pages interactive once loaded via a SPA approach.

Some companies have implemented this by combining a backend SSR framework a with front-end SPA framework, for example doing the server-side rendering with Node.js and loading HTML pages in a CDN, and then have those HTML pages use React to keep SPA interactivity.

There are now frameworks that implement a hybrid SSR + SPA approach, all-in-one. The two most notable are Next.js and Nuxt.js. Their names are similar which makes it confusing. Basically, Next.js is based on React.js, and Nuxt.js is based on Vue.js.

SSR + SPA hybrid frameworks are ideal when both SEO optimization and post-loading interactivity are absolute requirements and cannot be compromised. Nevertheless, they come with more boilerplate compared to simple SPAs.

Another advantage of Next.js and Nuxt.js over other hybrid frameworks is that they allow you to build on top of the very rich ecosystems of extensions and tooling from both React.js and Vue.js, which can save a ton of time and effort during development.

Progressive Web Applications (PWA)

A progressive web application (PWA) is a website that can be installed on a phone. It builds on top of the concepts of single-page applications (SPA). Another important characteristic is that it is delivered via the web, not via the app stores like native apps are.

The typical use case is that you would be browsing a website with your phone, and you can install that app on your phone, which is going to be the same web app, but without the address bar, and also you would be getting a shortcut to that web app on your home screen.

There are three conditions for a web app to be considered installable on Android and iOS:

1. being served over HTTPS,
2. having a Web App Manifest, and
3. registering a service worker.

To learn more:
https://web.dev/progressive-web-apps/

Micro Frontend

Micro Frontend is an approach to organize the structure of large frontend applications so they can be developed and released smoothly even when a large number of developers work on them simultaneously.

Within this model, different parts of a frontend website are split into separate applications that are developed and rolled out independently by the teams who own them, so that they do not block one another due to inter-dependencies or working on the same areas of the code.

Those different parts communicate via events directly in the web browser of the users, and they are combined into one by a single container application so that the end-users have the impression of a seamless application.

This resembles the approach of microservices that can be found nowadays in the architecture of some backends.

To learn more:
https://martinfowler.com/articles/micro-frontends.html

Serverless 

Serverless computing is an architectural approach in which applications rely on servers allocated on-demand in third-party cloud providers. The cloud provider services are sometimes referred to as Backend as a Service (BaaS) or Function as a Service (FaaS).

So it’s not exactly that there are no servers: those servers are externalized to third-party providers, who will take care of all the infrastructure management and provide computing power in exchange for a fee.

Computation nodes are used on-demand by the front-end application and are released once the computation is done. One of the benefits is that servers are used only as much as user activities require it, which compared to the traditional model of owning backend servers which may stay idle, saves costs.

To learn more:
https://martinfowler.com/articles/serverless.html

Hosting / Serving

Once the files and assets are loaded by the browser, the rest of the computations will happen in the web browser. The assets are static and can be served by any web server directly from the file system.

You sometimes see people serving their static assets from the combo Node.js + Express because it’s the technologies that they know. Although this inefficient and not recommended.

Instead, you should use nginx or Apache if you want to self-host, and if you’d rather use cloud services, then you can serve those assets with a AWS S3 bucket, Github Pages, or any other provider.

Headless CMS

A headless CMS (headless content management system) is a way to architect CMS systems. A typical example of a CMS is WordPress: pages are rendered in Php on the server using server-side rendering, and then the HTML and other assets are sent to the web browser of the user to be interpreted and displayed.

With a headless CMS, the front-end and backend are decoupled, and the backend is no longer sending a fully ready group of assets to the web browser. Instead, the backend is now a separate application only sending raw data via a JSON or GraphQL API, and the front-end is also a separate application that handles the interface and looks of the website and loads its data via an API.

To learn more:
https://bejamas.io/blog/headless-cms/

Code Architectures

There are several ways to organize front-end code, which is often tightly coupled with the JavaScript framework chosen for a project.

The traditional way of architecting a web application is to follow the MVC approach (Model-View-Controller). Architecting here means which part of the service code or business logic code goes into which class or file. It’s a way to organize code for maintainability.

Derivative options are MVP (Model-View-Presenter) and MVVM (Model-View-View-Model), and they all have the same problem that there is no single source of truth at any given point.

A more modern way of organizing code and keeping track of the state of an application is to use a unidirectional data flow architecture. The most common tools for this approach are Redux, Flux, and MobX.

To learn more:

• https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
• https://www.smashingmagazine.com/2018/07/redux-designers-guide/

WebAssembly (WASM)

WebAssembly is a compact binary format for web browsers. You can compile code written in C/C++, Rust, and so on, and it will run in web browsers with almost the same performance as if it had been compiled as a native desktop or server application.

This is a huge leap forward because it means that performance-intensive applications can now be developed with established languages and ecosystems like C++ and run directly in the web browser.

To achieve that, you can use Emscripten, an LLVM-based compiler, to compile C, C++, or Rust source code into the WebAssembly, so it can be executed in a web browser.

Do you want to learn more?

I hope you learned something reading this. There will be more articles coming on various technology areas such as databases, architecture, mobile development, and so on, so if you’re interested, drop your email in my mailing list below.

There are other front-end technologies and concepts that didn’t make it in this article, but that are important too. They will be the topic of a future article, I’ll just drop them in a list below, so in case you feel adventurous, you can look them up and start learning:

Performance

• Google Lighthouse and Puppeteer
• Web vitals metrics

Other tools

• Babel
• ESLint
• Jquery and AJAX
• CommonJS vs RequireJS vs ESNext
• V8 engine
• Visual Studio Code

Terms and Concepts

• Callbacks / Promises / Reactive programming
• JavaScript fatigue
• Polyfills
• JAMstack
• Minifying
• EcmaScript
• CSS-in-JS
• React Hooks
• JSON vs GraphQL

JavaScript Libraries and Frameworks

• TensorFlow
• D3.js
• Leaflet.js
• Chart.js
• RxJS
• Three.js
• UglifyJS
• Svelte

Languages

• Dart
• Elm
• CoffeeScript