Static or Not?

Static website generator? Why don't I use it? Kev Quirk's short comment: Kev uses WordPress:

Want to blog on your iPad? no problem. Want to write on your phone? That's OK. Written on machines that I don't use often? As long as you have a browser, there is no problem.

First of all, it is worth mentioning that using WordPress does not mean that you cannot use static website generators. WordPress has an API that makes it possible to call the API during the build process to build your website. That's what Gatsby does, it has a plugin that exports static websites, while projects like Frontity blur the lines.

But I agree with Kev's reason. For all his reasons, and countless others, running a WordPress website is a perfectly acceptable and often wise choice. I think it's about robustness and functional completeness. Need e-commerce capabilities? WordPress has it. Need a form? There are many excellent plugins. Need to enhance the functionality of CMS? You can control the content type and its content. Need authentication? This is the core function. Want an excellent editing experience? Gutenberg is awesome.

Time and again, I quickly and efficiently build what I want with WordPress, which makes me feel efficient and powerful. But I don't want to talk about WordPress in particular; the same applies to any "classic" CMS. Craft CMS has a GraphQL API natively. We just posted a post about the Drupal Jamstack webinar.

In a relatively new world of static websites, a small thing can end up turning into a long process of research and implementation, and it feels like you are the only person on earth doing it.

Having said that...

What do I think of the static website generator and the world of Jamstack? They are great .

I think there are many benefits to building a website this way. The separation of data and front-end is wise. Very safe. The developer experience is also great, and everything is great for deploying previews and Git-based. The startup speed is amazing (providing HTML services from CDN is a feat).

Just like a classic server-side CMS won't stop you from building static websites, using static websites won't stop you from doing dynamic things — even super advanced dynamic things. Josh Comeau has a great new article that goes into this in depth. He built a nifty little app that does a lot of work with React in his browser, but that doesn't mean he still can't serve most of the content statically. He calls it a "change in mindset" and refers to what you might think you need a database call, but do you really need it? Has the database call occurred and a static file been generated? If not, then part of the content can still be generated statically and the rest can be obtained dynamically.

I look forward to a world where we begin to truly see the best of both worlds. We generate as much content as possible, get as much content as we can through the API that we cannot generate statically, and do not sacrifice the best tools throughout the process.

When to choose a static website...

• If you can, you should consider it because it is unparalleled in speed and safety.
• If you are working on a Greenfield project.
• If your project is built from and uses an accessible API, you can call the API during the build process and use it after the initial HTML is loaded.
• If a static website generator looks great for what you are doing.
• If the cost analysis shows it is cheaper.
• If certain features (such as build previews) are very helpful for the workflow.

When to choose server-side software...

• If you need the functionality of a classic CMS (such as WordPress), and the technical debt from there is too high.
• If you have been deeply involved in a server-side rendering project (Ruby on Rails, Python, etc.) and have not encountered any existing problems.
• If your team has the most expertise in the field.
• If the cost analysis shows it is cheaper.
• If there is no good static solution for what you want to build (such as forum software).
• If you are in extreme situations, such as millions of URLs, and the static build time is too long.

The wrong reason to choose a static website...

• You need to use a server. (Why? You can still call the API on the server at build time or runtime.)
• You need authentication. (Why? Jamstack can perfectly implement authentication with JWT, etc.)
• You haven't even considered the Jamstack approach.

The error reason for choosing server-side software...

• You haven't even considered the Jamstack approach.
• Because you think using comfortable/existing/classic/mature/supported well-supported tools will prevent you from building anything statically.
• Questions like SEO. (If anything, static rendering should perform better. However, it is understandable if the shift to static means turning to client calls to get product data, etc.)

The above is the detailed content of Static or Not?. For more information, please follow other related articles on the PHP Chinese website!