htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext
htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react
Honestly this is completely ridiculous. Hypertext using HTML constraints is absolutely insufficient for representing application state. It’s the wrong tool for the job and always has been, because it conflates document structure with semantic meaning.
Said another way, HTML cannot be relied on to capture a representation of application state.
The reason REST doesn’t use HTML in most contexts is because applications don’t use HTML in most contexts anymore.
Demanding that application representation use a specific encoding strategy is ridiculous and misses the point entirely, which is that HTTP is no longer the right protocol for the job.
While HTML is hypertext markup language, hypertext is not HTML.
Hypertext doesn’t imply a specific encoding strategy, it implies semantics - data contains links to related data. If you want to encode it in protobufs - you do you, REST explicitly calls for freedom in this regard.
To paraphrase yourself, ranting about HTML as if it was a requirement for REST is ridiculous and misses the point entirely.
Yeah which you can do with JSON as well. GitHub’s API does exactly that, providing links to all the rest of the resources so the client doesn’t need to “know anything”.
The author of the article completely conflates JSON with “JSON == Not-REST” which couldn’t be further from the truth (also calling json apis “RPC” is fucking hilarious to me. I can tell the author has never touched actual RPC). JSON was standardized on because it encoded the information that was in html in a much smaller format and allowed a backend server to communicate with any client, not just a browser (not that other clients can’t use html or xml, but they didn’t want to because they might not be documents). Dealing with xml is a nightmare. JSON made that better, and still allowed you to do HATEOS if you really wanted to.
They’re not demanding anything. They’re describing how the current meaning of REST is nothing like the original one.
They’re making a point for not splitting application state and logic into client and server with shared knowledge. If you’re making that a pretext of course their argumentation won’t fit. They’re describing an alternative architecture and approach. Not an alternative protocol for the current common web application architectures.
Honestly this is completely ridiculous. Hypertext using HTML constraints is absolutely insufficient for representing application state. It’s the wrong tool for the job and always has been, because it conflates document structure with semantic meaning.
Said another way, HTML cannot be relied on to capture a representation of application state.
The reason REST doesn’t use HTML in most contexts is because applications don’t use HTML in most contexts anymore.
Demanding that application representation use a specific encoding strategy is ridiculous and misses the point entirely, which is that HTTP is no longer the right protocol for the job.
While HTML is hypertext markup language, hypertext is not HTML.
Hypertext doesn’t imply a specific encoding strategy, it implies semantics - data contains links to related data. If you want to encode it in protobufs - you do you, REST explicitly calls for freedom in this regard.
To paraphrase yourself, ranting about HTML as if it was a requirement for REST is ridiculous and misses the point entirely.
PS: HTML is not a protocol.
Yeah which you can do with JSON as well. GitHub’s API does exactly that, providing links to all the rest of the resources so the client doesn’t need to “know anything”.
The author of the article completely conflates JSON with “JSON == Not-REST” which couldn’t be further from the truth (also calling json apis “RPC” is fucking hilarious to me. I can tell the author has never touched actual RPC). JSON was standardized on because it encoded the information that was in html in a much smaller format and allowed a backend server to communicate with any client, not just a browser (not that other clients can’t use html or xml, but they didn’t want to because they might not be documents). Dealing with xml is a nightmare. JSON made that better, and still allowed you to do HATEOS if you really wanted to.
They’re not demanding anything. They’re describing how the current meaning of REST is nothing like the original one.
They’re making a point for not splitting application state and logic into client and server with shared knowledge. If you’re making that a pretext of course their argumentation won’t fit. They’re describing an alternative architecture and approach. Not an alternative protocol for the current common web application architectures.