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.<p>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.<p>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".<p>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.
> htmx, a disciple of hypermedia, available only in hardcover do not look for alternatives, has been manifesting itself into existence recently<p>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 <i>have</i> to look for alternatives. I hate it when authors do this. I get why, but it's still frustrating.<p>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.<p>I'm really saddened to see somebody who claims to care about web standards be so dismissive of accessibility concerns.
The whole "htmx is the most dangerous thing to exist" is so funny to me.<p>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).
> ah yes, the famous XSS coming from your own backend API calls…<p>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.
> <i>also, 25,000 hours in 15 years? what kind of rookie lazy piece of shit numbers are those? [...]</i><p>Since we're bashing dumb comments with dumb comments, the Twitter comment is actually saying:<p><i>over 25,000 hours</i><p>Assuming<p><pre><code> - 5 weeks of vacation each year
- 8 hours of work, 5 days a week
</code></pre>
That's<p><pre><code> (52 - 5) * 5 days * 8 hours * 15 years = 28.200 hours
</code></pre>
If he worked any harder than that, <i>that's still over 25,000 hours.</i>
Maybe I am missing something, here.<p>Generally speaking - when you make an HTTP request - you are likely returning:<p>XML
<root>
<users>
<user>
<id>1</id>
<name>foo</name>
</user>
</users>
</root><p>[or]<p>JSON
{
"users": [{
"id": 1,
"name": "foo"
}]
}<p>[or]<p>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><p>[When using HTMX, you would add some additional tags. You are still just returning HTML]<p><pre><code> <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>
</code></pre>
What makes this anymore (or any less) dangerous? What is the problem?<p>I guess responses is more in line with -- "they tooook our jooooowbs!"<p>From what I read elsewhere.
"React creates jobs. HTMX doesn't"
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.<p>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.<p>If I would find myself in this scenario again, I'd gladly reach for htmx.<p>Apart from the social media observations, topics tend to be random here, but I like train-of-thought writing.
I find all the marketing, advertising intentional or not, around HTMX really obnoxious.<p>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.<p>It's a toy mascarading as a serious tool.
It's powerful to have your front-end library automagically run code returned by your API, sure.<p>But you can't hand-wave the security concerns of that away by ridiculing the people trying to discuss them.<p>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.<p>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!?