Static or Not?

A quick opinion piece by Kev Quirk: Why I Don’t Use A Static Site Generator. Kev uses WordPress:

Want to blog on my iPad? I can. Want to do it on my phone? No problem. On a machine I don’t normally use? Not an issue, as long as it has a browser.

First, it’s worth understanding that by using WordPress it doesn’t opt you out of using a static site generator. WordPress has an API, and that opens the door to hit that API during a build process and build your site that way. That’s what Gatsby does, there is a plugin that exports a static site, and projects like Frontity really blur the lines.

But I agree with Kev here on his reasoning. For all his reasons, and 1,000 more, it’s a perfectly acceptable and often smart choice to run a WordPress site. I think about it in terms of robustness and feature-readiness. Need e-commerce? It’s there. Need forms? There are great plugins. Need to augment how the CMS works? You have control over the types of content and what is in them. Need auth? That’s a core feature. Wish you had a great editing experience? Gutenberg is glorious.

Time and time again, I build what I wanted to build with WordPress quickly and efficiently and it’s made me feel productive and powerful. But I don’t wanna make this specifically about WordPress; this can be true of any “classic” CMS. Craft CMS has a GraphQL API out of the box. We just posted about a Drupal + Jamstack webinar.

In the relatively new world of static sites, a little thing can end up a journey of research and implementation, like you’re the only third person on Earth to ever do it.

Now all that said…

What do I think of static site generators and the Jamstack world? They are awesome.

I think there is a lot to be said about building sites this way. The decoupling of data and front-end is smart. The security is great. The DX, what with the deploy previews and git-based everything is great. The speed you get out of the gate is amazing (serving HTML from a CDN is some feat).

Just like a classic server-side CMS doesn’t opt you out of building a static site, building with a static site doesn’t opt you out of doing dynamic things — even super duper fancy dynamic things. Josh Comeau has a great new post going into this. He built a fancy little app that does a ton in the browser with React, but that doesn’t mean he still can’t deliver a good amount of it statically. He calls it a “mindset shift,” referring to the idea that you might think you need a database call, but do you really? Could that database call have already happened and generated a static file? And if not, still, some of it could have been generated with the last bits coming over dynamically.

I can’t wait for a world where we start really seeing the best of both worlds. We do as much statically as possible, we get whatever we can’t do that way with APIs, and we don’t compromise on the best tools along the way.

When to go with a static site…

• If you can, you should consider it, as the speed and security can’t be beaten.
• If you’re working with a Greenfield project.
• If your project builds from and uses accessible APIs, you could hit that API during the build process as well as use it after the initial HTML loads.
• If some static site generator looks like a perfect fit for something you’re doing.
• If a cost analysis says it would be cheaper.
• If functionality (like build previews) would be extremely helpful for a workflow.

When to go with server-side software…

• If you need the features of a classic CMS (e.g. WordPress), and the technical debt of going static from there is too high.
• If you’re already in deep with a server-rendered project (Ruby on Rails, Python, etc.) and don’t have any existing trouble.
• If that is where you have the most team expertise.
• If a cost analytics says it would be cheaper.
• If there aren’t good static solutions around for what want to build (e.g. forums software).
• If you have an extreme situation, like millions of URLs, and the build time for static is too high.

Bad reasons to avoid a static site…

• You need to do things with servers. (Why? You can still hit APIs on servers, either at build or during runtime.)
• You need auth. (Why? Jamstack is perfectly capable of auth with JWTs and such.)
• You haven’t even looked into doing things Jamstack-style.

Bad reasons to choose server-side software…

• You haven’t even looked into doing things Jamstack-style.
• Because you think using comfortable / existing / classic / well-established / well-supported tools opt you out of building anything statically.
• Something something SEO. (If anything, statically rendered content should perform better. But it’s understandable if a move to static means moving to client-side calls for something like product data.)

The post Static or Not? appeared first on CSS-Tricks.

from CSS-Tricks https://ift.tt/2xdDezr
via IFTTT