What's your thoughts on hypermedia as opposed to JSON APIs?
I've been looking at HTMX and thinking that hypermedia sounds great. No need to send JSON data to the client and have to parse it. Instead, the API returns HTML strings and you just put it in the DOM.
But it can't be that easy—or that convienient. Or else it'd be much more widely used. So I turn to you, my fellow front-end friends! What's your thoughts on hypermedia APIs? Do you think it's a good idea? Why or why not?
37 Replies
it really depends on what you implement and how much fucks you give about UI and UX
Assume that anything I do will be a character sheet for my current TTRPG :p
Well, then I guess you're useless here 👋
if your UI is more static than dynamic
Mostly static, but a few dynamic places. Like when the character takes wounds, gains XP or what not
Htmx is great for frameworks that do SSR that you also want some janky reactivity
hypermedia, and HTMX in particular changes where the templating logic is implemented.
Or you could just use Sveltekit 😅🥲
Now with server components 🔥
But most of the "dynamicness" of the character sheet for attributes, skills, name, and gear are mostly static and tend to change between adventures (if at all)
for a JSON endpoint the backend cares very little about how the data it sends is displayed, for HTMX you need to template everything on the backend
the JSON data thingy will be snappier if you do a lot of dynamic UI stuff on top of the received data, but you need to do templating on the client
Yeah, the were it happens seems to be the big difference
Yup
if you use HTMX any changes done to the displayed data might need a round trip to the server which might make the experience slower
Not might it does period no?
hypermedia relies on better server code, while JSON does more work on the client. I like the idea of hypermedia but I'm not sure if passing the templating to the server is the right call
depends on the latency, anything below 100ms round trip is unnoticable for the average meat bag
Having the client do it makes more sense to me as even with 10k connections the server isn't doing any more work—the client does all the work for the template
it's not necessary "better server code", it's just "templating on the backend"
but if you already do SSR, it can make sense
Should have said "more" not "better"
especialy if the stuff you send is pretty light interaction wise
How about the best of both worlds 🥲 (progressively enhanced optimistic UI)
it's really a trade off game and a question of if you prefer writing server code or clientside code
How about no to Sveltekit as it doesn't really answer the question 😜
but as B1 pointed out, fullstack meta frameworks, like sveltkit, throw the question out the window and you just do everything in the same file
For me, right now, it's all JS so…no big change :p
it kinda dows actually, as it's an hybrid approch
node.js code can and will look a lot different than browser code, especially if you bring in a backend framework or libs ('cause writing bare node code for the backend is pure insanity)
$app/forms • Docs • Svelte
$app/forms • Svelte documentation
I am the definition of insanity, so…yeah. Raw Node code for me
Leverage the native APIs
Yeppers
Keep the sanity
using
node:http really isn't fun and I don't think you should do it beyond just learning how serverside stuff worksWell, I write my own server lib so there's that. But in the end most of 'em use
node:http so I don't really get itjs for backend is really different than js for frontend and should not be approached the same way, but that's besides the original question
more or less everything uses it under the hood, doesn't mean you should use it directly. especially since bringing in a lib on the server has little to no cost compared to clientside
but to go back to your original question :
it's about how much you want to do on the server vs how much you want to do on the client
and how interactive you want the page to be