On: htmx

[cosmojg]

Heh, the "Memes" section of their Essays page is brilliant: https://htmx.org/essays/#memes

[hliyan → cosmojg]

I actually found their haiku quite insightful:

    javascript fatigue:
    longing for a hypertext
    already in hand

[vyrotek → cosmojg]

And lots more if you follow him on Twitter.

https://twitter.com/htmx_org

[411111111111111 → cosmojg]

A lot are also missing the point entirely for comedy's sake. Which is admittedly fine for a meme...

While I love making projects with htmx, doing the equivalent for the complicated frontends we've got at my dayjob would not be enjoyable to maintain either. You'd end up with with fragment routes all over the place and will have serious issues finding where which is used, as the routes are all just strings with variable substitutions. Its also annoying to write non-e2e tests for the resulting backend IME, which is totally fine for a lot of applications, but forces you to restructure your code awkwardly to be able to write unit-tests in the backend

[Nextgrid → 411111111111111]

There's a class of applications where JS-heavy SPAs make perfect sense. HTMX should not be viewed as a general anti-JS movement. It is indeed unmaintainable to deliver the same functionality in HTML as a JS SPA would allow.

The catch is that very few JS SPAs actually deliver that functionality either - the functionality I'm talking about is desktop-app-grade functionality (think a trading terminal for example) that very few JS SPAs actually deliver. Most JS SPAs are just shitty reimplementations of basic browser functionality, and that is reasonably trivial to convert to server-side rendered HTML with HTML or ad-hoc (inline?) JS sprinkled in where necessary.

Keep in mind that server-side-routing doesn't prevent the use of React or similar frameworks either. If you have an application where 90% of the pages would be fine as server-side-rendered HTML but 10% require heavy interactivity, you can have your server return a page that embeds React or your JS framework of choice. (the reverse is also possible - if you have a JS-heavy website but have a few "boring" pages like for example an account details form, you can have your backend serve that as an HTML form and just have your JS iframe it)

[yawaramin → 411111111111111]

> You'd end up with with fragment routes all over the place

Or, you could define every route to render a full page by default and render a fragment only if you detect an htmx request. So you end up with the same number of routes as for a normal MPA.

[winrid → cosmojg]

Those are great.

What's the logo of the cornucopia looking thing next to the django and rails logos?

[DarkCrusader2 → winrid]

Flask, a python micro framework.

[JodieBenitez → cosmojg]

This is gold !

[shearos → cosmojg]

so good