badbotty

Haven’t tried them but I can see these features being really useful for screen reader users.

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.

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.

The URL is not a HTTP method.

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.

https://html.spec.whatwg.org/multipage/text-level-semantics....

I'm working on a personal project with this right now. Closure components FTW.

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.

No sex workers. No porn actors. No strippers. Do they generalize these occupations into the "escort" occupation when they are so very specific everywhere else? These are all legal occupations where I come from.

https://projector.tensorflow.org/?config=https://raw.githubu...

That looks like a better way of doing it.

No idea

Surely, when you are writing little 150+ line js programs in your html attributes you have to start considering if Alpine.js is the right tool for the job.

https://devdojo.com/pines/docs/select

That doesn’t describe mithril which is on the list though

Hey mate, you need to try a web browser. I found my experience using the Internet greatly improved when I stopped trying to parse the html documents myself.

> Oh wow, you seem to have come out of reading this blog post still extremely confused.

Yea, guilty of not reading the article properly sorry. I now get what you are saying about not using the status to drive what forms appear in UI / actions can be performed. Using JSON-ld you might use the https://schema.org/potentialAction property to describe what actions the resources allows which provides the equivalent information as the HTML form tag.

After reading Roy Fielding's blog a bit I do find my understanding of REST to be lacking. My reading of the principles agrees with your statement: "It displays the hypermedia without knowing semantics at all" but then he seems to also endorse RDF and N3 which are more like JSON-ld from my understanding and I'm not sure how they cater to display purposes.

> When representations are provided in hypertext form with typed relations (using microformats of HTML, RDF in N3 or XML, or even SVG), then automated agents can traverse these applications almost as well as any human. There are plenty of examples in the linked data communities. More important to me is that the same design reflects good human-Web design, and thus we can design the protocols to support both machine and human-driven applications by following the same architectural style.

https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

Have you looked into JSON-ld? Sure it is an extension of json but it has a formal specification which solves all the problems you have with your json examples, specifically the out-of-band issue you have with your json and how to link to other things. FWIW I maintain a API and frontend which use JSON-ld and has the backend passing the information I need to render forms based of backend permissions like you are describing.

What your html isn't doing for me is give proper type information. Should I look for the text "Status: x" in some div to find the status, and how is this better than having "status" as a key in some json object? I would not enjoy developing a consumer which had to interface with an api nesting data in divs.