This is wildly inaccurate and unrepresentative of the JAMstack ecosystem. I'd consider it downright naive to say there's "very little business value" in static sites.

Consider Gatsby, for example. This is an open source static site generator for React that recently raised $3.8M in funding and formed a business around static site development.

Or perhaps consider Contentful, a headless CMS popular in the JAMstack ecosystem. They just raised $28M in funding late last year.

If your clients are happy with WordPress, that's excellent. By all means stick to WordPress! Where I work, though, are clients are constantly demanding more modern toolsets and pushing the limits of what a website can be. For these clients, WordPress is not a solution in which they are interested. We work with Contentful, Gatsby, React, Serverless and more on a regular basis for some very high profile clients. I can assure you that these clients find substantial business value in these "static" websites.

We've come a long way from the previous generation of static site generators. With the ability to deploy highly dynamic, browser-based JavaScript applications to CDN's, the line between a static and a dynamic site has become increasingly blurred. Gatsby, for example, has started to move away from the term "static site generator" to avoid confusion here.

The clients with which we work are designing and requesting functionality that would not be maintainable were it implemented in a few hours with a suite of WordPress plugins, so reaching for these modern tools is much more feasible in my day-to-day work.

I strongly suggest reading up on some literature and case studies on jamstack.org/ or check out some of Gatsby's showcase to see just how much you can accomplish with these tools. You'll find sites with full login workflows, ecommerce, and more.

I'd argue against there being "little business value" in static sites.

• They're 10000x more efficient than their server-rendered counterparts since they can be purely served off a CDN. You get less bandwidth costs and immense scalability with static.
• Your site is 10000x more secure because it's run off a CDN, not a server, so there's no much malicious code that can run. And even if there was some scrupulous client-side script, it'd be difficult to slip through, since content is controlled (Markdown only basically). No issues with a client installing a rogue plugin that runs mining operations or bloats the DB.
• Since most deployments are through Git, your site is version controlled, allowing you to step backwards to a previous state, easier than a Wordpress backup.
• You can still serve your static content from Wordpress as an API, and benefit from the flexibility of it's content structure (like using ACF).
• Your SEO can be handled completely, like Yoast in WP. It's simply setup by the develop when they optimize the website (often using react-helmet and Markdown metadata).

It really depends on the client. If your client is looking for a product they can iteratively develop themselves, sure, Wordpress and a slew of plugins will work. But those clients probably aren't dealing with scaling issues, or honestly, they don't know what they want and the site's quality will suffer regardless.

At that point, they're not looking for a website, as much as a theme builder. Those are the clients I could recommend Squarespace or Wix and they'd probably be more satisfied with the greater degree of control. and honestly, being cheapos who want to install a plugin for a contact form instead of paying a dev to do it

I spent the last two years championing static sites using SSGs and a variety of headless CMSs in a marketing agency. We ultimately came back to WordPress because our clients requested it and there's a lot of value out of the box. However, I still wanted the benefits of static sites (speed, security, scalability).

That's when we found a service called HardyPress. They host WordPress in an anonymous environment that goes to sleep when you're not using it. A static version of the site is deployed to a CDN when you're ready to publish changes. It's been the best of both worlds for us.

You do still have to think about what it would mean for your WordPress site to be static. Not all plugins will work. HardyPress does provide support for Contact Form 7 and search.

I have no affiliation with HardyPress. I just think it's an ingenious idea.

hardypress.com/

How do you convince a client to a static website?

I show them the benefits, whether it's the savings on hosting/bandwidth costs, or the lightning fast load times of static vs server-side. I also show them the process of adding content, and managing the behemoth.

If by the end of the short presentation they're impressed enough, we go static! If not, I lean towards more common solutions like Wordpress.

It also depends on the situation. I'm obviously assuming the site benefits from being static. If it was a dynamic community site like dev.to, I wouldn't recommend static. It's easier to recommend when there are pros to outweigh cons.

What are your favorite players?

NextJS is great for simpler projects with a few, non-dynamic pages (/about vs /blog/).

GatsbyJS is fantastic for generating larger static sites with dynamic pages. Since Gatsby loads all your content during development and runs the build process, it can generate physical static pages for anything you need. So you can take hundreds of Wordpress blog posts and generate real HTML pages.

Netlify CMS is an admin panel for static websites. It seems to be the solution to brining a human element to static sites, since most are deployed via Git using Markdown -- not the most non-dev friendly process.

I haven't tried it yet, but Jigsaw looks like a great static site option for PHP/Laravel devs.

Solutions like Gitbook, Docusaraurus, React-Styleguidist, etc -- all do an excellent job of creating a (nearly) zero-config build process for documentation. Drop a Markdown file, or run a CLI, and you've got yourself an entire documentation website, looking slick and styled.

Do you have any tricks or tips you want to share?

Make lots of boilerplates (or find/clone some). Most SSG solutions are great, but they're far from fully featured out-of-the-box. GatsbyJS for example has plugins for sitemaps, RSS, etc -- but you have to install and configure it for each project.

Having structured projects for certain situations, like documentation, make the process of rolling out another static site so much easier.

I dont get it, you are the professional, you should decide which solution is the best.

Anyway you can just lay out the advantages of not having a server, which are costs and performance, low complexity and cheaper.

Coming to this thread a little late, but I have recently had to answer this question many times over, so I decided to do a little googling and arrived here...

First, I think the discussion here went a bit off the rails. Some people went down the path of "use the right tool for the job," which is valid, but irrelevant to this thread. The situation I find myself in more often is the client is a candidate for JAMstack, but that means they are also a candidate for Wordpress, how do I convince them to buy my product? The fact is these tools both get the job done but I work faster and deliver a better product in a custom, modern tool chain. So, if you want me to build your website, then these are the tools I use, and I can give this to you with exceptional service, fewer compromises, and at a good price.

In the end, you are the product, not the website. So when I sell a client I sell myself first. So when we arrive at the question of CMS to use, the tension is between wanting ME to build it but not wanting to use something they haven't heard of.

Here's the thing, I don't do Wordpress, or joomla, or drupal ever (anymore). I don't have to make every website on earth. I spent the better part of my early career wrestling with these CMS's, and they worked well for me back then. The issue is, most clients quickly learn they don't want to mess around with design as much as they thought and are constantly calling for tutorials on how to edit the navigation or to add a tag or how to edit something I had to hard code because it wasn't something the CMS supported out of the box.

Then I got DDoS attacks on wp-login pages, databases that weren't backed up, or had to deal with a purchased template that didn't work 100% on the version of PHP they were running on some cheap hosting provider. I even had a template that used to mysteriously wipe the custom CSS for no apparent reason. I've spent hours trying to implement a design that a friend of a friend gave to a client, frustrated at the fact that I knew I could hard code it in thirty minutes if I didn't have to deal with making it totally editable in this CMS or work with X plugin.

Then I got used to version control, continuous deployment, automated testing, and at last found Contentful. I got used to an easy CDN for images that handled all sorts of manipulations as well as being able to do full re-designs later on without ever having to migrate a database or deal with hosting. Clients were actually editing their content only, they got exactly the design they wanted, for the budget they set out for. They were happy and so was I.

The fact is I don't need to build everyone's website. And if someone comes to me that really cannot live without Wordpress I'm happy to point them in another direction. But if you want my team and I to build your site it isn't going to be with Wordpress. I will work my ass off to get you exactly the design you dreamed about and will make sure that you are satisfied enough to never want to go with another developer.

There's a lot of talk about business in this thread without actually talking about a customers number one business need. A reliable, consistent developer that delivers a super fast, awesome website and can be called on over and over again to deliver updates. My advice to you is sell yourself and your company first to the client, then use whatever technology helps YOU deliver on the best possible service to that client.

After reading this thread I realized there's a million technical reasons to not use Wordpress anymore, but very few that clients understand, because what they are buying is a service not a website.

Whether or not there is immense business value in a specific site architecture is the wrong argument to have. There is immense business value in having the right person or team do the job and do it right the first time. I craft websites now that are always backed by a headless CMS but may or may not be JAMstack compatible but I constantly remind myself before every pitch the technology is irrelevant right now, make sure they buy the team first.

1. Using a headless CMS, (check out Sanity or NetlifyCMS) my clients actually feel empowered to edit the site content, knowing that they can't muck up the design or flow of the website.
2. No plugins, core, or theme to update – saving my clients $$$ in maintenance costs.
3. The obligatory comment about performance, security, and free hosting.

But obviously – like others have stated – use the right tool for the job (even if that means resisting the urge to use Gatsby for everything).