22 ms·

Django, HTMX and Alpine.js: Modern websites, JavaScript optional

450 points by czue 5y ago

1270018080 5y ago
This honestly sounds like a miserable tech stack.
reidjs 5y ago
Can this stack easily handle 2-way data bindings on the frontend? For example, when you update a text input, the title of the text input changes?
- czue 5y ago
  Alpine should be able to do this by itself.
- mejutoco 5y ago
  Yes. You give ids to elements and the html indicates which id to replace with which content. You can even replace ids in other sections (might get complex quickly, but it works). https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/ Source: I used this to implement my https://fromzerotofullstack.com https://fromzerotofullstack.com website.
- recursivedoubts 5y ago
  purely front end use cases like this would be handled by alpine syncing state with the back end would be handled by htmx
miki_tyler 5y ago
This is a very promising architecture! We are actually building a template for Kit55 (http://stack55.com http://stack55.com) 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?
- czue 5y ago
  I'm not sure! As I say in the article, I kind of think of HTMX as "alpine for AJAX"
- recursivedoubts 5y ago
  From a sibling comment: htmx is for syncing client side actions with the server effectively within the hypermedia model AlpineJS (and hyperscript) are better for purely front end needs. htmx and Alpine pair well together, as does htmx/jQuery, htmx/VanillaJS or, if you are brave, htmx/hyperscript
gavinray 5y ago
Can someone genuinely explain to the the desire/interest to use HTMX/Hotwire/LiveView etc? 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: $(‘#user-list’).html(“<%= j render(‘index’, users: @users) %>”) As an automatic callback to some action. 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. 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. When we turned apps into pure API's and just exchanged data with them, it opened up the ability to be platform-agnostic. 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.
- interactivecode 5y ago
  because you still want server rendered html? because you focus on building websites? Being platform specific makes it easier to have a higher quality and integration on that specific platform.
  - gavinray 5y ago
    I build exclusively web apps and I still use the backend as an API. You fetch data from the API and render it with JavaScript. React, Vue, Svelte, Angular, Alpine, pick whatever. Not sending HTML over server endpoints, or using templated views like ERB/EJS/EEX/etc doesn't mean you inherently have a worse quality app. If you do this in something like Next.js with "getServerSideProps()", it's functionally equivalent. React even went so far as to make "Server Components": https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react...
    - roywiggins 5y ago
synergy20 5y ago
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. alpine increases client side interactivity, it can also do ajax to talk with server, why do I still need htmx then? On the other hand if I use htmx I will probably use its hyperscript for interactivity on the client side, to be 'consistent'. Note both projects are trying to make frontend simpler, mixing them seems not to help that goal to me.
- recursivedoubts 5y ago
  htmx is for syncing client side actions with the server effectively within the hypermedia model AlpineJS (and hyperscript) are better for purely front end needs. htmx and Alpine pair well together, as does htmx/jQuery, htmx/VanillaJS or, if you are brave, htmx/hyperscript
- nop_slide 5y ago
  I don't think Alpine has any similar AJAX directives as HTMX.
  - synergy20 5y ago
    that's the only piece messing indeed, alpine.js is following vue.js, both can use axios for ajax needs. I honestly still don't see the point of htmx, to me alpine.js + axios can cover all the front needs, assuming backend returns json instead of html. htmx is useful for django etc when it's returning html though, but new frameworks are more likely to return json instead.
- deniz-a 5y ago
  The pattern is that you use htmx for anything it can do, then use Alpine for things that shouldn't/can't require a server round-trip (toggling sidebar, animations etc). You can reimplement htmx functionality with Alpine, but htmx is a lot better than `@click="fetch('/partial').then(res => res.text()).then(frag => $el.innerHTML = frag)"` all over the place (with a slight variation in that one component that you miss because of the noise). Don't use _hyperscript just to be "'`consistent`'", use it because you want to. Being agnostic and playing well with other tools is a big thing for htmx. _hyperscript is lots of fun and lets you write very readable code, but you also need to stomach a 26mb bundle just to toggle some classes :/ (if anyone reading this can help us make it smaller, LMK)
ksec 5y ago
Sorry if this is off topic, I remember reading a proposal of including something similar to Alpine.js / HTMX within the HTML5 spec. 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.
- technobabbler 5y ago
  Web components? https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components
- deniz-a 5y ago
  This might be it https://discourse.wicg.io/t/extending-html-as-a-hypermedia/5294 https://discourse.wicg.io/t/extending-html-as-a-hypermedia/5...
btown 5y ago
An alternative that requires even less server-side work is to use PJAX https://www.npmjs.com/package/pjax https://www.npmjs.com/package/pjax which is the spiritual successor to Turbolinks from the early Rails days. It's really a two-step process: - 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) Then you just render pages server-side like it's 2000, without any pjax-specific code needed in your templates themselves. 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.
- hermes8329 5y ago
  Since when is Django not a modern framework?
  - acdha 5y ago
    I read that as a modern JavaScript framework. I think there's definitely a good debate about what “modern” means in that case because I think it's less about “modern” and more along the lines of “suitable for a large team working on complex client-side functionality”. Reaching for that prematurely can add a massive toolchain to your critical path, which adds a lot of frictional cost you might not see sufficient benefit from. One of the challenges we have is that people tend to hear about practices from very large tech companies because they have enough people to have things like developer evangelists and time to write lengthy blog series or produce videos. That often leaves people without the nuance that some of the tradeoffs make more sense when you have 50 developers including a dedicated support group but smaller teams might not make back the cost of entry. I like posts like this for reminding people that there are other options which might be appropriate for different projects, especially since even at large organizations it's usually easy to find small projects.
fareesh 5y ago
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.
- iudqnolq 5y ago
  Here you go. Disclaimer: I've only implemented part of this personally because my use case didn't need previews. https://hexdocs.pm/phoenix_live_view/uploads.html#upload-entries https://hexdocs.pm/phoenix_live_view/uploads.html#upload-ent...
  - fareesh 5y ago
    Ah Phoenix, how is the package ecosystem these days? I've always hesitated because the Rails ecosystem of gems saves a lot of time.
    - iudqnolq 5y ago
      I'm pretty inexperienced, my general feeling is that it's been good enough for me so far. For example, I found good Excel writing and job scheduling libraries. Definitely not as good as gems though
strogonoff 5y ago
Downside of most HTMX examples (such as the form in TFA) seems to be lack of graceful degradation with non-JS-enabled user agents. 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.
- recursivedoubts 5y ago
  progressive enhancement is possible with htmx (e.g. the hx-boost attribute is p/e friendly) but often requires thought by the programmer for example, the active search example can be made p/e'd by wrapping the input with a form that submits to the same page: https://htmx.org/examples/active-search/ https://htmx.org/examples/active-search/ but it requires work by the end developer the idea here is to be pragmatic: obviously some people care deeply about p/e and are unwilling to sacrifice it for more advanced U/X, but others are willing to do so, so let's make it possible for both camps to improve their sites with the tool
Wronnay 5y ago
https://archive.md/9YAJm https://archive.md/9YAJm
awinter-py 5y ago
'django saas startup kit' concept of the author is really smart 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 feels like this scratches an increasingly common itch of 'the web as a platform isn't shaped like what people use the web for'
- czue 5y ago
  100% agree. Frameworks are an incredible starting place and allow everyone to get a head start. But there's still a big gap between what a framework will cover versus what a SaaS app needs. Also boilerplates occupy a very important world between no-code and code-everything-yourself. In a no-code world you're fully at the mercy of whatever options someone has provided you with. But starting from a boilerplate allows you to dive in and completely customize things how you need to, without having to worry about the provided abstractions. As a developer the interface I want to use is code, but few products provide that.
  - awinter-py 5y ago
    'progressive enhancement of boilerplate'
Mizza 5y ago
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.
- koyote 5y ago
  Having recently looked into Blazor Server (similar to LiveView but in C#), one of the cons Microsoft listed was the scalability (compared to a typical SPA) as each client now needs an active websocket connection to the server, which will require more server resources. Do you have any experience in that? I'd love to know where server resource requirements sit between SPA, this and a typical SSR site like Django.
  - yurishimo 5y ago
    The thing that elevates Phoenix in this regard is since it’s built on Elixir (and consequently the BEAM), adding a new “process” to hold the web socket in memory is trivial and basically comes for free out of the box. The Phoenix core team has demonstrated over a million (maybe it was even 5?) simultaneous connections running on one server all being updated at once. Granted, it was a proof of concept, but in the real world, you would load balance well before that in all likelihood. The point is the same though. BEAM languages can easily manage a hundred thousand nodes of state simultaneously without breaking a sweat. For most apps, this is plenty as demonstrated by discord, WhatsApp, and other BEAM focused tech companies.
- SoylentOrange 5y ago
  Can you explain what you mean by “Live App” era vs React era? Can you point towards resources which might disambiguate the two?
  - Mizza 5y ago
    Sure! Basically, the idea is that rather than requests in JavaScript going through an API, each user connection is maintained by a lightweight process on the server (which Elixir can scale easily), and then interactions with the page are pushed as a diff via WebSockets and then magically merged into the DOM. Interactive pages, no JavaScript required. I'm still pretty new to it, but after learning the ropes it's seeming very productive, and most importantly, fun. https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
bingohbangoh 5y ago
I'm a big fan of these setups but has anybody ever successfully used a minimal-JS setup for anything useful? I mean, there's apps like Pinboard but React & Redux do handle a lot of complexity and most modern apps demand that complexity.
- nnoitra 5y ago
  Whatever you can do with React you can do with pure JS.
- deniz-a 5y ago
  People have done plenty of useful things with htmx, just like people did (and some continue to do) useful things with links & forms. Here's the example that's most convenient for me to pull up: https://www.youtube.com/watch?v=zHoAwVcSLdE https://www.youtube.com/watch?v=zHoAwVcSLdE (via https://www.commspace.co.za/ https://www.commspace.co.za/) > most modern apps demand that complexity. Citation needed.
- infamia 5y ago
  Basecamp and Hey.com for starters.
nawgz 5y ago
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. 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.
- VWWHFSfQ 5y ago
  I think you misunderstand what HTMX is
  - nawgz 5y ago
    Explain it closely to me then. What is HTMX doing that enables someone to write HTML attributes that make arbitrary actions that update the DOM possible?
    - VWWHFSfQ 5y ago
      when there's no javascript those attributes do nothing and your webpage acts like normal. ie, link clicks do a full page load. so your website works with or without javascript.
    - post-it 5y ago
      My understanding of HTMX is that the main draw is not having to write JS as a dev, not not having to run JS as a user.
      - hunterb123 5y ago
        Optional JS is a term already for web pages that degrade gracefully when JS is turned off. It's a shady marketing technique to hijack that term when it doesn't work that way.
        VWWHFSfQ 5y ago
nop_slide 5y ago
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. https://unpoly.com/ https://unpoly.com/
- midrus 5y ago
  From my point of view, Unpoly is just more "full stack" than the others. You have the functionality of several of the others in one single package, plus awesome things such as automatic loading indicator (turbolinks style), very good error handling, modals, layers, popups, sidebars, slow network detection, caching, eventbus, server provided instructions via custom http headers, polling, keeping elements across page transitions, compilers (kind of "stimulus" for creating custom behavior based on html attributes), etc. And all of it in an awesome and very clear API: It's all custom and data attributes on standard elements. HTMX, in my opinion, has a smaller scope. Of course you can do everything, but you'll have to do more yourself. Alpine seems to be even more low level, kind of a lightweight Vue. I don't like it, it really turns me off adding code in html attributes.
thih9 5y ago
Is anyone here using either HTMX or Alpine.js (or both) in production? What are your thoughts, are you happy with how these work in practice?
- jonathan-adly 5y ago
  I am using HTMX in production in two applications - it’s sped development considerably. I completely stopped using React
- werdnapk 5y ago
  I use Alpine.js in a handful of my production apps and have had no real issues when Vue, etc is overkill, except that when dealing with a lot of data, I found Alpine.js to be just way too slow with rendering. Swapping out Alpine.js for Vue fixed my problem. I likely was pushing Alpine.js beyond it's intent of "small" snippets to enhance a page.
- sgt 5y ago
  Am using AlpineJS on a new production Django app. Works fine.
jonathan-adly 5y ago
For people who want to see more advanced examples/tutorials built using Django and htmx- you can see a bunch here: https://htmx-django.com/ https://htmx-django.com/ 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
- robertoandred 5y ago
  All I see there is someone using <span>s as fake <a>s.
  - jonathan-adly 5y ago
    cool, right? You don't have to do this with htmx, but you can if you want too and I did because I wanted too :) Keep an open mind and continue reading on
    - gxnxcxcx 5y ago
      Requiring 28 kB of javascript in order to be able to click on navigation links might not be the alternative to the sins of the JS ecosystem I expected when following this thread. Of course, that fact alone doesn't undermine the merits of the subject matter. But I'd seriously consider it a presentation issue when doing evangelism.
    - robertoandred 5y ago
      Fake links break normal link behavior. Accessibility issues, opening links in new tabs, etc.
    - nauticacom 5y ago
      So cool! I love being able to break accessibility and the fundamental building block of the web :)
    - pwdisswordfish0 5y ago
      >because I wanted too Why though? I see this sometimes even on mainstream sites and I always wonder what the idea is.
cosmotic 5y ago
What makes it 'modern'?
- nprateem 5y ago
  It's required to call something 'modern' to get on HN.
resoluteteeth 5y ago
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. 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.
- jon1628492 5y ago
  I'm new to htmx and alpine, but isn't alpine's global store what you'd want in this case? https://alpinejs.dev/magics/store https://alpinejs.dev/magics/store
  - saimiam 5y ago
    (I'm not very familiar with Alpine and htmx but I'm comfortable with Vue and React.) Htmx pulls html content from the server and replaces inner|outerHTML with it. A JSON object (of the type React/Vue and presumably Alpine use) isn't a good fit to store html blobs and state.
- nlitened 5y ago
  Yeah, those damned early 2000s when back/forward buttons worked perfectly and we didn't lose the entire rich client state upon page refresh or wireless internet hiccup. Thank god we have a lot of JavaScript libraries and ambitious programmers to save us from those trivial things :)
  - kiawe_fire 5y ago
    But those were actual problems back then, and they were solved only through significant engineering work to hide them, each of which had their own problems. Frameworks like .Net WebForms were created to abstract and hide a lot of this from developers, with things like long encoded strings of "view state" that would be re-posted on each request, by serializing things to the URL, or by saving them to Cookie-backed sessions. But each of these has issues, from privacy concerns using the URL, to security concerns with the "view state", to concurrency and integrity concerns with sessions. IMO, the biggest reasons these didn't stand out as huge problems in the early 2000's was because: (a) we didn't use the web like we do today, and our expectations were very different in how things would work if we, for example, added an item to a shopping cart (b) most heavily interactive / app-like things that more closely work "the way we expect" today, were either still done as desktop apps (like business software) or were implemented as Java applets, Flash, or something else of the sort (c) in the rare cases that neither (a) nor (b) applied, it was because some very good engineers put in a lot of work to make it work that way.
robertoandred 5y ago
Don't use a framework, use three! 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.
- ozzythecat 5y ago
  I did web development work in the early 2000s (PHP, MySQL) and briefly in 2013-2014. In the past few years, I explored a recent version of Angular, React, and some other framework. The tooling seemed really nice at first, but I was actually shocked at the number of dependencies and just the overall complexity with all the layers of abstractions. Fundamentally, these are still websites. I honestly see this as people getting bored, inventing new things to deal with their boredom, and the rest of the industry follows. Meanwhile, the services I was writing in Java like 10 years ago haven’t really changed. We agreed Spring sucked and moved on. At a FANG where I work, we use Java and Kotlin. A lot of my data crunching jobs are in Scala. We did start using Rust for shared libraries deployed on mobile operating systems… because the entire team preferred it over C++. But I come back to web development and there’s always a new flavor of solving the same problem. /shrug
  - BoumTAC 5y ago
    I do not understand it too. The cost due to the complexity is at least 10 times more. It feels strange to me that nobody in the hierarchy consider it. I do understand that developer like to play with new technology and don't care about the cost as long as they can play with it and get paid but the hierarchy must have seen the millions dollars lost. Why did they do not say something about it ?
    - SavantIdiot 5y ago
      I met a guy at a bar in San Jose who worked at a web startup in the early 2010's. He said they easily spent over one million in UI/UX resources just to animate form validation because the default browser validation wasn't cool enough for their brand.
- 5y ago
streamofdigits 5y ago
would it possible to have a browser ship 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) are there any unsurmountable issues around security and the sandbox etc (not terribly familiar with browser internals)
- deniz-a 5y ago
  Most of what htmx does is a direct extension of the browser's capabilities. Some issues I can think of are - maintaining the "accessible by default" nature of HTML - swapping. htmx takes html from the server and uses one of innerHTML, outerHTML and insertAdjacentHTML to put it into the document, but it also does a whole lot more to avoid unexpected behavior. This would all need to be specified and implemented natively
- yawaramin 5y ago
  In general there are good reasons not to do that. It's much easier to ship a tiny dependency-free JS library than it is to ship a browser.
colbyhub 5y ago
Another one to consider is https://www.django-unicorn.com https://www.django-unicorn.com if you want that LiveView feeling for Django. For my latest project[1], I've opted for https://unpoly.com https://unpoly.com 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. [1]: https://heraldsms.com https://heraldsms.com
- benbristow 5y ago
  https://www.django-unicorn.com/examples/count-characters https://www.django-unicorn.com/examples/count-characters Sending an AJAX request every time you enter characters just to count them. Ewwww.
  - alpha_squared 5y ago
    I guess that's the extreme end of no-js. Wanting to use compute, but philosophically sticking-to-your-guns on where that compute happens.
    - benbristow 5y ago
      Well it's still using JS to send the AJAX request, so in-fact something along the lines of 'on text change, set some element text to text.length' is a lot less JavaScript code than 'on text change, format and POST an AJAX request and then set the element text to a value within the response'.
      - RussianCow 5y ago
        The difference being that the code to send an Ajax request an update the DOM based on the response is already coded and already used in other places, whereas updating the text length client-side would have to be custom code. Not that I'm arguing one way or another, but the reason it's done that way is to reuse the same set of primitives for everything.
jonatron 5y ago
Not sure about the snippet: // 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); }); }); }); It'd be clearer without useless comments and useless extra code: document.addEventListener('DOMContentLoaded', () => { document.querySelectorAll('.close').forEach((closeButton) => { closeButton.addEventListener('click', (event) => { event.target.parentNode.remove() }) }); });
polyrand 5y ago
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: 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) 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. 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. 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. [0] https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/ [1] https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/ https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...
- abstract_put 5y ago
  Big +1 on all of this. I have terrible rural internet, and just recently tried developing my first app with HTMX (wasn't aware of Alpine.js), and _man_ is it fast. For city slickers with their symmetrical gigabit connections it may be unnoticeable, unfortunately. Not saying SPAs have to be bloated, it just seems like most sites that turn into SPAs are bloated. All that said, trying to push everything server-side if you've been working in a heavy client takes some getting used to. In my real life job I've seen feature flags shipped as an API so the client queries whether a feature flag is enabled - this is something that always struck me as silly, the server serving the front end already knows if the feature flag is enabled. While that might be justifiable in some cases, it is definitely not so much in the on-prem-only product I worked on.
beebeepka 5y ago
I think it's great people who passionately dislike JavaScript have such powerful options. 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. I get it, though. We are all capable of going to great lengths to prove a point. Having more viable options is great.
- joelbluminator 5y ago
  It's not necessarily about disliking JavaScript. I can see Node people using this as well, why wouldn't they? Not everyone wants or needs to double their app code by building both a server app and a SPA. I might be exaggerating by "double" but it's for sure a major increase of code. Github is doing fine without a SPA last I heard.
joelbluminator 5y ago
I like how many frameworks end up cloning what Rails is doing (Stimulus / Turbolinks etc).
amenod 5y ago
I agree that the way modern JS (need to?) download half the Internet for a semi-useful app is annoying, wasteful and dangerous. 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. Of course, if you need server-side rendering (for example because of SEO) then the equation changes, and maybe using Alpine.js makes sense.
- stepbeek 5y ago
  That internal state is a burden on small teams though - you're efectively implementing the persistence layer twice. I'm totally onboard for SPAs as an option when breaking down an organization, or for solving a particular kind of problem. But they're just not worth the effort for a form-oriented website with a small-medium team behind it. Almost everything about a web-app is harder with an SPA.
- deergomoo 5y ago
  > Alpine.js doesn't either While it won’t fit the needs of a complex app with dozens of components, it does drive the UI from the state. In fact, it uses Vue’s reactivity engine.
- smolder 5y ago
  I was very good at making reliable apps and managing states manually in the jquery days. Having a scaffolding helps overall and in many ways, but now in the dense jungle that is the JS "ecosystem", there is sometimes a productivity loss searching for "the right way to do X in framework Y" or troubleshooting underlying tools instead of just writing the code to do the thing. Easier, maybe, but not at all satisfying.
  - scaryclam 5y ago
    I think the trick is, that state needs to be carefully considered at an overall systems level, not just client vs server. That's quite hard, so many (most?) devs don't do it. Certainly, I've seen state managed well using jquery, and even vanilla JS in the ES5 era, so frameworks don't make it possible, it's always been so. So the question is, do frameworks make it easier? I don't think they really do. I think they make it easier to manipulate state, but not designing your system will still mean state being mismanaged.
austincheney 5y ago
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? * Is it because JavaScript is too hard to learn or too unpleasant to write? * Is it because training people to write JavaScript is too much effort? * Is it due to a lack of trust in your fellow developers? * Is it due to challenges in planning or forming architecture? * Something else?
- sam_goody 5y ago
  I find that relying on JS in all browsers, on all platforms, over a long period of time is guaranteed to cause you pain. I have ~16 years of experience. My old PHP websites have advanced seriously, and are more reliable that my Node based ones. The tooling changes in node, the platform changes, the capabilities of the user agent (the iPhone's per tab memory !== that of a virtual browser on AWS), the restrictions of the system, the assumed tools and tool rot. Similarly, as Angular was replaced by React by Vue by Svelte in developer mindset, and the skill set of those coming in changed, as the versions of each of those platforms became less and less compatible; I have pages in Mootools that are just dead weight. But even if I had PHP3 pages, they would be humming along with minor changes.... Not to mention the security issues the JS community faces relative to eg. PHP, and you can bet that HTMX definitely appeals to me for anything that I don't need to do in the browser.
_9hey 5y ago
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.
jamesgeck0 5y ago
It's worth noting the security tradeoffs of these micro-frameworks. 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. https://htmx.org/docs/#security https://htmx.org/docs/#security 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. https://alpinejs.dev/advanced/csp https://alpinejs.dev/advanced/csp
- deniska 5y ago
  > HTMLX uses innerHTML/outerHTML extensively, meaning that XSS is a real concern. It's the same kind of a concern as having a user input inside HTML served from a server in the first place. And typical backend frameworks people would use with HTMX are already good at mitigating XSS inside served HTML.
- ketzu 5y ago
  > it's the opposite of how sanitation tends to be handled in large JS frameworks such as Angular. But they still do server side input validation, right? Otherwise, that would be a security concern.
  - jamesgeck0 5y ago
    The thing about server side input validation is that if you miss something, that exploit is stored in your database. Mitigating issues you missed thus requires a backfill, which may not be scalable. So instead you sanitize any user input just before every place it’s processed. Escaped in SQL, escaped on the frontend, escaped in email mailers, etc. This philosophy means that that you can’t use things like innerHTML on the frontend at all because the server output might contain XSS, and frontend frameworks don’t escape content added to the page via direct DOM manipulation.
    - 5y ago
jpe90 5y ago
Any opinions on how this (or a PETAL stack) compares to using Clojure & Clojurescript?
chrisfinazzo 5y ago
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. In the meantime, I'll keep waiting until we get native HTML imports/includes - hopefully before the heat death of the Universe.
joseferben 5y ago
I wrote about my experience evaluating the same stack here: https://www.joseferben.com/posts/hoarddit_a_website_to_discover_art/ https://www.joseferben.com/posts/hoarddit_a_website_to_disco...
pjs_ 5y ago
HTMX really kicks ass, I simply love it.
Savageman 5y ago
It reminds me a bit of [MooTools Behavior](https://mootools.net/blog/2011/12/20/mootools-behavior https://mootools.net/blog/2011/12/20/mootools-behavior) (from 2011!) where interactivity was created by adding tags to HTML, similar to the article!
- VWWHFSfQ 5y ago
  And dojo/dijit. I cut my web teeth on dojo back in the day and still feel like it was better than the things that ultimately supplanted it.
abishekg 5y ago
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. I’ve been trying this in all my hobby projects and am absolutely hooked. It feels simpler than even django-sockpuppet, say.
theptip 5y ago
Based on the content of the last DjangoCon, it seems HTMX is the way the Django community is going. Anyone have thoughts on HTMX vs django-reactor (which is a LiveView port)?
ilrwbwrkhv 5y ago
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.
sam_goody 5y ago
There is a cycle that has existed for a while: - Home computer. - Mainframe. Much more powerful and reliable. - More powerful PC. Mainframes have latency et all. - More powerful Server, browser cannot handle that much computing. - More powerful browser. A whole OS really. Servers have latency. - More powerful server.. All that complexity is hard to rebuild on the client side, and besides phones are too slow... Party on! :D

450 points by czue 5y ago

This honestly sounds like a miserable tech stack.

Can this stack easily handle 2-way data bindings on the frontend? For example, when you update a text input, the title of the text input changes?

czue 5y ago
Alpine should be able to do this by itself.
mejutoco 5y ago
Yes. You give ids to elements and the html indicates which id to replace with which content. You can even replace ids in other sections (might get complex quickly, but it works). https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/ Source: I used this to implement my https://fromzerotofullstack.com https://fromzerotofullstack.com website.
recursivedoubts 5y ago
purely front end use cases like this would be handled by alpine syncing state with the back end would be handled by htmx

miki_tyler 5y ago

This is a very promising architecture! We are actually building a template for Kit55 (http://stack55.com http://stack55.com) 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?

czue 5y ago
I'm not sure! As I say in the article, I kind of think of HTMX as "alpine for AJAX"
recursivedoubts 5y ago
From a sibling comment: htmx is for syncing client side actions with the server effectively within the hypermedia model AlpineJS (and hyperscript) are better for purely front end needs. htmx and Alpine pair well together, as does htmx/jQuery, htmx/VanillaJS or, if you are brave, htmx/hyperscript

gavinray 5y ago

Can someone genuinely explain to the the desire/interest to use HTMX/Hotwire/LiveView etc? 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: $(‘#user-list’).html(“<%= j render(‘index’, users: @users) %>”) As an automatic callback to some action. 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. 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. When we turned apps into pure API's and just exchanged data with them, it opened up the ability to be platform-agnostic. 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.

interactivecode 5y ago
because you still want server rendered html? because you focus on building websites? Being platform specific makes it easier to have a higher quality and integration on that specific platform.
- gavinray 5y ago
  I build exclusively web apps and I still use the backend as an API. You fetch data from the API and render it with JavaScript. React, Vue, Svelte, Angular, Alpine, pick whatever. Not sending HTML over server endpoints, or using templated views like ERB/EJS/EEX/etc doesn't mean you inherently have a worse quality app. If you do this in something like Next.js with "getServerSideProps()", it's functionally equivalent. React even went so far as to make "Server Components": https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react...
  - roywiggins 5y ago

synergy20 5y ago

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. alpine increases client side interactivity, it can also do ajax to talk with server, why do I still need htmx then? On the other hand if I use htmx I will probably use its hyperscript for interactivity on the client side, to be 'consistent'. Note both projects are trying to make frontend simpler, mixing them seems not to help that goal to me.

recursivedoubts 5y ago
htmx is for syncing client side actions with the server effectively within the hypermedia model AlpineJS (and hyperscript) are better for purely front end needs. htmx and Alpine pair well together, as does htmx/jQuery, htmx/VanillaJS or, if you are brave, htmx/hyperscript
nop_slide 5y ago
I don't think Alpine has any similar AJAX directives as HTMX.
- synergy20 5y ago
  that's the only piece messing indeed, alpine.js is following vue.js, both can use axios for ajax needs. I honestly still don't see the point of htmx, to me alpine.js + axios can cover all the front needs, assuming backend returns json instead of html. htmx is useful for django etc when it's returning html though, but new frameworks are more likely to return json instead.
deniz-a 5y ago
The pattern is that you use htmx for anything it can do, then use Alpine for things that shouldn't/can't require a server round-trip (toggling sidebar, animations etc). You can reimplement htmx functionality with Alpine, but htmx is a lot better than `@click="fetch('/partial').then(res => res.text()).then(frag => $el.innerHTML = frag)"` all over the place (with a slight variation in that one component that you miss because of the noise). Don't use _hyperscript just to be "'`consistent`'", use it because you want to. Being agnostic and playing well with other tools is a big thing for htmx. _hyperscript is lots of fun and lets you write very readable code, but you also need to stomach a 26mb bundle just to toggle some classes :/ (if anyone reading this can help us make it smaller, LMK)

ksec 5y ago

Sorry if this is off topic, I remember reading a proposal of including something similar to Alpine.js / HTMX within the HTML5 spec. 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.

technobabbler 5y ago
Web components? https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components
deniz-a 5y ago
This might be it https://discourse.wicg.io/t/extending-html-as-a-hypermedia/5294 https://discourse.wicg.io/t/extending-html-as-a-hypermedia/5...

btown 5y ago

An alternative that requires even less server-side work is to use PJAX https://www.npmjs.com/package/pjax https://www.npmjs.com/package/pjax which is the spiritual successor to Turbolinks from the early Rails days. It's really a two-step process: - 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) Then you just render pages server-side like it's 2000, without any pjax-specific code needed in your templates themselves. 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.

hermes8329 5y ago
Since when is Django not a modern framework?
- acdha 5y ago
  I read that as a modern JavaScript framework. I think there's definitely a good debate about what “modern” means in that case because I think it's less about “modern” and more along the lines of “suitable for a large team working on complex client-side functionality”. Reaching for that prematurely can add a massive toolchain to your critical path, which adds a lot of frictional cost you might not see sufficient benefit from. One of the challenges we have is that people tend to hear about practices from very large tech companies because they have enough people to have things like developer evangelists and time to write lengthy blog series or produce videos. That often leaves people without the nuance that some of the tradeoffs make more sense when you have 50 developers including a dedicated support group but smaller teams might not make back the cost of entry. I like posts like this for reminding people that there are other options which might be appropriate for different projects, especially since even at large organizations it's usually easy to find small projects.

fareesh 5y ago

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.

iudqnolq 5y ago
Here you go. Disclaimer: I've only implemented part of this personally because my use case didn't need previews. https://hexdocs.pm/phoenix_live_view/uploads.html#upload-entries https://hexdocs.pm/phoenix_live_view/uploads.html#upload-ent...
- fareesh 5y ago
  Ah Phoenix, how is the package ecosystem these days? I've always hesitated because the Rails ecosystem of gems saves a lot of time.
  - iudqnolq 5y ago
    I'm pretty inexperienced, my general feeling is that it's been good enough for me so far. For example, I found good Excel writing and job scheduling libraries. Definitely not as good as gems though

strogonoff 5y ago

Downside of most HTMX examples (such as the form in TFA) seems to be lack of graceful degradation with non-JS-enabled user agents. 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.

recursivedoubts 5y ago
progressive enhancement is possible with htmx (e.g. the hx-boost attribute is p/e friendly) but often requires thought by the programmer for example, the active search example can be made p/e'd by wrapping the input with a form that submits to the same page: https://htmx.org/examples/active-search/ https://htmx.org/examples/active-search/ but it requires work by the end developer the idea here is to be pragmatic: obviously some people care deeply about p/e and are unwilling to sacrifice it for more advanced U/X, but others are willing to do so, so let's make it possible for both camps to improve their sites with the tool

Wronnay 5y ago

https://archive.md/9YAJm https://archive.md/9YAJm

awinter-py 5y ago

'django saas startup kit' concept of the author is really smart 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 feels like this scratches an increasingly common itch of 'the web as a platform isn't shaped like what people use the web for'

czue 5y ago
100% agree. Frameworks are an incredible starting place and allow everyone to get a head start. But there's still a big gap between what a framework will cover versus what a SaaS app needs. Also boilerplates occupy a very important world between no-code and code-everything-yourself. In a no-code world you're fully at the mercy of whatever options someone has provided you with. But starting from a boilerplate allows you to dive in and completely customize things how you need to, without having to worry about the provided abstractions. As a developer the interface I want to use is code, but few products provide that.
- awinter-py 5y ago
  'progressive enhancement of boilerplate'

Mizza 5y ago

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.

koyote 5y ago
Having recently looked into Blazor Server (similar to LiveView but in C#), one of the cons Microsoft listed was the scalability (compared to a typical SPA) as each client now needs an active websocket connection to the server, which will require more server resources. Do you have any experience in that? I'd love to know where server resource requirements sit between SPA, this and a typical SSR site like Django.
- yurishimo 5y ago
  The thing that elevates Phoenix in this regard is since it’s built on Elixir (and consequently the BEAM), adding a new “process” to hold the web socket in memory is trivial and basically comes for free out of the box. The Phoenix core team has demonstrated over a million (maybe it was even 5?) simultaneous connections running on one server all being updated at once. Granted, it was a proof of concept, but in the real world, you would load balance well before that in all likelihood. The point is the same though. BEAM languages can easily manage a hundred thousand nodes of state simultaneously without breaking a sweat. For most apps, this is plenty as demonstrated by discord, WhatsApp, and other BEAM focused tech companies.
SoylentOrange 5y ago
Can you explain what you mean by “Live App” era vs React era? Can you point towards resources which might disambiguate the two?
- Mizza 5y ago
  Sure! Basically, the idea is that rather than requests in JavaScript going through an API, each user connection is maintained by a lightweight process on the server (which Elixir can scale easily), and then interactions with the page are pushed as a diff via WebSockets and then magically merged into the DOM. Interactive pages, no JavaScript required. I'm still pretty new to it, but after learning the ropes it's seeming very productive, and most importantly, fun. https://dockyard.com/blog/2018/12/12/phoenix-liveview-interactive-real-time-apps-no-need-to-write-javascript https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...

bingohbangoh 5y ago

I'm a big fan of these setups but has anybody ever successfully used a minimal-JS setup for anything useful? I mean, there's apps like Pinboard but React & Redux do handle a lot of complexity and most modern apps demand that complexity.

nnoitra 5y ago
Whatever you can do with React you can do with pure JS.
deniz-a 5y ago
People have done plenty of useful things with htmx, just like people did (and some continue to do) useful things with links & forms. Here's the example that's most convenient for me to pull up: https://www.youtube.com/watch?v=zHoAwVcSLdE https://www.youtube.com/watch?v=zHoAwVcSLdE (via https://www.commspace.co.za/ https://www.commspace.co.za/) > most modern apps demand that complexity. Citation needed.
infamia 5y ago
Basecamp and Hey.com for starters.

nawgz 5y ago

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. 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.

VWWHFSfQ 5y ago
I think you misunderstand what HTMX is
- nawgz 5y ago
  Explain it closely to me then. What is HTMX doing that enables someone to write HTML attributes that make arbitrary actions that update the DOM possible?
  - VWWHFSfQ 5y ago
    when there's no javascript those attributes do nothing and your webpage acts like normal. ie, link clicks do a full page load. so your website works with or without javascript.
  - post-it 5y ago
    My understanding of HTMX is that the main draw is not having to write JS as a dev, not not having to run JS as a user.
    - hunterb123 5y ago
      Optional JS is a term already for web pages that degrade gracefully when JS is turned off. It's a shady marketing technique to hijack that term when it doesn't work that way.
      - VWWHFSfQ 5y ago

nop_slide 5y ago

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. https://unpoly.com/ https://unpoly.com/

midrus 5y ago
From my point of view, Unpoly is just more "full stack" than the others. You have the functionality of several of the others in one single package, plus awesome things such as automatic loading indicator (turbolinks style), very good error handling, modals, layers, popups, sidebars, slow network detection, caching, eventbus, server provided instructions via custom http headers, polling, keeping elements across page transitions, compilers (kind of "stimulus" for creating custom behavior based on html attributes), etc. And all of it in an awesome and very clear API: It's all custom and data attributes on standard elements. HTMX, in my opinion, has a smaller scope. Of course you can do everything, but you'll have to do more yourself. Alpine seems to be even more low level, kind of a lightweight Vue. I don't like it, it really turns me off adding code in html attributes.

thih9 5y ago

Is anyone here using either HTMX or Alpine.js (or both) in production? What are your thoughts, are you happy with how these work in practice?

jonathan-adly 5y ago
I am using HTMX in production in two applications - it’s sped development considerably. I completely stopped using React
werdnapk 5y ago
I use Alpine.js in a handful of my production apps and have had no real issues when Vue, etc is overkill, except that when dealing with a lot of data, I found Alpine.js to be just way too slow with rendering. Swapping out Alpine.js for Vue fixed my problem. I likely was pushing Alpine.js beyond it's intent of "small" snippets to enhance a page.
sgt 5y ago
Am using AlpineJS on a new production Django app. Works fine.

jonathan-adly 5y ago

For people who want to see more advanced examples/tutorials built using Django and htmx- you can see a bunch here: https://htmx-django.com/ https://htmx-django.com/ 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

robertoandred 5y ago
All I see there is someone using <span>s as fake <a>s.
- jonathan-adly 5y ago
  cool, right? You don't have to do this with htmx, but you can if you want too and I did because I wanted too :) Keep an open mind and continue reading on
  - gxnxcxcx 5y ago
    Requiring 28 kB of javascript in order to be able to click on navigation links might not be the alternative to the sins of the JS ecosystem I expected when following this thread. Of course, that fact alone doesn't undermine the merits of the subject matter. But I'd seriously consider it a presentation issue when doing evangelism.
  - robertoandred 5y ago
    Fake links break normal link behavior. Accessibility issues, opening links in new tabs, etc.
  - nauticacom 5y ago
    So cool! I love being able to break accessibility and the fundamental building block of the web :)
  - pwdisswordfish0 5y ago
    >because I wanted too Why though? I see this sometimes even on mainstream sites and I always wonder what the idea is.

cosmotic 5y ago

What makes it 'modern'?

nprateem 5y ago
It's required to call something 'modern' to get on HN.

resoluteteeth 5y ago

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. 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.

jon1628492 5y ago
I'm new to htmx and alpine, but isn't alpine's global store what you'd want in this case? https://alpinejs.dev/magics/store https://alpinejs.dev/magics/store
- saimiam 5y ago
  (I'm not very familiar with Alpine and htmx but I'm comfortable with Vue and React.) Htmx pulls html content from the server and replaces inner|outerHTML with it. A JSON object (of the type React/Vue and presumably Alpine use) isn't a good fit to store html blobs and state.
nlitened 5y ago
Yeah, those damned early 2000s when back/forward buttons worked perfectly and we didn't lose the entire rich client state upon page refresh or wireless internet hiccup. Thank god we have a lot of JavaScript libraries and ambitious programmers to save us from those trivial things :)
- kiawe_fire 5y ago
  But those were actual problems back then, and they were solved only through significant engineering work to hide them, each of which had their own problems. Frameworks like .Net WebForms were created to abstract and hide a lot of this from developers, with things like long encoded strings of "view state" that would be re-posted on each request, by serializing things to the URL, or by saving them to Cookie-backed sessions. But each of these has issues, from privacy concerns using the URL, to security concerns with the "view state", to concurrency and integrity concerns with sessions. IMO, the biggest reasons these didn't stand out as huge problems in the early 2000's was because: (a) we didn't use the web like we do today, and our expectations were very different in how things would work if we, for example, added an item to a shopping cart (b) most heavily interactive / app-like things that more closely work "the way we expect" today, were either still done as desktop apps (like business software) or were implemented as Java applets, Flash, or something else of the sort (c) in the rare cases that neither (a) nor (b) applied, it was because some very good engineers put in a lot of work to make it work that way.

robertoandred 5y ago

Don't use a framework, use three! 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.

ozzythecat 5y ago
I did web development work in the early 2000s (PHP, MySQL) and briefly in 2013-2014. In the past few years, I explored a recent version of Angular, React, and some other framework. The tooling seemed really nice at first, but I was actually shocked at the number of dependencies and just the overall complexity with all the layers of abstractions. Fundamentally, these are still websites. I honestly see this as people getting bored, inventing new things to deal with their boredom, and the rest of the industry follows. Meanwhile, the services I was writing in Java like 10 years ago haven’t really changed. We agreed Spring sucked and moved on. At a FANG where I work, we use Java and Kotlin. A lot of my data crunching jobs are in Scala. We did start using Rust for shared libraries deployed on mobile operating systems… because the entire team preferred it over C++. But I come back to web development and there’s always a new flavor of solving the same problem. /shrug
- BoumTAC 5y ago
  I do not understand it too. The cost due to the complexity is at least 10 times more. It feels strange to me that nobody in the hierarchy consider it. I do understand that developer like to play with new technology and don't care about the cost as long as they can play with it and get paid but the hierarchy must have seen the millions dollars lost. Why did they do not say something about it ?
  - SavantIdiot 5y ago
    I met a guy at a bar in San Jose who worked at a web startup in the early 2010's. He said they easily spent over one million in UI/UX resources just to animate form validation because the default browser validation wasn't cool enough for their brand.
5y ago

streamofdigits 5y ago

would it possible to have a browser ship 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) are there any unsurmountable issues around security and the sandbox etc (not terribly familiar with browser internals)

deniz-a 5y ago
Most of what htmx does is a direct extension of the browser's capabilities. Some issues I can think of are - maintaining the "accessible by default" nature of HTML - swapping. htmx takes html from the server and uses one of innerHTML, outerHTML and insertAdjacentHTML to put it into the document, but it also does a whole lot more to avoid unexpected behavior. This would all need to be specified and implemented natively
yawaramin 5y ago
In general there are good reasons not to do that. It's much easier to ship a tiny dependency-free JS library than it is to ship a browser.

colbyhub 5y ago

Another one to consider is https://www.django-unicorn.com https://www.django-unicorn.com if you want that LiveView feeling for Django. For my latest project[1], I've opted for https://unpoly.com https://unpoly.com 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. [1]: https://heraldsms.com https://heraldsms.com

benbristow 5y ago
https://www.django-unicorn.com/examples/count-characters https://www.django-unicorn.com/examples/count-characters Sending an AJAX request every time you enter characters just to count them. Ewwww.
- alpha_squared 5y ago
  I guess that's the extreme end of no-js. Wanting to use compute, but philosophically sticking-to-your-guns on where that compute happens.
  - benbristow 5y ago
    Well it's still using JS to send the AJAX request, so in-fact something along the lines of 'on text change, set some element text to text.length' is a lot less JavaScript code than 'on text change, format and POST an AJAX request and then set the element text to a value within the response'.
    - RussianCow 5y ago
      The difference being that the code to send an Ajax request an update the DOM based on the response is already coded and already used in other places, whereas updating the text length client-side would have to be custom code. Not that I'm arguing one way or another, but the reason it's done that way is to reuse the same set of primitives for everything.

jonatron 5y ago

Not sure about the snippet: // 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); }); }); }); It'd be clearer without useless comments and useless extra code: document.addEventListener('DOMContentLoaded', () => { document.querySelectorAll('.close').forEach((closeButton) => { closeButton.addEventListener('click', (event) => { event.target.parentNode.remove() }) }); });

polyrand 5y ago

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: 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) 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. 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. 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. [0] https://htmx.org/attributes/hx-swap-oob/ https://htmx.org/attributes/hx-swap-oob/ [1] https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/ https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...

abstract_put 5y ago
Big +1 on all of this. I have terrible rural internet, and just recently tried developing my first app with HTMX (wasn't aware of Alpine.js), and _man_ is it fast. For city slickers with their symmetrical gigabit connections it may be unnoticeable, unfortunately. Not saying SPAs have to be bloated, it just seems like most sites that turn into SPAs are bloated. All that said, trying to push everything server-side if you've been working in a heavy client takes some getting used to. In my real life job I've seen feature flags shipped as an API so the client queries whether a feature flag is enabled - this is something that always struck me as silly, the server serving the front end already knows if the feature flag is enabled. While that might be justifiable in some cases, it is definitely not so much in the on-prem-only product I worked on.

beebeepka 5y ago

I think it's great people who passionately dislike JavaScript have such powerful options. 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. I get it, though. We are all capable of going to great lengths to prove a point. Having more viable options is great.

joelbluminator 5y ago
It's not necessarily about disliking JavaScript. I can see Node people using this as well, why wouldn't they? Not everyone wants or needs to double their app code by building both a server app and a SPA. I might be exaggerating by "double" but it's for sure a major increase of code. Github is doing fine without a SPA last I heard.

joelbluminator 5y ago

I like how many frameworks end up cloning what Rails is doing (Stimulus / Turbolinks etc).

amenod 5y ago

I agree that the way modern JS (need to?) download half the Internet for a semi-useful app is annoying, wasteful and dangerous. 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. Of course, if you need server-side rendering (for example because of SEO) then the equation changes, and maybe using Alpine.js makes sense.

stepbeek 5y ago
That internal state is a burden on small teams though - you're efectively implementing the persistence layer twice. I'm totally onboard for SPAs as an option when breaking down an organization, or for solving a particular kind of problem. But they're just not worth the effort for a form-oriented website with a small-medium team behind it. Almost everything about a web-app is harder with an SPA.
deergomoo 5y ago
> Alpine.js doesn't either While it won’t fit the needs of a complex app with dozens of components, it does drive the UI from the state. In fact, it uses Vue’s reactivity engine.
smolder 5y ago
I was very good at making reliable apps and managing states manually in the jquery days. Having a scaffolding helps overall and in many ways, but now in the dense jungle that is the JS "ecosystem", there is sometimes a productivity loss searching for "the right way to do X in framework Y" or troubleshooting underlying tools instead of just writing the code to do the thing. Easier, maybe, but not at all satisfying.
- scaryclam 5y ago
  I think the trick is, that state needs to be carefully considered at an overall systems level, not just client vs server. That's quite hard, so many (most?) devs don't do it. Certainly, I've seen state managed well using jquery, and even vanilla JS in the ES5 era, so frameworks don't make it possible, it's always been so. So the question is, do frameworks make it easier? I don't think they really do. I think they make it easier to manipulate state, but not designing your system will still mean state being mismanaged.

austincheney 5y ago

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? * Is it because JavaScript is too hard to learn or too unpleasant to write? * Is it because training people to write JavaScript is too much effort? * Is it due to a lack of trust in your fellow developers? * Is it due to challenges in planning or forming architecture? * Something else?

sam_goody 5y ago
I find that relying on JS in all browsers, on all platforms, over a long period of time is guaranteed to cause you pain. I have ~16 years of experience. My old PHP websites have advanced seriously, and are more reliable that my Node based ones. The tooling changes in node, the platform changes, the capabilities of the user agent (the iPhone's per tab memory !== that of a virtual browser on AWS), the restrictions of the system, the assumed tools and tool rot. Similarly, as Angular was replaced by React by Vue by Svelte in developer mindset, and the skill set of those coming in changed, as the versions of each of those platforms became less and less compatible; I have pages in Mootools that are just dead weight. But even if I had PHP3 pages, they would be humming along with minor changes.... Not to mention the security issues the JS community faces relative to eg. PHP, and you can bet that HTMX definitely appeals to me for anything that I don't need to do in the browser.

_9hey 5y ago

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.

jamesgeck0 5y ago

It's worth noting the security tradeoffs of these micro-frameworks. 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. https://htmx.org/docs/#security https://htmx.org/docs/#security 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. https://alpinejs.dev/advanced/csp https://alpinejs.dev/advanced/csp

deniska 5y ago
> HTMLX uses innerHTML/outerHTML extensively, meaning that XSS is a real concern. It's the same kind of a concern as having a user input inside HTML served from a server in the first place. And typical backend frameworks people would use with HTMX are already good at mitigating XSS inside served HTML.
ketzu 5y ago
> it's the opposite of how sanitation tends to be handled in large JS frameworks such as Angular. But they still do server side input validation, right? Otherwise, that would be a security concern.
- jamesgeck0 5y ago
  The thing about server side input validation is that if you miss something, that exploit is stored in your database. Mitigating issues you missed thus requires a backfill, which may not be scalable. So instead you sanitize any user input just before every place it’s processed. Escaped in SQL, escaped on the frontend, escaped in email mailers, etc. This philosophy means that that you can’t use things like innerHTML on the frontend at all because the server output might contain XSS, and frontend frameworks don’t escape content added to the page via direct DOM manipulation.
  - 5y ago

jpe90 5y ago

Any opinions on how this (or a PETAL stack) compares to using Clojure & Clojurescript?

chrisfinazzo 5y ago

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. In the meantime, I'll keep waiting until we get native HTML imports/includes - hopefully before the heat death of the Universe.

joseferben 5y ago

I wrote about my experience evaluating the same stack here: https://www.joseferben.com/posts/hoarddit_a_website_to_discover_art/ https://www.joseferben.com/posts/hoarddit_a_website_to_disco...

pjs_ 5y ago

HTMX really kicks ass, I simply love it.

Savageman 5y ago

It reminds me a bit of [MooTools Behavior](https://mootools.net/blog/2011/12/20/mootools-behavior https://mootools.net/blog/2011/12/20/mootools-behavior) (from 2011!) where interactivity was created by adding tags to HTML, similar to the article!

VWWHFSfQ 5y ago
And dojo/dijit. I cut my web teeth on dojo back in the day and still feel like it was better than the things that ultimately supplanted it.

abishekg 5y ago

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. I’ve been trying this in all my hobby projects and am absolutely hooked. It feels simpler than even django-sockpuppet, say.

theptip 5y ago

Based on the content of the last DjangoCon, it seems HTMX is the way the Django community is going. Anyone have thoughts on HTMX vs django-reactor (which is a LiveView port)?

ilrwbwrkhv 5y ago

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.

sam_goody 5y ago

There is a cycle that has existed for a while: - Home computer. - Mainframe. Much more powerful and reliable. - More powerful PC. Mainframes have latency et all. - More powerful Server, browser cannot handle that much computing. - More powerful browser. A whole OS really. Servers have latency. - More powerful server.. All that complexity is hard to rebuild on the client side, and besides phones are too slow... Party on! :D