Agree with this. Like the author, I've been keeping ajour with web development for multiple decades now. If you have deep software knowledge pre-LLM, you are equipped with the intuition and knowledge to judge the output. You can tell the difference between good and bad, if it looks and works the way you want, and you can ask the relevant questions to push the solution to the actual thing that you envisioned in your mind.
Without prior software dev experience people may take what the LLM gives them at face value, and that's where the slop comes from imho.
The game changer for me will be when AI stops hallucinating SDK methods. I often find myself asking ”show me how to do advanced concept X in somewhat niche Y sdk”, and while it produces confident answers, 90% of the time it is suggesting SDK methods that do not exist, so a lot of time is wasted just arguing about that
It would lower the barrier to switch to Cloudflare for new customers, and once they are inside with a credit card on file it’s arguably easier to explore their product offerings
The obvious go-to choice was Cloudflare for us too, but then it turned out you can't use CF just as a registrar (at least on the basic plan or equivalent), you need to use Cloudflare's nameservers as well... But we use Google's Cloud DNS for everything, so that was a showstopper. In the end we went with AWS Route 53.
CF could probably get a lot more customers if they would allow you to use custom nameservers for your domain.
The point is you should be able to operate you own paywall. The tech is mature enough in 2024 to make it work.
Make the browser store you credit/debit card info, make the browser handle the payment UI, make the browser expose JS apis to invoke payments and receipt fetching against pluggable payment providers.
My ideal world looks like this. New html button element:
`<pay amount="1.00" currency="USD" reference="my-article-123" checkoutUrl="https://...">Unlock for $1.00</pay>`
Clicking it opens browser checkout flow. The url you get from stripe/paypal or another whitelisted payment provider that has implemented the spec, some flow similar to OAuth. On a successful tx, a signed receipt (something like a jwt) is returned from the provider and saved by the browser, on disk on your computer.
The webpage can then load signed receipt references from the browser api, sends it to the backend which can return the article content if the receipt jwt is valid.
It can be fixed if the right people from Chrome and Stripe got together in a room and brainstormed for a bit. Then everyone else would follow.
Been pretty useful for discovery of SDK functionality in open-source libraries, that otherwise takes a bunch of time Googling the answer for. For example;
- Using golang, how do I write a custom marshaller for uber/zap
- Given a list of protogen.Files, how do I parse protobuf options and their values
Unfortunately the generated code is more often than not incorrect or uses non-existing API methods, but can give an idea of methods to use or where to look in the official api docs.
Yeah I’m sure there are all sorts of considerations. Also not saying it’s straightforward, just easier than writing a new db. You can for example write proto message extensions to support custom field behaviours.
But like a sibling comment said here, if you want the database implementation to dictate your models you can probably generate protos from something like EdgeDB. But then the db implementation is in charge, which seem a bit backwards.
If you’ve used graphql you’re presented with a similar challenge but on the other end of the spectrum - the graphql schema that needs to map to application models.
So one of the main considerations is to figure out how and where you want to define your source models. Is it the view layer, the model layer or the database layer.
Love this idea, and in general agree that using a proto model as the single source of truth is a neat concept.
Not sure you need a completely new db though; with protobuf’s native support for plugins, perhaps the missing piece you’re looking for is a protoc plugin that generates the table definitions for your db of choice? Could work well for databases with declarative schemas..
Don’t want to discourage you from creating a new database, but writing a proto plugin is arguably a quicker undertaking!
Demand grows, but the bitcoin supply is limited. Price increases. Also, after each halving the bitcoin miner payout gets cut in half, so price has to increase for the network to stay alive.
Without prior software dev experience people may take what the LLM gives them at face value, and that's where the slop comes from imho.