Haha yes of course if the code of conduct is all about inclusive language it's just missing the point. I guess what I'm saying is that maintainers also sometimes (even more often?) have a bad day and don't want to read "This lib is useless" as the second comment of an issue.

Today at work… Interesting…

"self"… what’s this? The actual endpoint itself?

The

_links

section (and thus 'self') is part of a "standard" - https://en.wikipedia.org/wiki/Hypertext_Application_Language

I think it's supposed to be like, "Here are some useful endpoints relating the main result that you can also do"

So maybe there is a little hope for “real” RESTfull JSON APIs…

It's up for debate. One of the htmx essays goes into this a bit here - https://htmx.org/essays/hateoas/. Read the whole thing, but the relevant bit is the "HATEOAS AND JSON" section.

For those interested in the Hypermedia approach, I thought this Douglas Adams BBC documentary from 1990 about Hypermedia was very good:

BBC? Wow. My opinion of them has slightly increased

ngl the intro felt like I was watching an old mr bean episode

Intro is a bit hard going but it gets really interesting 5 mins in

"Look what they need to mimic a fraction of our power" meme

the trick (and this took me a long time to appreciate) is that you need a hypermedia client as well. Creating a hypermedia API isn't that difficult at the end of the day (there are only two hypermedia controls and then some form-related stuff to mimic in HTML, after all). What's hard is creating a client that understands all that and that is general enough to also present it to a human in a nice form. building a client like a browser that respects the uniform interface of a hypermedia API and is also not a terrible experience for a human user appears to be really, really hard to me

what is going to have more perceived performance? something like sveltekit or htmx?

Highly dependent on the backend

and also on what you're actually doing

if you don't use hx-indicator or something like that then sveltekit can be perceivably smoother otherwise i'd say its a tossup and it depends as @tall-dinner-62086 said, sveltekit or whatever does clientside rendering will surely use more CPU

node and/or golang mostly i've been hovering around htmx and considering transferring for a while now because i love the idea. i haven't done much other than cursory reading and occasionally looking at some of the docs as for what i'm doing, i was thinking i'd try to make something like sveltekit's mix of CSR with SSR with htmx

but more generally the use case would be small games, medium-sized web apps and websites

Assuming you're "as good" at svelte as you are at htmx, I don't think you'll really notice a performance difference in the majority of cases

Unless you're at an extreme case of server being very poor at rendering html while the client has resources to spare, or vice-versa

i looked at hx-indicator in the docs. so it has built-in UX features? thats pretty cool

is CSR possible with htmx? and if the performance is mostly imperceivable and can do the same thing, then htmx looks way easier and it might be worth the move

The whole point of htmx is to have the server do the rendering

However, there is a client-side template extension

you generally combine htmx with its own internal set of CSR functions, or jquery, or surreal, or umbrella, or hyperscript. htmx can get drastically lower latency, higher performance in a lot of situations, (ideal for games) because so many layers of complexity (slowness) are removed. But it's all about the patterns you decide to use.

There's nothing really faster than the direct-to-js approach htmx uses, in a vast majority of situations. No virtual dom or anything.

Faster in terms of latency.

If you need to go to the server for something, of course, you're always going to incurr that round-trip network time no matter what you use.