Thanks for > Any thoughts you can share? A while back I wrote a blog post that mentioned this: https://news.ycombinator.com/item?id=32495133 https://news.ycom

Thanks for > Any thoughts you can share? A while back I wrote a blog post that mentioned this: https://news.ycombinator.com/item?id=32495133 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 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.