front-of-the-front-end / back-of-the-front-end

Photo by Alex on Unsplash

Late 2019 Brad Frost already pondered about The Great Divide and introduced the terms “front of the frontend” and “back of the frontend”. In a new post he gives the easily-shareable overview that lists the differences between both.

A succinct way I’ve framed the split is that a front-of-the-front-end developer determines the look and feel of a button, while a back-of-the-front-end developer determines what happens when that button is clicked.

  • A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.
  • A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.

Imo this separation also is present in backend development, where you have the “front-of-the-backend” people and “back-of-the-backend” people. Hear me out:

  • A Front-of-the-backend person writes PHP/JS/etc. scripts which perform the required actions such as inserting records into a database, sending off an e-mail, etc.
  • A Back-of-the-backend person provisions and maintains the infrastructure.

You might already know these two parties as “backend devs” and “ops”, so nothing new there. Thanks to things like Docker and CI/CD the line between both has become more and more vague, with overlaps in responsibilities between both.

front-of-the-front-end and back-of-the-front-end web development →

The 2020 Web Almanac

From the folks over at the HTTP Archive

The Web Almanac is a comprehensive report on the state of the web, backed by real data and trusted web experts. It is comprised of 22 chapters spanning aspects of page content, user experience, publishing, and distribution.

Be sure to reserve some time for this, as this is a huge resource! A PDF version is also available.

The 2020 Web Almanac →
The 2020 Web Almanac PDF (23MB) →

Web Vitals – Essential metrics for a healthy site

Web Vitals is a new great set of articles on (by Google) focussing on delivering a great user experience on the web. To help developers focus on what matters most, they’ve selected a set of metrics which they call “Core Web Vitals”.

The metrics that make up Core Web Vitals will evolve over time. The current set for 2020 focuses on three aspects of the user experience — loading, interactivity, and visual stability — and includes the following metrics (and their respective thresholds):

  • Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
  • First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of less than 100 milliseconds.
  • Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of less than 0.1.

The easiest way to quickly see these metrics is to use the Web Vitals Chrome Extension.

To get data from your visitors there’s the web-vitals library that you can use to store the data yourself (or in Google Analytics if you’re using that)

import {getCLS, getFID, getLCP} from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});


The best part of the whole Web Vitals series is that not only they tell you what the important metrics are, they also tell you what you can do to score better on each individual metric.

Once you’ve measured the Core Web Vitals and identified areas for improvement, the next step is to optimize. The following guides offer specific recommendations for how to optimize your pages for each of the Core Web Vitals:

Those three articles are packed with solid and actionable advice. Every web developer should read this. Twice.

Web Vitals →