by vimota on 7/19/22, 6:38 AM with 138 comments
by noidexe on 7/19/22, 11:36 PM
From the user point of view, I think there are two main types of experiences on the Web:
a ) Interactive documents. Basically web 1.0 but today we want fancier transitions and interactions. This can be provided by htmx and should always have been developed declaratively. It should ideally be provided by the browser and htmx shouldn't need to exist. Examples of this are Gmail and most social networks and forums including this one.
b) Desktop apps-but-I-don't-want-to-have-to-install-them. This would be things like Google Docs, Photopea and most real-time games. To deliver this, right now we have a browser that has become almost an OS inside an OS, to the point only Google can keep up with the complexity. On top of that, we pretend apps are documents and for all the imperative code we need we use a scripting language that was not meant for that, and we need a really complex VM just to keep it more or less performant. For this use case I think at some point we should move all the way into just delivering apps, if not native apps, something like wasm, where the browser tab would just be a vm player.
by silviogutierrez on 7/20/22, 12:45 AM
But to me, writing my markup in JSX (really, TSX with TypeScript) and using scoped CSS solutions was too good to pass up. I just couldn't bear writing text-based templates.
That's why I built Reactivated: combining the best of both worlds. Server-rendered, simple markup — albeit still in TypeScript — but you can add interactivity as needed.
Of course, HTMX is far less opinionated and framework-agnostic. So it can be used with any number of libraries / stacks.
[1] https://www.reactivated.io
[2] https://www.reactivated.io/documentation/philosophy-goals/#t...
[3] https://www.reactivated.io/documentation/philosophy-goals/#r...
[4] https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
by recursivedoubts on 7/19/22, 9:18 PM
I know my alternative approach, htmx-enhanced hypermedia, isn't right for every application, but it can be a much simpler approach for many applications, and, since it is so simple, can be used to conserve complexity in applications that have parts that are not amenable to the hypermedia approach.
by vladstudio on 7/19/22, 1:19 PM
Make sure to check other essays at https://htmx.org/talk/ (scroll down for Essays)
by jasongi on 7/20/22, 12:11 AM
Occasionally you get a head nod in the direction that “sometimes, React is the best tool” but most of the time it’s Simpsons memes stoking a culture war.
If you’ve worked in an org where someone with decision making power has drunk the “progressive enhancement not SPA” koolaid, then it’s just as bad as someone who has drunken the SPA always koolaid - at least you’ll find it easy to hire and find support/libraries with the latter.
by rlawson on 7/19/22, 10:31 PM
The real sweet spot is it allows you to push server side frameworks like Django even further. You may find you can skip the SPA all together. And nothing beats the speed of development of a Django/Rails/Laravel.
Htmx is part of my go to stack for solo/side projects and my preferred stack on the job for crud heavy line of business applications.
by drchaim on 7/19/22, 6:46 PM
by quickthrower2 on 7/19/22, 11:32 PM
by kulor on 7/19/22, 9:22 PM
by daotoad on 7/19/22, 8:39 PM
http://youtube.github.io/spfjs/
SPF was a bit more focused on being easy to merge into an existing server side app.
I am glad to see this and hope it has some legs. It could help free us from the need to write every UI in JavaScript(ish).
by no_wizard on 7/19/22, 9:02 PM
React & Angular do scale this far, I have yet to encounter any who works with Vue that ships over a million lines of deployed code though I'd love to hear from you!
by MrWiffles on 7/19/22, 4:33 PM
(And don't start with "it's faster/more efficient", that comparison isn't terribly valid because the inefficiencies seen with React/Vue are largely an artifact of bad code/practices, not the libraries themselves.)
by tr1ll10nb1ll on 7/20/22, 12:58 PM
[Tetra](https://www.tetraframework.com/) might be an alternative if you’re hell-bent on not using React.
But, if you want to ship quick, have a maintainable codebase in a technology a lot of devs are familiar with and have the power to instantly ship for mobile (and buy yourself some time to build one in React Native; code is going to be similar to React.js), I’d recommend using React.
You can use Capacitor.js for instantly shipping a mobile app with your codebase that “just works”. Use Capgo for affordable codepush and you’re set!
HTMX all the way if you’re not building an app cause not everything is an “app”.
At the same time, if you’re building an app with a framework unlike Phoenix, I don’t see why one would not go ahead and use a decent JS framework. Using frontend framework seems to be facing a lot of aversion and I don’t understand if it’s because of the inability to learn these frameworks or what.
Point is, your users just need a snappy app that works. That’s it! And using a robust frontend framework makes it easier.
by jmull on 7/20/22, 1:30 AM
Why should only <a> and <form> be able to make HTTP requests?
Why should only click & submit events trigger them?
Why should only GET & POST methods be available?
Why should you only be able to replace the entire screen?
By removing these arbitrary constraints, htmx completes HTML as a hypertext
The fourth is a reasonable point -- it's quite common that you only want to update a portion of a page.
But it's very unclear that HTTP requests are the way to do it.
For one thing, using HTTP requests as the transport for app event handling adds nothing conceptually. It seems nice to use something that people are widely familiar with to build an event model on top of, but HTTP isn't a good fit for everything. So you either need something else (javascript or another language/api/framework) or you awkwardly fit everything into this model anyway.
But more importantly, it implies a strongly hierarchical structure to your app UI, which I think is overly rigid and unrealistic. Content tends to be largely hierarchical, but frequently important cross-cutting concerns pop up... maybe not on day one, but maybe on day 100 or 1000. Now you're swimming upstream.
Also, it's not like there aren't a very high number of HTML-centric options available. It has an interesting low-level approach, but in the end we're developing apps and UIs. It's very unclear to me whether htmx really offers advantages that other approaches don't meet or exceed.
by jdthedisciple on 7/19/22, 9:15 PM
by danbulant on 7/20/22, 8:54 AM
by soruly on 7/20/22, 5:13 AM
It provides a smooth UX by fetching next page's HTML in background, then replace the DOM by compareing the diff in HTML. So you won't see a blank page while navigating between pages.
by NorwegianDude on 7/20/22, 1:24 AM
Great TTFB as I don't need to send it to node to render js, faster navigation for many users with slow plugins and easy to implement.
This seems to do the same thing, and much more. I really need to try htmx, looks cool!
by calderwoodra on 7/20/22, 10:58 AM
by hencq on 7/20/22, 12:02 AM
by zagrebian on 7/20/22, 12:45 AM