Htmx Is a Erlang
matt.sh
matt.sh
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.
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.
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.
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).
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.
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.
Since we're bashing dumb comments with dumb comments, the Twitter comment is actually saying:
over 25,000 hours
Assuming
- 5 weeks of vacation each year
- 8 hours of work, 5 days a week
(52 - 5) * 5 days * 8 hours * 15 years = 28.200 hours
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.
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]
<div class="users">
<div class"user" hx-target="this" hx-swap="outerHTML">
<span class="user-id">1</span>
<span class="user-name">foo</span>
<button hx-get="/user/1/edit" class="btn btn-small">edit</button>
</div>
</div>
I guess responses is more in line with -- "they tooook our jooooowbs!"
From what I read elsewhere. "React creates jobs. HTMX doesn't"
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.
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.
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.
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?
Ps: Nathan James, pls stop