It seems like the person is wading in a pool of excrement of their own choosing.
1. Node.js or package.json or Vue.js or Nuxt.js issues or Ubuntu C library issues
2. Debugging and customizing pre-built CSS frameworks
First of all they're running a very simple blog, a SSG should be more than sufficient for their usecase. If for some reason the engineer in them decides they want to ship their own, which I completely relate to, all these problems come packaged with that decision.
Even then, after browsing their site, it's very barebones, nothing more than a router and a md -> html transformer is needed.
You don't even need a custom CSS framework for whatever this is, all the components on their website are so simple a single CSS file < 300 lines (I'm being very liberal) including media queries should do the trick.
Regarding DNS, in my 15 years of experience building/deploying websites there have been very few cases where setting up DNSs was a pain and that was only when I was using shady webhosts to minimise cost.
Can't comment much on caching, but I remember with Jekyll you can just append `{{ site.time | date: '%s%N' }}` to your asset and lo behold ez cache busting.
I host several statically built websites on a cheap VPS. DNS and SSL was configured once, Pelican + Rsync bungs up the new posts whenever I need them.
The site itself handles hundreds of requests daily without breaking a sweat. The server has an up time approaching 2 years. I’ve had to maintain it minimally since then; APT updates break nothing, thanks Debian.
Maybe my tastes are different, but I enjoy playing with the scripts, the config, tweaking the CSS here and there. The risks are tiny and the payoff is I have a fun site that a couple of other people enjoy.
All of the effort to create sites like mine is in the initial configuration; lifetime maintenance is minimal. Chasing security obstructions and NPM build errors every week, I don’t see the fun in that. Even if a self built Vue.js web app does some cool things, or looks good on your portfolio. I'll pass.
It's a reflection on the fact that making all of these mistakes with my own stuff allows me to make better choices at work - and provides a constant canary project where the stakes are lower, but it's actually hosted...so it strikes a good balance of continued learning and experimentation for me.
It's also an experiment in firing blog posts sooner - keeping them "living" in the sense that I can always update them quickly later. Some of the contrived examples I chose didn't really hit their mark, for example, so I'll probably revise them later.
This comment section feels like no one bothered to really read the article.
> But here's the thing: despite all the frustration, the hair-pulling, and the curse words muttered under my breath, there's something strangely satisfying about tackling these challenges head-on. In the process of keeping this site running, I've learned even more about full-stack development than I would have otherwise, and, more importantly, I've continued developing callouses as I encounter and solve so many common web-based pain points that are totally relevant to my day job, too.
> [...] maintaining this site fucking sucks!
> And that's exactly why I do it. It's one of the best projects I've ever created.
It's an over-exaggerated rant about the positive effects of over-engineering a basic blog page.
I swear we are getting too damn smart for our own good. What's wrong with a 205 Reset Content error code? Or a 503 Service Unavailable code? Yes, some users will bounce and never come back to check your page, but who cares if you are getting 1000x or 10000x the baseline visitors.
There are multiple ways you could avoid this though:
1. Use a language that isn't JavaScript and avoid JavaScript frameworks, since most non JS setups don't require managing thousands of dependencies to get something working.
2. Use a framework or CMS so that you can update at a reasonable pace, and its someone else's responsibility if something in the tech stack breaks. This is why so many people still use WordPress/Ghost/Jekyll/whatever system they feel like using rather than hand coding everything themselves, even if they have the ability to do so.
Maintaining a website is as difficult as you make it.
If you have constant headaches with your authoritative DNS for a domain, pointing A records at things you run and self host elsewhere, you are doing it wrong. Or need to go back to fundamentals and study bind9 better. I literally spend maybe 5 minutes a year managing DNS for all my different project domains.
Who the hell that has a clue is hosting their DNS with GoDaddy???!?
I'll use bind9 here as an example because if you learn to do authoritative-only DNS with it properly, you will naturally as a side effect learn the same DNS standard specific concepts which apply to other DNS software that can answer authoritative queries.
Most complaints about how hard it is to build a website these days, especially when it's a personal site or a blog, are actually complaints that the amount of effort necessary outweighs the reward you get from doing it. If the author's website got 10 million views a month and was a reason for Google's recruiters to be getting in touch he'd think it was a breeze and an incredibly valuable use of time.
Complexity has increased while engagement has dropped. I believe that's the reason for a lot of the 'problems'.
First, let's talk about the DNS management. You would think that something as simple as pointing a domain name to an IP address would be straightforward, but no. There's always some bizarre propagation delay or weird caching issue that makes you question your sanity.
If you think that updates to a globally distributed database can be simple, instantaneous, and free of caching issues then I'm not going to listen to your opinions on software complexity.
- why would you use node.js, and a single page application framework setup for your personal page? Looks like static site generators would work just fine (gohugo, jekyl, astro, https://jamstack.org/generators etc., emacs org mode?). Maybe "just host that" on github page, gitlab page, cloudflare page, sourcehut page etc.)
That page looks like it could have been made in HTML 1.1(and that’s actually a compliment, honestly!) - why bother with all those crazy dependencies? Why cache your images at the edge, if you have like 10 images total?
I dunno about that. I created a site push to repo, deploys via netlify and has dns/cache with cloudflare. Admittedly I haven't upgraded Vue version but didn't feel I needed to.
I do follow the gist of it though. I've remade backends for some services in so many languages, frameworks, and even making frameworks and libraries for them. What I don't do is maintain them. After porting to the next, I'll abandon the old, or even abandon the current, sometimes even let it bitrot and go out of service having served it's purpose. Maintenance is a choice that you can change your mind about it if sucks more than it's worth.
I've been running a fairly custom jekyll blog for over a decade without feeling like it's painful. Does it run the newest Jekyll? Probably not, but since it's just a static generated site it hardly matters.
The lighthouse metrics are in the 80s, with a handful of performance things I could address, but let's be honest don't really need to, this is not after all a multi-million user app.
What part about that blog is custom enough that it requires Vue.js? And thereby requires you to keep it updated.
Next time I encounter the question "Why is Wordpress still so popular?", I will just share this article as a response. It's worth considering that even experienced developers find it exhausting to handle the complex dependencies required to maintain their websites. You can only imagine the challenges faced by those who are new to web development.
I will gladly stick with my simple 1-click-update Wordpress blog. Thank you very much.
I knew them and always found that https://thebestmotherfucking.website/ captures the spirit the best (because it's very light yet looks good and is not completely minimal).
Text is hilarious too: "The author is 1899441 (seriously? His username looks like my PIN code!)"
This is partially why I'm zeroing in on a markdown driven static (astro) site on bunnycdn. Enough opportunities to scratch various technical itches while largely sidestepping the nodejs server garden of weeds.
Also happens to be cheaper & faster.
Could go for one of the pages-like solutions but that seems a touch too boring.
Why does one need any server side code to run a simple website or a blog?
Just browsing through the site it seems to be just links to articles and blog posts. All of that could be "pre-compiled" into plain old HTML pages and pushed to something like github pages and you wouldn't need to worry about DNS, the server or any of the software running in the stack.
1. Node.js or package.json or Vue.js or Nuxt.js issues or Ubuntu C library issues
2. Debugging and customizing pre-built CSS frameworks
First of all they're running a very simple blog, a SSG should be more than sufficient for their usecase. If for some reason the engineer in them decides they want to ship their own, which I completely relate to, all these problems come packaged with that decision.
Even then, after browsing their site, it's very barebones, nothing more than a router and a md -> html transformer is needed.
You don't even need a custom CSS framework for whatever this is, all the components on their website are so simple a single CSS file < 300 lines (I'm being very liberal) including media queries should do the trick.
Regarding DNS, in my 15 years of experience building/deploying websites there have been very few cases where setting up DNSs was a pain and that was only when I was using shady webhosts to minimise cost.
Can't comment much on caching, but I remember with Jekyll you can just append `{{ site.time | date: '%s%N' }}` to your asset and lo behold ez cache busting.