Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
I am confused, did I miss the part where you simply cache pages on WordPress so you don’t hit the database?
I mean they even make the plugins for page caching “non tech” friendly, unlike SSGs.
I mean that is the whole argument for a static site generator presented here, that you are serving static files?
Other than cost, which is a valid reason for micro sites, distribution to CDNs and not needing a database are the big winds for SSG surely?
Don’t get me wrong I am not a fan of WordPress but I have seen it run sites that have thousands of visitors on modest hardware.
Wordpress sites are slow due to crappy plugin choices, bloated themes etc. It is not WP itself that is slow and trust me I have seen enough sites on SSG be slow as well as the front end tends to be the bottleneck.
Yeah, but I sort of feel that caching is like dealing with the symptoms of the problem instead of the underlying problem (if that makes sense). I do agree with the fact that SSGs are not for everyone, but developers might work better with them than WordPress
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
I chose to move from Wordpress to SSG (using two CMS approaches: NetlifyCMS or raw Markdown in git for my own site; offline Wordpress and an SSG plugin for a friend who likes WP), primarily for: cost reduction - CDN hosting is massively (1000+ times) cheaper than a VM; security posture improvement (a cloud company problem, not mine now); lower operational hassle (no more patching, DB backups, etc.)
The problem is that a major cache plug-in for WP just released an update with a bug that broke caching in an impossible to debug manner. This just isn't an issue with SSGs. Plus there are plugin vulnerabilities, etc.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
That still isn't a WordPress problem as per my first answer.
It is a plugin problem and SSGs will suffer a similar fate with broken plugins as they gain popularity and people with less experience start developing with them.
As for plugin vulnerabilities, SSGs use plugins too and most are served via something like npm (which can be an additional vulnerability as people just blindly trust packages).
Yet again I would stress I am not a fan of WordPress but none of the issues are an issue with WordPress itself and SSGs are far from immune, they are just not widely used enough to justify the effort of attacking them (yet).
I understand what you're saying, and WP isn't inherently bad.
There is something different about the dependencies, though. WP plug-ins are code running on your production server. That is inherently more dangerous (to my server) than an npm script that runs in the browser, or a plugin that emits static HTML code that I upload to S3. The npm script can't bork my production DB and take down my site because there isn't a production DB (speaking strictly about page/article content).
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
All valid points and I am playing devils advocate in all of this as I actually like SSGs, I am in the middle of working on a hybrid system as we speak.
Just sticking up for poor old WordPress (poor thing with its dominant market share 😂😂).
I just made a bunch of arguments against WP to the marketing department and inadvertently made a new project for my team to redo the site with an SSG. Maybe I'll tell them you said it's not so bad 🤣🤣
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
SSG doesn't need caching. WordPress plugins like WP Super Cache would generate static HTML files but those are basically just snapshots of dynamic WP pages. It's very difficult to manage that if your site is dynamic. You would need to re-generate those snapshots quite often
Yeah it's true you could achieve that with something like fragment caches. But honestly it seems to be a lot of work and I'm not sure if it's worth it. As someone said above it's dealing with the symptoms of the problem instead of the actual problem
I hear you on that. Jamstack is missing the great user experience that WordPress enjoy in exange for developer's experience. Headless CMSs are closing the gap, but there's still a big gap there. Especially in regards of dynamic data rendering. On the other hand, I sees amazing possibilities from decoupling the front-end from the data/API. This is where I'm investing and I feel there is so much that remains to be seen in that area.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am confused, did I miss the part where you simply cache pages on WordPress so you don’t hit the database?
I mean they even make the plugins for page caching “non tech” friendly, unlike SSGs.
I mean that is the whole argument for a static site generator presented here, that you are serving static files?
Other than cost, which is a valid reason for micro sites, distribution to CDNs and not needing a database are the big winds for SSG surely?
Don’t get me wrong I am not a fan of WordPress but I have seen it run sites that have thousands of visitors on modest hardware.
Wordpress sites are slow due to crappy plugin choices, bloated themes etc. It is not WP itself that is slow and trust me I have seen enough sites on SSG be slow as well as the front end tends to be the bottleneck.
Yeah, but I sort of feel that caching is like dealing with the symptoms of the problem instead of the underlying problem (if that makes sense). I do agree with the fact that SSGs are not for everyone, but developers might work better with them than WordPress
A static site generator is literally a site like wordpress but with an extra build step. Wordpress + caching takes that build step away.
If you ignore all the problems with WordPress, then yeah.
I chose to move from Wordpress to SSG (using two CMS approaches: NetlifyCMS or raw Markdown in git for my own site; offline Wordpress and an SSG plugin for a friend who likes WP), primarily for: cost reduction - CDN hosting is massively (1000+ times) cheaper than a VM; security posture improvement (a cloud company problem, not mine now); lower operational hassle (no more patching, DB backups, etc.)
The problem is that a major cache plug-in for WP just released an update with a bug that broke caching in an impossible to debug manner. This just isn't an issue with SSGs. Plus there are plugin vulnerabilities, etc.
That still isn't a WordPress problem as per my first answer.
It is a plugin problem and SSGs will suffer a similar fate with broken plugins as they gain popularity and people with less experience start developing with them.
As for plugin vulnerabilities, SSGs use plugins too and most are served via something like npm (which can be an additional vulnerability as people just blindly trust packages).
Yet again I would stress I am not a fan of WordPress but none of the issues are an issue with WordPress itself and SSGs are far from immune, they are just not widely used enough to justify the effort of attacking them (yet).
I understand what you're saying, and WP isn't inherently bad.
There is something different about the dependencies, though. WP plug-ins are code running on your production server. That is inherently more dangerous (to my server) than an npm script that runs in the browser, or a plugin that emits static HTML code that I upload to S3. The npm script can't bork my production DB and take down my site because there isn't a production DB (speaking strictly about page/article content).
All valid points and I am playing devils advocate in all of this as I actually like SSGs, I am in the middle of working on a hybrid system as we speak.
Just sticking up for poor old WordPress (poor thing with its dominant market share 😂😂).
I just made a bunch of arguments against WP to the marketing department and inadvertently made a new project for my team to redo the site with an SSG. Maybe I'll tell them you said it's not so bad 🤣🤣
How would you cache a shopping cart website with many pages and components changing all the time?
And how would you manage the same with a SSG?
There are fragment caches, object caches, partial page caches etc.
SSG doesn't need caching. WordPress plugins like WP Super Cache would generate static HTML files but those are basically just snapshots of dynamic WP pages. It's very difficult to manage that if your site is dynamic. You would need to re-generate those snapshots quite often
Yeah it's true you could achieve that with something like fragment caches. But honestly it seems to be a lot of work and I'm not sure if it's worth it. As someone said above it's dealing with the symptoms of the problem instead of the actual problem
I hear you on that. Jamstack is missing the great user experience that WordPress enjoy in exange for developer's experience. Headless CMSs are closing the gap, but there's still a big gap there. Especially in regards of dynamic data rendering. On the other hand, I sees amazing possibilities from decoupling the front-end from the data/API. This is where I'm investing and I feel there is so much that remains to be seen in that area.