Industrial Empathy

New on the web platform in November, 2022

2022-11-03T00:00:00Z

It may take an extra 6 months, but This Is Happening™️

…which is why we get solid Safari releases

…and useful privacy feature only 7 years late.

I believe it when it ships

Nobody really knows why this is good, but it aligns Blink with Gecko

More support for CSS-only UI

Pre-rendering is back in Chrome. Now also for 'same-site' navigations (e.g. foo.example.com and bar.example.com)

Seems useful

This API seems underappreciated?

Shopify buys Remix

JXL is not coming to Chrome. But JXL features may come to JPEG 🤯

RIP document.domain

One of the weirdest gotchas of the web platform: with CORS mode you can control whether to send cookies BUT the HTTP cache might respond with a result that was fetched using a different CORS mode.

Next.js 13!

Using custom fonts well on the web is finally somewhat easy

New on the web platform in October, 2022

2022-10-06T00:00:00Z

If you ship one thing today, make it this

The best Chrome feature of the millennium (link to text fragment) is coming to Safari! "Implemented full search for text directives for Scroll to Text Fragment spec"

Grumble

Shared Element Transitions seem to be happening

O(features uses) JS frameworks are becoming mainstream accessible

Good Riddance

Hope that this actually gets released quickly

MOAH CPU

The SQLite on the web API is coming to Android

Visual viewport sizing gets cross browser compat

And same for logical viewport units

You should probably not use this, but it exists

ShadowDOM may become usable for non-specialized use cases

…because this is the other missing link

INP debugging

The end of SPA-discrimination in Core Web Vitals is in sight

Seems like a great idea

A billion IOT owners sigh in relieve

The security-theater certificates are no longer slow

New on the web platform in September, 2022

2022-09-01T00:00:00Z

AVIF is amazing, and even better for boring images

WP Optimize is fraud

Good trend: good defaults for `prefers-reduced-motion`

Attempt to fix DLL Hell for custom elements

Bun got financing

Modern pre-rendering is coming to desktop on Chrome

#

Life-saver for multi-Chrome-profile livings

TIL that WebKit doesn't have site isolation yet

Lots of WebView drama this month. One thread here…

OriginFileSystem coming to the last browser. SQLite is back on the web!

The fallacy of “thriving in ambiguity”

2022-08-29T00:00:00Z

A key mantra in Google’s work culture and across big tech is “thriving in ambiguity”: The ability to make progress and make good decisions in the presence of uncertainty around the future in general and the interpretation of the data available today.

It is very human to be uncomfortable with ambiguity. It can be very nice to just follow procedure and execute on a well laid out plan pointing toward a known objective. And reality is that many jobs are like that. You learn it, you progress your skills, and while you may face many challenges along the way, the solutions stay within a relatively tight framework of the job description.

“Thriving in ambiguity” means to do well when all of that is not the case. You have to dynamically adapt, rapidly learn new skills, execute, pivot, be willing to cut your losses, and do it all over again as new information emerges–all without knowing you are on the right track.

I’m all for learning to be more comfortable with ambiguity. I might even be good at it. But this post is about when “thriving in ambiguity” is a potential fallacy and how to do even better.

My basic thesis is: Ambiguity is bad #

My basic thesis is: Ambiguity is bad. You should thrive in it, sure, but you should also strive to eliminate it whenever possible.

Ambiguity is bad because it impacts the efficiency of communication #

I’ve seen many teams that couldn’t decide on what the right path forward is. Subsequently, all communication needs to be qualified: “Assuming for a bit that X is true, we should do Y”. What inevitably happens is that someone doesn’t add the qualification and now every listener makes their own assumptions which scenario of possible futures the speaker likely meant. Typically folks eventually figure out when they got the interpretation of the scenario wrong but only after lots of time has been lost to folks arguing over things only to find out they were operating under different basic assumptions.

Ambiguity is bad because it has opportunity cost #

If you hedge your bets due to inability to make the right decision, you’re likely not executing as well on the options as if you’d concentrated on a single one. A question I’m often asking my teams is “Is the maximum delta in outcome between two options actually bigger than the cost of reduced focus in execution?” More often than not, the answer is no. In that case you are better off focusing on one option, and doing it truly well.

“Thriving in ambiguity” can cloud your judgment #

Finally, “thriving in ambiguity” can cloud your judgment such that you end up treating every situation as if it was truly ambiguous. Some things are actually clear and simple, but I’ve seen teams run the “ambiguity playbook” without critically thinking about the necessity. That makes you and your team less efficient and effective. Instead try to always think about the degree of uncertainty and tailor your behavior to it.

In summary: Thrive in ambiguity, but be aware of the way it impacts your team communication, its opportunity cost, and make a habit out of critically thinking about whether a situation is truly ambiguous.

New on the web platform in August, 2022

2022-08-11T00:00:00Z

Both are fine

INP clarified: Time from physical event until next paint would be possible.

One weird trick to improve INP in React

AVIF everywhere

CPU pressure API

Don't bother with DocumentFragment

Almost-default-lazy 3P iframes experiment in Chromium

has and container queries. Has is now everywhere

This is interesting, but I'm highly doubtful it is a good idea. The difficulty in loading the right font subset was in quickly finding the subset, not so much in loading that subset.

Observability for `content-visibility: auto`

Approved

New on the web platform in July, 2022

2022-07-07T00:00:00Z

iOS browser-diversity is going to be the law of the land in the EU

We're continuing to explore the JS execution environment trade-off space

`setTimeout(…, 0)` may actually mean 0 more often soon

Neat idea to use Brotli with PNG. But also: Use lossless WebP

I helped make some edge computing

Client-hint for how large the user screen is!

#

It's happening!™️ AVIF coming to Apple devices

The most ungeneric web API yet!

Send preload headers without deciding on the HTTP status code!

Rest in Pieces

New CruX data with bigger coverage (due to changes in the way data is collected that pushes more origins above the K-anonymity threshold)

Interview with your's truly

Very useful

New on the web platform in June, 2022

2022-06-02T00:00:00Z

This isn't new but worth a PSA

Standardization effort for Web API based server runtimes

Start logging this to learn why you are not benefitting from free performance

…and a way to turn off one major reason for no BFCache

It's happening™️

Also the literal opposite is happening

This API proposal is a big deal. Primarily because it looks like it might be easy enough to use to get adoption

Tooltip (etc.) positioning in CSS

Faster H3 discovery through DNS

Keep folks on their toes

$entropy--

'Looks to the left, looks to the right'.gif

The USA is joining the browser-engine diversity regulation game

Better async debugging

#papercuts

#

ServiceWorker ☠️

Attempt to bind cookies to their origin by default (rather than the weird legacy semantics from before origins were a thing)

It was always weird that media queries didn't support full boolean logic

Browser-built-in HTML Sanitization. Will also be great for Deno and friends

New on the web platform in May, 2022

2022-05-05T00:00:00Z

We're about to see many more users requesting reduced data usage

Major speed-ups from privacy-preserving prefetching

Rest in Pieces ☠️

US is seeking input on Apple's browser engine monopoly

The EU is going ahead banning Apple's browser engine monopoly

Same in the UK. Plus Apple is majorly staffing up the Safari team so they can actually compete in a fair environment. It's happening™️

#

Sandbox➡️Prison

Fewer lines of code to write!

Cross-site caching is coming back in a privacy-safe way

I had known about this, but thought it was only impactful for legacy Windows and some Linuxes. But turns out that there is also a setting in MacOS that gets turned on when using a mouse that enables scrollbars that benefit from this change.

If you adobt anything from today, make it this:

I think "Window Controls Overlay" is significant not because that is particularly important but rather it shows how far web apps have come. Browsers are really now shipping the long tail of operating system integrations.

☠️ to require

If you hide your content in your app, then your website will not rank well in Google.

Per-page TTFB now available

Mobile PWA: Kind of Meh. Desktop PWA: On the road to 100% market share for Desktop apps.

New on the web platform in April, 2022

2022-04-06T00:00:00Z

Fold estimation is the next frontier in web perf optimization

Coordinated announcement by all browser makers

`content-visibility`, the CSS primitive for O(1) DOM layout cost without breaking a11y, is now in progress or shipped in all major browser engines.

s/importance/fetchpriority

…and shipping in Chromium

New responsiveness metric is available to read in CrUX

Yet another PSA: Free performance

And Chromium is shipping away on the 'veto reasons'

Interesting decision to be made by browsers

The non-runtime effectful parts of TS may soon be valid JS

AI in the browser

Native lazy loading: 🍻, Navigation preload: You can now use ServiceWorkers for "websites" in Safari, Strict dynamic CSP: You can now use CSP in Safari, Viewport units: There are now units that work like you thought the old ones did, CSS cascade layers: 🤩

This is a very important new feature making it possible to virtualize DOM (not to be mistaken with virtual DOM) in a way that it is still accessible to find-in-page. The most obvious use case is to markup the contents of accordion style UIs to automatically open on find.

Hardware AV1 decoding on Qualcomm and Intel

Micro-frontend tech

Native lazy loading is good

This may also impact the #AppleBrowserBan

You can now pay for MDN

Free performance win (if it is web compatible)

Yeah, we can't have pre-cached npm, but we can have pre-cached Helvetica!

This looks really helpful

Plus, it works for setters!

Why we can't have nice things

One more browser on the way for bare imports

"A partner finished an experiment and confirmed that latency on their service is reduced by 45%."

11 years at Google

2022-03-04T00:00:00Z

On March 4th, 2022 was my last day at Google.

It was an amazing 11+ years working with some of the most inspiring and talented colleagues one could imagine.

As my final role, I was leading Google Search for Desktop computers. I still cannot believe they let me run the literal search engine. In fact, this was my first time leading a major consumer product after years of being focused on infrastructure, and to my own surprise, I was actually kind of good at it.

Of all the code that I wrote, my favorite change was probably the introduction of SUPER_UNCOMPILED mode for JavaScript delivery during development. Prior to this, Google engineers would wait to compile their JS and debug unobfuscated but compiled code losing files, line numbers, etc. I managed to fix this before source maps were a thing, yet retaining 100% compatibility with the semantics of the compiled code.

I later built a JS framework called Wiz which is now powering Search, GMail, Photos, Drive, Meet, and many other consumer UIs. In hindsight, I should have open-sourced it, but at the time, I didn’t realize how relatively powerful and unique it was, and by now it badly needs an overhaul relative to modern framework developer experience.

I got incredibly lucky with Wiz. Wiz was designed to be small and nimble specifically for G+ on Desktop with the goal of making it faster without slowing it down too much from the added page weight of a new framework. Turns out we never really used Wiz for that, but it was perfect for mobile web UIs on underpowered devices at the time leading to its broad adoption.

As the next thing, me and my team built a similarly widely adopted end-to-end frontend framework and serving system for Google’s internal microservice platform. I contributed its UI-and-data-component abstraction, but the main kudos goes to @shubhie for really opening our eyes to the power of using application-level linting for scaled software engineering.

Taking this idea, I ended up making a little thing called AMP. Let’s just say I learned a lot from it, and I think we ended up very successfully taking those lessons and applying them to the Page Experience ranking system based on Core Web Vitals–helping make the web much faster in the process.

From this I moved on to work on the Search Engine proper. I just cannot emphasize enough what a humbling experience it has been to work with the absolute top of the world class on this problem space. This is especially true for incredible data science and quantitative UXR teams which uplevel the professionalism and excellence of the product operations to levels I had never witnessed before, and which deeply influence how I will work in the future. Also, I got to turn off Internet Explorer for the biggest website on the planet, so that was cool. :)

The time at Google has been an incredible learning experience that I’ll be forever grateful for, and I’ll dearly miss my amazing colleagues. Throughout my career I’ve tried to follow a thread of finding invariants that eliminate the trade-offs between making it easy to write programs, yet achieving excellent user experience. I’ve learned a lot and there is still so much more to do in this space.

That was 11 years in a few 100 words. Was it a good time? Yes. Should you work at Google? Yes, I’d recommend it. But for me it is time to try something new!.

New on the web platform in March, 2022

2022-03-02T00:00:00Z

For less snark and Malte-bias check out Rachel's new series with the same theme

We're CORSing private network requests. This will be painful but is badly needed for IOT security

Chromium is looking to ship full network state partitioning. We have already lost the HTTP cache shared between sites; with this things like H2/H3 connections H3 TLS resumption, & DNS cache are also partitioned. This substantially increases the perf impact of 3P resources.

BFCache, also known as the one weird trick to make LCP be 0 milliseconds for all back navigations on your site, now has a dedicated tab in Chrome DevTools

Trigger global exception handlers without breaking execution flow

Compatibility data in MDN is no longer manually maintained!

An API rises from the dead ☠

Certificate transparency is diversifying

Required reading

My main pet-peeve is being addressed

I was shocked to learn that this wasn't supported. But, yaihh, I guess

Users know which sites you really use. This should be used more to pre-qualify permission prompts, etc.

This effect is extremely common. If you make your website demonstrably faster while the performance metrics measured in the field go down BUT your revenue (or whatever end to end gross business success metric you are using) goes up, then this is probably what is happening.

`@layer` is cool

Core Web Vitals ranking on Google Search for Desktop is launching

Is it web news that Google Docs is finally abandoning the pager-page metaphor?

Godspeed to the good folks fighting the #AppleBrowserBan

New on the web platform in February, 2022

2022-02-02T00:00:00Z

Awesome to see continued innovation on the good old link

Safari did not have a good month

Actually it was very bad

Even though Igalia tried their best to help out

And Apple is trying to staff up

The pressure works

Accelerated animations in Safari are subject to OS capability. Thread has details on bail-outs. Every browser will have such bail-outs.

Navigation preload in Safari is a big deal for ServiceWorker viability

Custom Elements in React are progressing

#

…related data (thanks to [Zouhir!](https://twitter.com/_zouhir))

Great article looking at statistical trends for web dev in 2022

Great to see more web APIs landing in Node. Thanks Deno for the competition!

Prefetch in a privacy-safe web

New on the web platform in January, 2022

2022-01-12T00:00:00Z

Container queries are being standardized

Hell freezing over

Actually working app history is landing

Chrome DevTools catching up on a11y

You probably want AVIF, but this is the choice for very high quality images

Super insightful performance improvement journey

Colored fonts in browsers

I did not know this

Viral software deadlines

2022-01-03T00:00:00Z

Unnecessary trade-offs are the root of all evil in software engineering. This article is about one of the most common sources of such unnecessary trade-offs: The unrealistic deadline of a partner team leading to exponential growth of technical debt throughout the organization.

In this scenario your team is building some kind of new feature requested by some other team (“CoolFeature Team”) who insists they need it by date Y so that they can ship their feature by later date X.

The failure mode I’ve seen happen time and time again, is that the following happens:

You realize that the right way of building the new feature cannot be achieved by date Y and so you resort to some short-term hack to make it happen. You actually have your thing ready by date Y.
However, as date Y arrives it becomes apparent that CoolFeature Team’s project has slipped their own deadline date X and they really don’t need you to be ready yet.
Tragically you discover that you could have built the new feature the right way, without accruing major technical debt, if you had known when CoolFeature team really needed you to be ready. However, now it is too late to start over and have the right way of doing it ready by the new deadline and the hack remains in place.

This case is distinct from you setting unrealistic deadlines for yourself. Sure, that also sucks, but at least you are in control of the impact and can make choices that you deem locally correct. But with partner teams coming into the picture that are doing work based on such deadlines it is important to realize how such bad planning can snowball through the organization. In fact, it can multiply the negative impact in an exponential way: Each partner may in turn ask for changes down the stack proliferating the original unrealistic deadline further into the organization.

What can we do? #

This isn’t a post offering advice on how to avoid slipping deadlines of software projects. This will happen. In fact, the professional thing is to mitigate the impact of inevitable slippage rather than attempting to fully eliminate it.

What we can do is:

Realize when our deadlines have follow-on impact beyond the immediate reach of our team such as partner teams reprioritizing work and potentially accruing technical debt.
Really, really be honest to ourselves what a realistic finish date for a project is. We will make planning mistakes, but more often than not it would have been possible to anticipate that a deadline was never going to happen.
Especially as a leader who might be using deadlines as a device to improve productivity, it is important to consider the “total cost of the deadline”, which may be bigger than what is immediately visible.

Summary #

Deadlines in software projects can be viral in that they force partner teams to reprioritize work and accrue technical debt. In large organizations or complex stacks these partner teams may in turn “infect” their partner teams to work towards the same deadline leading to exponential growth of technical debt. As professional engineers we must consider the total cost of our decisions. When we fan out our deadlines into the organization it is important to be honest to ourselves about realistic deadlines to minimize unnecessary technical debt at the time of delivery.

New on the web platform in December, 2021

2021-12-01T00:00:00Z

Page experience ranking for Desktop

Smoothness Web Vitals metric is in the works

The web is getting faster quicker than ever!

Single browser engine per OS is a dangerous strategy

😬

Container queries polyfill!

#

Path to safe local network HTTP

The bad/wrong same-domain canonical URL check is gone!

Native AI on the web platform?

Huge relatively-low-effort performance improvement potential!

New on the web platform in November, 2021

2021-11-03T00:00:00Z

In-browser HTML Sanitizer API is coming

Finally a browser will open semantically closed elements when their contents match a `find in page` query

Mentioned last month, now shipped

The `importance` attribute can be powerful

RIP

Your monthly `content-visibility: auto` PSA

There might be auto dark mode in Chrome

Photoshop and Illustrator are on the web. Not a big deal

I'm mildly excited

The web sometimes seems static but this is amazing adoption

It's actually a blender

New on the web platform in October, 2021

2021-10-06T00:00:00Z

Important change in preload ordering. Will help many, but may require re-testing of strategies

The WASM killer app

Easy way to make signed exchanges via Cloudflare

Platforms are catching up on Core Web Vitals

#AppleBrowserBan is becoming mainstream discussion

Smoothness web vitals in the works

Chromium is giving up on making C++ memory safe

Your monthly reminder that AVIF is good

Igalia is why we can have some nice things

Actually deployable CSP is coming to Safari

Narrator: It did not go well

New important(^Wnce) performance tuning primitive

It is time

💯

RIP AppCache

Slightly more reasonable CORS

All the ❤️ to jQuery. Also: Get rid of it if you can. You no longer need it

Cool stats about installed PWAs.

New on the web platform in September, 2021

2021-09-01T00:00:00Z

Chrome ended up deciding not to break most AVIFs

AVIFs in Fx

The "best" post IE6 API is getting an "unneeded" makeover

An actual API to schedule tasks in the browser 😍

jQuery is nice. The module system was shit. And the selectors are as maintainable as CSS selectors. But it was nice.

Long-term V8 regex parsing bug is fixed. Might break your code

I feel seen

This is just so nice

This post is showing how CSS selectors that are inherently O(n) where n is the DOM size stay O(1) in apps that are decomposed with Shadow DOM

Custom protocol handling for Chromium PWAs

#

👀

🔥

New on the web platform in August, 2021

2021-08-01T00:00:00Z

A nice sync, safe-for-thread-model API

Another nail in the coffin of IE

Good insight for finalizer use in cross-worker JS programs

You just can't believe we put up with it for so many years

Good pointers for what client-side privacy APIs could do

Anti-layout-shift API tweet 1/3

2/3: No layout-shift with art directed images in picture

3/3: For when you really want the field-reported CLS to hit 0

DNS resolutions no longer considered a scarce resource

Native nesting in CSS (proposal stage)

New on the web platform in July, 2021

2021-07-01T00:00:00Z

Virtual keyboard presence is finally exposed to the web platform

Chromium is slowly modernizing all aspects of its rendering engine

Theme colors now support the media attribute (for dark mode) in Safari and Chrome

Responsiveness metrics need more work after FID

If you are reading this website, then AVIF is just fine for your use case

Fixed in Chrome now. Pending in Safari and Fx

Important early research into website memory usage

Page experience ranking is shipping

Native non-JS imports part 1

Native non-JS imports part 2

#

Domain sharding 2021

New on the web platform in June, 2021

2021-06-02T00:00:00Z

Yet another attempt at smooth transitions

A small step for the error object, a big step for debuggability

Page experience ranking coming to desktop

More good news from the browser front. And global marketshare dropped another 13% last month

This is significant in that a major cause of 3P JS slowness reacted to Core Web Vitals

Iframes Anonymous

The web is getting faster

I nerded out on software design again

A ~solution for font-induced CLS

The proliferation of JS VM tiers continues

JXL is coming to browsers.

The Context Tree Design Pattern

2021-05-23T00:00:00Z

The Context Tree Design Pattern is broadly used in framework design and fascinatingly appears in seemingly unrelated applications implemented with many different strategies. As far as I can tell, this pattern does not yet have a name and so I made one up. C2 documents the Context Object and why it is bad, yet falls short of identifying the relationship to trees that push the pattern beyond a fancy bag of global variables.

Description and examples #

The Context Tree Design Pattern appears whenever there is some kind of tree (in the computer science sense) and ancestor nodes want to communicate state to all their transitive children. Such trees might be:

A function call tree.
A remote procedure call or multiple event invocation tree.
A user interface tree such as a DOM tree.
A transient render tree (such as found in React).

One common capability of setting context in a tree is the ability to shadow named context values that were specified by an ancestor with a different value for all children.

Applications #

Common application of context in such trees would be:

A reference to the current locale, HTTP request, or logger.
The window or other container a UI object is inside of.
Tracing of complex but strongly related computer system behavior that spans multiple events, processes, and/or machines.

Implementation strategies #

Explicit passing of context #

This might seem like the most naive implementation strategy: One simply passes a context object argument to the next child.

function example_function(context, arg1, arg2) {
  other_function(context, arg1);
  yet_another_function(context, 123);
}

This method leads to significant boilerplate and leaks the existence of context to every participant in the call tree. However, sometimes, such as when crossing system boundaries, this may be the only implementation option. Frameworks can hide this from user code through mechanisms that pass context via standardized headers or side channels for remote procedure calls.

Context stack #

In the simplest application of the Context Tree Design Pattern, the function call tree, the pattern is typically implemented using a stack. One pushes a value to store it, children read it by peeking at the top element of the stack, and then one pops the value when the calls to the children have completed. Interestingly, the Perl 5 programming language has native support for this pattern with the local keyword. Respectively, it becomes obvious that the Context Tree Design Pattern in a synchronous function call tree is the same concept as dynamic scoping.

var context_stack = new Stack();

function example_function() {
  context_stack.push("context value");
  child_function();
  context_stack.pop();
}

function child_function() {
  // Actually read the context.
  var context_value = context_stack.peek();
  // Shadow the value for a child.
  context_stack.push("override");
  nested_child_function();
  context_stack.pop();
}

Note, that user code would essentially never interact directly with this implementation. Instead they'd use higher level APIs that hide the implementation detail of the stack and ensure that pushes and pops are well paired.

This simple implementation, however, doesn’t work to more complex use cases of call trees, such as when they span threads, asynchronous invocations, or even physical machines; and the implementation strategy does not work for persistent trees such as DOM trees.

Thread local variables #

Thread local variables may act as the host for the stack described above. In a system where threads are dedicated to a single execution context such as a HTTP request, thread local variables are useful to provide context that is isolated to handling that request.

Hooking event loop entry points #

Event driven systems (such as Node.js) cannot use thread local variables as there may only be a single thread and even if there are more than one, they may be used across many logically separate computations.

A strategy to still get somewhat convenient context access in such a scenario is to change all points that represent the root of a call stack in an event loop invocation to properly restore context and to make each invocation that places work on the event loop store context such that it can be restored upon invocation.

Walking up the tree #

While function call trees do not typically allow inspection of the state of the caller (There are, of course, exceptions) this is very commonly possible in persistent trees such as the tree representing a user interface like a DOM tree. Nodes on the tree can walk up their parent nodes in reasonably efficient O(k depth of the tree) to find context provided to them.

// Visit parent elements of the start element and return the
// context value if they provide it.
function get_context(element, key) {
  do {
    // We assume for this example that every parent element
    // has a context map.
    if (element.context.has(key)) {
      return element.context.get(key);
    }
  } while ((element = element.parentElement));
  return undefined;
}

Using event propagation #

Another way to implement the same approach is to rely on event bubbling that is commonly natively supported in UI systems. Here the target nodes sends a custom event up the tree. Ancestors intercept the event, and if they can provide the desired context, they send it down to the target and stop propagation of the event.

Context in React-style frameworks #

Context is commonly found in React-style frameworks, but they tend to implement context in terms of the function call tree that underlies the render tree rather than the persistent UI tree.

Trace context #

Many software systems have invested in observability through tracing. As seen in the examples above, tracing is itself an application of the Context Tree Design Pattern. However, if one has a good tracing system, one can use (abuse) it to attach context to it that is unrelated to tracing.

function get_context(trace) {
  // We store context in a weak map keyed by
  // the current trace.
  return context_weak_map.get(trace);
}

An anti-pattern? #

The Context Tree Design Pattern can easily be misused and has a long range of failure modes:

Messy bag of quasi global variables #

The context may grow to a messy bag of quasi global variables.

Mitigation: Consider requiring an allow-list that requires engineering leadership approval for new values stored in context.

Action at a distance #

Context may create fragile, implicit, and undocumented dependencies between seemingly unrelated nodes in a tree.

Mitigation: Consider introducing a type-system that requires context consumers to be only callable by callers that provide that context or which require their callers to provide that context (Note: I’m not sure such a type system exists; it smells a bit like checked exceptions in Java but might still be a good idea).

Unexpected consumers #

Context may be read by unexpected consumers creating even more brittle dependencies.

Mitigation: Consider protecting the keys to read context to be protected by some kind of access control mechanism such as an allow-list.

Summary #

I find it fascinating that this pattern has found such a wide range of applications and is implemented through seemingly unrelated implementation strategies. I probably missed use cases, alternative implementations, and failure modes. Comments with additions or corrections are very welcome!

New on the web platform in May, 2021

2021-05-05T00:00:00Z

CLS no longer penalizes long-running sessions with unlimited cumulations

Declarative Shadow DOM. And easily polyfillable

Faster number crunching if you need to crunch numbers

New timing for page experience ranking

Every web page can be a desktop app

HTML sanitization as a platform primitive

Chrome continues to catch up on back-forward cache

The IE11 death march continues

No excuses

Fix committed but unclear if shipping

Woke: FCP in Safari Broke: Not actually reporting paint time

#

New on the web platform in April, 2021

2021-04-07T00:00:00Z

Top-level await in Firefox (It is already in Chrome/v8) …

…and also coming to Safari

It is now 0.73%. Down and to the right! 📉

Chrome going HTTPS-connect by default (falling back to HTTP if that fails)

#

Also in that release: Freeze dried tabs that take no memory but start up fast.

Page experience ranking is coming!

Balanced look at privacy-preserving interest-based ads

Think AVIF, but with progressive loading

End of an era. Except the old era is still linked from the new era.

APIs prevailed

Safari uses proprietary image decoding, but this is still a good sign.

I wish browsers would handle these but until then:

New on the web platform in March, 2021

2021-03-11T00:00:00Z

End of an era

AVIF is good

AVIF is shipping in Firefox

JPEG XL is also good

Lighter embeds are a major trend

This has strategic implication for long-term web design planning

`content-visibility: auto` is our most powerful new hammer. Use wisely.

It is amazing that jQuery is still being actively maintained

A new Chrome every 4 weeks

Deep-dive on Post-Spectre web dev

Please use this

Framework-layer perf improvements are the best ones

AVIF and WebP encoding quality settings

2021-02-20T00:00:00Z

AVIF and WebP are modern image formats that generally produce smaller file sizes compared to the widely used JPEG format. This post explains what quality setting to pick when generating AVIF and WebP images as alternatives for serving JPEG on the web. The goal is to find the quality setting that will create images that look as good as the JPEG, but with a smaller size to optimize page load time without sacrifizing image quality.

One more thing: This post is advice for tuning your automatic image optimization process where if you're anything like me you'll configure a global value once and then never look back. If you are the type of person who optimizes each image individually, then this post is probably not for you 😇. But you may still want to play with my tool.

The 1 minute version #

If you usually encode JPEGs with quality setting 60, then encode AVIF with quality setting 50 and WebP with quality setting 65. You should expect your AVIF files to be on average 36% smaller and your WebP images 15% smaller than the equivalent JPEG image.

Quality settings for a range of JPEG qualities #

More generally, this table maps quality settings for JPEG to the respective AVIF and WebP quality settings:

JPEG quality	50	60	70	80
AVIF quality	48	51	56	64
WebP quality	55	64	72	82

There are some notable differences in how well the different image codecs perform for varying image dimensions (especially between very small images like thumbnails and highres images). If you want to fully optimize things, check out this pivot table for the gory details.

Visual verification #

Quality numbers are cool, but you might want to verify that I did not just pick them out of thin air. For a head-to-head comparison of images with the varying quality settings, check out this tool:

Methodology #

To generate the data above, for a set of sample images:

I generated JPEG, AVIF, and WebP images for various screen dimensions and with a multitude of quality settings.
I then used dssim to calculate how visually different each of these images are from the source images.
And finally I picked those AVIF and WebP images in a given size and JPEG quality setting that were as different from the source image (again, as determined by dssim) as the respective JPEG.

For the full details, check out this GitHub project.

Caveats #

All quality settings are expressed on a range from 1 to 100.
Images were encoded using the sharp image processing library. Results with different encoders may vary.
The underlying data was generated from only 4 images (showing a landscape, a person, flowers, and architecture). These sample images may not be representative for the images on your website and you may require different encoding settings (Although I don't think so 😛). You can easily rerun the same fully automated process that I used for this post through this GitHub project.
If you're like "LOL, why only 4 sample images". The method explodes these out to over 2300 generated images. It is easy to add more samples, but it does cost a lot of CPU.

Browser support #

All modern browsers support WebP. At the time of this writing (February 2021) not all browsers support AVIF yet. However, very broad browser suport for AVIF is a safe bet with Chromium and Firefox having already shipped support and Apple, maker of Safari and the WebKit engine, being part of the AV1 consortium that makes the AVIF codec.

Check out my recent post on image optimization for how to load different image codecs with graceful degradation to JPEG using the picture element.

Summary #

With my image sample set AVIF images were on average 36% smaller and WebP images were 15% smaller than the equivalent JPEG. If you are looking for ways to improve metrics like Largest Contentful Paint, then supporting modern image formats may be a quick way to make progress.

For a wider perspective on image loading optimization on the web, check out my post on image loading optimizations.

New on the web platform in February, 2021

2021-02-10T00:00:00Z

Your timers might not fire. Deal with it😎

#

WorkerDOM but not in user land

Inline threads in JS

#

Mozilla being short-sighted. Feb 21 edition

AMP, but !AMP

#

I wrote a blog post because my blog had bad CLS

Further progress on origin isolation

A proposal for a non-broken history API

TIL

Dear my bank in particular

Caja is both deprecated and has unfixed vulns. Use [DOMPurify](https://github.com/cure53/DOMPurify)

NPM and other package registries dangerously allow private packages in the same namespace as public packages and prefer public packages

More than you ever wanted to know about font loading on the web

2021-01-29T00:00:00Z

When I started thinking about writing a post about web font loading my intention was to propose relatively sophisticated ideas that I've been playing with for a while. However, as I was trying to use them in real-world websites I realized that deployment of the more advanced techniques is de-facto impossible without the creation of new web standards.

With that the TL;dr of this post is: Use font-display: optional. However, I and many others really like our custom fonts. See the rest of the post for how we can get our cake and eat it, too–with a tool that automatically makes fallback fonts behave like their respective custom font counterpart.

Web fonts and Core Web Vitals #

2 metrics in Google's Core Web Vitals are directly impacted by font loading:

Largest Contentful Paint (LCP) measures (among other things) when text renders. With text rendering blocked behind the web font download, LCP may be delayed.
Cumulative Layout Shift (CLS) measures the document shifting around as the browser loads additional data. A browser switching from fallback font to a custom font leads to layout shift if fallback and custom font flow differently.

The following video is showing the layout-shift created by font-loading.

CLS and invisible text #

Font-based layout shift doesn't require the fallback font ever having displayed. If the page renders without the custom font having loaded but the fallback text remains invisible (this happens with font-display: auto, the default) then the space that is reserved for the invisible text depends on the space that would be taken up by the fallback text. Once the custom font comes in and the text becomes visible, there is a layout shift as the space taken up for text changes.

Stop worrying and use `font-display: optional` #

With font-display: optional the browser only renders the custom font if it is available extremely quickly. In most scenarios that requires it being cached locally.

This leads to the best possible LCP: Your text always renders quickly, independent of network speed.

And it leads to the best possible CLS: Your custom font loading never causes layout shift because it is only used when it is available for the first text paint.

When not to use `font-display: optional` #

The one reason that makes usage of font-display: optional impossible is if there is no viable fallback font: You need the custom font to load to make sense of the content. Generally that is the case for icon fonts. You probably shouldn't use these in the first place as they are bad for accessibility: You need to see the icons to comprehend them, and you cannot assign them alt-text.

Using preload with `font-display: optional` #

Browsers will only download a font for a web page when CSS evaluation completes and it is determined that it is actually used on the page. That is much later than e.g. when image downloads are initiated which are done by the so-called pre-parser that does a quick scan of the HTML document as soon as it is available to the browser (and without blocking on synchronous scripts, stylesheets, etc.).

The common work-around is to use a link-preload element like this which explicitly instructs the browser to start the font download as soon as it discovers the element.

<link
  rel="preload"
  href="/fonts/Inter-Bold.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

The question is: Should you use these together with font-display: optional? The conventional wisdom is: No. The reason being that with font-display: optional either your font is already in cache in which case this doesn't do anything, or the font download is likely not fast enough to make the short deadline and the browser would render the fallback font anyway. In the latter case you give bandwidth at the most urgent time to the font which will never render and that bandwidth could be used to download other critical resources instead.

When disk caching isn't enough #

However, with font-display: optional even users who have the font cached to disk might see the fallback font for the first page view of a new session because the custom font hasn't been loaded into the memory cache (Note, that while you might be developing your website on a laptop or phone with a very fast SSD, many of your users will have degraded storage devices with cache performance worse than a fast network). At least Chrome has a heuristic that if you preload the font, then it will hold painting for a few 100 of milliseconds and give the client a chance to fetch the font from disk or through a very fast internet connection. Whether you have a "budget" to spend those extra 100s milliseconds depends on your overall load performance.

Fonts and CDNs #

One of the big changes in the web ecosystem over the last few years is that browsers no longer cache resources across top level sites. That means if your site and my site both load the exact same Roboto from Google Fonts, the browser will download it twice as opposed to only once like they used to do. This is very sad. It is, however, also the right call in the short-term from a privacy & security perspective. In the long-term, maybe we can define web standards that eliminate the privacy & security threats from cross-origin caching for heavily shared resources like fonts.

So, what are the consequences of this change in browser caching behavior? The main change is that font CDNs like Google Fonts and Adobe TypeKit now strictly make your site slower. They used to help with cross-site caching, but that benefit is gone. Instead they add expensive cross-origin requests (and their DNS lookups, TLS negotiations, etc.) into the critical path of loading your website.

With that it is clear that we should self-host all fonts on our primary domain for maximum performance. With fonts this can sometimes be problematic for licensing reasons, etc. but there is a good middle ground: Instead of self-hosting the fonts, self-host the loading code. For all common Font CDNs (even TypeKit with some digging, they default to JS based loading) this is simply a CSS file. Just download that CSS file. It won't bite 😄. Or, if your font provider likes to sometimes change it, just fetch the CSS file once during your build process. Then inline the CSS file into your HTML and you completely eliminate the expensive cross-origin request from your critical path. While this approach still downloads the fonts themselves from the CDNs this doesn't hurt when you are using our friend font-display: optional.

What if I really don't want to use `font-display: optional` #

So, I have a solution for you. It works remarkably well. This is based on an idea/tool by Monica Dinculescu that she published in 2016. It allows tweaking your fallback font such that it uses approximately as much space as the custom font.

This is an awesome idea as it avoids the layout shift issues associated with loading the custom font: With the fallback already taking up the right amount of space, the custom font just swaps back into the same space when it loads.

Tool: Perfect-ish font fallbacks #

My contribution over Monica's idea is that I made a tool that automatically matches the fallback font to the custom font–because computers are good at that stuff. Try it out here.

The tool allows you to select every Google Font from a select menu. If you aren't using a Google Fonts, you can remix this Glitch for a custom solution.

Samples #

The fallback-to-custom-font matching works really well in most cases. Here the left font is the custom font and on the right side is Arial:

However, the whole thing is just an approximation. It definitely happens that things do not match 100%. (The screenshot shows the same text/font as before, but uses a different viewport width). The solution works most of the time. It isn't perfect but better than always having a major layout jump.

Finally, your mileage may vary with more extreme fonts. For very narrow fonts the fallback font may become unreadable. Having said that, for fonts that are commonly used this is not a problem.

Deploying fallback corrections to the website #

Just add CSS like this:

<style>
  /* Make a custom fallback font based on the local Times New Roman */
  @font-face {
    font-family: "CustomFont-fallback";
    size-adjust: 116.19%;
    src: local("Times New Roman");
  }

  /* Set the body to CustomFont, but if it is missing fallback 
  to our bespoke fallback 'CustomFont-fallback'  */
  body {
    font-family: "CustomFont", "CustomFont-fallback";
    /* The value doesn't matter, but you must specify a line-height for all text with custom fonts to avoid CLS */
    line-height: 1.5em;
  }
</style>

…and that is it. This is possible as of July 2021

A new web standard #

With the @font-face property size-adjust a web standard solution is coming for the font-matching problem space. The tool in this article(requires Chrome 92+ or Firefox 92+) here has been updated to rely on size-adjust.

Note, that there are additional related CSS properties ascent-override and descent-override. However, you do not need to worry about these if you set a line-height of any non-default value for all text.

Summary #

Using font-display: optional together with self-hosting the CSS for your web fonts gets you in really good shape with respect to LCP and CLS. However, with new web standards support for size-adjust there is a feasible way to avoid CLS while still always eventually switching to the custom font.

Tools #

This is a list of known technologies and tools implementing all of these optimizations:

New on the web platform in January, 2021

2021-01-13T00:00:00Z

Avoid crashing your node process with unexpected RegExp behavior

Your's truly wrote a blog post over the Holidays

3rd time's a charm

👀

Tightly controlling your 🍪s is the future

Easier URL routing in browsers

AVIF generation is now [trivial](https://www.npmjs.com/package/sharp)

COVID vaccines explained for engineers

Cool/useful hack

We're onto something

🎉🎉🎉🎉

This has now happened

Maximally optimizing image loading for the web

2020-12-28T00:00:00Z

In this post I'll outline 8 image loading optimization techniques to minimize both the bandwidth used for loading images on the web and the CPU usage for image display. I'll present them in the form of an annotated HTML example to make it easy for folks to reproduce the results. Some of these techniques are more established, while others are somewhat novel. Ideally, your favorite mechanism for publishing web documents (like a CMS, static site generator, or web application framework) implements all of these out-of-the-box. I'll keep a list updated at the end of this posts with technologies that provide all of the optimizations outlined here.

Together the techniques optimize all elements of Google's Core Web Vitals by

Minimizing the Largest Contentful Paint (LCP) through reducing bytes, caching, and lazy loading.
Keeping Cumulative Layout Shift (CLS) to zero.
Reducing First Input Delay(FID) through reduced (main-thread) CPU usage.

View the source of this sample image to see all the techniques in action:

Optimization techniques #

Responsive layout #

This is a well understood technique to make an image use the available horizontal space up until its maximum size while retaining the aspect ratio. New in 2020 is that web browsers will reserve the correct vertical space for the image before it loads if the width and height attributes are provided for the img element. This avoids Cumulative Layout Shift (CLS).

<style>
  img {
    max-width: 100%;
    height: auto;
  }
</style>
<!-- Providing width and height is more important than ever. -->
<img height="853" width="1280" … />

Lazy rendering #

The second technique is more cutting edge. The new CSS attribute content-visibility: auto instructs the browser to not bother layouting the image until it gets near the screen. This has all kinds of benefits, but the most important one might be that the browser will not bother decoding our blurry placeholder image or the image itself unless it has to, saving CPU.

Update 01/27/2021 contain-intrinsic-size no longer needed #

An earlier version of this post explained how to use contain-intrinsic-size to avoid CLS impact of content-visibility: auto but as of Chromium 88 this is no longer needed for images that provide width and height as explained above. Other browser engines do not yet (01/27/2021) implement content-visibility: auto and would presumably follow Chromium's lead on this special case. So, yaihh, this is much simpler now!

<style>
  /* This probably only makes sense for images within the main scrollable area of your page. */
  main img {
    /* Only render when in viewport */
    content-visibility: auto;
  }
</style>

AVIF #

AVIF is the most recent image format that has gained adoption in web browsers. It is currently supported in Chromium browsers, and available behind a flag in Firefox. Safari support isn't available yet, but given that Apple is a member of the group that is behind the format, we can expect future support.

AVIF is notable because it very consistently outperforms JPEG in a very significant way. This is different from WebP which doesn't always produce smaller images than JPEG and may actually be a net-loss due to lack of support for progressive loading.

For more info on AVIF encoding and quality settings, check out my dedicated blog post.

To implement progressive enhancement for AVIF, use the picture element.

The actual img element is nested in the picture. This can be quite confusing, because the img is sometimes described as fallback for browsers without picture support but basically the picture element only helps with src selection but has no layout itself. The element that is drawn (and which you style) is the img element.

Until very recently it was relatively difficult to actually encode AVIF images on the server-side, but with the latest version of libraries like sharp it is now trivial.

<picture>
  <source
    sizes="(max-width: 608px) 100vw, 608px"
    srcset="
      /img/Z1s3TKV-1920w.avif 1920w,
      /img/Z1s3TKV-1280w.avif 1280w,
      /img/Z1s3TKV-640w.avif   640w,
      /img/Z1s3TKV-320w.avif   320w
    "
    type="image/avif"
  />
  <!-- snip lots of other stuff -->
  <img />
</picture>

Load the right number of pixels #

You might have noticed the srcset and sizes attributes in the snippet above. Using the w selector it tells the browser which URL to use based on the physical pixels that would be used if the image was drawn to the user's device given the width calculated from the sizes attribute (which is a media query expression).

With this the browser will always download the smallest possible image that provides the best image quality for the user. Or it may select a smaller image if, for example, the user has opted into some kind of data-saving mode.

Fallbacks #

Provide more source elements with srcsets for browsers that only support legacy image formats.

<source
  sizes="(max-width: 608px) 100vw, 608px"
  srcset="
    /img/Z1s3TKV-1920w.webp 1920w,
    /img/Z1s3TKV-1280w.webp 1280w,
    /img/Z1s3TKV-640w.webp   640w,
    /img/Z1s3TKV-320w.webp   320w
  "
  type="image/webp"
/>
<source
  sizes="(max-width: 608px) 100vw, 608px"
  srcset="
    /img/Z1s3TKV-1920w.jpg 1920w,
    /img/Z1s3TKV-1280w.jpg 1280w,
    /img/Z1s3TKV-640w.jpg   640w,
    /img/Z1s3TKV-320w.jpg   320w
  "
  type="image/jpeg"
/>

Caching / Immutable URLs #

Embed a hash of the bytes in the image in the URL of the image. In the examples above I'm doing that with the Z1s3TKV in the image URLs. That way the URL will change if the image changes and respectively you can apply infinite cache expiration for your images. You want your caching headers to look something like this cache-control: public,max-age=31536000,immutable.

immutable is the semantically correct cache-control value, but unfortunately it isn't widely supported in browsers (I'm looking at you, Chrome). max-age=31536000 is the fallback to cache for a year. public is important to allow your CDN to cache the image and deliver it from the edge. But only use that if it is appropriate from a privacy perspective.

Lazy loading #

Adding loading="lazy" to the img instructs the browser to only start fetching the image as it gets closer to the screen and is likely to actually be rendered.

<img loading="lazy" … />

Asynchronous decoding #

Adding decoding="async" to the img gives the browser permission to decode the image off the main thread avoiding user impact of the CPU-time used to decode the image. This should have no discernible downside except that it cannot always be the default for legacy reasons.

<img decoding="async" … />

Blurry placeholder #

A blurry placeholder is an inline image that provides the user some notion of the image that will load eventually without requiring fetching bytes from the network.

Some notes on the implementation provided here:

It inlines the blurry placeholder as a background-image of the image. This avoids using a second HTML element and it naturally hides the placeholder when the image loads, so that no JavaScript is needed to implement this.
It wraps the data URI of the actual image in a data URI of a SVG image. That is done because the blurring of the image is done at the SVG level instead of through a CSS filter. The result is that the blurring is only performed once per image when the SVG is rasterized, instead of on every layout saving CPU.

<img
  style="
      …
      background-size: cover;
      background-image: 
        url('data:image/svg+xml;charset=utf-8,%3Csvg xmlns=\'http%3A//www.w3.org/2000/svg\'
        xmlns%3Axlink=\'http%3A//www.w3.org/1999/xlink\' viewBox=\'0 0 1280 853\'%3E%3Cfilter id=\'b\' color-interpolation-filters=\'sRGB\'%3E%3CfeGaussianBlur stdDeviation=\'.5\'%3E%3C/feGaussianBlur%3E%3CfeComponentTransfer%3E%3CfeFuncA type=\'discrete\' tableValues=\'1 1\'%3E%3C/feFuncA%3E%3C/feComponentTransfer%3E%3C/filter%3E%3Cimage filter=\'url(%23b)\' x=\'0\' y=\'0\' height=\'100%25\' width=\'100%25\' 
        xlink%3Ahref=\'data%3Aimage/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAkAAAAGCAIAAACepSOSAAAACXBIWXMAAC4jAAAuIwF4pT92AAAAs0lEQVQI1wGoAFf/AImSoJSer5yjs52ktp2luJuluKOpuJefsoCNowB+kKaOm66grL+krsCnsMGrt8m1u8mzt8OVoLIAhJqzjZ2tnLLLnLHJp7fNmpyjqbPCqLrRjqO7AIeUn5ultaWtt56msaSnroZyY4mBgLq7wY6TmwCRfk2Pf1uzm2WulV+xmV6rmGyQfFm3nWSBcEIAfm46jX1FkH5Djn5AmodGo49MopBLlIRBfG8yj/dfjF5frTUAAAAASUVORK5CYII=\'%3E%3C/image%3E%3C/svg%3E');
    "
  …
/>

(Optional-ish) JavaScript optimization #

Browsers may feel obliged to rasterize the blurry placeholder even if the image is already loaded. By removing it on image load, we solve that problem. Also, if your images contain transparency, then this is actually not optional as otherwise the placeholder would shine through.

<script>
  document.body.addEventListener(
    "load",
    (e) => {
      if (e.target.tagName != "IMG") {
        return;
      }
      // Remove the blurry placeholder.
      e.target.style.backgroundImage = "none";
    },
    /* capture */ true
  );
</script>

Tools #

This is a list of known technologies and tools implementing all of these optimizations:

If you know of a technology (can be a combination of multiple "modules" or similar if they work well together) that should be on this list, please ping me.

New on the web platform in December, 2020

2020-12-15T00:00:00Z

Best use of your time today

#

Baseline import maps. No differential loading yet

Partioned caches in all browsers

getUserMedia in WebKit!

Finally!

Preload in Firefox (Finally!!)

:not(:not(aspect-ratio))

Privacy-preserving prefetch experiment

New on the web platform in November, 2020

2020-11-18T00:00:00Z

Happy-ending for WASM team after Mozilla layoffs

Incredible attack

…and the mitigation

Hell freezing over

PX launch date

RIP `Webmaster`

RIP H2 Push

New on the web platform in October, 2020

2020-10-21T00:00:00Z

Auto-upgrade of mixed content

Interesting blurry-image technique

Also available on Android

RIP FTP

#

You don't know HTML

New ways to not need 3P 🍪s

Web Stories in Discover

Aspect-ratio CSS is shipping in Chrome

New on the web platform in September, 2020

2020-09-23T00:00:00Z

Now only the tooling needs to catch up

What devs want

WordPress Web Stories editor launched

Worth the copy-paste

API for whether doing work now is OK

Safari 14 is here

Debug iOS browsers from MacOS/Windows

I made something

Focus is our friend

Filter the worst ads

content-visibility is the most important Web API of our time

#

Easy way to get on top of Chrome releases

Monthly-ish IE update

Fast page labeling in Chrome Beta

A high-performance blog template for 11ty

2020-09-01T00:00:00Z

I'm excited to announce the beta-release of eleventy-high-performance-blog–a high-performance blog template for 11ty based on this very website. The template itself is based on the awesome eleventy-base-blog adding features centered around performance, accessibility and some SEO.

Sites based on this template achieve 100 points on Lighthouse in the categories Performance, Accessibility, Best Practices, and SEO by default. Field-test performance in Largest Contentful Paint, Cumulative Layout Shift, is First Input Delay is very well into the green area of Core Web Vitals given standard server performance.

This website which is using the same template recently ranked #2 on the Eleventy Speed Leaderboard.

Get started!

Features #

Performance optimizations #

Images #

Transcodes images to AVIF (the latest widely supported next-gen image codec) and webp and generates picture element.
Transcodes GIFs to muted looping autoplaying MP4 videos for greatly reduced file size.
Generates multiple sizes of each image and uses them in srcset.
Generates a blurry placeholder for each image (without adding an HTML element or using JS).
Lazy loads images (using native loading=lazy).
Async decodes images (using decoding=async).
Lazy layout of images and placeholders using content-visibility: auto.
Avoids CLS impact of images by inferring and providing width and height (Supported in Chrome, Firefox and Safari 14+).
Downloads remote images and stores/serves them locally.
Immutable URLs.

CSS #

Defaults to the compact "classless" Bahunya CSS framework.
Inlines CSS.
Dead-code-eliminates / tree-shakes / purges (pick your favorite word) unused CSS on a per-page basis with PurgeCSS.
Minified CSS with csso.

Miscellaneous #

Immutable URLs for JS.
Sets immutable caching headers for images, fonts, and JS (CSS is inlined). Currently implements for Netflify _headers file.
Minifies HTML and optimizes it for compression. Uses html-minifier with aggressive options.
Uses rollup to bundle JS and minifies it with terser.
Prefetches same-origin navigations when a navigation is likely.
If an AMP files is present, optimizes it.

Fonts #

Serves fonts from same origin.
Preloads fonts.
Makes fonts display:optional.

Analytics #

Supports locally serving Google Analytics's JS and proxying it's hit requests to a Vercel Edge Function proxy (other proxies could be easily added).
Support for noscript hit requests.
Avoids blocking onload on analytics requests.

DX features #

Uses 🚨 as favicon during local development.
Supports a range of default tests.
Runs build and tests on git push.
Sourcemap generated for JS.

Share button prefering navigator.share() and falling back to Twitter. Using OS-like share-icon.
Support for OGP metadata.
Support for Twitter metadata.
Support for schema.org JSON-LD.
Sitemap.xml generation.

Largely useless glitter #

Read time estimate.
Animated scroll progress bar…
…with an optimized implementation that should never cause a layout.

Security #

Generates a strong CSP for the base template.

Default-src is self.
Disallows plugins.
Generates hash based CSP for the JS used on the site.

Getting started #

Hop on over to GitHub.

New on the web platform in August, 2020

2020-08-12T00:00:00Z

MDN and Servo teams among those layed off

Same-site cookies in Chrome to 100%

Be in the DOM, but not rendered, but take space

WebGL2 in Safari

Full referrers are now opt-in in Chrome

Choose and fund your favorite browser feature

Web Stories are exciting!

Strict-Soy as a web standard

New on the web platform in July, 2020

2020-07-08T00:00:00Z

I wrote a thing

We're continuing to fund browser compat

WYSIWYG is coming back to the web!

Related to previous entry

WeakRefs!

We can't have nice things 😿

Some nice things

But they will stilll be WebKit wrappers

Design Docs at Google

2020-07-06T00:00:00Z

One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-offs that were considered during those decisions.

As software engineers our job is not to produce code per se, but rather to solve problems. Unstructured text, like in the form of a design doc, may be the better tool for solving problems early in a project lifecycle, as it may be more concise and easier to comprehend, and communicates the problems and solutions at a higher level than code.

Besides the original documentation of a software design, design docs fulfill the following functions in the software development lifecycle:

Early identification of design issues when making changes is still cheap.
Achieving consensus around a design in the organization.
Ensuring consideration of cross-cutting concerns.
Scaling knowledge of senior engineers into the organization.
Form the basis of an organizational memory around design decisions.
Acts as a summary artifact in the technical portfolio of the software designer(s).

Anatomy of a design doc #

Design docs are informal documents and thus don’t follow a strict guideline for their content. Rule #1 is: Write them in whatever form makes the most sense for the particular project.

Having said that, a certain structure has established itself as really useful.

Context and scope #

This section gives the reader a very rough overview of the landscape in which the new system is being built and what is actually being built. This isn’t a requirements doc. Keep it succinct! The goal is that readers are brought up to speed but some previous knowledge can be assumed and detailed info can be linked to. This section should be entirely focused on objective background facts.

Goals and non-goals #

A short list of bullet points of what the goals of the system are, and, sometimes more importantly, what non-goals are. Note, that non-goals aren’t negated goals like “The system shouldn’t crash”, but rather things that could reasonably be goals, but are explicitly chosen not to be goals. A good example would be “ACID compliance”; when designing a database, you’d certainly want to know whether that is a goal or non-goal. And if it is a non-goal you might still select a solution that provides it, if it doesn’t introduce trade-offs that prevent achieving the goals.

The actual design #

This section should start with an overview and then go into details.

The design doc is the place to write down the trade-offs you made in designing your software. Focus on those trade-offs to produce a useful document with long-term value. That is, given the context (facts), goals and non-goals (requirements), the design doc is the place to suggest solutions and show why a particular solution best satisfies those goals.

The point of writing a document over a more formal medium is to provide the flexibility to express the problem set at hand in an appropriate manner. Because of this, there is no explicit guidance for how to actually describe the design.

Having said that, a few best practices and repeating topics have emerged that make sense for a large percentage of design docs:

System-context-diagram #

In many docs a system-context-diagram can be very useful. Such a diagram shows the system as part of the larger technical landscape and allows readers to contextualize the new design given its environment that they are already familiar with.

Example of a system-context-diagram.

APIs #

If the system under design exposes an API, then sketching out that API is usually a good idea. In most cases, however, one should withstand the temptation to copy-paste formal interface or data definitions into the doc as these are often verbose, contain unnecessary detail and quickly get out of date. Instead focus on the parts that are relevant to the design and its trade-offs.

Data storage #

Systems that store data should likely discuss how and in what rough form this happens. Similar to the advice on APIs, and for the same reasons, copy-pasting complete schema definitions should be avoided. Instead focus on the parts that are relevant to the design and its trade-offs.

Code and pseudo-code #

Design docs should rarely contain code, or pseudo-code except in situations where novel algorithms are described. As appropriate, link to prototypes that show the implementability of the design.

Degree of constraint #

One of the primary factors that would influence the shape of a software design and hence the design doc, is the degree of constraint of the solution space.

On one end of the extreme is the “greenfield software project”, where all we know are the goals, and the solution can be whatever makes the most sense. Such a document may be wide-ranging, but it also needs to quickly define a set of rules that allow zooming in on a manageable set of solutions.

On the other end are systems where the possible solutions are very well defined, but it isn’t at all obvious how they could even be combined to achieve the goals. This may be a legacy system that is difficult to change and wasn’t designed to do what you want it to do or a library design that needs to operate within the constraints of the host programming language.

In this situation you may be able to enumerate all the things you can do relatively easily, but you need to creatively put those things together to achieve the goals. There may be multiple solutions, and none of them are really great, and hence such a document should focus on selecting the best way given all identified trade-offs.

Alternatives considered #

This section lists alternative designs that would have reasonably achieved similar outcomes. The focus should be on the trade-offs that each respective design makes and how those trade-offs led to the decision to select the design that is the primary topic of the document.

While it is fine to be succinct about solution that ended up not being selected, this section is one of the most important ones as it shows very explicitly why the selected solution is the best given the project goals and how other solutions, that the reader may be wondering about, introduce trade-offs that are less desirable given the goals.

Cross-cutting concerns #

This is where your organization can ensure that certain cross-cutting concerns such as security, privacy, and observability are always taken into consideration. These are often relatively short sections that explain how the design impacts the concern and how the concern is addressed. Teams should standardize what these concerns are in their case.

Due to their importance, Google projects are required to have a dedicated privacy design doc, and there are dedicated reviews for privacy and security. While the reviews are only required to be completed by the time a project launches, it is best practice to engage with privacy and security teams as early as possible to ensure that designs take them into account from the ground up. In case of dedicated docs for these topics, the central design doc can, of course, reference them instead of going into detail.

The length of a design doc #

Design docs should be sufficiently detailed but short enough to actually be read by busy people. The sweet spot for a larger project seems to be around 10-20ish pages. If you get way beyond that, it might make sense to split up the problem into more manageable sub problems. It should also be noted that it is absolutely possible to write a 1-3 page “mini design doc”. This is especially helpful for incremental improvements or sub tasks in an agile project–you still do all the same steps as for a longer doc, just keep things more terse and focused on a limited problem set.

When not to write a design doc. #

Writing design docs is overhead. The decision whether to write a design doc comes down to the core trade-off of deciding whether the benefits in organizational consensus around design, documentation, senior review, etc. outweigh the extra work of creating the doc. At the center of that decision lies whether the solution to the design problem is ambiguous–because of problem complexity or solution complexity, or both. If it is not, then there is little value in going through the process of writing a doc.

A clear indicator that a doc might not be necessary are design docs that are really implementation manuals. If a doc basically says “This is how we are going to implement it” without going into trade-offs, alternatives, and explaining decision making (or if the solution is so obvious as to mean there were no trade-offs), then it would probably have been a better idea to write the actual program right away.

Finally, the overhead of creating and reviewing a design doc may not be compatible with prototyping and rapid iteration. However, most software projects do have a set of actually known problems. Subscribing to agile methodologies is not an excuse for not taking the time to get solutions to actually known problems right. Additionally, prototyping itself may be part of the design doc creation. “I tried it out and it works” is one of the best arguments for choosing a design.

The design doc lifecycle #

The steps in the lifecycle of a design document are:

Creation and rapid iteration
Review (may be in multiple rounds)
Implementation and iteration
Maintenance and learning

Creation and rapid iteration #

You write the doc. Sometimes together with a set of co-authors.

This phase quickly evolves into a time of rapid iteration where the doc is shared with colleagues who have the most knowledge about the problem space (often belonging to the same team) and through their clarifying questions and suggestions drive the doc to a first relatively stable version.

While you certainly find engineers and even teams who prefer version control and code review tools for document creation, the vast majority of design docs at Google are created in Google Docs and make heavy use of its collaboration features.

Review #

In the review phase a design doc gets shared with a wider audience than the original set of authors and close collaborators. Reviews can add a lot of value, but they are also a dangerous trap of overhead, so treat them wisely.

A review can take many shapes: The more lightweight version is simply sending out the doc to the (wider) team-list to give folks a chance to take a look. Discussion then primarily happens in comment threads in the document. On the heavy side of reviews, are formal design review meetings in which the author presents the doc (often via a dedicated presentation) to an often very senior engineering audience. Many teams at Google have recurring meetings scheduled for this purpose to which engineers can sign up to for a review. Naturally waiting for such meetings to happen can significantly slow down the development process. Engineers can mitigate this by seeking the most crucial feedback directly and not blocking progress on wider review.

When Google was a smaller company, it was customary to send designs to a single central mailing list, where senior engineers would review them at their own leisure. This may very well be a great way to handle things for your company. One benefit was that it did establish a relatively uniform software design culture across the company. But as the company scaled to a much larger engineering team, it became infeasible to maintain the centralized approach.

The primary value that such reviews add is that they form an opportunity for the combined experience of the organization to be incorporated into a design. Most consistently, ensuring that designs take cross-cutting concerns such as observability, security and privacy into account is something that can be ensured in a review stage. The primary value of the review isn’t that issues get discovered per-se, but rather that this happens relatively early in the development lifecycle when it is still relatively cheap to make changes.

Implementation and iteration #

When things have progressed sufficiently to have confidence that further reviews are unlikely to require major changes to the design, it is time to begin implementation. As plans collide with reality, it is inevitable that shortcomings, unaddressed requirements, or educated guesses that turned out to be wrong surface, and require changing the design. It is strongly recommended to update the design doc in this case. As a rule of thumb: If the designed system hasn’t shipped yet, then definitely update the doc. In practice we humans are bad at updating documents, and for other practical reasons changes are often isolated into new documents. This leads to an eventual state more akin to the US constitution with a bunch of amendments rather than one consistent piece of documentation. Links to such amendments from the original doc can be immensely helpful for the poor future maintenance programmer trying to understand their target system through design doc archaeology.

Maintenance and learning #

When Google engineers get confronted with a system that they hadn’t previously touched their first question often is “Where is the design doc?”. While design docs, like all documentation, tend to get out of sync with reality over time, they still often present the most accessible entry point to learn about the thinking that guided the creation of the system.

As the author, do yourself a favor and re-read your own design docs a year or 2 later. What did you get right? What did you get wrong? What would you do to decide differently today? Answering these questions is a great way to advance as an engineer and improve software design skills over time.

Conclusions #

Design docs are a great way to gain clarity and achieve consensus around solving the hardest problems in a software project. They save money, because they avoid going down coding rabbit holes that fail to achieve project goals and could have been avoided using upfront investigation; and they cost money, because creation and review take time. So, choose wisely for your project!

When considering writing a design doc, think about these points:

Are you unsure about the right software design, and would it make sense to spend upfront time to gain certainty?
Relatedly, would it help to involve senior engineers, who might not be able to review every code-change, in the design?
Is the software design ambiguous or even contentious such that achieving organizational consensus around it would be valuable?
Does my team sometimes forget to consider privacy, security, logging or other cross-cutting concerns in the design?
Is there a strong need for documents that provide high-level insights into the design of legacy systems in the organization?

If you answer yes to 3 or more of these questions, then a design doc is probably a great method to start your next software project.

Design docs – A design doc

New on the web platform in June, 2020

2020-06-08T00:00:00Z

Intentionally left Black

Core Web Vitals as a ranking factor in Google

Modern-ish form styles in Chrome

Core Web Vitals correlate with business success

Very few ads use a huge percentage of resources

Hell freezing over: aspect-ration in CSS

#

New on the web platform in May, 2020

2020-05-08T00:00:00Z

What would you do with 4GB of RAM?

Core Web Vitals = LCP + CLS + FID

RFC: WebBundles

Blink is prototyping a virtual keyboard API

Staying still is a regression

Be nice online

April 17, 2020

AV1 based image format

#

New on the web platform in April, 2020

2020-04-08T00:00:00Z

🤯

Reducing extra-disruption due to COVID

#

Won't be missed

Safari: 3P cookies gone for good. Client-side storage flaky

Microsoft buys the rest of the JS ecosystem

The creators of WebRTC are modern day heros!

New on the web platform in March, 2020

2020-03-08T00:00:00Z

Lighthouse is updating to modern metrics

Major new a11y features in DevTools

On my own behalf

The concept GIF > The GIF format

🍺🦠

Designing Even Larger Applications

2020-02-16T00:00:00Z

This is a mildly edited transcript of my JSConf Hawaiʻi talk (video).

Hey everyone! My name is Malte, I’m a Principal Software Engineer at Google, and today I want to talk about Designing Even Larger Applications. This is a sequel to a talk I gave at JSConf Australia two years ago. And just like last time, I want to kind of ground this talk in our career progression as software engineers. I think many of you in the audience would call yourself senior engineers; or, if you’re not there yet, you aspire to be one.

The way I would describe what it means to be a senior engineer is that if someone comes to me and they say something like “Hey, Malte, do this project in this domain that you are already familiar with”, I would say “Yeah, that is actually something I know how to do. I don’t need to get anyone else’s help”.

In my last talk I looked at how to go beyond that level of seniority in software engineering. It stops being only about yourself and instead your craft starts impacting other engineers. You’d say “I can anticipate how others do things and design APIs accordingly.”

In this talk I want to go yet one more level beyond that. I want to reach the stage where I can say, “I can design software such that for large groups of engineers the probability increases that the software that they produce is good.”

There are three key words in this statement.

First of all, large groups of engineers. If you work at a startup or a three-person company, then this talk may seem superfluous and boring. But I think many of you may work for insurance companies, banks, agencies, big tech, etc.–companies big enough that you have a bunch of folks and multiple teams and you need to coordinate stuff.
Next I’m talking about probability. There is no certainty here. You can only try to set things up so that they are likely to work. But there are no guarantees. There is no silver bullet.
The third key word is good. This is not a product management talk. This is not a talk that will not help you write the right program, but it will help you write that program well. What I mean is it being maintainable, high-performance, having low bug-density, being delivered on-time, etc.

I want to clarify one more thing: I’m going to say the words framework and software infrastructure a lot. I treat them kind of interchangeably. What I mean is software that helps us build better software. For this talk, I would like you all to kind of put your mind into you being the person in your company who is responsible for defining how people write software and, then, build the infrastructure that they’re using to write software. And when I say, you build a framework, I don’t mean that you necessarily make your own React or Angular. Instead I think whenever you have a set of teams you want to kind of standardize how they build applications. So, you put a literal framework around it.

Again, think about you being the person who is responsible for your team’s software infrastructure. This is a talk about how to make you successful at that job. And I’m going to talk about that in three chapters.

The first one I call understanding the degree of uncertainty
…and then we’re going to learn how to solve all known problems.
Finally, we’re going to learn about deploying change.

Understanding the degree of uncertainty #

How certain are we about the type of problems that we will need to solve in the future? This question is absolutely key for software engineering and I’m going to talk about a technique to understand how well we understand things.

What we’ll do is try to answer a set of questions:

What is it in the existing infrastructure that users struggle with and how are they struggling with it?
What is the class of applications that folks will build using your work in broad terms?
What are the trends that influence the industry and how do those trends influence the software that folks are probably going to write in the future?

All of these may sound a bit like reading the tea leaves but I think that with a bit of experience there are many scenarios where you can actually answer them quite well. The key in this exercise is really to observe how easy or hard it is to answer the questions.

If it is really easy and you write it down and everything is clear, then you have a low degree of uncertainty. If, however, you actually have no idea how to answer, then you have a high degree of uncertainty.

Even more powerful than knowing what it is that you need to do is knowing what you don’t need to do. Those are the non-goals.

What are non-goals? It is not a non-goal if you’re working for a software company to say “I don’t need to design surfboards”. That is not a non-goal, that is just ridiculous. Of course, you don’t want to do this. A non-goal is something that is actually super reasonable and even likely that you want to do it but you know you don’t need to do it (like “I need to support low-end devices”). If you can easily define your non-goals, you know that your degree of uncertainty is even lower.

So, why is it important for the degree of uncertainty to be low? When uncertainty is high you’re going to have to make tradeoffs and be flexible. You may think “I might need to support this special case so I better make sure that it would be possible”. You likely need to make a tradeoff to enable that special case. And the problem with tradeoffs is that they make stuff complex and less than ideal because you have to find the balance between conflicting concerns.

Things really get unpleasant when a high degree of uncertainty leads you to make an unnecessary tradeoff.

Let’s look at an example: imagine you’re building infrastructure for internal mobile apps at your company and maybe the salespeople all have old phones with low memory. Based on this you design things such that they work on low memory devices. But then your company goes out and buys everyone fancy new phones. All your work to support low-end devices was unnecessary, and even worse it probably made the software more complex in the future as well. Interestingly this is a generalization of Donald Knuth’s “premature optimization is the root of all evil”. Premature optimization is a special case of an unnecessary tradeoff. Every time you design your software for something it didn’t really need to support that is likely an unnecessary tradeoff.

This talk is being held at a web development conference, so I wanted to have one section on web development. We as a community have been building web frameworks for a few years. Over 20 years now. We actually understand how to build web frameworks really well. The degree of uncertainty for what people want to do with web frameworks is really low.

Compare that to this scenario: imagine it is 2015 and your manager comes and says “I want you to build infrastructure for deep learning”. You’re like, well, I have never done this before. No one in my company has done it before. There are like literally three blog posts on the topic in total. The degree of uncertainty is really high. You won’t be able to build infrastructure that is quite as nice as a web framework in 2020.

Dealing with uncertainty #

And so the question is: what do we do if the degree of uncertainty is very high? We tailor the degree of abstraction.

Let me get something out of the way: abstractions are awesome. You want to abstract everything as much as possible because abstractions make everything really expressive, more correct, reusable, and generally, more awesome. However, things rapidly fall apart if the abstractions don’t quite allow us to do exactly what we’d like to do. We now have to work around it and beat them into doing what we want. Everything is suddenly painful and terrible.

That is why we need to understand the problem space really well: It allows us to tailor the abstraction to the degree of uncertainty. And if uncertainty is high then we reduce the degree of abstraction.

Solving all known problems #

Every software project is going to have some degree of uncertainty. And so it is useful to have a set of techniques in our back pocket that are always good–no matter how uncertain we are: we’ll solve all known problems of software engineering.

Iteration velocity #

The first technique is optimizing iteration velocity. What I mean is: you write some code and hit save in your editor–how long does it take to go from that moment until you find out whether it was a good change? You might have super awesome hot code reloading and everything updates instantly like magic or you may need to manually kill your Java application server, recompile, and restart the server which takes like 20 minutes. I think many of us have probably been somewhere in between these two extremes.

Slow iteration cycles actually introduce tradeoffs into our software design. If it takes a long time to find out that you made a mistake then as a software designer, the professional thing to do is to then go and say “I have to design this API so that no one can ever get it wrong”. If on the other hand everything is super fast and folks can figure things out iteratively because the cost of failure is so low, then you as a designer of that API can say, maybe it is fine for people to do a little bit more exploring here.

Debuggability #

Next is debuggability. As a framework author we actually have a strong influence on how hard it is to debug a system. Maybe you designed this awesome but complex black box state machine that no one can figure out. Maybe your stack traces are super long and confuse people. Or maybe you put in a sensible logging and tracing system and people understand what is going on. They make a mistake, they debug it, they fix it. No problem.

Testability #

Similar to the debuggability you’re in control of how testable a system is. Maybe your framework makes it really hard to instantiate things to be in a given state that can be tested? Or you make that really easy. Folks will write more tests, have higher confidence, and be a happier customer of your framework.

Empathy #

For the last technique to solve all known problems of software engineering we’ll move a little bit away from the pure software side of things. We’ll talk about empathy.

And like I mentioned in my last talk: As a software engineer having empathy with other software engineers is empathy in easy mode. Our intuition for how a software engineer feels about something is much more likely to be correct than with a random person where we know little about their background. Today I want to talk about a very special aspect of empathy: You as the designer of framework could build the perfect application with it. You know everything about it. You can get everything right. But every other person who uses your framework will know less about it.

So, think about what it means to not know everything about your framework. And how you can make the framework be robust in the presence of such not-all-knowing users.

Deploying change #

Now that we have learned to solve all known problems of software engineering, let’s go to the final chapter which is deploying change.

This part is really, really key. Software infrastructure, no matter how great it is, if it has no users then it has no impact. However, in this field it is incredibly common that people build ivory towers with no real users in mind. They build something they’re excited about, and it was probably really fun to build. And then they come and say “Hey, I have a thing” and you’re like “But that thing doesn’t do what I need” and everyone is sad and they move on to build the next ivory tower.

If you want to professionalize building software infrastructure then this is obviously not the right way to do it. Getting your stuff adopted is everything. It is a big part of your job. So much so that my first piece of advice on how to get this right is actually totally in the realm of marketing.

Software engineers are human beings. They want to work on stuff that they think is cool and that they’ve heard about on Twitter (Think “Serverless”, “Machine Learning”, “Virtual DOM”, $HypedThingOfTheYear). I think it is fine to sprinkle some of that glitter into your framework. As long as it isn’t the worst unnecessary tradeoff in the world. Everyone will be a little happier and no harm is done. That was the marketing portion of this talk. Let’s go to a bit more serious topic.

Incremental adoption #

Adopting software is easier if you can do it incrementally. What this means is that instead of going like “Hey, try this new framework, rewrite everything from scratch in two years and hopefully it is good”, you migrate smaller parts step by step–and thus you see positive impact long before that 2 year full rewrite. What I’ve seen is that even projects that start out as a full rewrite will often pivot to ship at least a few parts early as the pressure from essentially having to do double-work (maintaining the legacy system and building the new one) increases and management wants to see results.

The path to incremental adoption, however, can be difficult for the framework designer. The following techniques have been proven to work in such scenarios.

Legacy composition #

The first technique is really simple and comes in two parts.

The first is composition of your new framework code into legacy code: Let’s say you haven’t gotten around to rewriting the app shell yet. The app is still built on the old architecture. But then the team comes and says, “I’m going to build that new feature based on the new framework and put it into that old code base”. That is composition of new code into legacy code.
And then there is the other side which is composition of legacy code into your new code base. Let’s say you have this super ultra-customized component, a jQuery date picker, and people want to keep it, right? And so you design your framework such that the jQuery thing, which probably violates all the assumptions you ever made, still works in your new code base. That is composition of legacy code into new code.

Both of these strategies put tradeoff pressure on your system because suddenly all these assumptions are no longer valid. But the tradeoff is probably worth it because it allows people to incrementally adopt your software.

Temporary imperfection #

The second technique is what I call temporary imperfection. As a framework author, you probably have this really idealized view of the world how people build software using your framework. But then it comes crashing down in the process of incremental adoption because not everything is ideal at all, but rather an entangled mess of old and new code.

My advice would be to do the following: Write a literal lint rule using a tool like ESLint that identifies the old way of doing something. And then when there is code in the code base that is not written to the new way, you get an error message. Hopefully the error message also says something helpful like “This is no longer the right way of doing it. Here are pointers to documentation for how to do it right”.

Step two is to then go and allow all existing violations using an allow-list. With that you’re in a position where no code is fixed, but where all new code has to comply with the new way of doing things. And this is really powerful because there might be all these engineers in the organization who have not read the email where they were told they need to do something differently. Now they get an error message and will just turn around and fix it.

A ledger of technical debt #

There is one more interesting insight. This allow-list which you check into your repository is, in fact, a ledger of technical debt. Technical debt can be this abstract concept that you know you have. It is probably out there somewhere but it is really difficult to nail down where it is. The ledger allows you to literally know that file X.js, line 15 has technical debt in it.

Knowing where the technical debt is, is the first step to paying it off. You can e.g. have a team fix-it where all you do is make the allow-list shorter. I think that is a powerful way to make tech debt very concrete just like debt from your bank account.

Automated migration #

The next technique is to enable automated migration. It is not going to get you all the way but it is pretty powerful. Tools like codemod from Facebook can help with such a process. You declare how to go from A to B and the computer does the rest of the work. It is great.

As many things in this talk, designing for automated migration puts tradeoff pressure on your new API because now your new API must ideally only require information that is already available in the existing codebase. But it might be worth it because no one has to do that work manually and it is going to make people more happy than having to do everything by hand.

Customer Zero #

Let’s talk a little bit more about humans. The one thing I would like everyone to take away from this talk is that when you’re in this role of being the person responsible for the software infrastructure, you always need a customer zero. Your customer zero is the antidote to the ivory tower. They are your first customer and you’ll be helping them to build a real product.

What you need to do is go and literally write their software with them–become part of their team. This is all happening before you declare your framework to be shippable because in this step you can actually validate your assumptions. You can find corner cases and you can iterate on your framework until it is actually good. This first customer should not be a migration. It should be something that you built from scratch. Because migrations are always going to be somewhat painful and long winding and you really don’t want to migrate to something that hasn’t been proven to be good.

One of the ironies of being an infrastructure engineer is that you rarely build anything with your infrastructure yourself. That makes it really difficult to actually write the documentation for how to get started with your infra. If you go and have a customer zero and you work with them, that is the best chance you get to write that onboarding doc for everyone who comes after. Don’t miss the chance!

Actually finding a customer zero can be challenging in large organizations. You might not find the team that is cool with working with an unstable framework that might be pretty bad. I’ve found a few arguments that work well to convince a team to be your customer zero:

There is typically a team that likes to be on the cutting edge. One of the things that you can pitch is to say “Hey, you’ll eventually have to migrate to this because it is the future stack everyone will have to use. Why don’t you want to be on the new thing already and skip that migration?”. That could be very attractive for a team. And you can argue that because you’re actually going to work with the team, they are going to get a framework tailor made for them–as opposed to everyone else who will have to make do with what is there.
If that pitch doesn’t work, you’ll have to move on to harsher tactics. In that case the organization has to be mature enough to accept that you’ll have to have a mandate. Someone will have to decide which team is going to be customer zero and they’ll have to accept it. Because the alternative is that you’d build an ivory tower. And that would be bad for everybody, not just that one team.

Migration Zero #

Eventually we’ll have to do a first migration of an existing code base to our new infra. Once again it is actually your job to do this migration yourself. That is because your framework might not actually be a great migration target yet. Let’s assume your framework is at point B and some project is at point A. It might be super hard to go from A to B. Any given team would probably just go ahead and do it anyway. But you as the author of the framework might see chances to slightly change that point B such that it is easier to get there. And because you’re a lazy person, you’re going to make that migration really easy and that is going to help everyone that comes after you have a much better time.

Summary #

These were the three things that I wanted to talk about. Just let me summarize really quickly:

The first thing that we need to do is to understand the degree of uncertainty and then tailor the degree of abstraction respectively.
Even if uncertainty is high, we want to solve all known problems: Increase iteration velocity, make things debuggable, testable and practice our empathy with a focus on what folks might not know.
And then finally, nothing here matters if you don’t focus on team adoption. Make your software likable, focus on incremental adoption, make a ledger of technical debt, and get that customer and migration zero done.

That is all I have today. Thank you very much.

Malte Ubl, 2020

Thanks to Esther, Ryan, and Jan for helping me copy-edit my verbal mess 🤣

New on the web platform in February, 2020

2020-02-08T00:00:00Z

Lazy loading merged into HTML

#

Flash device via WebUSB 🤯

Igalia did this as part of our sponsorship

Performance assumptions will break

#

New on the web platform in January, 2020

2020-01-08T00:00:00Z

Edge-ium is launching today

Chrome is deprecating the UA string

…and 3P cookies

Desktop hover detection leads to click delay in mobile Safari

New on the web platform in December, 2019

2019-12-08T00:00:00Z

An actual new browser engine

Debugging FB Browser

Scroll to fragment

ITP as an attack vector

V8 8.0

New on the web platform in November, 2019

2019-11-08T00:00:00Z

API freedom after all?

A rare, unexploitable XSS in AMP

Intent to prototype

Discover is being discovered

Speed metrics in Search Console

New on the web platform in October, 2019

2019-10-08T00:00:00Z

Site isolation on Android

Apparently the answer is: Yes

#

Align animations with video frame rate

Ultimate XSS protection

Aspect ratio inference outside of AMP!

Preload can now also pre-compile

New on the web platform in September, 2019

2019-09-08T00:00:00Z

Responsive images

Accelerometer on iOS

Death to smart quotes

#

HTTP3

Bundled Signed Exchanges

How long is this string? 💩

Reducing SPA pain

New on the web platform in August, 2019

2019-08-08T00:00:00Z

Perf cliffs are real

Privacy Sandbox in Chrome

JS in AMP launched

#

JSON is a valid subset of JS

Pre-rendering works!

WebAuthN is a thing

LCP is shipping

New on the web platform in July, 2019

2019-07-08T00:00:00Z

A better allow-same-origin

Everything seems to be working

SWR is actually here

WeakRefs in V8

New on the web platform in June, 2019

2019-06-08T00:00:00Z

iOS13 unbreaks overflowed scrolling

Federated alternative to npm announced

#

New layout engine in chrome

New FCP alternative

New on the web platform in May, 2019

2019-05-08T00:00:00Z

Don't forget the wetsuit

Portals behind a flag announced at IO

Cookies in Chrome same-site by default

IE11 in Edge

#

No more flash of white

New on the web platform in April, 2019

2019-04-08T00:00:00Z

I wrote a blog post

Work we're funding in WebKit is landing

Performance ranking is making a difference

OMG, native lazy-loading

#

#

#

Designing very large (JavaScript) applications

2018-04-15T00:00:00Z

This is a mildly edited transcript of my JSConf Australia talk. Watch the whole talk on YouTube. A sequel to this post is available over here.

Hello, I used to build very large JavaScript applications. I don’t really do that anymore, so I thought it was a good time to give a bit of a retrospective and share what I learned. Yesterday I was having a beer at the conference party and I was asked: “Hey Malte, what actually gives you the right, the authority, to talk about the topic?” and I suppose answering this is actually on topic for this talk, although I usually find it a bit weird to talk about myself. So, I build this JavaScript framework at Google. It is used by Photos, Sites, Plus, Drive, Play, the search engine, all these sites. Some of them are pretty large, you might have used a few of them.

This Javascript framework is not open source. The reason it is not open source is that it kind of came out at the same time as React and I was like “Does the world really need another JS framework to choose from?”. Google already has a few of those–Angular and Polymer–and felt like another one would confuse people, so I just thought we’d just keep it to ourselves. But besides not being open source, I think there is a lot to learn from it and it is worth sharing the things we learned along the way.

So, let’s talk about very large applications and the things they have in common. Certainly that there might be a lot of developers. It might be a few dozens or even more–and these are humans with feelings and interpersonal problems and you may have to factor that in.

And even if your team is not as big, maybe you’ve been working on the thing for a while, and maybe you’re not even the first person maintaining it, you might not have all the context, there might be stuff that you don’t really understand, there might be other people in your team that don’t understand everything about the application. These are the things we have to think about when we build very large applications.

Another thing I wanted to do here is to give this a bit of context in terms of our careers. I think many of us would consider themselves senior engineers. Or we are not quite there yet, but we want to become one. What I think being senior means is that I’d be able to solve almost every problem that somebody might throw at me. I know my tools, I know my domain. And the other important part of that job is that I make the junior engineers eventually be senior engineers.

But what happens is that at some point we may wonder “what might be the next step?”. When we reached that seniority stage, what is the next thing we are going to do? For some of us the answer may be management, but I don’t think that should be the answer for everyone, because not everyone should be a manager, right? Some of us are really great engineers and why shouldn’t we get to do that for the rest of our lives?

I want to propose a way to level up above that senior level. The way I would talk about myself as a senior engineer is that I’d say “I know how I would solve the problem” and because I know how I would solve it I could also teach someone else to do it.

And my theory is that the next level is that I can say about myself “I know how others would solve the problem”.

Let’s make that a bit more concrete. You make that sentence: “I can anticipate how the API choices that I’m making, or the abstractions that I’m introducing into a project, how they impact how other people would solve a problem.” I think this is a powerful concept that allows me to reason about how the choices I’m making impact an application.

I would call this an application of empathy. You’re thinking with other software engineers and you’re thinking about how what you do and the APIs that you are giving them, how they impact how they write software.

Luckily this is empathy on easy mode. Empathy is generally hard, and this is still very hard. But at least the people that you are having empathy with, they are also other software engineers. And so while they might be very different from you, they at least have in common that they are building software. This type of empathy is really something you can get quite good at as you gain more experience.

Thinking about these topics there is one really important term that I want to talk about, which is the programming model–a word that I’m going to use a lot. It stands for “given a set of APIs, or of libraries, or of frameworks, or of tools–how do people write software in that context.” And my talk is really about, how subtle changes in APIs and so forth, how they impact the programming model.

I want to give a few examples of things that impact the programming model: Let’s say you have an Angular project and you say “I’m going to port this to React” that is obviously going to change how people write software, right? But then you’re like “Ah, 60KB for a bit of virtual DOM munging, let’s switch to Preact”–that is an API compatible library, it is not going to change how people write software, just because you make that choice. Maybe then you’re like “this is all really complex, I should have something orchestrating how my application works, I’m going to introduce Redux.”–that is going to change how people write software. You then get this requirement “we need a date picker” and you go to npm, there are 500 results, you pick one. Does it really matter which one you pick? It definitely won’t change how you write software. But having npm at your fingertips, this vast collection of modules, having that around absolutely changes how you write software. Of course, these are just a few examples of things that might or might impact how people write software.

Now I want to talk about one aspect that all large JavaScript applications have in common, when you deliver them to users: Which is that they eventually get so big that you don’t want to deliver them all at once. And for this we’ve all introduced this technique called code splitting. What code splitting means is that you define a set of bundles for your application. So, you’re saying “Some users only use this part of my app, some users use another part”, and so you put together bundles that only get downloaded when the part of an application that a user is actually dealing with is executed. This is something all of us can do. Like many things it was invented by the closure compiler–at least in the JavaScript world. But I think the most popular way of doing code splitting is with webpack. And if you are using RollupJS, which is super awesome, they just recently added support for it as well. Definitely something y’all should do, but there are some things to think about when you introduce this to an application, because it does have impact on the programming model.

You have things that used to be sync that now become async. Without code splitting your application is nice and simple. There is this one big thing. It starts up, and then it is stable, you can reason about it, you don’t have to wait for stuff. With code splitting, you might sometimes say “Oh, I need that bundle”, so you now need to go to the network, and you have to factor in that this can happen, and so the applications becomes more complex.

Also, we have humans entering the field, because code splitting requires you to define bundles, and it requires you to think about when to load them, so these humans, engineers on your team, they now have to make decisions what is going into which bundle and when to load that bundle. Every time you have a human involved, that clearly impacts the programming model, because they have to think about such things.

There is one very established way that solves this problem, that gets the human out of the mess when doing code splitting, which is called route based code splitting. If you’re not using code splitting yet, that is probably how you should do it as a first cut. Routes are the baseline URL structure of your application. You might, for example, have your product pages on /product/ and you might have your category pages somewhere else. You just make each route one bundle, and your router in your application now understands there is code splitting. And whenever the user goes to a route, the router loads the associated bundle, and then within that route you can forget about code splitting existing. Now you are back to the programming model that is almost the same as having a big bundle for everything. It is a really nice way to do this, and definitely a good first step.

But the title of this talk is designing VERY large JavaScript applications, and they quickly become so big that a single bundle per route might not be feasible anymore, because the routes themselves become very big. I actually have a good example for an application that is big enough.

I was figuring out how to become a public speaker coming up to this talk, and I get this nice list of blue links. You could totally envision that this page fits well into a single route bundle.

But then I was wondering about the weather because California had a rough winter, and suddenly there was this completely different module. So, this seemingly simple route is more complicated than we thought.

And then I was invited to this conference, and was checking out how much 1 US dollar is in Australian dollars, and there is this complex currency converter. Obviously there is about 1000s more of these specialized modules, and it infeasible to put them all in one bundle, because that bundle would be a few megabytes in size, and users would become really unhappy.

So, we can’t just use route based code splitting, we have to come up with a different way of doing it. Route based code splitting was nice, because you split your app at the coarsest level, and everything further down could ignore it. Since I like simple things, how about doing super fine-grained instead of super coarse-grained splitting. Let’s think about what would happen if we lazy loaded every single component of our website. That seems really nice from an efficiency point of view when you only think about bandwidth. It might be super bad from other point of views like latency, but it is certainly worth a consideration.

But let’s imagine, for example, your application uses React. And in React components statically depend on their children. That means if you stop doing that because you are lazy loading your children, then it changes your programming model, and things stop being so nice.

Let’s say you have a currency converter component that you want to put on your search page, you import it, right? That is the normal way of doing it in ES6 modules.

But if you want to lazy load it, you get code like this where you use dynamic import, which is a new fancy thing to lazy load ES6 modules and you wrap it in a loadable component. There are certainly 500 million ways to do this, and I am not a React expert, but all of these will change how you write the application.

And things aren’t as nice anymore–something that was static, now becomes dynamic, which is another red flag for the programming model changing.

Slide text: Who decides what to lazy load when?

You have to suddenly wonder: “Who decides what to lazy load when” because that is going to impact the latency of your application.

The human is there again and they have to think about “there is static import, there is dynamic import, when do I use which?”. Getting this wrong is really bad because one static import, when it should have been dynamic suddenly may put stuff into the same bundle that shouldn’t be. These are the things that are going to go wrong when you have a lot of engineers over long periods of time.

Now I’m going to talk about how Google actually does this and what is one way to get a good programming model, while also achieving good performance. What we do is we take our components and we split them by rendering logic, and by application logic, like what happens when you press a button on that currency converter.

So, now we have two separate things, and we only ever load the application logic for a component when we previously rendered it. This turns out to be a very simple model, because you can simply server side render a page, and then whatever was actually rendered, triggers downloading the associated application bundles. This puts the human out of the system, as loading is triggered automatically by rendering.

This model may seem nice, but it does have some tradeoffs. If you know how server side rendering typically works in frameworks like React or Vue.js, what they do is a process called hydration. The way hydration works, is you server side render something, and then on the client you render it again, which means you have to load the code to render something that is already on the page, which is incredibly wasteful both in terms of loading the code and in terms of executing it. It is a bunch of wasted bandwidth, it is a bunch of wasted CPU–but it is really nice, because you get to ignore on the client side that you server side rendered something. The method we use at Google is not like that. So, if you design this very large application, you have think about: Do I take that super fast method that is more complicated, or do I go with hydration which is less efficient, but such a nice programming model? You will have to make this decision.

My next topic is my favorite problem in computer science–which is not naming things, although I probably gave this a bad name. It is the “2017 holiday special problem”. Who here has ever written some code, and now it is no longer needed but it is still in your codebase? … This happens, and I think CSS is particularly famous for it. You have this one big CSS file. There is this selector in there. Who really knows whether that still matches anything in your app? So, you end up just keeping it there. I think the CSS community is at the forefront of a revolution, because they realized this is a problem, and they created solutions like CSS-in-JS. With that you have a single file component, the 2017HolidaySpecialComponent, and you can say “it is not 2017 anymore” and you can delete the whole component and everything is gone in one swoop. That makes it very easy to delete code. I think this is a very big idea, and it should be applied to more than just CSS.

I want to give a few examples of this general idea that you want to avoid central configuration of your application at all cost, because central configuration, like having a central CSS file, makes it very hard to delete code.

I was talking before about routes in your application. Many applications would have a file like “routes.js” that has all your routes, and then those routes map themselves to some root component. That is an example of central configuration, something you do not want in a large application. Because with this some engineer says “Do I still need that root component? I need to update that other file, that is owned by some other team. Not sure I’m allowed to change it. Maybe I’ll do it tomorrow”. With that these files becomes addition-only.

Another example of this anti-pattern is the webpack.config.js file, where you have this one thing that is assumed to build your entire application. That might go fine for a while, but eventually needing to know about every aspect of what some other team did somewhere in the app just doesn’t scale. Once again, we need a pattern to emerge how to decentralize the configuration of our build process.

Here is a good example: package.json, which is used by npm. Every package says “I have these dependencies, this is how you run me, this is how you build me”. Obviously there can’t be one giant configuration file for all of npm. That just wouldn’t work with hundreds of thousands of files. It would definitely get you a lot of merge conflicts in git. Sure, npm is very big, but I’d argue that many of our applications get big enough that we have to worry about the same kind of problems and have to adopt the same kind of patterns. I don’t have all the solutions, but I think that the idea that CSS-in-JS brought to the table is going to come to other aspects of our applications.

More abstractly I would describe this idea that we take responsibility for how our application is designed in the abstract, how it is organized, as taking responsibility of shaping the dependency tree of our application. When I say “dependency” I mean that very abstractly. It could be module dependencies, it could be data dependencies, service dependencies, there are many different kinds.

Obviously, we all have super complicated applications, but I’m going to use a very simple example. It has only 4 components. It has a router that knows how to go from one route of your application to the next, and it has a few root components, A, B, and C.

As I mentioned before this has the central import problem.

Because the router now has to import all the root components, and if you want to delete one of them you have to go to the router, you have to delete the import, you have to delete the route, and eventually you have the holiday special 2017 problem.

We at Google have come up with a solution for this, that I want to introduce to you, which I don’t think we have ever talked about. We invented a new concept. It is called enhance. It is something you use instead of import.

In fact, it is the opposite of import. It is a reverse dependency. If you enhance a module, you make that module have a dependency on you.

Looking at the dependency graph, what happens it that there are still the same components, but the arrows point in the opposite direction. So, instead of the router importing the root component, the root components announce themselves using enhance to the router. This means I can get rid of a root component by just deleting the file. Because it is no longer enhancing the router, that is the only operation you have to do to delete the component.

That is really nice, if it wasn’t for the humans again. They now have to think about “Do I import something, or do I use enhance? Which one do I use under which circumstances?”.

This is particular bad case of this problem, because the power of enhancing a module, of being able to make everything else in the system have a dependency on you is very powerful and very dangerous if gotten wrong. It is easy to imagine that this might lead to really bad situations. So, at Google we decided it is a nice idea, but we make it illegal, nobody gets to use it–with one exception: generated code. It is a really good fit for generated code actually, and it solves some of the inherent problems of generated code. With generated code you sometimes have to import files you can’t even see, have to guess their names. If, however, the generated file is just there in the shadows and enhances whatever it needs, then you don’t have these problems. You never have to know about these files at all. They just magically enhance the central registry.

Let’s take a look at a concrete example. We have our single file component here. We run a code generator on it and we extract this little route definition file from it. And that route file just says “Hey Router, here I am, please import me”. And obviously you can use this pattern for all kinds of other things. Maybe you are using GraphQL and your router should know about your data dependency, then you can just use the same pattern.

Unfortunately this is not all we need to know. There is my second favorite problem in computer science which I call the “Base bundle pile of trash”. The base bundle in your graph of bundles in your application is the one bundle that will always get loaded–independent of how the user interacts with the application. So, it is particularly important, because if it is big, then everything further down will also be big. If it small, then dependent bundles at least have a chance of being small as well. A little anecdote: At some point I joined the Google Plus JavaScript infrastructure team, and I found out that their base bundle had 800KB of JavaScript. So, my warning to you is: If you want to be more successful than Google Plus, don’t have 800KB of JS in your base bundle. Unfortunately it is very easy to get to such a bad state.

Here is an example. Your base bundle needs to depend on the routes, because when you go from A to B, you need to already know the route for B, so it has to always be around. But what you really don’t want in the base bundle is any form of UI code, because depending on how a user enters your app, there might be different UI. So, for example the date picker should absolutely not be in your base bundle, and neither should the checkout flow. But how do we prevent that? Unfortunately imports are very fragile. You might innocently import that cool util package, because it has a function to make random numbers. And now somebody says “I need a utility for self driving cars” and suddenly you import the machine learning algorithms for self driving cars into your base bundle. Things like that can happen very easily since imports are transitive, and so things tend to pile up over time.

The solution we found for this are forbidden dependency tests. Forbidden dependency tests are a way to assert that for example your base bundle does not depend on any UI.

Let’s take a look at a concrete example. In React every component needs to inherit from React.Component. So , if your goal is that no UI could ever be in the base bundle just add this one test that asserts that React.Component is not a transitive dependency of your base bundle.

Looking at the previous example again, you just get a test failure when someone wants to add the date picker. And these test failures are typically very easy to fix right then, because usually that person didn’t really mean to add the dependency–it just crept in through some transitive path. Compare this to when this dependency would have been around for 2 years because you didn’t have a test. In those cases it is typically extremely hard to refactor your code to get rid of the dependency.

Ideally though, you find that most natural path.

You want to get to a state where whatever the engineers on your team do, the most straightforward way is also the right way–so that they don’t get off the path, so that they naturally do the right thing.

This might not always be possible. In that case just add a test. But this is not something that many people feel empowered to do. But please feel empowered to add tests to your application that ensure the major invariants of your infrastructure. Tests are not only for testing that your math functions do the right thing. They are also for infrastructure and for the major design features of your application.

Try to avoid human judgement whenever possible outside of the application domain. When working on an application we have to understand the business, but not every engineer in your organization can and will understand how code splitting works. And they don’t need to do that. Try to introduce these thing into your application in a way that is fine when not everybody understands them and keeps the complexity in their heads.

And really just make it easy to delete code. My talk is called “building very large JavaScript applications”. The best advice I can give: Don’t let your applications get very large. The best way to not get there is to delete stuff before it is too late.

I want to address just one more point, which is that people sometimes say that having no abstractions at all is better than having the wrong abstractions. What this really means is that the cost of the wrong abstraction is very high, so be careful. I think this is sometimes misinterpreted. It does not mean that you should have no abstractions. It just means you have to be very careful.

As I was saying at the start of the presentation: The way to get there is to use empathy and think with your engineers on your team about how they will use your APIs and how they will use your abstractions. Experience is how you flesh out that empathy over time. Put together, empathy and experience is what enables you to choose the right abstractions for your application

If you found this interesting, consider reading my article on design documents or the sequel to this post “Designing Even Larger Applications”.

Developer Experience VS User Experience?

2017-01-03T00:00:00Z

A few days ago Jake Archibald ruffled some feathers with this observation:

This strongly reminded me of the first and most important item in AMP's design principles:

So, given that my project is setting very similar guidelines compared to what Jake implied in his tweet, I thought it’d be useful to explain the thinking behind it.

When creating systems for user facing software, then user experience is more important than developer experience. We add a third item: “Ease of implementation” is less important then developer experience. The implementation here refers to the creator of the underlying system and framework. The idea is that the framework creator should always strive to optimize developer experience, even if they have to work harder for it.

Of course, there is a lot of nuance to the statement that user experience is more important than developer experience. The most important nuance is that in many, many cases they do not stand in conflict at all. Furthermore, in a large number of cases improving developer experience is the best way to improve user experience, so rather than being in conflict these goals are often in congruence. My favorite example is to improve developer experience by speeding up the iteration cycle (e.g. by improving build time or providing hot reloading): This is great for developers and it allows them to spend more time improving UX in any given day, thus leading to better results.

Similarly, there are many cases where improved developer experience might just enable a piece of software being build in the first place. The UX might not be perfect, but at least the thing exists. That should typically be a net win :)

Having said all this, there are trade offs where improved developer experience, just leads to bad UX. My favorite example is

<img src=”./image.jpg”>

which has much better developer experience, than

<img src=”./image.jpg” width=400 height=300>

The first image tag is missing the dimensions. (Ignoring the complexities of responsive sizing that do not impact the point) This is great for the developer. They literally do not need to write the piece of software that determines the dimensions, which saves a little bit of time. Now what happens is that the browser will assume: “Ah, no dimensions, the image is probably 0 pixels big”. Then it will download the image and realize “Ah, it is actually 400x300, lets redraw the page”. This creates a lot of jank for the user every single time a page is looked at.

A system that favors user experience over developer experience would always make sure that the image dimensions are known when the page is downloaded. Now, of course, one could improve developer experience again, by somehow making it very easy (or automatic) to provide the image dimensions. Another case, where one can have the best of both worlds, but getting good UX does require going the extra mile during framework development.

Server side rendering, lazy loading of JavaScript bundles and splitting up CSS files are all optimizations of user experience that do incur a cost on developers. Again, a given framework can chose to make them as automatic as possible, but such abstractions tend to be at least a little bit leaky and add visible complexity.

My post about tradeoffs in server and client side rendering tries to dive into that topic in particular. The React style hydration of a server side render right upon initial load is a user experience and developer experience trade off: It is better than not doing server side rendering at all, but it is strictly worse than lazily initializing the JS on the client (because it does an initial eager diff and installs event handlers). User experience may not be ideal, but going the extra mile may not be worth it or delay shipment indefinitely for a large class of applications (maybe that class includes everything except google.com, twitter.com, and facebook.com).

Having said all this, the premise that user experience is more important than developer experience is still an important thing to keep in mind as a framework developer. We always need to ask ourselves:

What is the right thing to do for user experience?
How can I provide the best possible DX given my UX goals?
What is the smallest possible UX tradeoff given my DX goals?
How can I make tradeoffs that improve DX while sacrificing UX, but only in development mode?
How can I document things for developers, so they can make informed tradeoffs between UX and DX?

Design docs - A design doc

2015-05-20T00:00:00Z

Design docs are a fundamental tool for communicating software design decisions–but communicating things is hard and so is writing design docs. Time for an overly detailed exploration into what would happen if one wrote a design doc for design docs.

May 19th, 2015
Status: Draft
Authors: Malte Ubl

Note: While this post continues to be independently useful, I have published a more approachable write-up about Google's use of design docs in Design Docs at Google

Context and scope #

Software design is an important element of software engineering in which, after we established the requirements of the product or system we are building, we make plans and decisions how to best implement those requirements in software.

This document describes how a design document is used to facilitate the process of coming to an agreement on a software design and to document it for current and future implementers, maintainers and other stakeholders of the software.

Goals #

Document the software design.
Clarify the problem being solved.
Act as discussion platform to further refine the design.
Explain the reasoning behind those decisions and tradeoffs made in that decision.
List alternative designs and why they were not chosen.
Support future maintainers and other interested parties in understanding why the original design was chosen.

Non-goals #

Establish non-technical requirements of the software.
Be independently understandable by a person with no background in the software (but links should guide to documentation that covers missing parts).
Act as user documentation for the product or system.
Suitable to document non-software-designs such as the design of a design doc.

Overview #

Our core design idea is that we use a document to informally describe the software design. This extra step before the implementation is chosen, because it has proven inefficient to evolve early software design in terms of fully working implementations. For similar reasons maintainers who try to understand an existing software system often struggle to understand the fundamental design decisions just by looking at the source code.

The design doc starts with explaining the objective of the software design, how it fits into the wider landscape and why the problem at hand was sufficiently complex to warrant a design document. Explicitly listing goals and non-goals is done to encourage thinking about them.

The document then continues with a short overview of the design without describing all the details. This overview is followed by the detailed design section that contains the bulk of the content describing why the design was chosen and what the software design is.

Several sections on cross cutting concerns such as privacy and security directly address how the design relates to them.

We finish by quickly describing what alternatives were considered and why they were not chosen.

Design documents are designed to be an efficient design documentation and discussion platform. As such the writer may take great liberties in the actual content and form to best express the design.

Detailed design #

The process of designing software should ideally have the following properties:

Draws on the experience of experts of the topic matter from within and around the team.
Is flexible to changing requirements of the software.
Produces a guideline for the initial implementation.
Produces accurate documentation of the software design behind the actually implemented software.
Produces a design that is implementable within the given constraints such as time and resources.
Quickly establishes that a chosen design is viable.
Quickly establishes that a chosen design is not viable and then produces a viable design.
Reduces the risk that a design is not viable.
Produces simple designs.
If applicable comes to the conclusion that an existing solution exists and no design is necessary.

While some of the requirements in this (incomplete) list may seem redundant, some cannot be achieved at the same time.

The most direct way to show whether a system can be implemented is to implement it, but that may take too long to quickly establish what the right design is and requirements may have changed by the time the viability of the design under the old requirements was proven.

In this trade-off-space the design doc plays a vital role by being easy to collaborate on and informal, yet relatively exhaustive and updateable over time:

By using modern collaborative software, such as Google Docs, experts from the team and beyond can collaborate on the final document.
Being informal allows the content and form to be tailored to the design issue at hand making it an efficient way to document designs.
The same informality reduces the “cost of change”.

The software design toolbox contains things such as “the proof of concept”, “the micro benchmark” and “the white board discussion”. While it is beyond the scope of this design doc to explain all of them they should be considered as part of the software design process. E.g. pointing to a proof of concept can be a great way in a design doc to establish the viability of the design.

Relationship to other systems #

The design doc is written as part of the development of the software design. It gets informed and refined through other elements of software design such as whiteboard sessions and design reviews.

Software design is primarily driven by the project requirements and if applicable by the user interface design. The requirements, independent of how they are expressed, define what a piece of software should do while the design establishes how that is achieved and why that design was chosen. The design then informs the implementation and the implementation feeds back into the design (through updates of the design when it confronts with reality).

Structure #

The structure of a design doc is chosen, so that a reader can efficiently and effectively dive into the subject matter. The document starts out relatively high level and then dives deeper into the details of the design.

This “funnel” is chosen so readers

can quickly evaluate the context, scope and goals of the design and get a basic understanding of the design.
and can then choose to read the entire document.

Meta information #

Design docs should always have a title and immediately state their authors as primary contacts and a last updated date. Stating the status is helpful for setting expectations for the reader as to the completeness and definiteness of the document. Useful states are:

(The above code snippet was inserted to illustrate the point further down that copy pasting irrelevant code snippets is not a great idea.)

Context, scope & goals #

The document should first establish the context and scope of the design. This may be done across multiple or a single paragraph. This section should include bullet point lists of “Goals” and “Non-goals” for three reasons:

It is an efficient way for the reader to establish what the design tries to achieve and what it doesn’t want to achieve.
It can be used to evaluate whether the detailed design establishes how those goals are achieved.
It forces the authors to actually make decisions about the scope.

Overview #

Next the document gives an overview of the design. This helps readers gain an understanding of the overall approach, which will make it much easier to evaluate how the details relate to the design. It is important to realize that the design doc should not build up tension when being read from start to the end. Quite the opposite, information is given as fast as possible and the structure should aim to avoid putting related information too far apart.

Detailed design #

This section explains the design, its trade offs and consequences as appropriate. The concrete contents are greatly determined by what is being designed and will vary widely between various types of systems, APIs, front ends, etc. The authors are explicitly empowered to choose a form that best fits their design.
See “Level of detail” below for guidance as to what should determine the contents of the detailed design section.

Cross cutting concerns #

There may be one or multiple chapters that talk about specific concerns from their specific point of view. While the entire design should have them in mind the dedicated chapters ensure that they are addressed and highlight how the design applies to them. Examples for such concerns are privacy, security, scalability and monitoring.

Alternatives considered #

This section is a fixed part of the document structure as it forces the authors to think about what alternatives would have been available to achieve the goals of the design. Alternatives may be other possible designs or the use of an existing system that does almost what is needed, the purchase of a standard software or to do nothing at all.

Level of detail #

As stated before a design doc should be an efficient platform for design discussion and documentation. The longer the document gets the harder it becomes to consume and change. The document should thus be as short as possible and as long as necessary.

No definite guidance can be given when a document is too detailed, but there are some signs when this is the case:

Specification of APIs that are not vital to the design.
Copy pasted source code that is only partially relevant to the design.
Raw data.
Bullet point lists that contain an extra item for no good reason beside meta referentiality.

Given the design doc a software engineer who either has existing experience in the subject matter or is willing to invest to get that experience should be able to implement the design doc.

In a similar manner a “reasonable software engineer” with experience in the subject matter should be able to follow why the design was chosen even if they do not agree with the conclusion.

The design document itself is not responsible to give any reader independent of their prior experience full context into the subject matter but it should provide links that enable the reader to establish the full context necessary to follow the rest of the doc.

Lifecycle #

Document creation #

Early in the lifecycle of a design doc major changes are more likely than later in the project when the design is more settled. Early iterations of the document should thus be as lightweight as possible so that changes are quick and the author’s resistance to change it minimized.

Techniques such as whiteboarding and sketching out chapters with bullet point lists may be employed in early phases of the doc.

While the document itself is informal, initial setup can be sped up through the use of templates or by the time proven technique of copy pasting the last design doc one has written. The usage of these templates helps ensure a minimum level of coverage and reduces boilerplate.

Canary rollout #

When the document has stabilized it is advisable to first share it with a small set of canary readers. These will often be peers who participated in early whiteboard sessions and design discussions. By incorporating their feedback into the design doc we ensure that no major questions are unaddressed and ensure general soundness of the design before circulating it with a wider audience.

Rollout #

At this time the document is shared with the wider team and other stakeholders. Readers are encouraged to ask questions and make suggestions via inline comments and authors reply. If warranted the document should be updated to address the feedback.

Eventually the design is declared final. Often this happens informally signaled by the fact that people start implementing the design.

Security and privacy considerations #

The design doc has dedicated sections for security and privacy considerations and other such cross cutting concerns if applicable to ensure that they are sufficiently addressed.

Alternatives considered #

Meet in front of a whiteboard, draw stuff on it, take a photo.
It is great when this is sufficient to document a design, but often systems are too complex to be expressed through a single whiteboarding session and people who did not themselves take part in the discussion may be missing context.
Having said that, whiteboarding sessions are a great start to flesh out the major points of a design in a lightweight process before diving in to actually write it down.
Agile Scrum KISS™, just winging it.
Doing the simplest thing that could possibly work is generally a great idea but it stops being fun when that includes a lot of boilerplate or in aggregate becomes so complex that everyone loses track what is going on. If the simplest thing that could work is still complex a design doc may help document that simplest thing.
Verbal design review
Design reviews are another way to discuss a design and spread knowledge about it. It can be a great addition to every design doc but is insufficient to serve as long term evolving documentation of a project’s design.

The cost of failure

2015-05-11T00:00:00Z

In UI engineering the path to an excellent product is often not clearly set. Especially if we push the boundaries of hardware across numerous devices experimentation and tweaking are an integral part of polishing the experience. Experimentation is an iterative process, a string of small failures, that eventually leads to the desired result. Minimizing the cost of these failures can materially impact the quality of the final product.

We know from the mythical man month that adding more engineers to a projects doesn’t necessarily increase output and every project will want to eventually ship. This is 2015 so we ship MVPs, but we still have to ship them at some point.

My thesis is that quality/excellence/fidelity of that final product given time and resource constraints is a function of the number of iterations the team was able to make within the available time.

Lets consider the following example: The product spec calls for an animation where state A of the product morphs into state B. Cool, most talented UI engineers will be able to implement it given enough time. But will it be good? Slight variations in how the animations are performed will dramatically affect how the GPU handles the task, etc. It may need to be tested with various forms of content and one 4–5 different devices. The iteration speed determines how long it takes to tweak the animation and complete each experiment.

So what is iteration speed in concrete terms? The length of the cycle of:

Having the idea that a change may improve fidelity.
Implementing that change.
Compiling the program.
Deploying it onto the target device.
Reinstating the state of the program to where the behavior-under-improvement is exhibited.
Observing/measuring whether the fidelity is improved.
Optionally repeat 4–6 on N devices.

Differing development environments exhibit vastly differing times for each elements of the cycle.

Steps 1, 2 and 6 are the only steps that are necessary. All other steps would ideally take 0 seconds and there are, indeed, systems that do not require these steps at all.

The get-off-my-lawn old person in me remembers the golden days of the 90s where in VisualWorks SmallTalk one would just stop the UI, unwind to some previous state, change the running program and rerun the relevant part.

However, it isn’t the 90s and things are much worse. There are web developers who not only have to compile their program for dozens of seconds, they even have to manually invoke that compilation; there are native mobile developers who have to compile and transfer a program to the device and then have to touch their app’s icon to start it and then manually click through their app to get back to the part they were working on. And then they put another device on the USB cable and repeat.

Lets do some hypothetical calculations:

Assume it takes about 5 minutes to come up with an idea for an improvement, implement it and measure whether there was an improvement.

If the overhead (Steps 3, 4 and 5) takes 0 seconds we can make a program better 12 times per hour. What is more important because there are no context switches it is actually feasible to do so and we can take 15 minutes out of the hour for a nice coffee break.

What happens when compilation, or deployment or state recreation take 2 minutes? In theory we could still do 8 iterations per hour, but now we have those frequent 2 minute breaks. Reddit, HackerNews and Twitter will get in the way. 5 iterations are more realistic under this setting, but things get even worse if testing has to be repeated on multiple devices.

As a consequence even what may seem to be relatively short breaks can fast cut the number of iterations that can be done on a given product in half. And it just won’t be as good.

So what can be done to improve iteration speed?

Cut human interaction out of tasks: The system should sense when a task needs to be done, not wait for user invocation.
Can eliminate or shorten steps 3 & 4.
Cut all tasks that do not need to block iteration out of the critical path. Type checking? Its nice, but doesn’t have to block running the program.
Eliminates step 3.
Invest in hot code replacement.
Eliminates step 3 & 4 and shortens step 5.
Invest in time traveling debuggers.
Together with hot code replacement eliminates steps 3, 4 & 5.
Fan out hot code replacement: Do just in time hot code replacement on N devices concurrently.

Even if a system trades off being able to do these things against a lesser maximum performance (a classic choice between lower and higher level programming constructs. E.g. late binding VS. early binding), the increased fidelity through higher iteration speed will quickly make the net performance better.

Obviously the above is only true within certain limits, but I feel that we as a software engineering community are underinvested in increasing development productivity. This is the one part of the equation that we can directly influence ourselves by building better tools and we should make it a priority.

Anecdotes about frontend and backend engineering

2015-04-06T00:00:00Z

This is the story about how I became what some people would call a frontend engineer and an exploration into what that even means.

This was October 2008 and I just joined a new company and was leading a team of 11 or so engineers in a company of roughly 200.

I was also really excited about this new company but then I discovered the thing that made me really mad:

Me being the new manager for the team I decided to do some pair programming with each person on the team to kinda get a feel for what their work was like. When I eventually got to work with the first dev doing client side work I went completely What The Fuck?!?! Their work flow for JS and CSS was to make the changes and then click the deploy button in Eclipse, which would then

Start up ant
Cleanly shutdown tomcat
Recompile the Java project to include the updated files as a resource
Startup tomcat

Overall a cool few minutes would pass by only to see a new background color.

So, I was yelling “What The Fuck?!?” or probably something more along the lines “How do you put up with this? This is completely unacceptable! We should stop doing anything else and make this better first”.

Luckily it turned out the person responsible for the Java build process was sitting right next to us. He was like: “Wait, go to Eclipse and from the build menu select the ‘Deploy resources’ item. Does the job and only takes 1–2 seconds. I made this because I was annoyed when I needed to make a JS change, but I guess I never really told anyone else.”

There were 2 major fails here:

The client side dev didn’t go on strike the second they realized there was no reload-to-refresh in the system they were working on.
While the “backend dev” realized there was a problem, they didn’t actually communicate this to the “frontend dev” sitting literally a chair to the right.

The reality was that those 2 people were sitting on the same desk but they had essentially never talked to each other nor were they aware of each other’s problems.

This was just one of several similar experiences and so I was really mad: The work product was not good and it seemed so obvious how to fix it. We were building consumer facing ecommerce web apps and I was feeling like we weren’t able to deliver the type of experience that the consumers deserved. While there are definitely cases where backend work leads to hard-to-copy differentiating features, this is not what happens in many areas. Backend systems are often commodities (vast majority of ecommerce sites work this way), and real differentiation is achieved through excellent user experience.

Now we come to the part where I was full of myself. I was thinking: “While all the senior people do backend work, I’m like the best senior engineer and from now on I am going to be a frontend engineer”.

So, I did a presentation at the next engineering all hands meeting talking about the anecdote above and how that is unacceptable and: “If you want to join the new cool kids, better do work on the client. We need the best of you all doing work closest to our users.”

Needless to say that actually worked. While there was certainly larger changes at play at the company that shifted the perception and role of the non-engineering work in UX, etc. as well, the baseline quality of the work product the entire company delivered has risen very significantly since.

I just made up the term “user facing engineering”; I’m not personally a fan of using the word frontend as a category of engineering. I now work at Google where like 98% of engineers build bigtable frontends or frontends to those frontends and bigtable itself is basically just a physical storage frontend. The term is relative and thus meaningless without context. The Chrome browser has a backend team: it implements the actual HTML rendering on the client.

On the other hand “backend engineer” as typically used is also hard to define. In my cynical mind it means: ”spends most of their time with data migrations from the legacy system to the future legacy system.”

So, should everyone be a “full stack engineer”? The answer is a clear No. What is important is that skills are equally distributed across disciplines and that communication across engineers on different layers of the stack happens regularly. If you talk to a colleague on a different layer all the time, eventually you will know enough about that layer to be a little more “full stack” and you’ll be able to design systems that impact or span multiple layers of the stack. To me that is one of the most important aspects of “seniority”.

But you will still be an expert for probably just one of the layers and that is completely fine. Each layer of software engineering is deep enough to spend many many years in perfecting its craft and really hard problems require specialists.

Coming back to the “frontend” or the “client side” or the “user facing engineering”: As the medium “computer” matures, the discipline of engineering that deals with computer user interfaces has become so “deep” that I would not want to leave it to my least experienced engineers. We need people who are really good at applied matrix math, deeply understand how GPUs and networks work, can design multi-million-lines-of-code systems, understand accessibility requirements and maybe even have a sense for design aesthetics (I so wish I would fall into that latter category). To me all of these seem sufficiently hard and interesting that I dedicated my career to getting better at them and maybe eventually actually be a senior engineer ☺

10x engineer 10% of the time

2015-02-05T00:00:00Z

I’ve lately been thinking about what patterns could explain perceived differences in individual productivity in software engineering. I’m using the word perceived because productivity is really a complex topic and I can think of few ways how to effectively measure it within the complex social structure of a larger engineering team.

So, this is the list of things I came up with:

Programming languages, tools and frameworks come and go, but having a great debugging instinct and skill set will pay back for the rest of one’s career. Debugging can and must be practiced. I personally think that for someone new to software engineering who asks “What should I focus on in my career” debugging should be the #1 answer. It is the one thing that will always be there in our jobs.

Manage your work load and make sure that whenever a given task can not be continued there is something else waiting to be done already.

During the typical software engineering job there are millions of reasons why one may not be able to proceed working on the current task: waiting on a designer, product manager, another team making a release, etc.. The ability to embrace this situation and switch to a different task while the other is waiting is I think the most hated, stress producing and still helpful skill for using a larger percentage of the time available for actual programming. The key is finding the sweet spot between reduced productivity from task switching and increased productivity from larger utilization. Everyone will have a different sweet spot but I think that professionally embracing the fact that task switches are part of everyday work allows us to get better at it over time.

In software engineering we often face the decision whether to automate a piece of work or just do it manually. Some examples:

Create a scaffolding script or write the boilerplate by hand?
Improve the error message after debugging found what was wrong, so the problem is obvious next time it happens, or let the next person search for it again?
Set up hotswapping or restart the server all the time?

Knowing when to do one or the other is in my experience one of the greatest signals of seniority in software engineering.

In my experience most engineers tend to overestimate the amount of work to build the tool and thus choose to do manual labor when they could have saved hours, days or weeks of engineering time with a tool that takes 8 hours to build. But there is certainly also the other extreme: Automating everything while creating a maintenance burden for tools that almost never run.

Having good intuition as to what way to go can be learned. I know I was certainly in the “too much manual work” camp, but I learned to correct myself for that, and it seems from hindsight I’ve been able to chose correctly more often.

It could be argued that the reading code is more important than writing code; it gives perspective and insights into our fellow engineer’s brilliant minds but the truly most important reason that reading code is so important: documentation is bad and always will be bad. So making oneself independent of docs as much as possible is super important for getting things done. Not enough is being talked about good code reading techniques: I personally always try to empathize with the authors based on the code I’m seeing and try to get a feel for how they write software, so I can more quickly start to make correct assumptions from scanning other code in the same project.

Programming is often seen as this magical thing where some people are just better than others by talent or whatever; instead it is a craft, a craft that one can get better at. Getting better takes practice and with limited time practice should focus on the most important aspects of the craft. This posts focuses on the workflow side of things — there are obviously many more important fields like coding itself and software design. I’m very interested in feedback and maybe I’ll eventually get to talk about the other topics in another posts.

Tradeoffs in server side and client side rendering

2015-01-15T00:00:00Z

For a long time there has been a debate in web development as to whether web apps and sites should be rendered on the server or the client — or, of course, both.

With a recent post by PPK the debate flamed up again and one thing that struck me as particularly unhelpful was the argument that where something is rendered would be automatically determine whether a given framework is (one dimensionally) good or bad. In my opinion such an simplistic view on things hides the real underlying tradeoffs that should drive decisions.

For some perspective: My day job is building web frameworks for Google. The one I’m designing is from the ground up build to support server side rendering very well (it isn’t open source mostly because I felt Google had enough open source web frameworks already and I didn’t want to make the choice even harder, but I also never want to say never). So, it may seem that I’d be somewhat “partisan” with this respect, but the opposite of true. My framework comes with a disclaimer saying that it is particularly designed for very large consumer-facing web applications. Anything that doesn’t fit that description might still be happy, but there will be tradeoffs made that make their life more difficult than otherwise necessary.

First I’d like to establish that server side rendering is hard beyond the pure ability to render on the server. Assuming you are building a complex app that wants to render initial responses on the server and then update subsequent state using XHR, there are several challenges that a good server side rendering solution needs to overcome and complexity that is added in any case:

Client side decoration. It is great that you can render a chunk of HTML on the server, but you also need to do things like registering events handlers on the client. Many modern frameworks do that during rendering. One approach is to just immediately after load do a client side render using the same data that was used for server side rendering. React makes this quite nice. But this now means that loading the code that is necessary to make the page interactive includes the code that is necessary for client side rendering (read your templates!) and with that a major benefit of server side rendering is gone.
I would assume that your templating language (or whatever you use to eventually have a DOM) runs equally well on the client and the server. This isn’t everything, of course: You need to duplicate the data fetching logic and other code. Now one could argue that with e.g. Node.js you could reuse the code but in reality the difference in code you write when your database is 10ms away VS. 100–2000+ms is so big that unless you have a very big abstraction layer there will be significant duplication.
Both render paths need to be tested and integration tested.
On a client side render you always know how wide or high the screen is. For very high fidelity sites you at some point will want to make a rendering decision based on something that you cannot express in CSS. There are work arounds for this that still work with server rendering but they will require major discipline by engineers to walk on the thin path of only using information available on the server during rendering even if rendering happens on the client.
For very high fidelity you may need to sometimes fall back from server side rendering to client side rendering: That is because on the client you can retry and give the user some feedback when a backend is temporarily unavailable while on the server you’d need to show an error page.
The approach to render everything on the server, even incremental updates to the page is very dangerous and will be make you unhappy, so you need to plan with being able to server and client side render everything. E.g. Rails TurboLinks and I hear Twitter.com uses a similar approach where server side rendered pages are incrementally merged into a running web app: This means that your 5 days old JS may need to be able to handle HTML rendered today. This type of forward and backward compatibility will eventually (or rather really soon) go wrong.

I could go on, but the gist is: server side rendering comes at complexity cost because while all of the issues above can be eliminated the solutions will add very significant complexity to your project.

So why would you do server rendering:

Some people say that search engines still like it better.
Or that it is the right thing to do because web.
You might need to print out some OGP, Twitter Card and Schema.org markup anyway, so some of the extra complexity is not optional.
It is faster. But only sometimes (Recent data by Brett Slatkin). Yes, you can do really well with client side rendering but the reality is that due to high latency between web client and server it is extremely hard to keep the critical path so ideal that you have a fighting chance of staying competitive with server rendering. I’m not saying it can’t be done, but I’d argue that with a team of 10 people and a year of frequent feature additions the server rendered app will stay significantly faster than the same app rendered only on the client.

Looking at the benefits of server rendering there are entire classes of apps that don’t benefit from it at all:

Your intranet ERP, HR, Financial, blah software will not want Schema.org markup. In reality most software that is being written falls into this category.
Slightly hipper things like bug tracking, todo management, or whatever every other startup is building really falls in the same category.
Google Inbox renders the list of emails on the server when you first go to it. That is kind of nice compared to how GMail loads, but amortized over an entire day the benefit is really marginal.
The more general case is almost all “Information and Business Systems” : If the typical user loads it at most once a day and then uses it for hours, initial load performance will not be the most important thing.
All native apps on your phone and tablet are client side rendered. Seems to be alright.

The most obvious class of apps where server side rendering would have major benefits are content publishing sites like the New York Times or, you know, Medium as well as other user generated content sites that rely on referral traffic for perma link pages (Think Instagram, Youtube, Twitter, etc). As one of these the amount of engineering I’d be willing to take on to make my pages just a bit faster, friendlier to BingBot and easier shareable on other social networks may be pretty high. That it may not be high enough can be seen on Instagram which is not server rendered (Update 2016: It is now server rendered using the fastboot pattern. Faster but requires a lot of CPU per page load); I’d not be suprised if that changes in the future, but it seems for them shipping was more important than ultra high fidelity.

I’m excited that Ember.js is adding server rendering. I’m sure they’ll do a great job hiding the complexity, but this decision will still impact their project in the long term:

Some stuff just won’t work on the server. That has to be documented somewhere. People have to read those docs.
If the above isn’t true, some stuff just will no longer be possible at all.
Future and present features may need to be slightly tweaked to support server rendering thus getting an ever so slightly worse API than would be possible for client rendering only.

In the more general case there are dozens of tradeoff spaces in which frameworks can make decisions as to what they want to optimize for. Some frameworks have data binding which is awesome if your app has lots of forms and getting shit done is super important and more important than making UX absolutely perfect— in that case adding each event handler one-by-one may not be cool — on the other hand if your job is to build the Facebook image upload dialog you may have a UX team and 2 engineers twiddling every last aspect for multiple months. These are very different types of software and even though both may be rendered from HTML, I’d use a very different underlying system to build them.

In conclusion: Server rendering is great, use it where applicable but be conscious about the hit in productivity due to extra complexity and decide whether it makes sense for your app.