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:
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.
First, many sites do not need a mobile app — people who sell apps like to present that as a requirement but there large categories where it doesn't make sense and most users won't install it because it takes space on their device and they [correctly] fear ads, notification spam, and possible invasions of their privacy. I've seen figures for this where pretty well-known organizations spent millions on the app and then saw install rates under 10% with most users opening it only once or twice.
Second, this is something of a false dichotomy: if you have a website, you need to have HTML somewhere. One approach is to use an SPA but that increases the cost somewhat significantly and absent a significant engineering effort will reduce performance and reliability because you are moving functionality out of a high-performance data center where you control everything onto the users' devices where you have to work with whatever browser and extensions/ad blockers they have installed.
An alternative approach is to render HTML on your servers — quite possibly using the same JSON API as the source — and then progressively enhance it with the functionality which makes sense to do on the edge. This gives you a hefty performance win for the initial page-load times, helps with things like search engines, and ensures that your users get at least the basic experience when something goes wrong with client side JavaScript (network errors, browser compatibility issues, ad blockers, etc.) rather than nothing working at all.
1) No need for 3.7GB of node_modules to crank out a simple site
2) Single solution, easier to bring on junior developers and reason about application logic
3) Caching much easier, too many people think they need real-time push when NRT-polling + caching is far easier and more performant
Broadly speaking it's often a case of YAGNI. The JS ecosystem really does still suck for its complexity, I remember that every time I ramp up a new developer onto a React project. It's smoothed out with tooling but the litany of JSON configuration files and the mess created by hot-reload + proxying + microservices etc etc. Often just YAGNI.
People today don't remember the VB6 IDE days where you could slap a button on a Form, write a line of code for a MessageBox, and smash that play button with zero effort. JS development is often about working your way through a tangled spider-web of helper utilities and config files and JS modules at which point when it finally works you're afraid to rev anything.
Worth pointing out that HTML is more ubiquitous than you're making it out to be: just plop a WebView in your native app, and you're done. I know, for example, that the Uber app does webviews in some places; you probably wouldn't even be able to figure out where just from looking at it as a user.
Another case in point: is your dev team going to support PSP devices[0]?
> 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.
The answer lies in the "if" there. The speed and lack of complexity developing server-side with no API is unparalleled to doing client -> api -> backend. Not to mention, you aren't tying yourself into several different JS technologies (Which GraphQL or REST lib? Which view framework? What testing frameworks? And what's the whole backend stack? etc. etc.) I can only speak for LiveView but the whole top-down experience is in Elixir with sprinkles of vanilla JS (the community is big into Tailwind and AlpineJS as well, but not exclusively).
I have real world experience of dev'ing API-first only to have the company nix any plans to open up the API. Adding new features is always a slog as we have to think about if the business logic needs to be on the client, the server, or both... not to mentioning have to update about 18 different places the name of a new field you're adding.
The company I work for actual has a LiveView widget that is embedded on their client's apps. I can't speak very well to it since I only just started working there and don't actually start until next week, haha.
But ya, I'll also echo the whole idea that a lot of companies don't need mobile apps. I'm certainly one of those people who uses the browser on my phone whenever I can.
- flexibility: e.g. because of the uniform interface, versioning is much less of an issue
- power: e.g. deep linking is trivial
Additionally, there is increasing awareness[1] that Application APIs and Data APIs have different needs and "shapes", and, once you have split them up, reconsidering using hypermedia for your application API[2] is a reasonable thing to do
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:
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.
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.
Haven't used django for a year or 2 but used to use django-rest-framework's negotiation to get both json and html responses (was using inertiajs not htmx) and it worked pretty well. You can use decorators on the api methods to set things like templates. Here's an example:
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.
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.
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.
> 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
I think this varied a lot depending on how teams approached it and that a lot of the appeal to something like React, Vue, etc. was simply that there was one way to do it.
The approach I've been quite happy with is to use JavaScript classes (IE11 is less than 1% of global web usage) for internal state, where you follow standard practice for having ownership and updates between different parts of your app, and the HTML5 data APIs for the public elements which are managed by different codebases. Web Components has something like 95-97% availability these days but this can be as simple as using element.dataset.whatever as needed. React is definitely good for huge apps but a significant fraction of the web sites I use are solidly in the level of functionality which in 2021 doesn't need functionality outside of what a modern browser provides.
Keeping all state server side is a completely reasonable approach. The 37Signals guys have been advocating for it since 2006 or so and as long as you have a low latency connection to the server then it usually works great.
What doesn't work well (and what tended to happen with jQuery apps) is having state both on the client and on the server and having to coordinate between the two. My personal preference is for client side state with a lighter setup than React (i.e. Svelte). I like the predictable latency and I feel you don't run into a complexity barrier (e.g. multi-step forms) as the app grows.
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.
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.
For my latest project[1], I've opted for 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.
I've been looking at these libraries and Unpoly looks the most promising for my needs. HTMX looks good as well but Unpoly's infinite layers feature [1] rather grabbed my attention :)
Stimulus is the one I can't get myself to like. Separate JS controllers is clever but the DSL and general nature - it just doesn't click with me.
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
This is unfair. HTMX and Alpine could hardly be considered frameworks.
React, by comparison, is absolutely massive. It's complicated. It requires compilation, and often a complex build configuration. You still need a backend server, so it won't obviate Django.
Your comment speaks to a larger debate, but it's a rather disappointing contribution.
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.
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 :)
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.
'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'
An alternative that requires even less server-side work is to use 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.
pjax (first released 8 years ago) preceeded turbolinks (6 years old), and was the inspiration for it
htmx is an attempt to drive HTML forward as a hypermedia, so it exposes explicit, client-side attributes, rather than hiding them as with pjax/turbolinks, although there is an attribute, hx-boost, that acts similar to them both
worth noting that intercooler.js, which was the predecessor for htmx, is 8 years old as well
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: 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
// 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:
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.
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.
> 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.
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.
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)
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.
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.
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.
[+] [-] gavinray|4 years ago|reply
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:
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.
[+] [-] acdha|4 years ago|reply
Second, this is something of a false dichotomy: if you have a website, you need to have HTML somewhere. One approach is to use an SPA but that increases the cost somewhat significantly and absent a significant engineering effort will reduce performance and reliability because you are moving functionality out of a high-performance data center where you control everything onto the users' devices where you have to work with whatever browser and extensions/ad blockers they have installed.
An alternative approach is to render HTML on your servers — quite possibly using the same JSON API as the source — and then progressively enhance it with the functionality which makes sense to do on the edge. This gives you a hefty performance win for the initial page-load times, helps with things like search engines, and ensures that your users get at least the basic experience when something goes wrong with client side JavaScript (network errors, browser compatibility issues, ad blockers, etc.) rather than nothing working at all.
[+] [-] kirse|4 years ago|reply
1) No need for 3.7GB of node_modules to crank out a simple site
2) Single solution, easier to bring on junior developers and reason about application logic
3) Caching much easier, too many people think they need real-time push when NRT-polling + caching is far easier and more performant
Broadly speaking it's often a case of YAGNI. The JS ecosystem really does still suck for its complexity, I remember that every time I ramp up a new developer onto a React project. It's smoothed out with tooling but the litany of JSON configuration files and the mess created by hot-reload + proxying + microservices etc etc. Often just YAGNI.
People today don't remember the VB6 IDE days where you could slap a button on a Form, write a line of code for a MessageBox, and smash that play button with zero effort. JS development is often about working your way through a tangled spider-web of helper utilities and config files and JS modules at which point when it finally works you're afraid to rev anything.
[+] [-] lhorie|4 years ago|reply
Another case in point: is your dev team going to support PSP devices[0]?
[0] https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...
[+] [-] sodapopcan|4 years ago|reply
The answer lies in the "if" there. The speed and lack of complexity developing server-side with no API is unparalleled to doing client -> api -> backend. Not to mention, you aren't tying yourself into several different JS technologies (Which GraphQL or REST lib? Which view framework? What testing frameworks? And what's the whole backend stack? etc. etc.) I can only speak for LiveView but the whole top-down experience is in Elixir with sprinkles of vanilla JS (the community is big into Tailwind and AlpineJS as well, but not exclusively).
I have real world experience of dev'ing API-first only to have the company nix any plans to open up the API. Adding new features is always a slog as we have to think about if the business logic needs to be on the client, the server, or both... not to mentioning have to update about 18 different places the name of a new field you're adding.
The company I work for actual has a LiveView widget that is embedded on their client's apps. I can't speak very well to it since I only just started working there and don't actually start until next week, haha.
But ya, I'll also echo the whole idea that a lot of companies don't need mobile apps. I'm certainly one of those people who uses the browser on my phone whenever I can.
[+] [-] recursivedoubts|4 years ago|reply
- simplicity: e.g. something like active search can be implemented with a few attributes: https://htmx.org/examples/active-search/
- flexibility: e.g. because of the uniform interface, versioning is much less of an issue
- power: e.g. deep linking is trivial
Additionally, there is increasing awareness[1] that Application APIs and Data APIs have different needs and "shapes", and, once you have split them up, reconsidering using hypermedia for your application API[2] is a reasonable thing to do
[1] - https://max.engineer/server-informed-ui
[2] -https://htmx.org/essays/splitting-your-apis/
[+] [-] polyrand|4 years ago|reply
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/ [1] https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...
[+] [-] abstract_put|4 years ago|reply
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.
[+] [-] rojoca|4 years ago|reply
[+] [-] arvindamirtaa|4 years ago|reply
[+] [-] Mizza|4 years ago|reply
[+] [-] amenod|4 years ago|reply
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|4 years ago|reply
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.
[+] [-] acdha|4 years ago|reply
I think this varied a lot depending on how teams approached it and that a lot of the appeal to something like React, Vue, etc. was simply that there was one way to do it.
The approach I've been quite happy with is to use JavaScript classes (IE11 is less than 1% of global web usage) for internal state, where you follow standard practice for having ownership and updates between different parts of your app, and the HTML5 data APIs for the public elements which are managed by different codebases. Web Components has something like 95-97% availability these days but this can be as simple as using element.dataset.whatever as needed. React is definitely good for huge apps but a significant fraction of the web sites I use are solidly in the level of functionality which in 2021 doesn't need functionality outside of what a modern browser provides.
[+] [-] grayrest|4 years ago|reply
What doesn't work well (and what tended to happen with jQuery apps) is having state both on the client and on the server and having to coordinate between the two. My personal preference is for client side state with a lighter setup than React (i.e. Svelte). I like the predictable latency and I feel you don't run into a complexity barrier (e.g. multi-step forms) as the app grows.
[+] [-] deergomoo|4 years ago|reply
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|4 years ago|reply
[+] [-] colbyhub|4 years ago|reply
For my latest project[1], I've opted for 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
[+] [-] benbristow|4 years ago|reply
Sending an AJAX request every time you enter characters just to count them. Ewwww.
[+] [-] porker|4 years ago|reply
Stimulus is the one I can't get myself to like. Separate JS controllers is clever but the DSL and general nature - it just doesn't click with me.
[1] https://unpoly.com/up.layer
[+] [-] robertoandred|4 years ago|reply
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|4 years ago|reply
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
[+] [-] ttymck|4 years ago|reply
React, by comparison, is absolutely massive. It's complicated. It requires compilation, and often a complex build configuration. You still need a backend server, so it won't obviate Django.
Your comment speaks to a larger debate, but it's a rather disappointing contribution.
[+] [-] recursivedoubts|4 years ago|reply
so it is a very lightweight combination on top of plain-ol' HTML
[1] - https://bundlephobia.com/package/[email protected] [2] - https://bundlephobia.com/package/[email protected]
[+] [-] resoluteteeth|4 years ago|reply
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.
[+] [-] nlitened|4 years ago|reply
[+] [-] jon1628492|4 years ago|reply
[+] [-] synergy20|4 years ago|reply
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.
[+] [-] awinter-py|4 years ago|reply
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'
[+] [-] btown|4 years ago|reply
- 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.
[+] [-] recursivedoubts|4 years ago|reply
htmx is an attempt to drive HTML forward as a hypermedia, so it exposes explicit, client-side attributes, rather than hiding them as with pjax/turbolinks, although there is an attribute, hx-boost, that acts similar to them both
worth noting that intercooler.js, which was the predecessor for htmx, is 8 years old as well
[+] [-] hermes8329|4 years ago|reply
[+] [-] fareesh|4 years ago|reply
[+] [-] iudqnolq|4 years ago|reply
https://hexdocs.pm/phoenix_live_view/uploads.html#upload-ent...
[+] [-] jonathan-adly|4 years ago|reply
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
[+] [-] jonatron|4 years ago|reply
[+] [-] jamesgeck0|4 years ago|reply
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
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
[+] [-] deniska|4 years ago|reply
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.
[+] [-] brtkdotse|4 years ago|reply
Um, yes? You should treat every request to hit the backend as a potential attack, otherwise you're going to have a _really_ bad time at some point.
[+] [-] ketzu|4 years ago|reply
But they still do server side input validation, right? Otherwise, that would be a security concern.
[+] [-] nop_slide|4 years ago|reply
https://unpoly.com/
[+] [-] Savageman|4 years ago|reply
[+] [-] joseferben|4 years ago|reply
[+] [-] streamofdigits|4 years ago|reply
are there any unsurmountable issues around security and the sandbox etc (not terribly familiar with browser internals)
[+] [-] beebeepka|4 years ago|reply
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|4 years ago|reply
[+] [-] ksec|4 years ago|reply
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|4 years ago|reply
[+] [-] deniz-a|4 years ago|reply