Can someone genuinely explain to the the desire/interest to use HTMX/Hotwire/LiveView etc?<p>I was writing web apps when rendering templated HTML views on your server was standard, and you had controller endpoints that returned HTML content, or things like Rails "Unobtrusive Javascript" where you had code like:<p><pre><code> $(‘#user-list’).html(“<%= j render(‘index’, users: @users) %>”)
</code></pre>
As an automatic callback to some action.<p>Whether or not you love or hate this model of development is irrelevant, because if at some point you need to render on a client other than a browser -- you have to start from the beginning and write an API now.<p>IE, so that your Android/iOS app in Java/Swift or whatnot, can ask your backend for data and render it using the tools available on that platform.<p>When we turned apps into pure API's and just exchanged data with them, it opened up the ability to be platform-agnostic.<p>I guess I don't understand why someone would choose to build an app that sends HTML over the wire instead of JSON/XML/whatever, that any client can render. All it means is that you have to write this functionality later when you want it, in addition to now having this HTML stuff.
After reading some HTMX criticism, there's one point people seem to miss. Making HTML your application interface does *not* prevent you from having a JSON (or something else) API. If anything, it probably forces you to split your functions better. e.g:<p><pre><code> def get_user_data(user_id: int) -> Dict (JSON-looking data):
...
def render_user_view(user_id: int) -> HTML:
user_data = get_user_data(user_id)
render_template("user_detail_view.html", context=user_data)
</code></pre>
If you need the user data in a JSON API, nothing prevents you from exposing `get_user_data` as a JSON endpoint. You can also use WebViews in a mobile app.<p>People tend to overestimate the "interactivity" needs of their apps and underestimate what they can achieve by just swapping HTML. HTMX also lets you swap "Out of Band" [0]. This makes it easy to model more complex interactions (like "reactions"), for example, updating a counter somewhere else in the app when a form is submitted. Reactive frameworks can also become a Rube Goldberg machine if an app is not properly designed from the beginning. Then you start fighting rendering loops, build dependencies, components' side effects, etc.<p>Personally speaking, HTML-driven apps are not just about easy vs. hard development, it's also about your users [1]. Maybe a big React app runs fine on 8 CPU cores and 32 GB of RAM, but very often, your users just want to read some content, maybe submit a few forms, and leave. They may not want to download 2 MB of JS so that the page can render boxes with text, even more if your browser can already do that if you give it some HTML.<p>[0] <a href="https://htmx.org/attributes/hx-swap-oob/" rel="nofollow">https://htmx.org/attributes/hx-swap-oob/</a>
[1] <a href="https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/" rel="nofollow">https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...</a>
I've been moving from Django to Elixir/Phoenix/LiveView and loving it so far. I hated the Angular/React era of the web and mostly moved to doing backend development, but the Live App era has reinvigorated my interest in web development as a whole. I'll miss Python a lot and hope they can come up with something that solves the concurrency issues, but Elixir is really pretty good in its own right.
I agree that the way modern JS (need to?) download half the Internet for a semi-useful app is annoying, wasteful and dangerous.<p>However, I still remember the hell that was updating the state and keeping the rendering in sync with it when using jQuery. Native JS of course doesn't improve on that, and (judging by the description - no experience with it) Alpine.js doesn't either. For me, the paradigm of rendering from the internal state is what makes React (and Vue,...) useful. Too bad that npm ecosystem sucks and that everyone is inventing new shiny useless new things all the time... But React makes non-trivial single-page apps possible.<p>Of course, if you need server-side rendering (for example because of SEO) then the equation changes, and maybe using Alpine.js makes sense.
Another one to consider is <a href="https://www.django-unicorn.com" rel="nofollow">https://www.django-unicorn.com</a> if you want that LiveView feeling for Django.<p>For my latest project[1], I've opted for <a href="https://unpoly.com" rel="nofollow">https://unpoly.com</a> instead of Alipine+htmx as Unpoly allows me to write 100% server-side code and sprinkle some progressive enhancement where desirable. As a result, I can offer a no-JS experience (minus the Stripe Checkout) for those who may want/need it. Additionally, it forces me to focus solely on the server-side, and I write more idiomatic Django code as a result.<p>[1]: <a href="https://heraldsms.com" rel="nofollow">https://heraldsms.com</a>
Don't use a framework, use three!<p>This sounds like a lot of effort just to brag about how you avoided whatever piece of tech we're considering to be evil this month.
One major downside to HTMX is that as soon as there is any state you have to keep track of, you're teleported back to the late 90s or early 2000s where you have to keep track of all your state in hidden form fields, and you're extremely constrained in how you update pages.<p>IMO, it's annoying enough that it's probably not worth it unless you're doing something trivial. If you want to render html on the server you can still do that, but in many cases it is easier to just use custom javascript and maybe even receive the rendered html as json to simply updating pages rather than use htmx.
If I use alpine.js why do I need htmx still? I would use either of them but not both. Using both seems making a supposed-to-be-simple approach immediately back to complicated-again-now-you-need-two-components.<p>alpine increases client side interactivity, it can also do ajax to talk with server, why do I still need htmx then?<p>On the other hand if I use htmx I will probably use its hyperscript for interactivity on the client side, to be 'consistent'.<p>Note both projects are trying to make frontend simpler, mixing them seems not to help that goal to me.
'django saas startup kit' concept of the author is really smart<p>there's a hole in the market for people wanting to use frameworks to make saas sites -- frameworks provide great primitives that are subtly unusable for some modern web apps. Login but not saml, admin but not multitenant, forms but not multiple forms on a page<p>feels like this scratches an increasingly common itch of 'the web as a platform isn't shaped like what people use the web for'
An alternative that requires even less server-side work is to use PJAX <a href="https://www.npmjs.com/package/pjax" rel="nofollow">https://www.npmjs.com/package/pjax</a> which is the spiritual successor to Turbolinks from the early Rails days. It's really a two-step process:<p>- create a quick JS file that loads and configures PJAX to automatically intercept links and
- wherever you would have $(function() {}) ensure that it's also triggered on the PJAX load event, and is idempotent (e.g. check if you initialized a component before initializing it again)<p>Then you just render pages server-side like it's 2000, without any pjax-specific code needed in your templates themselves.<p>If you're building a data-focused product either solo or with a small team, it allows you to focus on your Python code, and anything frontend is as easy as accessing the variable in a Django template. Of course, it's a massive accumulation of technical debt - when you're successful you'll need to rewrite in a modern framework for maintainability and agility. But when you need to "punch above your weight class" and just get a product out into the world, it can be an amazing technique.
A suggestion for folks writing articles like this - sell me the advanced but typical example. I want to see an image input which is then previewed and then uploaded asynchronously with a loading bar and error states.
For people who want to see more advanced examples/tutorials built using Django and htmx- you can see a bunch here: <a href="https://htmx-django.com/" rel="nofollow">https://htmx-django.com/</a><p>Anything that can be done with React/Vue can be done with htmx in a more “Django-way”- it’s an amazing library that allows for complete web applications without the complexity of the JS ecosystem
Not sure about the snippet:<p><pre><code> // when the DOM is loaded
document.addEventListener('DOMContentLoaded', () => {
// find every element with the class "close"
(document.querySelectorAll('.close') || []).forEach((closeButton) => {
const parent = closeButton.parentNode;
// and add a "click" event listener
closeButton.addEventListener('click', () => {
// that removes the button's parent from the DOM
parent.parentNode.removeChild(parent);
});
});
});
</code></pre>
It'd be clearer without useless comments and useless extra code:<p><pre><code> document.addEventListener('DOMContentLoaded', () => {
document.querySelectorAll('.close').forEach((closeButton) => {
closeButton.addEventListener('click', (event) => {
event.target.parentNode.remove()
})
});
});</code></pre>
It's worth noting the security tradeoffs of these micro-frameworks.<p>HTMLX uses innerHTML/outerHTML extensively, meaning that XSS is a real concern. Any sanitation of user-generated content must happen server-side. This how traditional server-side frameworks generally work, but it's the opposite of how sanitation tends to be handled in large JS frameworks such as Angular.<p><a href="https://htmx.org/docs/#security" rel="nofollow">https://htmx.org/docs/#security</a><p>Alpine.js requires an alternative syntax to avoid running afoul of unsafe-eval Content-Security Policy. With this more verbose syntax, there no inline expressions in templates; everything is bound to attributes in Alpine.data instead.<p><a href="https://alpinejs.dev/advanced/csp" rel="nofollow">https://alpinejs.dev/advanced/csp</a>
Can anyone describe the use cases between HTMX/Alpine and Unpoly JS? I see the 3 routinely mentioned, but I am unsure what coverage Unpoly has vs HTMX/Alpine.<p><a href="https://unpoly.com/" rel="nofollow">https://unpoly.com/</a>
It reminds me a bit of [MooTools Behavior](<a href="https://mootools.net/blog/2011/12/20/mootools-behavior" rel="nofollow">https://mootools.net/blog/2011/12/20/mootools-behavior</a>) (from 2011!) where interactivity was created by adding tags to HTML, similar to the article!
I wrote about my experience evaluating the same stack here: <a href="https://www.joseferben.com/posts/hoarddit_a_website_to_discover_art/" rel="nofollow">https://www.joseferben.com/posts/hoarddit_a_website_to_disco...</a>
would it possible to have a browser <i>ship</i> with htmx so that it is possible to have truly "javascript optional"? (in principle this applies to any full js framework but I suppose it is natural in the htmx context)<p>are there any unsurmountable issues around security and the sandbox etc (not terribly familiar with browser internals)
I think it's great people who passionately dislike JavaScript have such powerful options.<p>Personally, I am not buying the whole "you can do anything this way" because it seems to me the main driver, implied or plainly stated, is always the "and no js!" part.<p>I get it, though. We are all capable of going to great lengths to prove a point. Having more viable options is great.
Sorry if this is off topic, I remember reading a proposal of including something similar to Alpine.js / HTMX within the HTML5 spec.<p>But I lost the page. And the proposal itself doesn't mention Alpine.js or HTMX so no keyword bring it up in Google. I am wondering if anyone have any idea.
Downside of most HTMX examples (such as the form in TFA) seems to be lack of graceful degradation with non-JS-enabled user agents.<p>But then, the rest of the page is server-generated (taking care of SEO), and handling interactivity without JS may not be a priority for most sites nowadays.
I always have the fear that something I write will be too complicated for someone else. This has become particularly irksome when integrating OIDC into a single page app. It’s gut wrenching to double check every random header for every domain it needs to serve, to set up SSL for localhost, to include the right headers on the fetch request, and maybe edit the /etc/hosts file to make it work. That process is a joy killer. The tools mentioned here can help stop that madness and bring joy back into development. So thank you! Please evangelize these ideas to browser standards committees and whoever will listen.
This is a pretty cool idea. The only catch is retaining consistent state across the page when there are multiple components that depend on same data. For instance, if there’s a form that submits to increment or decrement some dataset, but there is a stat based on that data in the sidebar, then it’s nearly impossible to keep the stat relevant. That said, its a planning problem than a stack problem.<p>I’ve been trying this in all my hobby projects and am absolutely hooked. It feels simpler than even django-sockpuppet, say.
I’m not sure I understand the motivation to avoid JavaScript. I completely understand not wanting 400mb of SPA/NPM nonsense, but otherwise what problem does avoiding JS solve in a webpage?<p>* Is it because JavaScript is too hard to learn or too unpleasant to write?<p>* Is it because training people to write JavaScript is too much effort?<p>* Is it due to a lack of trust in your fellow developers?<p>* Is it due to challenges in planning or forming architecture?<p>* Something else?
Smells like Turbo (and related frameworks) to me, which isn't a bad thing. From my brief use of CRA, I can see why many people are attracted to it, but the fact that a bunch of JS has to download before anything happens is never far from my mind.<p>In the meantime, I'll keep waiting until we get native HTML imports/includes - hopefully before the heat death of the Universe.
This is a very promising architecture! We are actually building a template for Kit55 (<a href="http://stack55.com" rel="nofollow">http://stack55.com</a>) that illustrates the use of Alpine,js. I think we should look into HTMX as well. Do you know if there is a comparison of Alpine.js vs HTMX somewhere?
There is a cycle that has existed for a while:<p>- Home computer.<p>- Mainframe. Much more powerful and reliable.<p>- More powerful PC. Mainframes have latency et all.<p>- More powerful Server, browser cannot handle that much computing.<p>- More powerful browser. A whole OS really. Servers have latency.<p>- More powerful server.. All that complexity is hard to rebuild on the client side, and besides phones are too slow...<p>Party on!<p>:D
I'm a big fan of these setups but has anybody ever successfully used a minimal-JS setup for anything useful?<p>I mean, there's apps like Pinboard but React & Redux do handle a lot of complexity and most modern apps demand that complexity.
Glad to see just a simple cdn script tag back in the play. Hopefully we can also pivot to smart documents rather than the web being an application platform.
Based on the content of the last DjangoCon, it seems HTMX is the way the Django community is going.<p>Anyone have thoughts on HTMX vs django-reactor (which is a LiveView port)?
I take so much issue with HTMX being branded as "JavaScript optional". It's a project built for people who hate JS by people who hate JS, and as the resulting developer workflows aren't JS-based have managed to convince themselves they're not using JS.<p>It's totally false. Your HTMX app does not work for JS-disabled people any more than someone's React/Angular/Vue first-render-on-server app.