70 %
Chris Biscardi

Avoid the Shadow UI

This advice is aimed at eventually wanting to hire UI specialists that can fully effect their speciality on your project, product, or service. If you know you'll never have a "UI person" involved, do whatever you want.

Ok so you've got a new web project that will at some point want interactivity that requires enough JavaScript to make someone tear their hair out. If you ever decide to have an API that your UI consumes, you already fall into this category.

How do the thing these days?

The Shadow UI

You should avoid, at all costs, the situation in which you have two UIs for the same application.

I don't mean an electron app and a web app and an admin app, etc. What I mean is two applications that do similar things that are overlaid on each other.

This often happens when you use a non-javascript language to render your UI on the server, and JS to render your UI in the browser. What this results in is the server rendering a Shadow UI that is taken over by the JavaScript UI. Hence: two UIs that often need to accomplish the same tasks.

Having a Shadow UI means that you are duplicating work all the time in two different ways. This means your UI people need to constantly decide where functionality goes and have to cover two language implementations for many behaviors. It means they can't use best-in-class tooling because best-in-class tooling (rightfully) doesn't consider golang (or X language) to be an implementation target. It targets JavaScript, whether at runtime (emotion) or build time (postcss).

It also means you don't have much of a choice between client-side, server-side, or prebuilding your UI. Everything has to fit into a two-language pipeline.

A Backend Comparison

Imagine you had two APIs serving from the same database. One serves responses to bootstrap a user request, and then the client transfers over to the other to continue interacting with