I'm a React dev and have been mentoring a junior. React's hooks, when and why they run, is very unintiuative for them. Skill issue is part of it, but React's immutable prop diffing forces the use of hooks and understanding how the framework uses them. Moving to a re-render model which always rebuilds the vdom tree allows callbacks, state to be defined outside of the render method without framework abstractions wrapping them. I'm not familiar with what Remix is doing but it looks a lot like Mithril.js, and working with Mithril is really enjoyable after working with React for as long as I have.
Of course teaching FP ideas to traditional-javascript devs is going to be tricky, but that’s less a React complexity problem as it is a familiarity problem.
If everyone came from a purescript/fp background the story would be different.
I like the safety aspect of QUERY. Having CDNs cache based off the semantics of the content might be a hard ask. I wonder if this might lead to a standards based query language being designed and a push for CDNs to support it. Otherwise you probably need to implement your own edge processing of the request and cache handling for any content type you care to handle.
GET is a keep things simple stupid approach to caching. The URL is the cache key plus any headers touched by the vary header. Adding the requirement to vary on the body and understand the body content semantics brings in a whole lot of complexity that GET avoids.
I find the semantic web stuff is really interesting but it seems to have more success where there are complex up-front data modeling and collaboration requirements, maybe between orgs. There is a Genome database out there for semantic web and I've heard of banks using it in complex fraud detection systems.
These elements have non-presentational definitions in the current spec. A screen reader could make use of the semantic difference between <strong> and <b>, even though desktop browsers default to presenting them the same way.
I tried solid and I didn't find it intuitive. Having your data behind proxies introduces more ceremony when splitting / combining props. I felt I was just moving the trade-off React makes when feeding a deps list to hooks to a different location. The proxies also made things hard to debug and you have to be careful about the language features you use with them.
I also have often have smaller deps lists in React's useEffect when wanting to call a callback on the props because of some local state changes. I wouldn't want the effect to fire because the callback changed however. I'm not sure solid even supports that in its createEffect since it is all automatic.
Are you against using something like json-ld, hal,... for embedding links? Adding arbitrary hx- attributes to html which require a javascript application to make use of comes across as un-RESTful as doing so in json to me.
Not saying you have to prefer it, but some of the htmx articles imply there is a difference.
