I don’t know for a fact but I would guess there are multiple reasons and all connected to how complex it is to operate etcd.
1. Most people will need to run 3 nodes of etcd (and can never be an even number), and they have to be set up to replicate data etc
2. IIRC, recovering etcd from a total failure of the cluster is not fun (e.g. if you shut down all nodes). It generally is a manual process that pretty much involves restoring from backup.
3. A lot of people know how to manage Postgres. Much less people know how to manage etcd in production.
4. Tooling for Postgres (to operate it, backup and restore, monitor, etc) is a lot more advanced.
5. Pretty much all cloud providers offer managed Postgres services. I don’t believe any one of them offers managed etcd.
> Pretty much all cloud providers offer managed Postgres services. I don’t believe any one of them offers managed etcd.
I think this is key. PostgreSQL is boring for sure (in a good way), but there is huge operational value in being able to point at a managed endpoint and move on to higher value work.
https://github.com/juanfont/headscale replaces the tailscale control panel with something open source and self-hosted. However, it doesn't have all the features of the official tailscale control panel.
I was not expecting this to surface out of the blue 2 years later, so I had to go back and re-read what I wrote
I still stand behind what I wrote for the most part. If what you are looking for is not building a full SPA and you need compatibility with most browsers, for most users, then jQuery is still a very solid alternative.
A few things have changed however since then:
- As others have pointed out in the comments, a larger chunk of the Web has moved to SPAs, sometimes just because they wanted to build on the back-end something API-driven that can be reused for other scenarios (like mobile apps). The amount of apps that follow the more "traditional" model of server-side generation and then use JavaScript just to "augment" that experience is much smaller, but there's still a lot of use for them if you want to build something quick-and-dirty, like an internal app for your business.
- Browsers are now implementing [cache partitioning](https://developers.google.com/web/updates/2020/10/http-cache...) which means that jQuery must now be re-downloaded by every website. It's still a rather small library, and compared with most modern apps the impact is negligible (average web page size is now [1900-2100KB](https://httparchive.org/reports/state-of-the-web#bytesTotal)). But this has negated one of the benefits of jQuery, the ability to serve it from a CDN that then is reused by other websites.
For a SPA, I would go 100% with Svelte as my first choice (but you may say I'm biased), but other frameworks are good too especially if you need to leverage existing skills on your team.
> Combining the information you get safely and securely from things like Twitter Analytics or Instagram Insights with your Google Analytics helps tell you even more about how your content is performing.
Google Analytics and similar are blocked by a large (and increasing) number of visitors. To my estimates, about 40-80% of a website's visitor will not be counted in Google Analytics (depending on website and audience). Some browsers now block those platforms without the need for any add-on too (like Edge in "Strict" privacy mode).
I have a new project site that's largely viewed by technically competent people. All my other logs indicate that I get a mere 50 to 75 unique visitors per day - not heavily trafficked. Google Analytics often counts about 10% of the visitors, which is easily confirmed by checking all the other metrics that are available to me.
So, yeah, I'm not sure how much longer they'll be a viable source of data.
Speaking for myself, containers are started and destroyed faster. When using VMs, the tendency is to keep updating the software within the VM, making changes to their state, etc: this eventually leads to drifts. When using containers, if you need to make a change, you destroy the container and re-build it, and the state is always consistent with what you (and possibly your teammates) use
1. Most people will need to run 3 nodes of etcd (and can never be an even number), and they have to be set up to replicate data etc
2. IIRC, recovering etcd from a total failure of the cluster is not fun (e.g. if you shut down all nodes). It generally is a manual process that pretty much involves restoring from backup.
3. A lot of people know how to manage Postgres. Much less people know how to manage etcd in production.
4. Tooling for Postgres (to operate it, backup and restore, monitor, etc) is a lot more advanced.
5. Pretty much all cloud providers offer managed Postgres services. I don’t believe any one of them offers managed etcd.