For toy apps and initial prototypes the problem is they aren't going to get used so the rot is that they will be in a good-enough state to come back to when you get the time. With supabase the drop-in auth completely broke at some point, probably just a deprecation I didn't keep up with.
The postgres instance spins down when you aren't using it, which is understandable and I will say it works, it's just Postgres and you get the database dump if you need to move or come back a year later.
The nuance here is that you get the raw connection string + the postgREST API which all makes sense but you're choosing full cloud/client mode which is completely different from if you just went with the raw connection string behind a server layer. I kinda had to work through all of that learning on my own. The full client mode trade-off is that you'll be doing everything with that pattern, handling migrations, security, auth, it's just kinda... it's a whole thing. The public postgREST and row level security is a different paradigm.
as a professional dev, I would have just chosen the raw connection string and managed the database from the server until I outgrew it and I'd have the dev workflow already, it's just a Postgres db. Or sqlite to start, same reasoning it's all the same dev workflow, the problem is the cloud-hosting transition, which is why fully-managed cloud db accessible from an edge/client runtime is so alluring, but you're trading two very different ergonomics.
+1 "alchemy of air" is a great read. The angle that would be most interesting to the HN crowd is that it exposed me to how much innovation was happening in chemistry in this pre-WWI era. Reminds me a bit of silicon valley.
The also a fascinating look at how the inventors got heavily caught up in WWI and WWII due to being in Germany and how tied up their industry became with government. Interesting to reflect on in current times.
I've been thinking about building a service that makes it easy to self host apps like this. I'm curious if you'd find it useful.
It would host webapps like yours that use in browser sqlite to store data, then the service provide a sync their sqlite data across different devices. The user not the app would pay for the storage of the data, so they would own their data. And you can use CSP to lock down the app from sharing with other domains, meaning an app can't leak your data.
The service would handle identity (only you can access your sqlite data - the app just ) and could provide an app store like experience with different apps of this type.
Sort of like a firebase style backend as a service, but the user would own the data instead of the app.
Pikapods looks to be running containers for you, preconfigured for the self hosted apps they support. That's a cool service, I assume there are other similar services around.
The concept I'm thinking about is different - it doesn't run any app code on the server, the apps are SPAs that run in the browser only (no backend supporting code), and then the server just syncs the data from the apps. This means the apps can focus on building ux/business logic and not worry about database, how data gets to/from clients, identity, etc. Somewhat like firebase but where the users pays for the server, not the app. That should hopefully be simpler for developers, and theres a lot less likelihood of issues with server config/etc (although presumably pikapod will handle that). It should also be cheaper since you're not constantly running a container, just storing data.
I'm not sure if it's a useful concept or not yet :)
Thanks for finding/sharing those links. As I read them they reminded me a lot of what I've been seeing as I have been using Remix (remix.run)
For example: in "how to update content", they discuss path dependent updates. Those are how remix does all it's updates - they use nested routes, so it knows it only needs to update a part of the page (eg only update the content of the page, leaving the nav alone, since an update occured only in the content part of the page)
I think the htmx folks would have a lot of issues with remix but I think remix takes a lot of the best of both worlds. Remix focuses on using basic html/http concepts and layering some smart JavaScript on top of that.
To return the favor, here's a couple docs I found helpful:
https://remix.run/docs/en/v1/tutorials/jokes - this is their advanced tutorial and it's a bit long but once you get past the setup steps it's a really well written introduction to the concepts of remix through useful examples. One of the better tutorials I've ever read.
The key concepts is remix is understanding the loader(), UI component, and action() interactions and how those work with minimal code changes in:
1) server side only mode (with only raw html served)
2) server + smart JS client mode
I'd be happy to work on building that for my service if someone is interested in using it.
I think your point about mozilla's pricing being too cheap is an interesting one. I don't think of the pricing as $1 - I think it as $1/month, so it builds over time. But clearly it would be a bigger deterrent if it cost more.
I think blocking these email masking services and treating them exactly like throwaway email services is the wrong way to go since I think a lot of users want to use something like this. (discloure: I'm working on https://www.thxnothx.com which is also an email masking service combined with some other features)
A fundamental part of charles' argument is that in order to sell ads, facebook must encourage you to set your profile settings to public. That's not the case. It doesn't matter whether you've set your profile to fully private - Facebook's privacy settings don't affect whether or not marketers can target you with ads. In fact, in that regard facebook is incented to protect your privacy so that you'll be comfortable putting more information in the site, which they can then use for better targeting. Since marketers don't get specific information about you when you're targeted, your privacy hasn't been breached in doing so.
This doesn't change that people should be very careful about their privacy settings, but the fact that facebook does targeted ads doesn't mean they have incentives to encourage you to make everything you post public.
I think Charles is right to be concerned about the current state of privacy in social media, but I take issue with his statement that facebook is deliberately making it harder to make your content private. If you click on Privacy setting in facebook today the first thing you're greeted with is a big control asking you if you want your profile to be public /friends/custom. But first you have to care enough to click on it.
Building social network privacy controls is not an easy problem b/c people don't want to do the extra work that's involved in setting privacy on things that they post AND it's confusing. Most people just don't want to choose a circle for their 300 fb friends.
Facebook has gone through many iterations of privacy controls - https://blog.facebook.com/blog.php?post=391922327130 goes into some of that history. Some of them even included google circle-like functionality for privacy. No one used them.
I'm not saying that these controls couldn't be improved, but the point here is that privacy controls take work from users. Until society as a whole is aware of these issues (and Girls Around Me does a great job of it :), people aren't going to invest the time to do it.
TL;DR - building privacy controls are hard. The industry as a whole needs to improve them, but society also needs to learn to care about their privacy so they actually use what's available to them.
