Front EndCenter

Last time out we were looking at how latency puts an upper limit on the performance of your site, and just how important it is to be hosting your content near your users. This time we go a step further: talking about the techniques and tradeoffs for highly cache-optimised sites, from content-addressable storage to federating your content across a CDN so requests don't even reach your server.

With just a few judicious build-time choices and deploy-time hooks, you too can have the fastest static site the web can offer.

Once you get your head around how MobX works and how it interacts with React components, the question becomes—how should I structure my stores? Should I tie my state as close to my React components as possible? Perhaps I should try to recreate the hierarchical structure of something like Redux? Or, maybe I should have a separate store for each domain object?

With a library as flexible as MobX, all these designs are possible. And each app has different needs—it's impossible to say that any particular design is "correct" for all cases. So in this episode we'll take an incremental approach—showing how designs change as more requirements come in, how they break down, and how to tease them apart.

By the end, we'll have a design that works well for pithy.af and the understanding of the choices that lead us there. Taking inspiration from the model layer from MVC frameworks such as Ruby on Rails, we'll see how MobX lets us present a clean, focussed API with a minimum of boilerplate. One that arguably hasn't really been possible in JavaScript before.

MobX is often talked about as an alternative to Redux for managing state in a React application—and both have their proponents. But where Redux enforces a fairly rigid structure and promises maintainability as a result, MobX offers complete flexibility. But what does that give you? And is it better?

In this episode, we start our journey towards answering that question. Armed with an understanding of the MobX's internals from the last episode, we'll experiment with a few different approaches and settle on a really clean delineation between data and UI.

MobX is a state management library that's found popularity in the React community—it's often introduced as an alternative to Redux that's easier to work with and reason about, where things "just work". But what about it makes it easy to use?

For starters, it follows the Observable pattern—you break your domain into mutable state objects, observers (which map neatly to React components), and actions that only change one thing at once. But Observable libraries are nothing new, in fact it's the exact mental model people are familiar with from working with spreadsheet applications. As a result, a version of this pattern appears in virtually every JS UI framework, as well as Node itself. But MobX still feels like something new. It feels like magic.

In this episode, we'll look at the two core mechanics that underlie MobX's beauty—what makes it possible to provide such an "invisible" API. In order to do that, we'll build up the same API from scratch and look at how some lesser-known features of JavaScript itself make things so seamless.

As we saw in the last episode, delivering an empty HTML page and relying on JavaScript on the client to render your UI has dramatic implications for both the usability and performance of your app. The golden rule is to always serve HTML, but how does that work exactly? What are the alternatives, and what are the tradeoffs involved?

In this episode, we'll dive into the way React makes pre-rendering possible (the good), the additional demands Server-Side Rendering places on your architecture (the bad), and the pitfalls of integrating server-rendering into a modern JS app (the ugly). And we'll see how Snapshot Rendering offers an alternative that plays to the strengths of your existing tooling and infrastructure.

There are undeniable benefits in using a JavaScript-centric development workflow—to building your UI as code & rendering on the client, rather than serving static markup & using JS just for interactivity. You get to draw your own boundaries along functional lines rather than language ones, wrapping things up in encapsulated components that can be reused in multiple places. You have more powerful ways of utilising libraries than simply injecting multiple script tags on the page. And you can bundle everything up using tools like Webpack that can seamlessly handle assets of all different types, applying specific tools and optimisations to each.

There are costs too, of course, but it's often a lot harder to enumerate those, since they differ so markedly depending on the particular use-case. But since it's such a controversial topic, discussions can quickly get sidetracked along ideological lines. I've seen it result in a vague convention: for public-facing marketing pages, use static HTML, CSS & unobtrusive JavaScript; for your main app behind your login screen, use a JS framework and a single-page app. It's a reasonable compromise, but we can do better.

With tools like server-side or snapshot rendering, we can take two seemingly opposed workflows and unify them in a way that gets the best of both worlds. To start, however, we need to better understand the problem—to dispassionately look at what we've lost without noticing, and conversely, what we now have to gain.

This episode is about the impact that

mix-blend-mode

could have on web design. At first glance, you might think that it isn't too different from the

background blend-mode

property we dug into in the last episode, but you'd be dead wrong. While the blend modes and the maths are the same,

mix-blend-mode

represents a monumental shift in the capabilities of web developers.

'Compositing' refers to two things. First, it's what the browser does to paint a webpage—building up each layer depending on its stacking context and

z-index

, blending them based on opacity and blend mode. But it's also the term for crafting a particular visual design—which layers we put where, how they respond to scrolling, etc. With a deep understanding of the former we open up totally new possibilities for the latter.

After all, it could be argued that Blending is really just "Photoshop in CSS". But Compositing? Well, that's a whole different beast altogether.

If you've used Photoshop or basically any other image processing application this century you've probably come across the concept of blending—mixing the colours of two layers beyond what's possible with opacity. You may also be vaguely aware that this feature has made its way into most modern browsers, but why is it useful?

If you're like me, you might assume that these effects are only useful for images, and, even then, only for the kind of dramatic effects that look good in a tech demo but, frankly, seem out of place in building products or pages day-to-day.

But blending and compositing (the subject of the next episode) is much more than that. It's a gateway into an internal browser process that completely changes the way a website gets displayed. And gives us an incredible potential for rich, performant web designs that haven't been possible before.

For this episode, though, we're going to make sure we understand the mechanics of what's going on. And answer the question—what kind of blend modes actually produce something that looks good?

The way a browser paints, in particular the z-index property itself, occupy an unusual spot in our collective knowledge. Most of the time, things work well enough that we never really feel the need to consider the underlying mechanics, but we still vaguely know there's more than meets the eye.

One day you'll have multiple layers seamlessly blending on a page, the next you won't be able to figure out why a click event is reaching the wrong element. Something's in the way, our element needs to be on top.

Like any good arms race, escalation is the smart choice, and so z-indexes of 10 turn into 100, 100 turns into 1000, and soon enough we can't distinguish real code from falling asleep on the keyboard.

It doesn't have to be this way. By digging down to the root of the problem, we can understand what's really going on. After all, there's only 3 really fundamental z-index values. How hard can it be?

About 18 months ago, I noticed that refreshing a page with Typekit fonts would cause a momentary jump—the fallback font would be rendered for only a few milliseconds before the web fonts would snap in. It annoyed me, and I started digging. Fast forward to now, and solving this problem has taken months of research and 3 whole episodes of groundwork, but we're finally there.

Join me as we finally defeat the Micro-Flash-of-Unstyled-Text-Even-When-We-Have-the-Fonts-Cached.

To kick off Front End Center for the new year we're going back to the fundamentals of web performance, and in particular the effect of latency on the speed of your site. Depending on where you live and the devices you use, high-latency internet access might be a totally foreign concept or an everyday reality, so in this episode we look at some concrete numbers to get a sense of just how much it can change someone's experience.

This is the first in a new series building up pithy.af, a side-project of mine that we'll use as a base to dive into lots of topics throughout the year. In this episode we look at the results of an experiment that I've been running, the TCP design decisions that cause connections to "slow start", and why it's worth adding a CDN to our architecture right at the beginning of the project.

Webfonts are a tricky thing to get right — the usual formula is: attractive visuals, good performance & reliable functionality (pick two). This episode is about how you can get all three by properly employing a fallback font while the webfont loads.

This episode comes in two parts: loading Webfonts properly & tuning the fallback font's CSS. This second part is an often-overlooked part of the process, and leads a lot of projects to conclude that the best way to use Webfonts is to hide the text until the font has loaded. And, as anyone who has stared at a blank screen on their mobile for 10+ seconds will tell you, that's not ideal.

Learn how you can cater for the unpredictable circumstances of your users without compromising the visual quality of your build.

Following on from the previous episode, this time we dig into the ideas of Interface Segregation and Liskov Substitution — two more Object-Oriented design principles that are remarkably relevant to working in a component-driven UI framework. We start to pick apart some of the reasons some components feel really inflexible and some seem to work everywhere, and give you some ideas about how to convert the former into the latter in future.

The Functional Programming (FP) aspects of React are fairly prominent: by making your UI a pure function of your application state you remove a whole class of bugs that plagued earlier frameworks. If you look closely at the render method, or performance optimisations like shouldComponentUpdate, as well as popular libraries like Redux, again you’ll see a strong FP influence. But that’s not the only thing at play.

Because component-driven design is actually much closer to Object-Oriented (OO) programming. Components encapsulate state, present a public API, and map to objects in the “real world” (or in our case the UI), which are all core properties of Objects in OO. And they relate to each other, they share information or depend upon each other, which are all classical OO design problems. It means there’s a wealth of ideas, discussions and patterns that we can bring to bear in making our React components more readable, reusable, and maintainable.

Responsive imagery is one of those topics that seems way more complicated than it aught to be. It’s the sort of problem that confronts virtually every website out there—every site has images—and yet the approaches offered by HTML alone aren't sufficient.

In this episode we'll look at how using a dedicated Image CDN can simplify your markup, enable pixel-perfection regardless of device, use the best possible image formats available, and simplify use of the

<picture>

element and

srcset

attribute.

Building on last episode, we cover a seriously compelling workflow blending the best of both worlds — authoring an SVG spritesheet in Sketch but injecting them as Inline SVG, without a bunch of manual steps in between.

SVG is one of the most powerful tools in a front-end developer's arsenal, and while its browser support is excellent, there's enough rough edges that a lot of people consistently reach for an alternative such as icon fonts, static images or CSS-only drawing techniques.

In this episode we'll look at what can be achieved by writing SVG by hand, simple effects that can add a lot to an interaction that only need a handful of lines of SVG + CSS. But we'll also consider why it is that Inline SVG, in particular, is so much easier to work with than embedding SVG in other ways.

The currentColor keyword is a wildly powerful yet sadly underused feature of CSS. And understanding it requires a deep look at some of the core concepts in CSS that are often glossed over. We'll look at concepts that were present in the very first draft of CSS1 in 1996 all the way to the almost-ready-to-use CSS Variables spec.

And with our new-found dynamism we'll show how to go past the superficial limitations of currentColor to build some contextually-themed real-world UI elements.

Webpack often gets a bad rap in the front end community — plenty of digital ink has been spilled over whether web development is "too complicated", with Webpack taking center stage. But in reality, it's no more complex than the sites we're building with it, and conceptually its role is quite clear.

Let's demystify the tool by stripping it back to what it truly is — an ahead-of-time compiler for the browser.