Really the problem is that the standard solution hasn't improved. Backends are still a hassle in the 2020s. People keep reinventing CGI.
Every now and again I think "why doesn't someone just produce a simple standardised solution that would be cheap to host and easy to write", and have to lie down until the madness goes away.
Is this C vs Rust again? (it's a joke, but go ahead, downvote).
Maintaining a static site is easy and places like github pages will host it for free; you can put a "SPA" in there if you like for no additional cost. But as soon as you need a backend it gets more complicated and expensive. Still cheap in absolute terms, but relatively more complicated. Oh and you need to keep an eye on it for security. I know the long list of reasons for this situation, but I'm questioning why it has to be this way.
Back in the 80s there were proprietary monolithic single-user systems for producing what were effectively interactive databases, such as dBase and FoxPro. There was also the legendary programmable hypertext system HyperCard. And yet developing a small web application to do something that could be knocked up with a few screens of dbase or hypercard is much more time-consuming.
Dokku install:
$> wget https://raw.githubusercontent.com/dokku/dokku/v0.19.13/bootstrap.sh;
$> sudo DOKKU_TAG=v0.19.13 bash bootstrap.sh
Create an app:
On the server:
$> dokku apps:create application_name
$> dokku postgres:create application_db
$> dokku postgres:link application_db application_name
On the client:
$> git remote add dokku ssh://dokku.servername.tld:22/application_name
$> git push dokku master
$> dokku letsencrypt application_name
$> dokku letsencrypt:cron-job --add
For a static site, you literally push a repo with a `.static` file and an `index.html` in the root dir (you can do more complicated things, too).
It's not quite as powerful as k8s or whatever, but it can run small to medium sites easily, and it does have an Alpha-quality scheduler to push to k8s that I haven't tried yet, but should work as well as the Docker backend, eventually (and I'll switch to that when it's fully capable, too).
With DigitalOcean, I hear you can do 1-click Dokku servers if you don't want to do it yourself (I haven't tried this).
It seems to me I see more and more a growing distance between how data is stored in a sql db and how the data is actually rendered or represented in the application.
With WordPress I don't worry about the PHP part, but for the tendency of people to bloat it by installing plugins and not updating it enough.
I mean how do you skip the "storing some sort of state in DB including a users table" step?
It is very typical for a small to medium business site client to want a minimal CMS and ability to add a few more users with edit rights.
With Netlify CMS it seems the build happens from a git repo so wouldn't it require for end user to learn git?
I love how fast and easy it is to publish static sites on Netlify but I do not see how one could host client sites on Netlify without requiring constant hand holding.
Content, copy, even menu items, metadata etc can be edited by multiple normal people. Translations too
A static site can be set up to rebuild when someone updates content.
You could also fetch content with JavaScript on the page. That would work if it was just opening hours as in the parent example
Regarding WordPress and plugins:
<?php define("DISALLOW_FILE_MODS", true);Tech is about automation. Php + mysql still serves well in this era. Wikipedia still runs on it and it’s a pretty fantastic and responsive site. So does Facebook to some degree I suppose.
Next dev will have easier time changing string in plain, straightforward code or static site generator than migrating plugins from PHP 5.3 or whatever.
>Tech is about automation.
Tech isn't about "automating" things that ultimately cause you to do more work to maintain status quo. Tech isn't about spending week to automate things that take you 1 minute three times a year.
I thought that was your junior response... you update it once a month, seems like WordPress is seriously overengineered for something managed internally. Static website + a 1h ticket once a month seems much better.
You'll save in performance, security, and it over a few years, it would take you less work time than doing a full WordPress.
If it's more than once a month, now it may be more interesting to go toward a WordPress, but that would be doubtful.
Sincerely, someone with way too many Wordpress sites.
More specifically, it isn't always up to the engineers:
> We need to build a basic company website.
Marketing is inherently trendy and the people designing the website, as in dictating what it needs to do and look like, are the marketers, who are influenced by the "cool" websites they've seen. Marketers follow trends. It isn't really negotiable in that profession. The engineers do their best to deliver on what marketing wants, and if that requires a WASM re-implementation of NyanCat to prove that we're retro-hip and DownToFax, so be it.
Pretty sure that’s not the case anymore, I have been a developer for 3 years and have never ever seen anyone use either of these for work
I do agree that if you need plug ins, that appears to get messy very fast, but the default WordPress site does everything I want and requires very little for maintenance.
For example, I like Ghost (https://ghost.org/) for my personal needs.
Worst case I use a dedicated PHP page and MySQL. But in reality I think I usually put my code in functions.php(?) And it works fine.
This article is about static HTML/CSS/JS. You can accomplish a good, modern CMS in halfway-decent languages using netlify and any static site generator framework you want without making your devs miserable.
Wordpress does what is required out of the box.
In fact, you don't even require a developer to do it. It's a point and click operation of selecting a theme, installing a cache add-on, add an SEO add-on, and hell, there's probably a "office hours" plugin as well.
If the receptionist isn't a technophobe s/he can probably do it themselves.
If you want to assign resources, get a designer in to make it look pretty. Wordpress has everything else covered.
this is one reason why i fully believe companies should have a give each developer a half-day or day to work on new thing for the company so that new developer get to scratch that itch without trying to force using something new just for the sake of using something new.
Also, if companies stop requiring 4 years of experience in a technology that came out 3 years ago in their job description that would also help. Instead, let people transfer from similar technologies and let them learn it on the job.
Some experienced developers get it, but I have argued with plenty who are busy keeping up with the hype cycle and resume driven development.
Why not use Wordpress --> static generator --> Netlify (aka free hosting)?
I related too hard.
I had an intern say something like this but didn't give a reason. So I asked "why?". He couldn't give me an answer.
Where there is a problem is the culture of software engineering, and the tendency to select the newest technology stack of the day for inappropriate applications. I think any seasoned software engineer has acquired the skill of successfully selecting the correct architecture for the project goals (even if it is _boring_ to actually work on).
Whereas, take the junior to mid developer streams. Every time there's an opportunity to learn something new and break the grind from doing [X] for the past [Y] months, there tends to be unwarranted justifcation on why "we should use this new thing" despite there already being a well-known and battle-tested solution sitting right there.
For example: We need to build a basic company website. Someone from reception needs to be able to update the contact form and trading hours around five times per year. Someone from marketing needs to update product brochures once a month.
Seasoned engineer: Let's use any well-tested CMS such as WordPress and install a caching front-end.
Junior - mid engineers: EW WordPress! Doesn't that use PHP? Hahaha. Hahaha. Why on earth would we want to be known for using _PHP_!?!? We'd be _far_ better to just create a front-end on react and then write a microservice that will allow our staff members to update content. If marketing says SEO is necessary, we can _simply_ add a server-side rendering layer for the react front-end and deploy it onto a second microservice. And to make sure it all works, we can subscribe to some monitoring services, write a full test suite and CI pipeline. Everyone can install monitoring on their phones so if it ever goes offline, someone can immediately sign in remotely and debug which micro service is broken.