Vibe Coding Is Metaprogramming
blog.valentin.sh
blog.valentin.sh
- web CRUD boilerplate is definitely a missing abstraction, I've been pondering how to tackle this one for quite a while.
- surely no one would be crazy to run LLMs in a build step, right?
- what if the missing abstraction cannot exist? Universe doesn't guarantee useful abstraction for everything
- what if LLMs are the abstraction? Struggling with re-prompting isn't that far from trying to force the compiler to output instructions you want.
I still lean more on the author's side, though.
NeXT's Direct2Web[0] did a pretty good job of this, though I think it might have been too much of a black box. We need to figure out the parts first.
First is direct support for REST, by having it be not just a "Web" thing, but instead supporting in-process REST[1]. Objective-S[2] does this[3][4]. This includes better support for composable storage.
With that and a templating engine that supports URL as well as HTMX's support for URIs and verbs, I think we are getting really close.
Finally, you need to have some support for tables not at the UI and not at the database level, but at the model level...which can then be mapped fairly seamlessly to DB and UI. In progress.
> I've been pondering how to tackle this one for quite a while.
Any thoughts you can share?
[0] https://developer.apple.com/library/archive/documentation/Le...
[1] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...
[3] https://dl.acm.org/doi/10.1145/2508168.2508169
[4] https://2019.splashcon.org/details/splash-2019-Onward-papers...
A while back I wrote a blog post that mentioned this: https://news.ycombinator.com/item?id=32495133
People posted links to bunch of interesting projects in the comments, probably the closest to this specific issue was FOAM: https://github.com/kgrgreer/foam3
Looked interesting but I had bunch of questions on whether it's practical enough to be useful. It comes to the problem from the modeling angle, and I get a bit too much OOP/UML vibes from it for my taste.
---
The way I've tackled this in my projects is basically moving them closer to HATEOS, avoid using the "business terms" in UI code, do most of the logic on the backend, and let the API and frontend code "speak the UI langauge."
Basically how HTMX works conceptually, but not all the way to HTML partials. Server driven UI is also a close concept.
This way you cut down a lot of pointless data shuffling between DB, JSON API, Frontend data layer and UI. The code resembles just a translation layer between domain concepts (users, invoices, ...) and UI concepts (headings, list items, carousels, buttons, actions).
It's not ideal though, there's still a lot to figure out in this model.