JAMstack is cool. If you haven't heard of Static Page Generators and Headless CMS yet, now's the time.
However, if you are familiar with it, and...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
Can I just hop on here to say that this is the most gloriously civil end to a discussion that I've ever seen on the internet.
^ seconded
Use this and you have a full funcional site in matter or minutes:
github.com/netlify-templates/one-c...
Let's stop here, because we are not on the same page. Let's agree that we don't agree.
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/
I haven't heard of HardyPress, but I will take a look at it.
I know about projects with Wordpress REST API as a backend with static page generators. This is similar approach, I think.
Thank you for sharing.
Yes, the WordPress REST API is another option, but it isn't used with HardyPress. You build your site like you normally would (besides not being able to use every plugin) and it deploys a static version of your WP frontend. Yes, this means your templating is still done in WP. We settled on using Timber to make that part less painful. :)
upstatement.com/timber/
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.
I haven’t done a lot of client work but I’ve definitely had some hair-pulling interactions where they had heard about some random technology or wanted me to use the same stack some other project is using for completely arbitrary reasons.
I’ve learned how to really get this out of the way early. Lay down the law in this regard.
That is precisely my point, which advantages, how to present them, and so on. I am a professional, and I know all that, but I am interested in how others do it to help others, not just me.
Ah I see, then you should have started with how you solved this problem in the past, what worked and not, then others can add extra info.
I am sorry for the misunderstanding.
Do you have anything to share now that you know the intention of this discussion?
No sorry, I was just trying to put myself in your shoes and that is all I came up with.
I stopped doing freelancing and working with the end customer many years ago, I felt like I will live less if I kept doing it 😁.
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-loginpages, 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.
Great point of view. I agree 100% about selling yourself and your services first. I don't see a problem in working with WordPress, mainly because I am rarely in charge of the backend, database, or security.
Thank you for the great response.
(100% sincere, no sarcasm here.)
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).
I"m going to argue a different way in favour of the 'JAMstack'; I hate marketing buzz, but whatevs.
This is the business value from what I can see; I'm newer to SPGs, so I could be wrong, but it's my current opinion.
Static sites do the following:
They are very very fast. Most WP sites that are setup on a budget are not fast and actually require hiring the right developer, not just 'any' developer to get it to serve quickly. Not the case with SPGs, if you can write HTML, CSS and JS then you are booming; it's very hard to make a slowly served site I'd wager.
Clients think they can just slap in a plugin and get a rocking; this is why wordpress is slow and they don't know who to call or what to do and they are channelling money into SEM and SEO and losing money there hand over fist; this is a huge value.
The code tends to be more easily read. This means if they call me up and say 'hey Roger can you create an xyz or do xyz', often I can do it in an hour or so and it's still fast and it's still easily read by the next guy.
Backups are built into the system al a github/git.
Security issues are basically null. In comparison to any surface like WP, effectively using Hexo, et all is a zero risk scenario.
Price. Outside of tools like Contentful and their type, the pricing is as close to $0 as you can get, which means I'm getting the lions share and that is good for me and good for my investment in good customer service.
Important caveats:
With Netlify and CloudCannon content management is included and no longer an issue of paying some over charging headless CMS provider extortion rates to just serve content.
Most SPGs come with Let's Encrypt and CDN built in and not as a value add either.
Honestly I'm very happy to have finally sold a client on a SPG and while down the road they may need to include a more diverse solution; today it'll be a great launch site for them handling so many potential scenarios without additional work on my or their part.
PS. This doesn't at all dismiss wordpress; that would be silly to say one over the other, just simply that SPGs have a ton of value and are very valid from a business use case.
Security :) (and no update every week like Wordpress or Joomla)
Performance is a good point too.
I use Pelican (only because it's Python and I can read the code/develop plugin)
Just an advice: if you never tested static sites and if you are affraid to be limited by markdown syntax, some plugin/extension allow personnal syntax to be exported in your own html.
Thank you for your comment.
A genuine question: how far you can go in your experience? Do you know of any really complicated website made with JAMstack? Since your a Wordpress developer, any pro and cons between the two approaches?
Thanks!
As I already stated in this comment, I have developed websites on Jekyll, Middleman, Hugo, and Hexo so far.
The most complicated website that is built on JAMstack that I know of is Smashing Magazine.
In my opinion, Wordpress and SPG are two different worlds. The first one is a global solution with an enormous amount of themes, plugins, and solutions. In the last couple of years, the platform moved forward, and it has many great features, but there are still too many options, settings, and cluttering. SPGs are unique, they could be developed specific to users needs, they could be extended by some customizations, plugins, shortcode, etc. But delivering content over CDNs as static files, that is powerful. And it could be free if you are using Netlify free plan.
Thank you!
I recently moved a bank from sitecore over to netlify, algolia, contentful using Gatsby and react.
The biggest selling point? Cost, security and flexibility.
Moving to jam stack offers huge potential for the future I reviewed all of the architecture patterns and with the bank wanting their content produced once but available anywhere it made real sense to move away from a tightly coupled traditional CMS.
One huge benefit of headless and the JAM stack is the incremental movement you can make.
We started out using just the static website and blog posts, product info and other content was all produced in markdown files. This got us to a point of replicating what we had without needing sitecore. It was also insanely fast without any database connections and Gatsby handling the build.
After that we added in contentful and removed the markdown where appropriate.
I would argue against the "clients can also manage their content themselves". As someone who has been a part of a group for 3 years. They are techno-phobic, yet willing to trust an outside vendor to manage their website including login credentials and personally identifiable information of their users.
If they could allow themselves to not have a login feature and just post their content publicly, a static website would serve their needs greatly and would reduce the cost of having someone "maintain" it.
I'm all for empowering clients. But when you've worked as long as I have, you've probably come across some clients that will nickel and dime you for services.
The kind of client that gets upset over charges for "updating the website" when you have to spend time swapping text and images they're indecisive over (and wanted moved around 3-4x). The same client that'll often insist to do work themselves, or in some other cases, outsource labor to cheaper places, and in even worse cases -- come back with broken code from that cheaper dev and ask you to fix it.
I'm not saying every client is like this, but I will say that these are the clients who prefer "simpler" plug and play solutions like Wordpress. It's the kind of client that doesn't respect your time as a professional. The same kind of client that'll pervade any service industry (like plumbing, car detailing, etc).
Had this conversation recently of static sites VS something like Wordpress, and the truth is, at the end of the day, clients really don't care about technologies, they care about scalability, SEO, posts, and Plugin support. Using something like Gatsby for static site generation isn't the best solution unless you use Netlify. In conclusion, using static sites without a service like Netlify is a huge NO.
Yes, I am using Netlify for every project.
You don't sell them a static website, because that sounds lame. You sell them a professional website with optimized loading and rendering performance and improved accessibility and SEO compliance, which is - what an amazing coincident - most easily achieved with a static web site and maybe some progressive enhancement with javascript.
Static Sites are cheap and secure.
My Favourite is Hugo, because of performance even with thousands of pages.
Use 3rd party api for authentication and comments etc.. Like Auth0 and Disqus
I think static sites have a much lower barrier for entry for many clients, especially when they just need simple feedback forms or contact pages. I made a static hosting service for my classmates to use for their web projects. We weren't taught about deployment as a part of the class, and they needed an easy way to get their projects online.
Thus, dragdrop.site
I was kinda inspired by Glitch, but they needed a way to upload static files that they'd already written, and allowing them to drag files into the browser to deploy to a site is a pretty cool experience.
If a site does not have Dynamic parts or they don't really want to update content themselves you don't even have to SELL IT.
The real benefits I see on general is
1) the site can be as fast as it can be as it needs no database lookups at runtime
2) best security as there will be no login functionality to be compromised
3) Those can probably translate to reduced maintenance costs depending on the automation you set for the deployment workflow and the frequency of deployment
EDIT: Just realized the post was from last august
Every comment counts. Thanks, Giorgos! 👍
So far, clients asked me to build them a static website.
I have built websites on Jekyll, Middleman, Hugo, and Hexo. I cannot say which one is my favorite, but I must admit that Hugo is fast.
Here's my two cents:
If you are using Netlify, you could add code snippets, like tracking snippets, right from Settings -> Build & deploy -> Post processing -> Snippet injection:
I fully agree with you, but I'd rather Hexo. It's more flexible than Hugo. Jekyll is very popular, because it's supported by github, but it's slower than Hexo and Hugo. I would also like to try a GatsbyJs that becomes more popular
Well, sometimes you cannot choose. I am using Hexo for my website, but if a client wants a website on Hugo than you build the website on Hugo.
Also, I don't know which one is more flexible, but I managed to fulfill all client's requirements no matter which generator is in use. If you have problems, the community will help you. For example, I had a problem, posted it on Hugo Discourse, and got an answer in minutes.
You are absolutely right. But if you do your own projects you don't need a clients ideas)) And that's why I like Hexo. It's more friendly with themes and plugins ;)
I can agree with Ankush. Wordpress just works. It's not perfect, but works. Bussinesses don't have years, they need it ASAP. Nothing can beat WP in that.
My first boss said it best, "I use the language and platform that makes me the most money."
A static site could be run on CDN like netlify for free.
You can sell it on safety. Tell them about security benefits.
I don't get it : when you click on getting started, there's nothing about getting started but about best practices :)
I would disagree. All those things could be done in SPG. It takes time and knowledge, but it is worth it if performance and security are a requirement.
I don't know much about SPG admittedly, but I know a lot about wordpress websites and specifically how to optimize them.
There is virtually no performance difference with the core platform. Performance is only sacrificed by unnecessary plugins for one function, bloated themes with built-in page builders, and poor image/code optimization by the designer/developer. What you save in milliseconds by building a site statically is instantly wasted by longer development times.
In terms of security, every site is at risk. Wordpress, when managed properly, is just as safe as a static website. With plugins like WordFence you could even argue it's safer because I can easily blacklist suspicious IP's.
With all of that being said, if I ever want to do things a specific way I have simply just said this is the best way. I'm the developer, I'm the one building it, my clients pay me for my expertise and knowledge. It's literally that simple.
Fair point. But you forgot there are clients that need smaller websites with smaller budget for development. You cannot say SPG is not good choice for those clients, IMO.