What are the benefits of using a static frontend?

#explainlikeimfive #webdev

isn't that what a CDN is for?

Top comments (9)

A few reasons why people (like me!) prefer building static sites to server-driven dynamic ones, even ones cached on a CDN:

There's no long-running server process to worry about managing, scaling, or securing.
They're usually cheaper to host, precisely because of (1).
Easier to develop locally. Since static sites aren't usually tightly coupled to a backend server, but rather to files in a git repo or a 3rd-party hosted API, it's easier to set up the development environment.
Better versioning of content. Since many static sites draw content from files in a git repo, it's easy to version all changes to the content within that same git repo.
Better versioning of rendered sites. Likewise, since the output of a static site is, again, just regular files, it's easy to version the outputs in git. Services like Netlify can do this even if the outputs aren't saved to a git repo.
Getting a server's frontend cached to a CDN is comparatively hard. Getting an SSG cached to a CDN is easy since most static site hosts do this automatically.
Tooling. A lot of the buzz around SSGs is very closely related to the buzz around frontend JS frameworks in general. Tools like Gatsby and Nuxt allow frontend developers to not only build single pages but entire multi-page websites, without leaving the comfort of their existing development workflows.
Decoupling the static frontend of a site from its backend makes it easier to support and extend both. The backend just needs to focus on data, the frontend just needs to focus on presentation. It also makes it simpler to reuse the backend data for multiple purposes (such as a website and a mobile app). The static site just becomes a smaller piece of the overall system in the case, as opposed to the server playing multiple roles when it is handling both the data and the presentation.

Max Antonucci • Nov 5 '19

These are basically the exact reasons I went from WordPress to Jekyll for my personal website and could never go back. So much stress in setting up and updating it is now gone. Plus it was relatively easy to work in tools I wanted like Tailwind and Turbolinks.

Jeff Matson 👾 • Nov 5 '19 • Edited

Exactly this.

To add, decoupling the frontend and backend can also be useful for client work. Clients love CMSs like WordPress because it's easy for them to mess with things, but sometimes they mess with things that they shouldn't. By decoupling things, they have the ability to make changes to content, but not to the frontend unless they know what they're doing.

Here's a good read that goes into why people would use a static frontend on a WordPress backend:
northstack.com/static-wordpress-fr...

david duymelinck • Nov 5 '19

The way to create a website is by creating html files and those are shown by the web server. Because people wanted to change those html files without learning html/css/js programmers created content management tools. Those content management tools use a database to collect how the html should be generated. Because the people demanded a lot of features generating html became slow.

That is why programmers came up with caching. Basically this is another database with pre-rendered html that sits between the content management tool and the web server. When people go to an url the database checks if it has html. When it has html it will return it. When it doesn't it lets you go to the content managment tool to generate the html, stores it, and displays it.

The problem with caching is that it still requires a database, it is faster but it still takes time to check.
There are also cases where people want parts of the html to refresh faster than others. For example when a new related page link/preview needs to be shown.

With static site generators you cut out those databases because you create the actual html pages. Each change will regenerate the whole site, which means the html files are always up to date.

If you ask why the programmers didn't use static site generators from the start. The answer is that it used to be much harder to set up web servers than it is at the moment. Now setting up new web servers is done virtually, that means there can be multiple web servers on one machine. Earlier it was one web server per machine.

So now when you change content a virtual web server is set up, the static site generator runs, the old web server gets switched to the new. Than the old web server can be used as a backup or can be removed to make place for future updates.

Kasey Speakman • Nov 5 '19 • Edited

Most of the reason I switched to static front-end are bad experiences with server-side UIs. Primarily, the bad performance of round-trips back to the server to re-render the UI. A browser-based front-end can switch pages immediately and remain responsive while data is loading.

In most of the apps I write, browser (or CDN) caching of whole pages is not desired as data changes are frequent and need to be reflected quickly. It would be impractical to invalidate CDN caches as data changed. Instead, the back-end database (or caching subsystem if necessary) handles caching of data. So repeated requests for the same data remain fast. The front-end assets are still browser/CDN cached, since they don't change as often.

In general, it makes for a good separation of concerns. When I did server-side UI, it was all too easy to mix UI and integration concerns, leading to more difficult maintenance in the long term. With good practices, you could avoid this mix of concerns on server-side UI. But it is less intuitive compared to when front/back are split.

A split front/back also allows two people/teams to work effectively in parallel, provided they agree on the data structures that pass between.

Ben Halpern • Nov 4 '19

isn't that what a CDN is for?

I'd say this is astutely correct. DEV, for example, does compile and serve a lot of pages as static, so for the end user it shouldn't make a big difference whether our site was "statically compiled" or "built by a server and database but cached via a CDN".

I think a lot of it comes down more to the developer experience and reliability of the whole application. There are tradeoffs in terms of what could go wrong and why for each approach, a different set of tools for different styles, etc.

The constraint of static frontends, in the JAMstack universe offers inherent guidance as to how to build a complex application, where typically the shell of the app is shipped and the data comes next. This imitates installable applications in a way that some developers might find helpful for their process.

Hope this helps, if anybody thinks I'm off base with any of this, feel free to weigh in.