[cookiengineer]

I was checking out HTMX the other day but I am not really convinced. There's a lot I like about using HTML to define API calls, but I want to keep the backend free of unnecessary burden (and therefore free of frontend related rendering tasks).

I'm looking for something like HTMX in its methodology, which uses HTML attributes for defining API calls and where the data comes from without having to write additional glue code in JS... but which uses OpenAPI as a schema for serialization/deserialization of data to/from the API endpoints.

Maybe something like that exists which I couldn't find with my Google Fu?

[whodev]

Too each their own, that's the great thing with programming, you can find what you like/want and use that. As you can probably tell I don't feel it is a burden on the backend. I subscribe to the thought that state is managed on the backend, and the browser is just the users client to view those hypermedia responses provided by the server. Template fragments in Go make it easy to only serve the necessary HTML from my templates, or if it's a full page request I can send the entire page.

I'm not sure of anything like what you described, good luck on the search for it. If you find/develop anything ensure you post an obscene amount of memes on twitter for optimal discoverability by tech influencers.

[skydhash]

Returning JSON instead of HTML is just the same. And you can still go back to JSON some interactive UI (Maps, RT Chats,…) but if the UI seldom updates and mostly on navigation, it’s great. I’m currently using Laravel and livewire for a project and not worrying about frontend state is nice. and if you worry about scaling, you can make the web service stateless, moving everything to the DB and external services (logs, caching?, jobs queue).