I like static site generators, but on my Wordpress Blog I can<p>1. Got comments and pingback with Antispam<p>2. Install a nice (Elastic) Search plugin with a decent search engine (name your preferred option).<p>3. HotSwap on the fly themes<p>4. Improve performance via cache plugins (there are a lot of them).<p>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.<p>So how can I get all this feature on static site generators without lockin for comments/search/moderation (just asking)?
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.<p>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.
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.<p>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.<p>[0] <a href="https://www.wpgraphql.com/" rel="nofollow">https://www.wpgraphql.com/</a>
[1] <a href="https://faustjs.org/" rel="nofollow">https://faustjs.org/</a>
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.<p>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 author<p>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.<p>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.<p>It has to be JS-free because I am a vulnerability researcher on JS/WASM-based “file-less” malware.
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 <a href="https://jamstack.org" rel="nofollow">https://jamstack.org</a> calls a "headless CMS" other than the fact that the editor is built into the frontend in the same decoupled fashion.<p>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 <a href="https://" rel="nofollow">https://</a> link (<a href="https://thomasridings.com/goodbye-wordpress-hello-jamstack/" rel="nofollow">https://thomasridings.com/goodbye-wordpress-hello-jamstack/</a>), which does also work? And relatedly for the author since they are commenting, perhaps you should setup an auto-redirect?
Jeez, the vitriol here.<p>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 <a href="https://hillcroftlacrosse.com" rel="nofollow">https://hillcroftlacrosse.com</a>).
> The backend API calls are all serverless and instantiated on request.<p>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.<p>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.
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 <i>converting</i>.<p>I'd agree on a new project, jamstack makes sense here.
I found DigitalOcean's Apps offering excellent for a bunch of static sites I've built.<p>3 free sites, followed by $3/month for each additional static site.<p>And it provides the same convenience of pushing to Github main (or branch of your choice) and having it automatically built and deployed.
There is something funny about this but HN killed my blog.
Added the Markdown content here: <a href="https://github.com/Ridingst/hillcroft-site" rel="nofollow">https://github.com/Ridingst/hillcroft-site</a>
<i>> I just trusted Svelte to deliver on my goals, especially picking it up quickly after six months away.</i><p>Is there any basis to believe Svelte is any more stable then any other JS framework?