The whole "htmx is the most dangerous thing to exist" is so funny to me.
Someone that does not understand sanitisation boundaries has no business working on web development. This is how you end up with html in your database, people just render whatever piece of data because it "just works" in frameworks like react (I've seen it myself in production).
Replace htmx with alpine js and I think the twitterers have some point. Eh, probably even with htmx.
It is true that the average WordPress developer might not care about XSS, and to refute one specific point: I have seen third-party returning HTML, plenty of them.
Deliberately acting on the contents response instead of directly executing code from said party forces you to think about XSS.
But it's not specific to htmx of course, it would be the same when using innerHTML or something while using a field in a JSON API response.
It's true that frameworks like React have safer defaults than Vanilla JS in that regard.
Reading that entire thing was a struggle. Really feels like _everyone_ is wrong here. Yes the current state of FE development is overly dogmatic and cultish. But it always has been. On the other hand the frameworks and build systems are solving actual problems, they're not there for looks.
5-7 second skeleton loaders are there because backend systems are slow, not because of the front end application. You can say "oh but you can pre-render", but there are times when you can't. You could render the whole thing on the backend, but then you'll wait 5-7 seconds at a white page vs. progressive loading. Whatever is taking 5-7 seconds (LCP) is not going to get faster for you in your region by some magical front end dance.
Not every business is the same and no one solution will work for everyone. And concluding that we should "go back to jQuery" really speaks volumes of the author. jQuery was not "the good old days".
The problem with FE is that they seem to be wannabe nodejs BE devs instead of the W3C experts they should be. If FE devs focus on web standards and less on Rube Goldberg machines they would be well served.
here here. I am very thankful that when i started out a decade ago the first book i read was Designing with Web Standards. I still recommend it to noobs but i can’t necessarily blame them for not getting through it when there are more shiny things like React and Vite to learn about.
To read that book now would be largely a history lesson because we no longer have to fight to maintain some quirk between a handful of browser versions. But man, knowing about semantic markup and really getting why that is a thing in the first place is super important.
there is no way any competently written back end system takes 5-7 seconds for any reason whatsoever. A middling back end system with median complexity is doing 10-100K requests per second per server and is near-perfectly horizontally scalable.
There was a time where a request taking even 500ms was considered to be slow, and then all of a sudden it just became normal to see API traces where requests would take over a second, or multiple seconds, and people would just shrug at it.
Even a backend roughly cobbled together in PHP4 with Varnish running on top of it would considerably outperform some of the stuff that is accepted as 'good enough' today.
> there is no way any competently written back end system takes 5-7 seconds for any reason whatsoever.
I'd argue that even a well written system that allows arbitrary date ranges and filtering of data can easily run past that limit. You just can always know ahead of time what some client might request and some strategies for making normal queries fast can make some queries slower. Its tradeoffs all the way down.
definitely not. If you don't already know ahead of time what a client might request, and just let them request anything arbitrarily without regard for whether that data is indexed or cached, then you are not competently writing a backend system.
If you serve data from a DC in California to the west coast of Australia it will take 10 seconds of just network transfer time. Sometimes data has a high degree of cardinality and cannot be cached. Some companies cannot afford to, or for other reasons cannot, have regional instances of their compute surfaces. This is just one common scenario, there are many others.
> A middling back end system with median complexity is doing 10-100K requests per second per server and is near-perfectly horizontally scalable.
You know perfectly your SLAs without knowing anything about the business, data, or the user access pattern? You don't even need a budget? Impressive!
You have no idea what you're talking about. Perth is about a third of a second away from Los Angeles. There is no data that cannot be cached owing to 'high cardinality'. There does not exist a company that is trying to serve Perth traffic from a US CA DC that cannot afford a server that can do 100k RPS.
Yeah, for anyone reading this that doesn't know these are embarrassing numbers. We call it an outage if our p95 latency goes above 100ms for more than a minute. Even if you think this is aggressive 50x slower is not normal. There will be necessarily be tasks that take longer than that but don't make your user sit there with the page just spinning. Post back when the task is finished asynchronously. Especially on mobile where those kinds of delays are assumed to be issues with the network and users will just hit the x and refresh.
I cannot fathom how you arrived at that conclusion - there are so many systems that need to display the results of complex data queries where caching or precomputing the results does not make sense - waiting several seconds for results would be normal in those cases.
I will echo what the parent said: there’s no way your backend is taking seconds (fucking seconds) to return data unless there is something terribly wrong with your system.
Complex queries should be optimized. The only time I have run into query issues is when: I was lazy, and didn’t want to optimize the query/schema/data layout and structures; the system was built by someone of questionable sanity and skillset; or the generated data is legitimately compute intensive, requiring lots of math i.e. more ops and cycles, but at that point it’s a report and the user can wait for it to gen (but in this case it is a lot of math that hasn’t taken advantage of parrallization).
In the wild, I’ve mostly seen people having zero clue what they’re doing (this includes management, who are as culpable for not caring about perf).
ChatGPT and many AI tools take several seconds to return responses.
I’m not saying it should always or even most of the time be the case (quite the opposite - I’m with you and parent on that) but to say that there is no situation like that strikes me as pretty odd.
10-100k RPS is throughput, not latency. There is a well-known latency-throughput tradeoff. For example, Erlang’s BEAM VM is optimized for low latency, while JVM is optimized for high throughput.
> there is no way any competently written back end system takes 5-7 seconds for any reason whatsoever.
Sure there is--ad networks.
Remember when 100ms was considered fatal? Funny how that went right out the window when the big companies decided that shoveling more ads at users was more profitable than anything else.
The current state of web development is all to paper over the idiocies brought along by serving ads.
Those of us who do web development and don't have to serve ads can pretty much use anything and hit metrics under 100ms and can scale for a very, very long time.
I think most of the post fell wide of the mark and as much as I hate to be cynical, I feel like the completely tangential Erlang piece is just there to game HN because HN lately can't get enough of Erlang and Elixir.
I don't think there was much to take away from this article except that the author should perhaps spend less time paying attention to the opinion of randos on Twitter.
> 5-7 second skeleton loaders are there because backend systems are slow, not because of the front end application.
There are very, cery, very few cases of this. The vast majority of "applications" we have are due to people not caring.
E.g. a recent Reddit redesign was praised because their time to paint was 2.4 seconds. Their backend rarely responds in more than 0.4 seconds.
> If FE devs focus on web standards and less on Rube Goldberg machines they would be well served.
Why do you think we have these Rube Goldberg machines? Precisely because standards are utter garbage. And doing anything with them leads to more Rube Goldberg machines.
Really enjoyed the tangents and the point makes sense. I hate idiotic frontend hate and I am not a fan of htmx, but I still like its approach - if it makes sense for the website.
I think every developer who has worked using a CMS using traditional templating + "ajax" has reinvented parts of it at some point in their career. At least I have.
If I would find myself in this scenario again, I'd gladly reach for htmx.
Apart from the social media observations, topics tend to be random here, but I like train-of-thought writing.
It's powerful to have your front-end library automagically run code returned by your API, sure.
But you can't hand-wave the security concerns of that away by ridiculing the people trying to discuss them.
There is a fundamental difference between your server returning data versus returning code. If you don't want to accept that, fine, it's your project, or career, whatever. But if you conduct extensive ad hominems against people (I'm not a fan of "Devrels" but jeez, that part of this post felt like blatant character assassination) instead of just debating the facts then you're a douche and no better than the people you're disparaging.
I think HTMX is an interesting project that I'll probably give a try at some point. But breathless cultish hype of it has already turned me off. I don't even know if React got this much attention!?
> But you can't hand-wave the security concerns of that away...
What security concerns, exactly?
> There is a fundamental difference between your server returning data versus returning code.
If my server returns a bit of something, and then my application code running in the browser takes conditional action based on that return value, was it data or was it code?
> ah yes, the famous XSS coming from your own backend API calls…
Author does not seem to understand the concept of XSS. Of course your own API could return user-provided data to trigger XSS attacks. Entering <script>alert(1);</script> in a messenger to see whether its rendered value is escaped correctly is a famous example.
> htmx, a disciple of hypermedia, available only in hardcover do not look for alternatives, has been manifesting itself into existence recently
As a screen reader user with no way to read words written on paper (short of getting a scanner and spending hours on putting books through it), I have to look for alternatives. I hate it when authors do this. I get why, but it's still frustrating.
There's also the fact that the author of this article decided to embed X posts as unlabeled screenshots for some unknown reason. This breaks accessibility, copy/paste, translations, flexible screen layouts and probably a bunch of other things I'm not aware of. Putting text in images is never a good idea, much less so when there's a perfectly fine embeds API for GOd's sake.
I'm really saddened to see somebody who claims to care about web standards be so dismissive of accessibility concerns.
I don't know what they're talking about with "available only in hardcover". Hypermedia Systems is here: https://hypermedia.systems/ available in HTML online, ebook format, hardcover, or you could go to the github repo and probably transform the source into whatever format you want: https://github.com/bigskysoftware/hypermedia-systems
> htmx, a disciple of hypermedia, available only in hardcover do not look for alternatives, has been manifesting itself into existence recently
I think this whole sentence was meant to be a joke. This "article" is filled with juvenile humor, random tangents, and twitter screenshots. The irony of complaining about people not properly using hypermedia while omitting some of the basic accessibility attributes of hyper text markup language (alt text) is astonishing.
I find all the marketing, advertising intentional or not, around HTMX really obnoxious.
Does it have its merits? Maybe? I don't know, I can never get past the memes and shit-slinging. Or past them superficially co-opting terms they have nothing to do with like Erlang, or hypermedia.
i am willing to admit that i get a little wild on the ol' twitters and understand if that isn't everyone's cup of tea (otoh, you probably wouldn't have heard of htmx if i went at things the normal way: i'm a solo dev in montana.)
Chapters 1 and 2 focus on what hypermedia is and how a hypermedia system works. My definition of hypermedia is "a media that contains hypermedia controls":
> A hypermedia control is an element in a hypermedia that describes (or controls) some sort of interaction, often with a remote server, by encoding information about that interaction directly and completely within itself.
I think that's a pretty clear definition. Maybe you disagree w/ it, but it's at least defensible, no?
As far as what it has to do w/ htmx, htmx extends HTML as a hypermedia, making the set of hypermedia exchanges it can perform larger and more general. (This is in contrast w/ something like React, which typically uses a fixed-format non-hypermedia data API to communicate w/ the server.)
I understand you don't like the somewhat crazy social media presence of htmx, but the philosophy underneath it is fairly well developed and, as far as I can tell, at least plausibly related to hypermedia.
> Chapters 1 and 2 focus on what hypermedia is and how a hypermedia system works.
Yes, they do. And they turn around, slap an "Extending HTML As Hypermedia" on it as if that sentence made any sense, and then keep on pretending what they do has anything to do with hypermedia.
> A hypermedia control is an element in a hypermedia that describes (or controls) some sort of interaction
> I think that's a pretty clear definition.
It's a string of words that make zero to no sense. What is an "element in a hypermedia"?
> htmx extends HTML as a hypermedia
This sentence also makes no sense
> making the set of hypermedia exchanges it can perform larger and more general.
Neither is true. HTMX limits all exchanges to HTML, and HTML only, and then clearly separates whatever HTML it accepts and "JSON Data APIs" into two separate entites. Doesn't make them hypermedia.
> but the philosophy underneath it is fairly well developed and, as far as I can tell, at least plausibly related to hypermedia.
But it's not. It's slapped on with al the confidence of a teenager who discovered a new word and now uses it everywhere.
Hypermedia isn't "we do REST requests and get HTML back" or "we separated HTML and JSON into two separate APIs, these are now hypermedia elements in hypermedia as we've extended HTML as hypermedia".
Just because you repeat something a hundred times, doesn't make it so.
They even mention HATEOAS a few times as if it had something to do with HTMX and literally throw it out of the window.
Edit:
They even completely misrepresented Roy Fielding's REST paper by pretending it only applies to HTML and claiming this somehow reflects the original idea behind the dissertation
"When I say Hypertext, I mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions"
htmx "extends" HTML as hypermedia by generalizing the idea of hypermedia controls in it, which is laid out pretty clearly in chapter 3. You might say it's a bad generalization, or generalizing hypermedia controls in general is a bad idea, but it's pretty straight forward:
- generalize the event that triggers the request
- generalize the HTML element that can issue the request
- generalize the type of HTTP request that can be made
- generalize the way the response can be placed in the page
I don't think it's reasonable to say that we pretend REST only applies to HTML when we present a completely different hypermedia, Hyperview, in our book as an example of a REST-ful system:
It appears that you really don't like me at a personal level, which I understand: I don't like myself a lot of the time. However, i think if you stepped back from that fact, you'd see you are being a bit unreasonable here.
> When I say Hypertext, I mean the simultaneous presentation of information
Doesn't come from his dissertation, does it?
Also, there's a reason hypertext and hypermedia are two different words.
> htmx "extends" HTML as hypermedia by generalizing the idea of hypermedia controls in it,
Indeed, you're creating your own custom DSL aka your own custom client to speak a custom protocol over the wire that only HTMX understands.
This is no different than someone doing exactly the same, but requesting JSON, XML or binary streams from the server, as long as their client knows how to deal with them.
> we present a completely different hypermedia, Hyperview, i
Ah yes. This is "different hypermedia", that there's no client for, but "many developers ignore the hypermedia features of the browser, in favor of building their web applications entirely in JavaScript." Unlike you, of course.
> It appears that you really don't like me at a personal level,
Until this moment in time I had no idea who you were and what you were doing. You were just some random text on screen.
If you are the author of HTMx, well, with this you just continue the same thing, again: acting as an overconfident teenager with a very superficial understanding of things, and taking everything as a personal affront.
> This is no different than someone doing exactly the same, but requesting JSON, XML or binary streams from the server, as long as their client knows how to deal with them.
I don't disagree w/ that, so long as there are hypermedia controls imposed on top of those formats (which are not natural hypermedia w/ native hypermedia controls) and are being consumed by a client that implements the uniform interface properly (https://htmx.org/essays/hypermedia-clients/)
> This is "different hypermedia", that there's no client for
Hyperview includes a client, which is one of the reasons I think it will be a successful hypermedia, in contrast w/, for example, attempts to impose hypermedia controls on JSON but not providing a client to consume those controls. (See the above essay, where i discuss this)
> acting as an overconfident teenager with a very superficial understanding of things, and taking everything as a personal affront.
I try to be a humble man and i certainly have much to be humble about, and i appreciate the reminder that at times I fall into the sin of pridefulness. Pride goeth before the fall, and a haughty heart before destruction.
HTMX is really pleasant to work with and in many cases means getting stuff done with way less code. I have an internal tool built with React and replaced it with HTMX. The HTMX version is much simpler and easier to add features. HTMX doesn't make sense for all use cases, but sometimes it's all around a better choice than something like React.
79 comments
[ 3.0 ms ] story [ 126 ms ] threadSomeone that does not understand sanitisation boundaries has no business working on web development. This is how you end up with html in your database, people just render whatever piece of data because it "just works" in frameworks like react (I've seen it myself in production).
It is true that the average WordPress developer might not care about XSS, and to refute one specific point: I have seen third-party returning HTML, plenty of them.
Deliberately acting on the contents response instead of directly executing code from said party forces you to think about XSS.
But it's not specific to htmx of course, it would be the same when using innerHTML or something while using a field in a JSON API response.
It's true that frameworks like React have safer defaults than Vanilla JS in that regard.
The text jumps from one topic to the other so abruptly that I had to check multiple times if I'm still reading the same article.
I guess I'm just not jiving with the author's thought process.
5-7 second skeleton loaders are there because backend systems are slow, not because of the front end application. You can say "oh but you can pre-render", but there are times when you can't. You could render the whole thing on the backend, but then you'll wait 5-7 seconds at a white page vs. progressive loading. Whatever is taking 5-7 seconds (LCP) is not going to get faster for you in your region by some magical front end dance.
Not every business is the same and no one solution will work for everyone. And concluding that we should "go back to jQuery" really speaks volumes of the author. jQuery was not "the good old days".
The problem with FE is that they seem to be wannabe nodejs BE devs instead of the W3C experts they should be. If FE devs focus on web standards and less on Rube Goldberg machines they would be well served.
To read that book now would be largely a history lesson because we no longer have to fight to maintain some quirk between a handful of browser versions. But man, knowing about semantic markup and really getting why that is a thing in the first place is super important.
Even a backend roughly cobbled together in PHP4 with Varnish running on top of it would considerably outperform some of the stuff that is accepted as 'good enough' today.
Like it's a trivial task. If it is... the whole system wasn't that complicated and likely similar results could be achieved without external caching.
I'd argue that even a well written system that allows arbitrary date ranges and filtering of data can easily run past that limit. You just can always know ahead of time what some client might request and some strategies for making normal queries fast can make some queries slower. Its tradeoffs all the way down.
> A middling back end system with median complexity is doing 10-100K requests per second per server and is near-perfectly horizontally scalable.
You know perfectly your SLAs without knowing anything about the business, data, or the user access pattern? You don't even need a budget? Impressive!
What? Is this a typo or do you think that’s true?
Where did you get that calculation? Looks way way off
I can measure the difference between US, Singapore and Sydney based DCs, but it's milliseconds.
10 seconds is abnormal and would indicate to me that something isn't functioning as expected!
Complex queries should be optimized. The only time I have run into query issues is when: I was lazy, and didn’t want to optimize the query/schema/data layout and structures; the system was built by someone of questionable sanity and skillset; or the generated data is legitimately compute intensive, requiring lots of math i.e. more ops and cycles, but at that point it’s a report and the user can wait for it to gen (but in this case it is a lot of math that hasn’t taken advantage of parrallization).
In the wild, I’ve mostly seen people having zero clue what they’re doing (this includes management, who are as culpable for not caring about perf).
I’m not saying it should always or even most of the time be the case (quite the opposite - I’m with you and parent on that) but to say that there is no situation like that strikes me as pretty odd.
In ChatGPT's case, I'm assuming they're throttling responses to not hemorrhage money.
https://remix.run/
Sure, I can allow users to run reports that take multiple seconds, but I'm generally not delivering that to the browser to be rendered.
And if I was, I'd crash the browser tab. Which is surprisingly easy to do...
Sure there is--ad networks.
Remember when 100ms was considered fatal? Funny how that went right out the window when the big companies decided that shoveling more ads at users was more profitable than anything else.
The current state of web development is all to paper over the idiocies brought along by serving ads.
Those of us who do web development and don't have to serve ads can pretty much use anything and hit metrics under 100ms and can scale for a very, very long time.
2. Salesforce, JIRA, Microsoft Teams, Reddit, even Gmail recently takes up to a minute to get content and be responsive, just to name a few.
What are the best resources for someone interested in being a W3C expert? (Aside from just slogging through https://www.w3.org/TR/)
Generally more practical than W3C.
I don't think there was much to take away from this article except that the author should perhaps spend less time paying attention to the opinion of randos on Twitter.
There are very, cery, very few cases of this. The vast majority of "applications" we have are due to people not caring.
E.g. a recent Reddit redesign was praised because their time to paint was 2.4 seconds. Their backend rarely responds in more than 0.4 seconds.
> If FE devs focus on web standards and less on Rube Goldberg machines they would be well served.
Why do you think we have these Rube Goldberg machines? Precisely because standards are utter garbage. And doing anything with them leads to more Rube Goldberg machines.
I think every developer who has worked using a CMS using traditional templating + "ajax" has reinvented parts of it at some point in their career. At least I have.
If I would find myself in this scenario again, I'd gladly reach for htmx.
Apart from the social media observations, topics tend to be random here, but I like train-of-thought writing.
But you can't hand-wave the security concerns of that away by ridiculing the people trying to discuss them.
There is a fundamental difference between your server returning data versus returning code. If you don't want to accept that, fine, it's your project, or career, whatever. But if you conduct extensive ad hominems against people (I'm not a fan of "Devrels" but jeez, that part of this post felt like blatant character assassination) instead of just debating the facts then you're a douche and no better than the people you're disparaging.
I think HTMX is an interesting project that I'll probably give a try at some point. But breathless cultish hype of it has already turned me off. I don't even know if React got this much attention!?
Your server already returns arbitrary html (which can include executable code) unless you are running a fully static backend.
HTMX moves where the trust boundary is a bit, but it doesn't change that it exists at all.
What security concerns, exactly?
> There is a fundamental difference between your server returning data versus returning code.
If my server returns a bit of something, and then my application code running in the browser takes conditional action based on that return value, was it data or was it code?
Since we're bashing dumb comments with dumb comments, the Twitter comment is actually saying:
over 25,000 hours
Assuming
That's If he worked any harder than that, that's still over 25,000 hours.Author does not seem to understand the concept of XSS. Of course your own API could return user-provided data to trigger XSS attacks. Entering <script>alert(1);</script> in a messenger to see whether its rendered value is escaped correctly is a famous example.
As a screen reader user with no way to read words written on paper (short of getting a scanner and spending hours on putting books through it), I have to look for alternatives. I hate it when authors do this. I get why, but it's still frustrating.
There's also the fact that the author of this article decided to embed X posts as unlabeled screenshots for some unknown reason. This breaks accessibility, copy/paste, translations, flexible screen layouts and probably a bunch of other things I'm not aware of. Putting text in images is never a good idea, much less so when there's a perfectly fine embeds API for GOd's sake.
I'm really saddened to see somebody who claims to care about web standards be so dismissive of accessibility concerns.
X posts as screenshots suck though.
I think this whole sentence was meant to be a joke. This "article" is filled with juvenile humor, random tangents, and twitter screenshots. The irony of complaining about people not properly using hypermedia while omitting some of the basic accessibility attributes of hyper text markup language (alt text) is astonishing.
Does it have its merits? Maybe? I don't know, I can never get past the memes and shit-slinging. Or past them superficially co-opting terms they have nothing to do with like Erlang, or hypermedia.
It's a toy mascarading as a serious tool.
This has nothing to do with hypermedia. You can return json, xml, pdf, or binary and be 100% hypermedia-driven.
https://hypermedia.systems
i am willing to admit that i get a little wild on the ol' twitters and understand if that isn't everyone's cup of tea (otoh, you probably wouldn't have heard of htmx if i went at things the normal way: i'm a solo dev in montana.)
Just because you use get/post and return HTML does not make you hypermedia, or "extend HTML with hypermedia" whatever that means.
> A hypermedia control is an element in a hypermedia that describes (or controls) some sort of interaction, often with a remote server, by encoding information about that interaction directly and completely within itself.
I think that's a pretty clear definition. Maybe you disagree w/ it, but it's at least defensible, no?
As far as what it has to do w/ htmx, htmx extends HTML as a hypermedia, making the set of hypermedia exchanges it can perform larger and more general. (This is in contrast w/ something like React, which typically uses a fixed-format non-hypermedia data API to communicate w/ the server.)
I understand you don't like the somewhat crazy social media presence of htmx, but the philosophy underneath it is fairly well developed and, as far as I can tell, at least plausibly related to hypermedia.
Yes, they do. And they turn around, slap an "Extending HTML As Hypermedia" on it as if that sentence made any sense, and then keep on pretending what they do has anything to do with hypermedia.
> A hypermedia control is an element in a hypermedia that describes (or controls) some sort of interaction
> I think that's a pretty clear definition.
It's a string of words that make zero to no sense. What is an "element in a hypermedia"?
> htmx extends HTML as a hypermedia
This sentence also makes no sense
> making the set of hypermedia exchanges it can perform larger and more general.
Neither is true. HTMX limits all exchanges to HTML, and HTML only, and then clearly separates whatever HTML it accepts and "JSON Data APIs" into two separate entites. Doesn't make them hypermedia.
> but the philosophy underneath it is fairly well developed and, as far as I can tell, at least plausibly related to hypermedia.
But it's not. It's slapped on with al the confidence of a teenager who discovered a new word and now uses it everywhere.
Hypermedia isn't "we do REST requests and get HTML back" or "we separated HTML and JSON into two separate APIs, these are now hypermedia elements in hypermedia as we've extended HTML as hypermedia".
Just because you repeat something a hundred times, doesn't make it so.
They even mention HATEOAS a few times as if it had something to do with HTMX and literally throw it out of the window.
Edit:
They even completely misrepresented Roy Fielding's REST paper by pretending it only applies to HTML and claiming this somehow reflects the original idea behind the dissertation
Here's what Fielding says:
"When I say Hypertext, I mean the simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions"
htmx "extends" HTML as hypermedia by generalizing the idea of hypermedia controls in it, which is laid out pretty clearly in chapter 3. You might say it's a bad generalization, or generalizing hypermedia controls in general is a bad idea, but it's pretty straight forward:
- generalize the event that triggers the request
- generalize the HTML element that can issue the request
- generalize the type of HTTP request that can be made
- generalize the way the response can be placed in the page
I don't think it's reasonable to say that we pretend REST only applies to HTML when we present a completely different hypermedia, Hyperview, in our book as an example of a REST-ful system:
https://hypermedia.systems/hyperview-a-mobile-hypermedia/
It appears that you really don't like me at a personal level, which I understand: I don't like myself a lot of the time. However, i think if you stepped back from that fact, you'd see you are being a bit unreasonable here.
Doesn't come from his dissertation, does it?
Also, there's a reason hypertext and hypermedia are two different words.
> htmx "extends" HTML as hypermedia by generalizing the idea of hypermedia controls in it,
Indeed, you're creating your own custom DSL aka your own custom client to speak a custom protocol over the wire that only HTMX understands.
This is no different than someone doing exactly the same, but requesting JSON, XML or binary streams from the server, as long as their client knows how to deal with them.
> we present a completely different hypermedia, Hyperview, i
Ah yes. This is "different hypermedia", that there's no client for, but "many developers ignore the hypermedia features of the browser, in favor of building their web applications entirely in JavaScript." Unlike you, of course.
> It appears that you really don't like me at a personal level,
Until this moment in time I had no idea who you were and what you were doing. You were just some random text on screen.
If you are the author of HTMx, well, with this you just continue the same thing, again: acting as an overconfident teenager with a very superficial understanding of things, and taking everything as a personal affront.
No, it came from a talk he gave entitled "A little REST and Relaxation":
https://www.slideshare.net/royfielding/a-little-rest-and-rel...
> This is no different than someone doing exactly the same, but requesting JSON, XML or binary streams from the server, as long as their client knows how to deal with them.
I don't disagree w/ that, so long as there are hypermedia controls imposed on top of those formats (which are not natural hypermedia w/ native hypermedia controls) and are being consumed by a client that implements the uniform interface properly (https://htmx.org/essays/hypermedia-clients/)
> This is "different hypermedia", that there's no client for
Hyperview includes a client, which is one of the reasons I think it will be a successful hypermedia, in contrast w/, for example, attempts to impose hypermedia controls on JSON but not providing a client to consume those controls. (See the above essay, where i discuss this)
> acting as an overconfident teenager with a very superficial understanding of things, and taking everything as a personal affront.
I try to be a humble man and i certainly have much to be humble about, and i appreciate the reminder that at times I fall into the sin of pridefulness. Pride goeth before the fall, and a haughty heart before destruction.
https://star-history.com/embed#bigskysoftware/htmx&bigskysof...
at the end of the day, i enjoy memes and shoot-posting and, as they say, to thine own self be true.
I'm not sure why so much of this thread takes offense to your work. HTMX has been transformational for me. I'm grateful that you persevere.
Ps: Nathan James, pls stop
Generally speaking - when you make an HTTP request - you are likely returning:
XML <root> <users> <user> <id>1</id> <name>foo</name> </user> </users> </root>
[or]
JSON { "users": [{ "id": 1, "name": "foo" }] }
[or]
HTML: <div class="users"> <div class"user"> <span class="user-id">1</span> <span class="user-name">foo</span> <button class="btn btn-small">edit</button> </div> </div>
[When using HTMX, you would add some additional tags. You are still just returning HTML]
What makes this anymore (or any less) dangerous? What is the problem?I guess responses is more in line with -- "they tooook our jooooowbs!"
From what I read elsewhere. "React creates jobs. HTMX doesn't"