Wait... HTMX is not just a meme?

I’ve seen job ads for it, so official enough

As somebody who knows a little html and css does mostly Python and C dev, htmx looks dope as hell.

HTMX is just as stupid relative to JS as Bootstrap/Tailwind etc are to CSS.

It's just what happens routinely when people completely fail to understand some tech and then make an "improvement".

@Fast-Nop don’t see what HTMX fails to understand about JS

@lotd Basically when and how to use it. Same as CSS frameworks with CSS.

@Fast-Nop well.. when they make you/your team more productive or simply makes you/team enjoy working more.

@lotd Starting with their motivations:

Why should only <a> and <form> be able to make HTTP requests?

They don't. Never looked at the network tab of your browser dev tools? Never seen what an IMG tag causes?

Why should only click & submit events trigger them?

Because that works with all user agents, and because these are the actually useful ones apart from shit that shouldn't even be on a website.

Why should only GET & POST methods be available?

Because these are the useful and secure ones. You don't want CREATE or DELETE available.

Why should you only be able to replace the entire screen?

So that deep links work and can be bookmarked, and also this wouldn't be an issue if you didn't bloat your website and neglected client side caching.

@lotd Also, looking at their own website, I see several scripts in the head with no async/defer, which already means they are unqualified to use JS. It's also evident that they don't know semantic HTML. Their main menu is a div soup with no nav, ul, li in sight. Style tag in the markup is invalid anyway, and the sponsor table is an actual table. A fucking layout table like it's 1998 or something.

The whole website that ought to be a primary show case just reeks of sleaziness and incompetence.

If you and your team enjoy working with completely nonsensical, incompetent trash, then there's something wrong with your team.

Also "nice": their trash example of lazy loading.

Nonsensical alt tag because fuck accessibility, and screwing around with JS instead of simply using HTML's loading="lazy". Failure to understand HTML leads to JS fuckery for nothing.

Even worse, they actually load a placeholder image, wasting bandwidth for nothing, because that's what the browser's preloader will see and load automatically before any script is even loaded.

Also, what the fuck makes them download a 2.5MB "sinon.js" that is used for testing purpose and shouldn't even end up in production?!

If these clowns can't get basics right, there's even less reason to trust them with anything else.

@Fast-Nop I haven’t inspected their website. I see it’s a mess, nonetheless not what I’m judging on.
I Only glided over their library and some examples. Looked simple enough and generally I like the idea of Locality of Behavior thru HTML attributes.
to me it looks like promoting server side partials rendered from the server which I in general agree is better than client side rendering & vdom for most projects.
All the lazy loading & other whizzbang I’ve just gracefully ignored. As I haven’t needed it.

Also the thing about other html elements as hypermedia initializers is generally something I often see in frontend projects, you know .. for UX sake.

@lotd The general trust issues with the HTMX devs aside, slopping a DSL into non-standard HTML attributes is pretty much on a par with CSS frameworks doing the same with presentational CSS classes.

It’s a little weird they said ONLY <a> and <form> tags make http requests when there’s millions of other ways, you just have to stick a handler on(event) on an element and the handler does the actual calling when the event is triggered, obviously. In react it’s mostly done in a callback in a useEffect after the initial render so there’s not even an element tied to it whatsoever.

Maybe the devs didn’t write the description and they hired a freelancer

HOPEFULLY the people who developed the website aren’t the SAME PEOPLE who developed this framework

@Fast-Nop if it’s something that’s often repeated (>= 3) then I find it a good candidate to extract as a component, not sure if CSS is the right place though

@aviophille You know, the fun when non-retarded people use irony is that the literal interpretation wouldn't make sense. With you, it's the other way around, which is also why it's not funny, just sad.

@Fast-Nop I think front end having full range of REST verbs would be good, actually. There’s nothing insecure about it.

@AlgoRythm Why would it be good? What actual problem would it solve?

Also DELETE would mean to delete the current HTML, which doesn't even make sense when it's generated HTML from a DB, and CREATE for a new file overwriting the current HTML is an obvious potential security issue. Can be handled properly ofc, but... why?!

Which is why server side languages such as PHP don't even support that. There's $_GET, $_POST, and the combo $_REQUEST, but no $_CREATE or $_DELETE.

@Fast-Nop Minimize reliance on JavaScript. Having a form or anchor tag which could delete a record without the need of opening up a request in JS would make sense, rather than them linking to something like GET /entity/delete/12345

@AlgoRythm Uhm.. HTMX is a JS library. So doing that completely relies on JS.

Not to mention that abusing an anchor tag for that has always been completely wrong.

@Fast-Nop I'm responding to you in general.

You said:

"Starting with their motivations: ...

Why should only GET & POST methods be available?

Because these are the useful and secure ones. You don't want CREATE or DELETE available."

I disagreed

@aviophille You didn't even understand the question, as always, so shut up, FE moron.

@aviophille You still didn't understand - just vomiting up some random stuff that you guess might be vaguely related. Whatever you post is invariably complete trash.

why do i feel like HTMX is a lame excuse for frontend devs to pretend like they know how to use a frontend "framework"?

hate me, but i'm going to stick with react - it's literally NEVER let me down in any situation ever

@fullstackcircus im also sick of every year a new framework that I have to learn to stay in the field and not lose my job and be rejected by everyone for lack of experience in that framework

@TeachMeCode same. i think i've finally at that point in my career where i start to understand the boomers and am just sick of the whole hype all the time now

@TeachMeCode Hasn't really been a new framework with widespread adoption since svelte? The rest are React variations.

But they're all the same, really.

@TeachMeCode If you think you have to learn every new framework that comes every year to stay relevant, you've not paid attention to what the market or certain industries demand and the State of JS/CSS/... surveys.
Since Deno and now Bun came out, the amount of jobs that were on Node.js barely changed in the areas I've seen, and that holds true for FE with React, Vue, Svelte (Angular and Ember being the notable ones that declined in various job sectors).

I don't know if you're new to the field or working in a startup that craves shiney new things without looking at the long term (like community adoption, ecosystem, job availabilities, etc) but that route will not help you (unless you truly want to be decent at dozens of frameworks and not experienced enough in a few).

@Berkmann18 true. I wasn’t being literal when I said every year.