How is it you can have a good experience, and yet my negative experience somehow doesn't qualify and you're insinuating the issue is with me, and not Hetzner?
This happens with every provider. One thing you're seeing is just that people with 5- and 1- star reviews have a lot of motivation to post reviews. People tend not to be motivated by "meh it's fine" feels.
For any critical email delivery make sure you can address this thing with the mailsender of choise:
1)SPF,
2)DKIM,
3)DMARC [2] (DMARC is often forgotten or can be super noisy when set up. Postmarc offers a aggregation service for free that sends you a weekly summary),
4)Dedicated IP
5)Reverse IP look up [1] (locate a dns PTR record for that IP address) should match the sender.
Not everyone supports 5).
4 and 5 is what you end up paying for, but totally worth it.
Sendgrid, SES, Mailgun etc.
And 1 surprising thing (to me) is some places (iCloud was what bit me) alway want you to be able to receive email (have MX records). Even though I have no need to support incoming emails iCloud was blocking my sending until I got that setup. The incoming emails just go to a black hole but that's enough.
Shameless plug: I've recently started my own transactional email service (https://www.markix.com), primarily targeting small senders, after having been a very happy Postmark customer for a long time. Our service is still in closed beta but delivering live emails.
I run a couple other businesses and moved all of my transactional email sending over to Markix.
Would love to have a chat with anyone that might be starting a new project and is open to try out a new mail service (mail in bio).
I think it’s a matter of lifestyle choices as well when comparing to the studio. A lot of us work on our computers for a good portion of the day, why not have the $3000 upgrade that looks way cooler?
People make these upgrades in trim options on their cars all the time.
If you stay on the same version of the init script, you're still marginally better than rolling your own.
On the other hand, if you learn it once and then allow updates to occur, you'll still understand the process in the abstract. You'll just have to let go of the notion of knowing all details of your stacks from top to bottom. This is why we have teams and specializations. Computing long ago exceeded typical human capacity for complete knowledge. Now we learn as much as we can including the wisdom of who to trust when the solution is bigger than we can individually muster.
We trust compilers and browsers and libraries and frameworks all the time. When they break, hopefully the broken area is in our wheelhouse or at least well-documented. But the issue of complexity isn't going away if we want to continue making forward progress.
My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
Change happens.
"Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
Also, things seem to be converging towards simplicity in a positive way, comparing e.g. Vite to Webpack.
But without any disagreement:
the churn is real.
Not upgrading is only an option if you
1) are sure you don't run vulnerable code on a server (e.g. through SSR) - if any code is public-facing, ignoring most "npm audit" reports ceases to be an option.
2) don't need new packages to change your build setup that are significantly newer than your previous setup.
To repeat, I don't disagree and I prefer the spirit of your comment to my critique.
Almost all of the time it is a good idea to settle on versions and evaluate when upgrading is worth it.
Update costs can also vary a lot depending on the project.
In other words, preserving behavior while fixing dependency conflicts, breaking changes etc after updating major versions.
If one avoids to do clever stuff with the bundler and if the project requirements are simple, it can be easy upgrade or even swap tools (e.g. Webpack for Vite).
This rings very true for me, bravo:
> My frontend dev setups perform auto reload on save in my IDE within a second, have clean integration with testing suites and CI/CD, and do so much beyond my ability to build on my own. Even if I were dedicated to dev build environments and had the sufficient skill to make a stable and complete solution, I will have incurred the opportunity cost of not actually solving my initial frontend problems the clients are paying me for.
> Change happens.
> "Dr. Strangedevelop" or "How I Learned to Stop Worrying and Love the Vite"
