You also get to defend the Wordpress site against hackers. Regular updates being managed for core. Plug-ins and Themes that introduce security holes. Extra server load when baddies target your sites api.
Static sites have been my goto for years. Especially after Netlify launched and a free tier became available.
Now cloudflare pages offers free hosting with basically unlimited hosting for personal sites.
I couldn’t go back to wasting time managing a personal site with Wordpress.
If your website/blog is primarily a website/blog I think Wordpress is a perfectly fine choice (maybe overkill for personal use, solid for teams of authors). For me the problem starts once one wants to start adding more web application like features to it. Obviously you can build everything on top of it, but you pretty much need specialized developers. WP development is just too foreign and unattractive for most fullstack developers I know. Also its database model can be a pain to deal with.
Don't know what the best solution is. I'm currently testing Strapi CMS on the backend with a NextJS frontend which should give me hybrid between pre-rendered/ssr as well as dynamic parts while having a consistent development experience across all of them that is very familiar to developers. Definitely not as quick to launch experience as slapping together landing pages in website builders and Wordpress with pre-made templates, but I'll see how it goes.
> Disqus uses, and also engages third party ad partners and affiliates who use cookie IDs, device IDs (including mobile), hashed email addresses, IP address, ISP and browser information, demographic or interest data, content viewed and actions taken on the Service or Partner Sites, including information about the websites you’ve viewed and advertisements you’ve interacted within order to provide you with more relevant advertising targeted to your preferences and interests derived from your interaction with the Service, Partner Sites or other third party websites.
> We may sell or share your personal data with the parties set out below for the purposes set out in the table in paragraph 5 above.
If you're going through the trouble of self-hosting something, why would you then outsource commenting to a company that sells your visitors data? Half the point of running your own platform is to get away from the nexus of dark patterns that have taken over the modern web, otherwise you might as well ditch Wordpress and run your blog on Facebook.
1. Got comments and pingback with Antispam
There are plenty of free/paid, SaaS, self-hosted comment systems to choose from.
2. Install a nice (Elastic) Search plugin with a decent search engine (name your preferred option).
Same as above, for most blogs something like http://elasticlunr.com/ can get the job done really well.
3. HotSwap on the fly themes
Most static site generators support this.
4. Improve performance via cache plugins (there are a lot of them).
The point of static sites is you don't really need to cache data. It's already generated ahead of time. You're just serving the content.
Oh man, I always find it funny in a slightly schadenfreude sort of way when someone swaps to a new platform, goes to talk about how great that new platform is, and then the platform can't handle basic load.
That being said I do use Jamstack quite extensively, it can trivially handle huge loads due to it being mostly just static files that can be served through CDNs. This seems like it has nothing to do with Jamstack but it's still funny.
I should of moved my blog over to Jamstack.
I put this link out and then realised there was a magic link exploit in the ghost version I was using. I took it down to make some emergency changes...DOH!
There is a certain irony on this. My blog site uses ghost not Jamstack. I was using an old version and it had a pretty bad exploit bug related to magic links.
I took the site down to patch and then put it back online...If I'd only used SSG for it too.
It's important to know that WordPress can be used as a headless CMS. There is active work in that area with plugins like WPGraphQL[0] and frontend frameworks like Faust.js[1]. So you don't _need_ to leave WordPress in order to use some of the tools and gain the scaling benefits of JAMstack.
There's another approach which works surprisingly well: If you use Nginx and PHP FPM you can utilize Nginx FastCGI cache [1] to cache dynamic contents. That even allows serving a stale version of an asset while fetching an up-to-date version in the background, avoiding the occasional slow requests for expired items.
With such a cache enabled Wordpress sites feel like they're static pages, while they still offer all features Wordpress offers.
I don't disagree. There's lots of options for the content part. I guess the thing I was trying to point out here was that I didn't need a CMS. The content is static, the site is basically a brochure. I was happy just writing static HTML.
It doesn't even have to be this hard -- just be familiar with how the WordPress database lays out its custom post types.
I wrote a Jekyll Generator plugin that just makes a SQL query to the WordPress database and generates all of the sites' content a good 5 or 6 years ago. It's fairly trivial work.
You're right and your approach works well for all the mostly static content. The tools above are useful if you want to enable things like authentication/gated content, e-commerce etc while also having some static content.
WP also has an HTTP-speaking API, but yeah, I've done the "extract posts and pages directly from the DB" thing too. It's maybe half a day if you've never looked at the WP DB schema before, mainly figuring out which tables & fields you need to look at to select only published items. Probably minutes if you're already familiar with it.
I love how so many these "just use static html files" posts includes abandoning WYSIWYG interfaces. It's like switching from MS Word to writing LaTeX in Vim.
If you don't need the features Wordpress exists for, static html is great. If you do... Wordpress actually works fairly well if you use a caching plugin.
The problem could be more that a non-technical person in the sporting club you've built the website for may not be able add new or updated content themselves without that WYSIWYG editor.
If you are a member at this club it's fine, but if you're just a local trying to help the club you wouldn't want to be involved in each content update all the time.
This is a super critical point.
I am a member and ran the site for 2 years prior to this change. I was the only person that logged in.
Honestly this technical solution isn’t for every scenario but I felt confident that nobody would be updating the site in WYSIWYG. Comes down to what you need. There are many tools for many jobs.
If you don't need any of the features MS Word provides and you are proficient in using LaTeX and vim... yes.
That's kind of my point. If you can avoid using a heavyweight tool whose features you don't need... don't use it. I highly recommend finding any alternative that would suit your needs. You will be a lot happier.
The problem is the constant unspoken assumption that heavyweight tools shouldn't be used at all.
If it's unspoken why assume that assumption is being made? I don't see anything to that effect in the article, and while I can't speak for others I certainly don't have any objection to other people using whatever tools they like. I'm just glad there are alternatives I prefer.
I know the personal server architecture of a bunch of docker containers reverse-proxied behind Nginx is really easy and popular but it's a lot of overhead and kills your throughput if you don't aggressively cache in the frontend.
Look at the proxy_cache_* options and you'll be able to handle the traffic with ease.
As a long-time Pelican (CSS, no Javascript, serverless) static site generator, I am intrigued to know if this Javascript-free approach can be continued with this Astro and maybe Sevlte.
It has to be JS-free because I am a vulnerability researcher on JS/WASM-based “file-less” malware.
Only advices (at this critical juncture) are to keep your website’s CSP very tight, your APIs authenticated. and protected by MFA especially to supplant PII with website-specific index/sequence numbers. Also to mandate HTML5 nonce element usages on all things referenced.
I think I'm a little confused as to what differentiates "JAMStack" from modern decoupled architectures. My website starts up a Go web server and then serves the output of Nuxt. The backend was primarily generated using an OpenAPI generator and uses decentralized auth (JWT/JWE). The backend seems to align to what https://jamstack.org calls a "headless CMS" other than the fact that the editor is built into the frontend in the same decoupled fashion.
One thing I'm not too sure on is, can a frontend served from a CDN do SSR? It became pretty apparent over the course of developing my blog that hybrid CSR and SSR was optimal.
At the risk of inciting an OT debate, might it make more sense to post the https:// link (https://thomasridings.com/goodbye-wordpress-hello-jamstack/), which does also work? And relatedly for the author since they are commenting, perhaps you should setup an auto-redirect?
Presumably this is a blog. A static file server might've handled the HN hug of death without a cache.
Any other sort of "stack" is going to need caching, varnish, cdn, etc.
EDIT: huh, that site claims the JAMstack is exactly a set of static pages...
"With Jamstack, the entire front end is prebuilt into highly optimized static pages and assets during a build process. This process of pre-rendering results in sites which can be served directly from a CDN, reducing the cost, complexity and risk, of dynamic servers as critical infrastructure."
People are jumping to conclusions and bashing jamstack/static without checking the source (it's not a static blog, it's ghost:node+sqlite/mysql) or reading the article (it's not about the blog, it's about https://hillcroftlacrosse.com).
Yes jumping to conclusions to disprove OP is a popular joke format that the internet seems to dig
You and the top level are doing the same but to the commenters- it's just one step further down and I feel the jokey aspect has been lost in favour of the internet's favourite response type: mild outrage over nothing
Sorry, I could not understand most of what you meant, but regarding that I am "jumping to conclusions" too I disagree.
Comments making fun of a site praising jamstack being down are jumping to two conclusions: the site is itself is using jamstack and the praise of jamstack is for use in blogs. That's what the commenter above pointed out.
When I point out that these commenters are jumping to conclusions I am not jumping to conclusions. It is pretty clear that they are associating the use of jamstack and the site being down.
> The backend API calls are all serverless and instantiated on request.
I think the "Jamstack" is the single worst trend to ever happen to static site generators as both an author and a reader. The whole appeal of static sites to me is that all the files can live in one place. As a site author this minimizes the number of failure points and things I need to pay for, and as a reader it minimizes my trackable footprint online since connections only need to go to one place.
The "Jamstack" throws all of that out and encourages people to glue together as many third-party APIs as possible that they get to keep paying for forever and that cast the surveillance net ever-wider around readers. Of course nothing stops people from Missing The Point and throwing Google Analytics on a totally-static site, but "Jamstack" normalizes that behavior. This is the opposite of progress.
> The "Jamstack" throws all of that out and encourages people to glue together as many third-party APIs as possible that they get to keep paying for forever and that cast the surveillance net ever-wider around readers. Of course nothing stops people from Missing The Point and throwing Google Analytics on a totally-static site, but "Jamstack" normalizes that behavior. This is the opposite of progress.
To be fair jamstack does not imply 3rd party APIs. A valid jamstack could all be on your own premises, just that every API is deployed independently.
While trying to understand what Jamstack actually is (or adds to simply using a SSG) I lost some faith due their site not functioning well in mobile safari. The filter buttons on the SSG page do not respond at all, and when you click a TOC item, the content silently loads below the fold (seems like we should jump down to the content).
Ye I think this could get messy at a point.
This project ended up with 2 or 3 API endpoints which I pushed up as serverless to give me some centralisation.
Not sure how happy I'd be if I needed to stitch 50+ API services together but not every project has the same requirements and we shouldn't assume the same solution.
Wordpress definitely has its issues. In this case I think it would've made more sense to just statically compile your wordpress site into HTML and serve that through traditional means (e.g. Azure Blob, Amazon S3, etc), than to go through all the trouble of converting.
I'd agree on a new project, jamstack makes sense here.
So there was a part of the story I haven't told.
The wordpress site was painfully slow to load and while I like the look of the theme it was costly from performance perspective.
I did try to render the wordpress site out to html but I just didn't find it plain sailing and after a couple of hours research/testing look for a new direction.
I've also really liked Netlify's free offerings as well. Same idea as DO's Apps, and it will do builds on pushes to repos, and amazingly it's free too! I have a slew of low-traffic sites, all with custom domains and on-demand builds (mostly Gatsby or custom CRA apps), hosted over at Netlify for $0.
The operating assumption is that you're still going to be doing dynamic work on the site but that it will all be client side.
You'll end up rendering huge JSON blobs with your public data in your markup for your client side JavaScript to do things with. Text is cheap. The client side does all of the heavy lifting but you'll probably need things like accurate time, which you can get by rendering pages using NGINX SSI module to render server time on pages. Obviously this won't stop some users from manipulating this information maliciously so you have to be careful what you use and where.
Naming this thing was always amusing to me though -- I'd been working with clients to switch from WP to essentially JAMstack years before it was ever named anything. Then suddenly I', in the JAMstack business.
This wasn't so much the technical stability problem; time will be the real test here. With Svelte I was able to very quickly scan the repo and pickup where I left of, even with long gaps between work.
1. Got comments and pingback with Antispam
2. Install a nice (Elastic) Search plugin with a decent search engine (name your preferred option).
3. HotSwap on the fly themes
4. Improve performance via cache plugins (there are a lot of them).
I do not run JetPack to avoid even Wordpress.com lockin. Also with PHP 8.x and code cache enabled the overall WordPress speed is very high.
So how can I get all this feature on static site generators without lockin for comments/search/moderation (just asking)?