using a bash script to munge a few files together then a cron job running to rsync them to an Apache server running on a VPS
is considered morally and technically superior to
using a JavaScript tool to build a site then having a GitHub Action push the files up to an S3 bucket with a cloudfront distribution in front of it.
There’s no obvious reason for this, other than a belief that if something can be done with 50 year old technology, it should be.
With bash, cron, rsync, and a vps, one is using stable, long-lived tools that usually come with Linux, are vetted and patched automatically, and are familiar in the sense that those same tools can be used for all sorts of tasks, not just frontend development. There is also the argument that the only remote piece controlled by the service provider is a vps which still gives you lots of control and flexibility with minimal lock-in.
I prefer somewhere in the middle of the two extremes, but I see more appeal to the "old" approach than you allude to.
Sure, there are maturity differences but it's nowhere near so vast a difference as some claim.
These are just preferences. It's not a culture war issue.
However there’s fundamental difference: in a model of distribution by a distro the developer only produces a software but they don’t release it themselves. They provide source code and that’s it. Maintainers of packages for each distro vet new releases, test, and sometimes patch them so they work best within context of a given distro. So there’s extra effort spent on making sure the software is stable. In a model where a developer publishes their new release to some package repository directly (npmjs.com is just one of them, same applies to pypi.org, rubygems.org, etc) that extra “QA” by others than the developer doesn’t happen.
While past performance is no predictor of future performance, on the face of it I'm likely to bet on the stability and longevity of the classic time tested technology outlasting that of the newer technology. Especially if the newer one relies on specific 3rd party services.
eg the trade offs of the new might be weighted differently than the old as they apply to building vs hosting. Your build breaking due to stack changes is a different PITA than a security vuln in the hosting. Although the build might break more often due to churn in the new fangled stuff, you might trade that off for the less hands-on hosting maintenance.
But for another trade-off, the old stuff is far less service dependent, so less work to migrate if you need to change service providers.
Engineering is trade-offs, and decisions are made based on assigned weightings of various factors. The weightings are subject to bias though and thus always personal.
Why would I want to introduce so many a dependencies when I can have zero? Yes in this case old tech is superior. Sure if (and that is a big if) your blog is super popular you might want to "cloudflare" but that's about it.
“ I've come up with a set of rules that describe our reactions to technologies:
1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.
2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.
3. Anything invented after you're thirty-five is against the natural order of things.”
Only when applied to Linux, this amounts to:
Anything that was copied from UNIX is normal and ordinary and just part of the way the world works.
Anything that is included in a standard Ubuntu distribution is exciting and revolutionary.
Anything else is a ‘dependency’.
> Anything that is included in a standard Ubuntu distribution is exciting and revolutionary.
> Anything else is a ‘dependency’.
The picture you're painting of pure back-in-my-day-sonny! bias, while not totally wrong, is also not quite accurate. These different technologies have different installed bases, different probabilities of security vulns, different probabilities of still being maintained in 10 years, etc.
These are the kinds of trade offs we make.
2) As for probability - I had zero security incidents on my personal website / blog in 15 years. And I did not spend my life patching things. Just few minutes every once in a while. Keep this FUD for uninformed.
If there is a security vulnerability in a static site generator, that is unlikely to present to the internet, as the generator is not running on a public-facing server.
Hugo is now 8 years old, Jekyll is now 13 years old. Both are actively maintained, and given the inability of most people to string together a shell script that is both portable and correct, are likely better solutions than said shell script.
Sure doc. You are free to follow and waste your time and money. I do not get a kick out of using half of the world resources for writing glorified "hello world". And let all those intermediaries control what you do in a process.
Adams Douglas was magnificent. Your attempt to use his words in this particular context however is anything but...
I don't have any moral opinion about it - in fact I run a site with the setup described which is half why I am satirizing it (It's cheap to run, but it's also overly complex, has a load of dependencies that ultimately a simple HTML file shouldn't have, and the final setup is quite limiting).
I do think we lose something intangible by building websites with mousetrap-esque technologies. The idea is usually that when you abstract something away, it becomes simpler to understand and quicker to develop in - but IMO it seems like we have abstracted away and it has become harder to understand and slower to develop in.
No, the biggest problem is that for so called 'engineers', software engineers who do web development are by far among the worst at actually evaluating solutions based on their engineering merit. Thus, we get overengineered solutions in companies and areas that simply do not need that level of complexity.
The two approaches I described have exactly the same number of moving parts; they require you to understand exactly the same number of technologies. There is no difference in ‘complexity’.
there is so much can go wrong that this unlikely to be as simple as running a bash script.
i usually use node cmd to write terminal programs but recently tried bash and i found it much better for simple stuff.