I’ve been using htmx for over a year now for our internal management application (order monitoring, partner management, CAD model uploading and management type stuff) and I continue to be delighted at how quickly I can add features and iterate existing ones. I write way less client side JS, the app is very fast and responsive and I don’t have to write the app twice like with a SPA + API.
One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down whatever resources I need (though it's honestly pretty wasteful at times).
With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?
This is the thing that makes me lose interest in HTMX. People talk about it like it eliminates the need for JS/React/etc, but as far as I can tell, you're still writing those same templates, just using your backend language instead of JS. Which is convenient, but hardly "less code", just a different language, and that backend language probably lacks a lot of functionality you'd want for UI convenience. That's all fine if you'll never want those UI conveniences, by my experience has been that the want of those UI conveniences creep in over time, and eventually you regret not using something that makes them native and easy.
I haven't actually played around with HTMX, so I might be sizing it up wrong, but it's mission statement just never resonated with me enough to want to try it out.
The value of HTMX is that state now resides solely on the server, and the browser becomes only a representation of that state. This simplifies applications considerably because maintaining two copies of the state between client and server is the source of a lot of complexity in modern applications.
It wasn't about writing less code (although it is about writing less javascript) but about working with the concept of hypermedia instead of against or around it.
Something I dislike about this argument is that there are a lot of UX flows where "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state. And popular backend frameworks are not super up to the task!
I have the impression that older web frameworks did in fact have a good amount of statefulness built in, and that causes a whole host of issues, so I believe to understand _why_ modern backend frameworks really don't lean into that.
You're absolutely right, htmx is not built for every UX flow.
But neither is React. And we've been reaching for it by default for everything and that's been a mistake.
So much of what's built these days could be stateless MPAs. Servers have gotten crazy fast, and I'd certainly rather optimize for page size and server latency than build a React app.
With the upcoming views transitions api, a bit of htmx, and custom web components and you get 95% of what React offers without anywhere near the package size or complexity. You don't even need a compile step.
I'd never argue htmx is best for all use cases, I would hate for it to mutate the way React has, trying to be everything to everyone. But I hope htmx is the start of re-thinking how they approach the web and realizing that there are significantly simpler ways to build a frontend.
I definitely think it’s important to note it’s not really React that’s mutated it’s damn Vercel with its extreme vendor lock in plan with Next that’s trying to force React to be server side as much as client side, especially now that Vercel employs some React core team members.
Unfortunately worked with someone I was reasonably sure was a ~~paid shill~~ part of some Vercel partner/influencer programme as they were adamant we must use Next (and Vercel but they lost that argument) for a project the team absolutely didn’t need to use it for.
In fact the rewrite of a project was worse than the original application. The original was snappy and instant and just worked meanwhile the Next version was slow, full page refreshes for every action, and just totally awful.
Next is odd because it gives lots of "high preformance" vibes with static rendering and image optimization. It is fast enough but not as fast as tuning up a classic MVC app which caching, avoiding JS bundles and React or deferring scripts etc. Send out the right cache headers and chuck a CDN in front.
Next is ironically fast if you prerender/static generate AND the client disables JS!
> "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state.
The issue with many SPAs I saw was that state had to be managed BOTH in the browser AND on the server. This resulted in more code, longer time to market, and reduced velocity.
The SPA route can be a requirement (e.g. when a highly interactive UX is warranted), in that case there's no way around it. But when it's simply a bunch of forms in a business app, that's usually not the case: in those cases I'd go with a traditional "multi page app" and/or HTMX.
Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation. But in my experience it’s not a bad one because only very best designers i worked with were deliberate about state so they could use this advantage.
More likely than not you get designs that create all kinds of messy app states around and users then can’t properly use bookmarks or back button. This in turn leads to hotfixes and more mess in frontend. Forcing designers to think about urls and their names is in most cases very good.
> Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation.
Rather than limitation, I think of it as a constraint. The best engineering takes place under constraints, because when you're unconstrained you have a high chance of repeating mistakes that have known solutions. In this case, you rightly point out that the UX of the browser has certain limitations and making all state URL-addressable is the interface to that UX.
this is the argument that resonates with me ... increasing complexity around event driven frameworks includes more cognitive load to reason about state information in two (or more) places whereas the web of olden times was conceived around stateless clients (plus some cookies)
as I say in the post, HTMX is not for you if you are building a web app that needs this ... but in 90% of cases web sites don't
This isn't unique to HTMX though. You can do the same with any frontend framework. You can argue that HTMX forces this to be the case, but has a lot of trade offs in doing so.
The approach actually is not that different if you realize that there isnt much difference between sending json and sending html. Htmx is like if you were using react and rendering raw html everywhere.
The main advantage people feel with htmx is that your routing is serverside and you dont have to keep quering/filtering/transforming data from your api to fit UI because you have access to everything.
Do you suddenly need number of groups user is part of in this one only place? Well api doesnt have it so either extend api (figure out how to name it and where to put it) or you fetch all groups user is part of and count them on frontend.
This middlelayer is something i realized i more often than not need. And when i need interactive UI i can initialize webcomponent or even have react island. Since htmx (and other similar tools) dont expect to overtake whole DOM but work with elements they can be very isolated if you want them to be.
At the end of the day, neather approach really has features over the other. HTMX doesn't forbid other JS components.
I think HTMX appeals to fullstack devs like me who often find themselves needing bespoke API calls for their frontend views anyway.
When writing tightly coupled backend code for a frontend view, I'm quick to think "well why am I not doing this entire feature in the backend, anyway?" And HTMX makes that super easy without giving much up.
> but as far as I can tell, you're still writing those same templates, just using your backend language instead of JS.
Yes.
> Which is convenient, but hardly "less code"
It is strictly less code because you're no longer validating on both client and server. It's also more than just "convenient", because it also forces you to stick to the well understood browser UX, ie. all state is URL-addressable.
I would rather write 1000 lines of Python than 100 lines of JS.
Nothing wrong with JS, I'm just not fluent in it. Whereas, Python is my native programming language, and I can just see it without looking anything up. This is why I love HTMX. I just want basic web interaction without having to do it all in Javascript.
No, you're pretty much exactly right. I am not a programmer by trade and when searching around and trying different technologies the first one that really clicked for me was HTMX. For whatever reason, handling all of that logic on the backend felt more natural. I've since started learning React and it's amazing how much 'easier' some of those UI conveniences really are. However, in places where they aren't truly necessary it's hard to beat the convenience and ease of a small Flask/SQLite/HTMX app, for me.
But yeah, if that doesn't really fit your mental model then I don't see a huge reason to give it a try.. other than it IS fun!
I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.
this is my medium term intent with HTMX & Raku ... I have in mind a programmatic / functional style of building websites where I can compose whole pages and sites
HTMX pairs incredibly well with something like Go’s templates. Giving you the “what you’d want react to be” experience for many scenarios. I imagine it’s similar with other languages with good templating engines, I just know it’s extremely easy to build things with Go and HTMX.
That being said, HTMX is not for everything. It’s great for internal tools as long as you don’t have very complex role-based access model. But security and access rights is where I think HTMX quickly becomes too complicated compared to a more traditional approach. As far as having “too many back end views” I do think that is down to you choosing an “incompatible” backend for your HTMX. It’s hard to say without knowing your details. You do say that you put a REST api behind it, but why would you do that with HTMX?
In the article I show HTMX and Pico CSS with Raku and Cro templates (Cro is one of the leading Raku web frameworks - there are others such as Hummingbird) in the same role as Go and ... (put your favourite Go HTML template engine here) - I am currently implementing the basic htmx.org examples in Raku by translating from https://github.com/Konfuzian/htmx-examples-with-flask/tree/m... which has them in Python / Flask. The HMTX Discord has about 35 channels across all the various server side language options (including node).
Certainly agree that HTMX is not for everything. Nor is Raku ;-)
When I build a page that uses HTMX, I go one of two ways.
Traditionally I first build it as a fully server-side rendered page. Once that’s working I setup my views to return HTML partials for different parts of the page.
So I might still have multiple views (or I might have single views that handle path parameters, query parameters, etc), but each is then basically just returning part of the existing template:
Full page: return render(request, "jobs/index.html", ...)
Some part of the page: return render(request, "jobs/index.html#status", ...)
You can sort of think of this the same as you would with JSON API endpoints, where you still need different endpoints handling different HTTP methods (GET, POST, etc) for the different CRUD operations, and there’s a tradeoff regarding how granular you get with views, but typically you can make the views pretty generic and reusable (the same way you can make JSON API endpoints that essentially just serialize database query results). There’s an article [0] that gives an example of a similar approach.
More recently I’ve been using a more component-based approach, using something like htpy [1] where I build up the page out of components (like you would in React), and sprinkle JS and CSS into the HTML with Alpine and Tailwind.
I've tried HTMX with a few different back end frameworks and languages, my setup varies a lot based on which framework/language I use.
The pattern I've been happiest with is when I can have a templating language designed to work really well with a component (or partials) approach.
I break down the UI into smaller components as I add more HTMX interactions. The UI is effectively a tree of nested components, much like react or svelte. When an HTMX request is sent, the API handler logic runs and instead of returning a success response it sends back HTML for the individual component(s) that HTMX needs to update.
tl;dr; When a request comes in, check headers to see if it was an HTMX request. If it wasn't, handle the API logic and return the full HTML page. If it was an HTMX request, still run the API logic but send back only the rendered components/partials that changed.
yeah it's just that when I have a REST API I get like... I guess 20 or so endpoints "for free" (since I can PATCH specific fields up in interesting ways).
Maybe I need to be writing REST-looking form submission endpoints.... but then I have the immediate issue of presentation.
Check out https://alpine-ajax.js.org it defaults to using the same template views you would in a typical JavaScript-less app, then you can sprinkle in fragments where you need to optimize requests.
I love htmx for internal dashboards. I find htmx difficult to use for user facing applications because it's difficult to get everyone on board with the constraints of htmx (no optimistic uis, simple ui/ux). When building complicated frontends with lots of popovers, modals, optimistic state, I like react.
UX designers are immersed in this world of React and frontend frameworks, so their designs are built with that in mind.
Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard.
We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.
I don't think htmx should be used on its own when implementing ui/ux - htmx has the job of getting the blocks of html, with data embedded, from the back-end to the front-end (and posting back up as necessary); once it's there, front-end client-only ui/ux can be handled by other tools in JavaScript
Alternatively, use web components which are baked into the browser, don't require a compile step, integrate well with HTMX and are much more stable than React.
Web components are the stuff that nightmares are made of.
The amount of boilerplate I had to write just to keep DOM attributes and JS properties in sync was not fun, the impedance mismatch between them (DOM attributes being strings) was painful to deal with, and templates/slots felt much worse than the React way.
The DOM didn't seem like a great model for moderately complex apps. Feels like web components didn't take off for a reason. IMO they feel like the solution you come up with when you create an abstraction in paper instead of writing a real-world thing that will solve your immediate problems. Not very pragmatic.
Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app.
Overall not a great experience for user-facing apps.
But that's yet-another-layer-of-abstraction with its own set of tradeoffs (e.g. I think CSS-in-JS is a trap, which seems to be the way for Lit; slots are still a thing; no SSR nor progressive enhancement; decorators!?!?!; etc.) which builds on top of what already feels like the wrong abstraction in the first place, only to provide React-like capabilities.
At that point why not just use React? What do I get from using Lit instead?
I don't personally mind writing web components by hand, but for those who want something easier, lit.dev is popular. There's also slim.js and Stencil if you don't mind a compile step.
The design of web components could be better, but I much prefer them to the true nightmare that React development has become. And the api is stable, which means a longevity that frameworks don't have.
| no SSR nor progressive enhancement
I have not been impressed by React SSR in the wild in terms of progressive enhancement. This seems like more of marketing promise than a real world experience. Do you have any examples to link?
I've used both and I prefer the htmx approach. React/NextJS are what over-complicate things - particularly when it comes to server vs client side rendering and hydration, state management, passing props, caching, static site generation, slow and fragile development environment etc etc etc.
I recently rewrote a site that was built in NextJS into Go+Echo+Templ+HTMX+AlpineJS, keeping just the Google Maps and Facebook components (but only injected as necessary, rather than needing a whole App wrapped around them)
The result was about 50% of the size of code that is much easier to reason about and test, better performance, simpler and smaller (size and resource) deployment - essentially better in every way.
I guess I could have done but the server was initially set up to respond with JSON and then the pages aspect got added in later and it felt easier to boot in htmx and bolt in the partials system and keep the json endpoints that are still needed than rearchitect for a proper MPA.
> I am a simple sole, ... go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style.
I am not sure if this is intended as humor, but JavaScript came before CSS.
I remember when CSS Zen garden was showcasing what you can do with CSS, and browsers (well, "browser", singular, as there was basically only IE 6 back then) supported Javascript and VBScript.
It seems JavaScript was first released, just internally, in May 1995 in a pre-alpha version of Netscape 2.0. It would not be publicly announced until December 1995. Netscape 2.0 didn't even come out until March 1996 and even then it was language version 1.0 which was extremely defective. The first version of the language that actually worked was JavaScript 1.1 that came out in August 1996. CSS on the other hand first premiered with IE3 that came out in August 1996.
The distinction either way is trivial, because at that time nobody was using either CSS or JavaScript as they required proprietary APIs. There was no DOM specification at that time.
JavaScript was created by Brendan Eich in just 10 days in May 1995 while he was working at Netscape Communications Corporation
CSS (Cascading Style Sheets) was introduced later than JavaScript. The first CSS specification was published in December 1996 by Håkon Wium Lie and Bert Bos.
> As we have seen in the previous posts, HTMX eliminates the need for JS to make dynamic web content.
Well, sort of! I suppose that for certain definitions of eliminating Javascript, this Javascript framework eliminates the need for Javascript completely.
HTMX is whooping 45KB of JS, which is being often loaded in <head> blocking rendering HTML, whereas you can have a fully functioning interactive website with pure CSS framework like Spectre.css (https://niutech.github.io/spectre/) and a sprinkle of 166-byte (sic!) HTMZ. See my demo: https://kodus.pl
Which is a bit surprising considering that react is 90kb unzipped, 46kb zipped. Yet there's this weird sentiment that react is JS bloat while htmx isn't.
htmlx, taiwind and the like certainly help back-end dev churn out web codebases faster, eliminating a lot of poor souls who have to maintain them afterward!
> I am a simple sole, I want to reduce the cognitive load in my web projects. The general idea is to go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style. An elegant division of roles.
(I'm not quite sure if this is the author's sentiment), but the point shouldn't be to escape JS entirely, but make it into something that can be used in a repeated pattern that works in lockstep with your application, such that you are neither creating custom JS for each page (e.g. React), nor blindly manipulating the DOM (like JQuery).
The division of roles between CSS and HTML is an almost contradictory point - your styling and layout should be coupled if you are to impose any meaningful order in your design. If you are rejecting the "decoupling" of front-end and back-end that React gives you, then why would you expect to be able to do it between HTML and CSS?
these two points are exactly where I am coming from ...
(i) I am deliberately starting from a(n over-) simplified pov to see how far I can get with zero JS ... but as I read the comments above I realise that, for real applications, I will need to "sprinkle" some Alpine and Tailwind here and there. (I chose Cro for the user auth.)
(ii) Indeed HTML and CSS are in an intricate contradictory dance. In the purest sense I think that my sites should be composed of reusable parts that sit within context. These parts can be composed from roles and may selectively tweak them. The roles convey aspects of the design (colours, typography, containment, scale, size). The parts contain content (text, image, actions), identity and semantic intent. Role mixing in SASS is a small start in this direction.
[This is a very weak stab at a very thorny problem ... please let me know if there is any reading that you recommend.]
HTMX is a great tool to bring the UI implementation back into the realm of more capable & expressive languages. And to start with a new perspective.
My personal preference is Raku, but you may prefer OCAML, Rust, Go, Python, Haskell, Elixir, ROC, Zig ...
Why not just use a pure CSS framework like Spectre.css (including accordions, modals, carousels, tooltips, tabs) and optionally a 166-byte HTMZ where CSS is not enough? You don't need more than 1KB of JS, see PHOOOS at https://kodus.pl.
HTMX, Unpoly and Twinspark are great, can't say anything about Raku.
I also really liked an idea about class-less CSS frameworks, as I was frustrated with all the `<table class="table">` and so on. Then I've tried it for one project where I had to integrate Leaflet map on a page. And it's just not possible to do with class-less CSS frameworks.
Since then I write `<table class="table">` and have zero problems with that.
How is it not possible? Can you not just use classes for the map tags and keep everything else the same? Or is the problem that the map styles are affected by the classless CSS?
I guess you're right and "impossible" was too strong of a statement. I just didn't feel like debugging those CSS things, especially when adding any new Leaflet plugins, or any other things. So I just switched to a style that I knew will work robustly.
To all rules, and then add the nostyle class to all elements you want to exclude.
The problem would be that you have to add the class to every single element (and all children) to exclude them, and there seems to be no good way of having
selector:not(.class and all children of .class)
The Shadow DOM method is really interesting though, I’ve never used it anywhere but it looks like it’s perfect for this application.
The main example in this article — immediately following a section on semantic HTML — is a list of <a> tags with the hrefs all set to `#` and the hyperlink behavior emulated with htmx. So we’ve taken what would otherwise be a perfectly functional list of links, removed the most important semantic attribute, broken a bunch of behavior and rendered them useless without a ~16kb JavaScript library.
…and look, that’s an okay mistake to make — it takes time to learn this stuff — but when you also go out of the way to pine for “the halcyon early days of the web before Netscape dropped the JS-bomb” it makes it difficult to take you seriously. A list of links is, like, the most basic essence of a website; if you aren’t able to make that work without a JavaScript library, what are you even pining for?
It’s not really about the tooling. My point is that people who talk about the “good old days” of the web often (charitably) are unfamiliar with or (cynically) don’t care about the medium they venerate.
I'm just curious if anyone is using unpoly instead of HTMX?
I know that HTMX has a much larger userbase, its main dev is well known and beloved, and the landing page doesn't look web 1.0
With that said, unpoly appears to have a similar feature set and one feature that HTMX doesn't: The ability to create modals without loading a new page.
I use it for a rewrite I'm doing because tracking state on both back- and front-end got too cumbersome.
I'm using Django, and a big positive of using unpoly is that I can write views like a traditional Django application and have a reactive frontend.
It does mean however that heavy pages impact front-end reactivity. So if there's only one tiny element that needs to be updated on the front-end, that takes more time than if the backend would only have to return a template partial (htmx) or some JSON (alpine).
Also, the documentation is really a reference. You need it read it front to back a few times to understand unpoly's capabilities.
It's strange that there are so few tutorials about it, because it's been around for a while already, it really has its use and it is still under active development.
It has "actions" that bridge a need for some client-side interactivity, without resorting to write lots and lots of JS. I have some interactive stuff that don't touch server. Also it's pretty easy to add more actions when needed.
And if I need to do something really complex, I can just go and read its source code. Which is really hard to do with unpoly and its really complicated OOP style.
Yes, using unpoly, I conclused the way updates work in unpoly to be easier to work with, less need for lots of special endpoints for every kind of interaction than in htmx. But haven't really tried htmx much.
i know tailwind wasn't created in a vacuum and solves a massive problem. but part of me does feel sad it "won" and now we all are forced to deal with it in one way or another. i remember when HTML was clean and semantic, and crawlable. there was a certain respect in that way.
Recently, I’ve been working with Quarkus[1], the quarkus-qute[2] (a type-safe templating engine), and htmx. I found the experience quite positive. Quarkus offers lightning-fast compilation with a hot-reloading Maven wrapper (mvnw), making development seamless. Picking up qute was straightforward, and combining it with htmx, especially with qute’s #fragment support for htmx, felt like a natural fit.
For the "semantic web" part, what we've been using in my company recently , is the `<x-something>` tag which are valid html5
so except if there's a really fitting html5 tags (like footer, h1 , main ), we will have `<x-card>` `<x-avatar><img ></x-avatar>` (In case we must have an additional ) so that it's easier to convey the semantic (especially when looking in the dom inspector)
for the css we've been using tailwind (and couldn't be happier), but for personnal projects I guess picocss would be a really nice fit with `<x-semantic>` tags
I hope you are not a sole, and have the complete human embodiment of a soul. Otherwise, yes, I agree. My one off projects use more and more cdn loaded information. I love pico, bulma and htmx.
As a more backend focused dev (though one who's touched a bunch of different JS / CSS frameworks over the years), seeing Pico in this article seemed pretty nice in comparison to what I've seen in the past. What are some of the similar frameworks that compete in your opinion?
WASM isn't friendly with any other web technologies because it's compiled code. You can't interact with the DOM at all, so if you're doing rendering via WASM it's always gonna be in it's own little island.
For me I'll never go back to normal front-end work after doing Blazor with C#. It's the nice bits of React (reusable code) but the flexibility of never having to decide between front-end only focused code, or some back-end powered AJAX style code, that is transparently rendered for you. You never have to touch JavaScript, but there's ways to do so.
WASM is the best thing that ever happened to the web. When other major web frameworks adopt template engines that compile to WASM, we will see a shift in focus on JS heavy frameworks, and just people building things instead of fighting and trying to remember all the weird quirks of JavaScript.
I've done web dev with various other frameworks: Django, React (front-end only - no SSR), Vue, CherryPy, and a few others. Blazor is the only technology that allows me to use 1 programming language outside of HTML / CSS. You have component UI libraries like React does, so you have to think less about hand crafting HTML and can focus on per component logic / UI much like when developing with React or any "SPA Framework" out there.
You should try it out; microsoft makes good contributions to open source software, and C# is, in my view, the best (or maybe the only good) backend language put there
One of the frontend problems is that too much frontend engineers think a web app should be a single page app. A lot of apps don't need to be that. Server-side endpoints and templating + lightweight vanilla JS and framework-agnostic web components works and is now even easier than ever.
It‘s a kind of collective hallucination. It‘s affected me too.
I just recently decided to go back in time and wrote a web app using Flask, all rendered server side, with a minimum of JS and JSON endpoints for a bit of client-side interactivity (e.g. autocompleting an input field). Very fast, iterative work. No duplication of data classes, no weird caching issues…
Felt like a breath of fresh air, sadly. Have we witnessed a full turn of the wheel?
That's a good old case of "the right tool for the job".
But let's be honest: the frontend dev rat race had the effect to make the base web technologies better. Better CSS (variables, nesting, effects, media support, etc), better JS (webcomponents), useful libs available as wasm and so on... all good things that can be used natively and allow us to make better MPAs.
I think most people choose SPAs because they also maintain the frontend state of a an application. If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell. How do you manage the transition between one view and another on the same page? How do you pass state between two pages? I think webcomponents solve some of this but there's a lot of react developers out there who don't have the requisite software engineering skills to handle this
> How do you manage the transition between one view and another on the same page?
HTMX solves this, and it's mostly automatic. You get some nice transitions.
> How do you pass state between two pages?
You don't. You submit some data to the server, it generates HTML dynamically, you replace HTML on the frontend or redirect all together, you're done. The state is on the server.
> So then you need some kind of state management on the server
Yes. You might call this an application, lol. You will require this no matter what, unless you have a fully client-side application. Like photoshop or something.
> If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell.
How so ? Vanilla JS has never been easier and more powerful.
> How do you pass state between two pages?
Why is it even considered to be a problem ? This is basic stuff. All web frameworks since the 90s have had this concept of sessions where you can store data that will be available across pages.
Vanilla js is unstructured. It's very easy to write spaghetti code with vanilla js.
Sessions are a kind of global state. I mean temporary state, like when filling out a form and moving from one page to the other, but without submitting the results until the end.
Functions, classes, modules... everything is available to organize code. The mess some programmers make can be unstructured, but that's the case with any paradigm and yes, we've seen that with "modern" JS frameworks too. Spaghetti mess, lasagna mess, components mess or whatever pasta mess.
> I mean temporary state
What is the problem here ? It's as temporary as you need it to be.
clear boundary is good, I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense. They are just shifting complexity from a place they feel uncomfortable, to where they do, but at the cost of destroying their own nirvana. Certainly one way, but hardly the only one.
> I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense.
Because the tooling has been here for decades and it works damn fine. No need to trash the frontend with ever changing piles of dependency and build nonsense.
when? View code in the back-end always looks like crap and never able to achieve the interactivity the front-end can. People wrestling with it was the reason SPA was born. There was no dictator forcing people to move on from such "awesome" working "damn fine" pipelines to modern front-end for no reason.
Commercial-grade applications need some grade of offline operativity that classic HATEOAS can't provide, often target users who won't learn or can't really use a web browser (tabs, back button, extensions, bookmarks besides whatever they can fit in the bar, etc), often want to give a UX which abuses and deforms a web browser by design.
Yeah, FE engineers may all look like dumbasses with macbooks (i don't think this of them!), but they have real problems to solve.
That's for sure, for example any blog software (a few SSGs included) is a failure for WWW and for itself (most of the interaction between author and reader must be mediated with third-party or big cloud to avoid spam and scam).
I think the churn and misery of front end development is the inevitable result of 30 years of path dependence on technologies that were either substandard to begin with (javascript, css) or were never designed for what they're used for (html, css).
I must be a masochist because I love FE frameworks. I love learning them and comparing them. I love how they are changing all the time and things are always improving somehow. What was great 10 years ago now are ridiculous to think about, What is great now will be completely forgotten in a couple years time. It's beautiful and maddening at the same time.
My favorite stack right now is Astro + SolidJS. Maybe it'll change next week. Who knows?
I don't know if you're a masochist, but I bet you aren't writing large apps. At work, the last thing I want is the technology I'm using to be obsolete in two months.
At my day job, we use something called ClickUp for task tracking. Watching the UI elements load one at a time reminds me of those greybeard stories about using vi over 300 baud modems. ClickUp is supposed to be productivity software.
HTMX pretty much enforces a 'one user action, one HTTP request, one HTTP response' pattern, which is necessary for a usable UX for users who can't see the data centre from their office window.
Like the article's writer, I remember the Netscape days and when JS came into existence. I was only a kid back then, like 9 years old, and was _just_ getting into coding in C and playing around with HTML/CSS. The results I produced, as you might have imagined, were akin to the results a toddler would produce given a wet loaf of bread to play with: mess everywhere.
Anyway, back then the HTML was simple (but it was tables and spacer GIFs ha ha!) and the CSS even simpler. Now it's just such a chaotic mess that people actually think Web Assembley is a good idea; as if somehow they've invented something new: the sandbox and the machine code. Like running a process at the OS level and making _that_ better, more secure, etc. wasn't the right path.
HTMLx is as close to the UI as I'll come. Everything else is an absolute headache to get into.
I’ve been using htmx for over a year now for our internal management application (order monitoring, partner management, CAD model uploading and management type stuff) and I continue to be delighted at how quickly I can add features and iterate existing ones. I write way less client side JS, the app is very fast and responsive and I don’t have to write the app twice like with a SPA + API.
One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down whatever resources I need (though it's honestly pretty wasteful at times).
With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?
This is the thing that makes me lose interest in HTMX. People talk about it like it eliminates the need for JS/React/etc, but as far as I can tell, you're still writing those same templates, just using your backend language instead of JS. Which is convenient, but hardly "less code", just a different language, and that backend language probably lacks a lot of functionality you'd want for UI convenience. That's all fine if you'll never want those UI conveniences, by my experience has been that the want of those UI conveniences creep in over time, and eventually you regret not using something that makes them native and easy.
I haven't actually played around with HTMX, so I might be sizing it up wrong, but it's mission statement just never resonated with me enough to want to try it out.
The value of HTMX is that state now resides solely on the server, and the browser becomes only a representation of that state. This simplifies applications considerably because maintaining two copies of the state between client and server is the source of a lot of complexity in modern applications.
It wasn't about writing less code (although it is about writing less javascript) but about working with the concept of hypermedia instead of against or around it.
Something I dislike about this argument is that there are a lot of UX flows where "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state. And popular backend frameworks are not super up to the task!
I have the impression that older web frameworks did in fact have a good amount of statefulness built in, and that causes a whole host of issues, so I believe to understand _why_ modern backend frameworks really don't lean into that.
You're absolutely right, htmx is not built for every UX flow.
But neither is React. And we've been reaching for it by default for everything and that's been a mistake.
So much of what's built these days could be stateless MPAs. Servers have gotten crazy fast, and I'd certainly rather optimize for page size and server latency than build a React app.
With the upcoming views transitions api, a bit of htmx, and custom web components and you get 95% of what React offers without anywhere near the package size or complexity. You don't even need a compile step.
I'd never argue htmx is best for all use cases, I would hate for it to mutate the way React has, trying to be everything to everyone. But I hope htmx is the start of re-thinking how they approach the web and realizing that there are significantly simpler ways to build a frontend.
I definitely think it’s important to note it’s not really React that’s mutated it’s damn Vercel with its extreme vendor lock in plan with Next that’s trying to force React to be server side as much as client side, especially now that Vercel employs some React core team members.
Unfortunately worked with someone I was reasonably sure was a ~~paid shill~~ part of some Vercel partner/influencer programme as they were adamant we must use Next (and Vercel but they lost that argument) for a project the team absolutely didn’t need to use it for.
In fact the rewrite of a project was worse than the original application. The original was snappy and instant and just worked meanwhile the Next version was slow, full page refreshes for every action, and just totally awful.
I couldn’t get off that team quick enough.
Next is odd because it gives lots of "high preformance" vibes with static rendering and image optimization. It is fast enough but not as fast as tuning up a classic MVC app which caching, avoiding JS bundles and React or deferring scripts etc. Send out the right cache headers and chuck a CDN in front.
Next is ironically fast if you prerender/static generate AND the client disables JS!
> "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state.
The issue with many SPAs I saw was that state had to be managed BOTH in the browser AND on the server. This resulted in more code, longer time to market, and reduced velocity.
The SPA route can be a requirement (e.g. when a highly interactive UX is warranted), in that case there's no way around it. But when it's simply a bunch of forms in a business app, that's usually not the case: in those cases I'd go with a traditional "multi page app" and/or HTMX.
Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation. But in my experience it’s not a bad one because only very best designers i worked with were deliberate about state so they could use this advantage.
More likely than not you get designs that create all kinds of messy app states around and users then can’t properly use bookmarks or back button. This in turn leads to hotfixes and more mess in frontend. Forcing designers to think about urls and their names is in most cases very good.
> Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation.
Rather than limitation, I think of it as a constraint. The best engineering takes place under constraints, because when you're unconstrained you have a high chance of repeating mistakes that have known solutions. In this case, you rightly point out that the UX of the browser has certain limitations and making all state URL-addressable is the interface to that UX.
this is the argument that resonates with me ... increasing complexity around event driven frameworks includes more cognitive load to reason about state information in two (or more) places whereas the web of olden times was conceived around stateless clients (plus some cookies)
as I say in the post, HTMX is not for you if you are building a web app that needs this ... but in 90% of cases web sites don't
This isn't unique to HTMX though. You can do the same with any frontend framework. You can argue that HTMX forces this to be the case, but has a lot of trade offs in doing so.
I haven't used htmx, but this doesn't seem to be true at all. The equivalent state would also be in the client, as URL and HTML.
The state is represented by the url and html, but that's not the same as managing state in client-side memory using Javascript.
Hypermedia Systems is a great read, by the htmx creator, available here:
https://hypermedia.systems
But it's not on the server any more than with a JS app.
Not sure I understand what you mean.
The equivalent of the JS state doesn't live in the server side session, or something like that.
The client doesn't produce those URLs or HTML - the server does. That's just what the user sees.
There is client state. The URL plus the sum of whatever partial swaps you did since loading the page.
That's the representation of state, not the state itself.
The approach actually is not that different if you realize that there isnt much difference between sending json and sending html. Htmx is like if you were using react and rendering raw html everywhere.
The main advantage people feel with htmx is that your routing is serverside and you dont have to keep quering/filtering/transforming data from your api to fit UI because you have access to everything. Do you suddenly need number of groups user is part of in this one only place? Well api doesnt have it so either extend api (figure out how to name it and where to put it) or you fetch all groups user is part of and count them on frontend. This middlelayer is something i realized i more often than not need. And when i need interactive UI i can initialize webcomponent or even have react island. Since htmx (and other similar tools) dont expect to overtake whole DOM but work with elements they can be very isolated if you want them to be.
At the end of the day, neather approach really has features over the other. HTMX doesn't forbid other JS components.
I think HTMX appeals to fullstack devs like me who often find themselves needing bespoke API calls for their frontend views anyway.
When writing tightly coupled backend code for a frontend view, I'm quick to think "well why am I not doing this entire feature in the backend, anyway?" And HTMX makes that super easy without giving much up.
But the opposite reaction would be equally valid.
> but as far as I can tell, you're still writing those same templates, just using your backend language instead of JS.
Yes.
> Which is convenient, but hardly "less code"
It is strictly less code because you're no longer validating on both client and server. It's also more than just "convenient", because it also forces you to stick to the well understood browser UX, ie. all state is URL-addressable.
I would rather write 1000 lines of Python than 100 lines of JS.
Nothing wrong with JS, I'm just not fluent in it. Whereas, Python is my native programming language, and I can just see it without looking anything up. This is why I love HTMX. I just want basic web interaction without having to do it all in Javascript.
No, you're pretty much exactly right. I am not a programmer by trade and when searching around and trying different technologies the first one that really clicked for me was HTMX. For whatever reason, handling all of that logic on the backend felt more natural. I've since started learning React and it's amazing how much 'easier' some of those UI conveniences really are. However, in places where they aren't truly necessary it's hard to beat the convenience and ease of a small Flask/SQLite/HTMX app, for me.
But yeah, if that doesn't really fit your mental model then I don't see a huge reason to give it a try.. other than it IS fun!
Check these out and see if they provide any insight for your specific issues :)
- https://htmx.org/essays/template-fragments/
- https://htmx.org/essays/10-tips-for-ssr-hda-apps/
I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.
this is my medium term intent with HTMX & Raku ... I have in mind a programmatic / functional style of building websites where I can compose whole pages and sites
[flagged]
rofl
[flagged]
HTMX pairs incredibly well with something like Go’s templates. Giving you the “what you’d want react to be” experience for many scenarios. I imagine it’s similar with other languages with good templating engines, I just know it’s extremely easy to build things with Go and HTMX.
That being said, HTMX is not for everything. It’s great for internal tools as long as you don’t have very complex role-based access model. But security and access rights is where I think HTMX quickly becomes too complicated compared to a more traditional approach. As far as having “too many back end views” I do think that is down to you choosing an “incompatible” backend for your HTMX. It’s hard to say without knowing your details. You do say that you put a REST api behind it, but why would you do that with HTMX?
In the article I show HTMX and Pico CSS with Raku and Cro templates (Cro is one of the leading Raku web frameworks - there are others such as Hummingbird) in the same role as Go and ... (put your favourite Go HTML template engine here) - I am currently implementing the basic htmx.org examples in Raku by translating from https://github.com/Konfuzian/htmx-examples-with-flask/tree/m... which has them in Python / Flask. The HMTX Discord has about 35 channels across all the various server side language options (including node).
Certainly agree that HTMX is not for everything. Nor is Raku ;-)
When I build a page that uses HTMX, I go one of two ways.
Traditionally I first build it as a fully server-side rendered page. Once that’s working I setup my views to return HTML partials for different parts of the page.
So I might still have multiple views (or I might have single views that handle path parameters, query parameters, etc), but each is then basically just returning part of the existing template:
Full page: return render(request, "jobs/index.html", ...)
Some part of the page: return render(request, "jobs/index.html#status", ...)
You can sort of think of this the same as you would with JSON API endpoints, where you still need different endpoints handling different HTTP methods (GET, POST, etc) for the different CRUD operations, and there’s a tradeoff regarding how granular you get with views, but typically you can make the views pretty generic and reusable (the same way you can make JSON API endpoints that essentially just serialize database query results). There’s an article [0] that gives an example of a similar approach.
More recently I’ve been using a more component-based approach, using something like htpy [1] where I build up the page out of components (like you would in React), and sprinkle JS and CSS into the HTML with Alpine and Tailwind.
[0] https://www.circumeo.io/blog/entry/django-htmx-and-template-...
[1] https://htpy.dev/
You may want to look at https://roca-style.org/
If you have problems filtering in the backend but it's easy in the frontend your backend technology is probably lacking.
I've tried HTMX with a few different back end frameworks and languages, my setup varies a lot based on which framework/language I use.
The pattern I've been happiest with is when I can have a templating language designed to work really well with a component (or partials) approach.
I break down the UI into smaller components as I add more HTMX interactions. The UI is effectively a tree of nested components, much like react or svelte. When an HTMX request is sent, the API handler logic runs and instead of returning a success response it sends back HTML for the individual component(s) that HTMX needs to update.
tl;dr; When a request comes in, check headers to see if it was an HTMX request. If it wasn't, handle the API logic and return the full HTML page. If it was an HTMX request, still run the API logic but send back only the rendered components/partials that changed.
yeah it's just that when I have a REST API I get like... I guess 20 or so endpoints "for free" (since I can PATCH specific fields up in interesting ways).
Maybe I need to be writing REST-looking form submission endpoints.... but then I have the immediate issue of presentation.
Check out https://alpine-ajax.js.org it defaults to using the same template views you would in a typical JavaScript-less app, then you can sprinkle in fragments where you need to optimize requests.
yea I'm seeing alot of people combine it with alpine, but then whats the point ?
I love htmx for internal dashboards. I find htmx difficult to use for user facing applications because it's difficult to get everyone on board with the constraints of htmx (no optimistic uis, simple ui/ux). When building complicated frontends with lots of popovers, modals, optimistic state, I like react.
UX designers are immersed in this world of React and frontend frameworks, so their designs are built with that in mind.
Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard.
We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.
I don't think htmx should be used on its own when implementing ui/ux - htmx has the job of getting the blocks of html, with data embedded, from the back-end to the front-end (and posting back up as necessary); once it's there, front-end client-only ui/ux can be handled by other tools in JavaScript
So why complicate things and just use something like React + Next.js, which is already designed for complex apps?
Alternatively, use web components which are baked into the browser, don't require a compile step, integrate well with HTMX and are much more stable than React.
Web components are the stuff that nightmares are made of.
The amount of boilerplate I had to write just to keep DOM attributes and JS properties in sync was not fun, the impedance mismatch between them (DOM attributes being strings) was painful to deal with, and templates/slots felt much worse than the React way.
The DOM didn't seem like a great model for moderately complex apps. Feels like web components didn't take off for a reason. IMO they feel like the solution you come up with when you create an abstraction in paper instead of writing a real-world thing that will solve your immediate problems. Not very pragmatic.
Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app.
Overall not a great experience for user-facing apps.
> Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app.
You can SSR web components using the Declarative Shadow DOM API, which is finally supported in all of the major browsers and works without JS.
| Web components are the stuff that nightmares are made of.
There's lit.dev for an easier approach.
https://lit.dev
But that's yet-another-layer-of-abstraction with its own set of tradeoffs (e.g. I think CSS-in-JS is a trap, which seems to be the way for Lit; slots are still a thing; no SSR nor progressive enhancement; decorators!?!?!; etc.) which builds on top of what already feels like the wrong abstraction in the first place, only to provide React-like capabilities.
At that point why not just use React? What do I get from using Lit instead?
I don't personally mind writing web components by hand, but for those who want something easier, lit.dev is popular. There's also slim.js and Stencil if you don't mind a compile step.
The design of web components could be better, but I much prefer them to the true nightmare that React development has become. And the api is stable, which means a longevity that frameworks don't have.
| no SSR nor progressive enhancement
I have not been impressed by React SSR in the wild in terms of progressive enhancement. This seems like more of marketing promise than a real world experience. Do you have any examples to link?
I have been musing in going in this direction - but your post has lowered this idea in my project plan for now ... thanks!
I've used both and I prefer the htmx approach. React/NextJS are what over-complicate things - particularly when it comes to server vs client side rendering and hydration, state management, passing props, caching, static site generation, slow and fragile development environment etc etc etc.
I recently rewrote a site that was built in NextJS into Go+Echo+Templ+HTMX+AlpineJS, keeping just the Google Maps and Facebook components (but only injected as necessary, rather than needing a whole App wrapped around them)
The result was about 50% of the size of code that is much easier to reason about and test, better performance, simpler and smaller (size and resource) deployment - essentially better in every way.
i used it for simple dashboard, worked well but for complex projects it leads to spaghetti code for me, I had to stick to react for that.
For such an internal web app, why not do it in a fully traditional/multi-page/server-rendered manner?
I guess I could have done but the server was initially set up to respond with JSON and then the pages aspect got added in later and it felt easier to boot in htmx and bolt in the partials system and keep the json endpoints that are still needed than rearchitect for a proper MPA.
Plus I wanted an excuse to use htmx.
> I am a simple sole, ... go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style.
I am not sure if this is intended as humor, but JavaScript came before CSS.
And "HTML for structure, CSS for style" is a philosophy that developed later. As is evidenced by early HTML tags like <small>, <center>, <b>, <i>, etc
I remember when CSS Zen garden was showcasing what you can do with CSS, and browsers (well, "browser", singular, as there was basically only IE 6 back then) supported Javascript and VBScript.
Back in 2008 we had a team building exercise to create a Zen Garden sample. Here was mine: https://prettydiff.com/zen/
In those days the three content columns vertically aligned to the same height cross-browser.
And it's soul, not sole. Unless the author is also a fish.
sorry - maybe we need AI smell checkers
Haha
I'm noted for my dry wit
I read that as "sole [proprietor]"
It seems JavaScript was first released, just internally, in May 1995 in a pre-alpha version of Netscape 2.0. It would not be publicly announced until December 1995. Netscape 2.0 didn't even come out until March 1996 and even then it was language version 1.0 which was extremely defective. The first version of the language that actually worked was JavaScript 1.1 that came out in August 1996. CSS on the other hand first premiered with IE3 that came out in August 1996.
* https://www.w3.org/Style/CSS/msie/
* https://webdevelopmenthistory.com/1995-the-birth-of-javascri...
The distinction either way is trivial, because at that time nobody was using either CSS or JavaScript as they required proprietary APIs. There was no DOM specification at that time.
yikes, I stand corrected...
JavaScript was created by Brendan Eich in just 10 days in May 1995 while he was working at Netscape Communications Corporation
CSS (Cascading Style Sheets) was introduced later than JavaScript. The first CSS specification was published in December 1996 by Håkon Wium Lie and Bert Bos.
apologies
Hmm apparently it also came before DSSSL. Surprising.
> As we have seen in the previous posts, HTMX eliminates the need for JS to make dynamic web content.
Well, sort of! I suppose that for certain definitions of eliminating Javascript, this Javascript framework eliminates the need for Javascript completely.
HTMX is whooping 45KB of JS, which is being often loaded in <head> blocking rendering HTML, whereas you can have a fully functioning interactive website with pure CSS framework like Spectre.css (https://niutech.github.io/spectre/) and a sprinkle of 166-byte (sic!) HTMZ. See my demo: https://kodus.pl
Which is a bit surprising considering that react is 90kb unzipped, 46kb zipped. Yet there's this weird sentiment that react is JS bloat while htmx isn't.
~14kb gzip'd, and it solves a bit of a different problem.
htmlx, taiwind and the like certainly help back-end dev churn out web codebases faster, eliminating a lot of poor souls who have to maintain them afterward!
Raku is such a fantastic, feature-laden language. Cool to see it get a (tiny) bit of HN attention!
Yeah - I think that many people are put off Raku by its imo undeserved reputation ... if languages were clothing, then Raku would be the tank top.
> I am a simple sole, I want to reduce the cognitive load in my web projects. The general idea is to go back to the halcyon early days of the web before Netscape dropped the JS-bomb. You know HTML for the layout and CSS for the style. An elegant division of roles.
(I'm not quite sure if this is the author's sentiment), but the point shouldn't be to escape JS entirely, but make it into something that can be used in a repeated pattern that works in lockstep with your application, such that you are neither creating custom JS for each page (e.g. React), nor blindly manipulating the DOM (like JQuery).
The division of roles between CSS and HTML is an almost contradictory point - your styling and layout should be coupled if you are to impose any meaningful order in your design. If you are rejecting the "decoupling" of front-end and back-end that React gives you, then why would you expect to be able to do it between HTML and CSS?
these two points are exactly where I am coming from ...
(i) I am deliberately starting from a(n over-) simplified pov to see how far I can get with zero JS ... but as I read the comments above I realise that, for real applications, I will need to "sprinkle" some Alpine and Tailwind here and there. (I chose Cro for the user auth.)
(ii) Indeed HTML and CSS are in an intricate contradictory dance. In the purest sense I think that my sites should be composed of reusable parts that sit within context. These parts can be composed from roles and may selectively tweak them. The roles convey aspects of the design (colours, typography, containment, scale, size). The parts contain content (text, image, actions), identity and semantic intent. Role mixing in SASS is a small start in this direction.
[This is a very weak stab at a very thorny problem ... please let me know if there is any reading that you recommend.]
HTMX is a great tool to bring the UI implementation back into the realm of more capable & expressive languages. And to start with a new perspective.
My personal preference is Raku, but you may prefer OCAML, Rust, Go, Python, Haskell, Elixir, ROC, Zig ...
Why not just use a pure CSS framework like Spectre.css (including accordions, modals, carousels, tooltips, tabs) and optionally a 166-byte HTMZ where CSS is not enough? You don't need more than 1KB of JS, see PHOOOS at https://kodus.pl.
that looks very interesting - thanks for the tip
Hi Steve. Please include https://github.com/beercss/beercss in your exploration.
it’s already my favourite - great tip
HTMX, Unpoly and Twinspark are great, can't say anything about Raku.
I also really liked an idea about class-less CSS frameworks, as I was frustrated with all the `<table class="table">` and so on. Then I've tried it for one project where I had to integrate Leaflet map on a page. And it's just not possible to do with class-less CSS frameworks.
Since then I write `<table class="table">` and have zero problems with that.
How is it not possible? Can you not just use classes for the map tags and keep everything else the same? Or is the problem that the map styles are affected by the classless CSS?
Yes, map styles are affected by the classless CSS.
But can’t you just do
For the styles that are a problem? That’s maybe 10 properties you need to remove?I guess you're right and "impossible" was too strong of a statement. I just didn't feel like debugging those CSS things, especially when adding any new Leaflet plugins, or any other things. So I just switched to a style that I knew will work robustly.
I find "removing" or resetting styles kind of hacky.
Another solution might be packing the map in a shadow element so that it doesn't get affected by the page CSS.
Another thing that one could try:
Use a CSS preprocessor to add a
To all rules, and then add the nostyle class to all elements you want to exclude. The problem would be that you have to add the class to every single element (and all children) to exclude them, and there seems to be no good way of having The Shadow DOM method is really interesting though, I’ve never used it anywhere but it looks like it’s perfect for this application.The main example in this article — immediately following a section on semantic HTML — is a list of <a> tags with the hrefs all set to `#` and the hyperlink behavior emulated with htmx. So we’ve taken what would otherwise be a perfectly functional list of links, removed the most important semantic attribute, broken a bunch of behavior and rendered them useless without a ~16kb JavaScript library.
…and look, that’s an okay mistake to make — it takes time to learn this stuff — but when you also go out of the way to pine for “the halcyon early days of the web before Netscape dropped the JS-bomb” it makes it difficult to take you seriously. A list of links is, like, the most basic essence of a website; if you aren’t able to make that work without a JavaScript library, what are you even pining for?
Try HTMZ, which is progressively enhanced and is just using a single <iframe>.
It’s not really about the tooling. My point is that people who talk about the “good old days” of the web often (charitably) are unfamiliar with or (cynically) don’t care about the medium they venerate.
I'm just curious if anyone is using unpoly instead of HTMX?
I know that HTMX has a much larger userbase, its main dev is well known and beloved, and the landing page doesn't look web 1.0
With that said, unpoly appears to have a similar feature set and one feature that HTMX doesn't: The ability to create modals without loading a new page.
With popover[1] and dialog[2], do you really need this from a JS framework?
1: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
2: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
I use it for a rewrite I'm doing because tracking state on both back- and front-end got too cumbersome.
I'm using Django, and a big positive of using unpoly is that I can write views like a traditional Django application and have a reactive frontend.
It does mean however that heavy pages impact front-end reactivity. So if there's only one tiny element that needs to be updated on the front-end, that takes more time than if the backend would only have to return a template partial (htmx) or some JSON (alpine).
Also, the documentation is really a reference. You need it read it front to back a few times to understand unpoly's capabilities.
It's strange that there are so few tutorials about it, because it's been around for a while already, it really has its use and it is still under active development.
How does it work with Javascript deactivated? In theory it should work that way, isn't it?
I'm using twinspark.js: https://twinspark.js.org/
It has "actions" that bridge a need for some client-side interactivity, without resorting to write lots and lots of JS. I have some interactive stuff that don't touch server. Also it's pretty easy to add more actions when needed.
And if I need to do something really complex, I can just go and read its source code. Which is really hard to do with unpoly and its really complicated OOP style.
Yes, using unpoly, I conclused the way updates work in unpoly to be easier to work with, less need for lots of special endpoints for every kind of interaction than in htmx. But haven't really tried htmx much.
i know tailwind wasn't created in a vacuum and solves a massive problem. but part of me does feel sad it "won" and now we all are forced to deal with it in one way or another. i remember when HTML was clean and semantic, and crawlable. there was a certain respect in that way.
It won mainly because it was a much better solution for styling in react than what existed at the time.
In react today I'd still probably reach for Tailwind. In any other scenario I'd only reach for it I wasn't comfortable with CSS.
You can’t remember a time that never existed.
bootstrap won just a few years ago. something else will win soon.
edit: I'm trying to impress the fact that things change. looking at if this library "won" or not misses the point.
I think 10 years is a good metric for “won” in FE land.
React “won” Wordpress “won”
Java applets did not
Those iPhone web apps that were around before the App Store should’ve, but didn’t.
Tailwind undecided
Vue did not win, right? Seems like nowadays Svelete took its place, though still undecided imo
Both are still around, but in the space of frontend frameworks, React is currently the winner.
> i remember when HTML was clean and semantic, and crawlable
I'm confused, HTML under tailwind is not any less semantic than under any other CSS toolkit.
Pico looks like it may be the classless styler I was looking for, thanks.
it's arguably the most starred classless css indeed, it's my default styler
(sole = bottom of shoe
soul = spiritual part of a human)
Recently, I’ve been working with Quarkus[1], the quarkus-qute[2] (a type-safe templating engine), and htmx. I found the experience quite positive. Quarkus offers lightning-fast compilation with a hot-reloading Maven wrapper (mvnw), making development seamless. Picking up qute was straightforward, and combining it with htmx, especially with qute’s #fragment support for htmx, felt like a natural fit.
[1] https://quarkus.io/
[2] https://quarkus.io/guides/qute
For the "semantic web" part, what we've been using in my company recently , is the `<x-something>` tag which are valid html5
so except if there's a really fitting html5 tags (like footer, h1 , main ), we will have `<x-card>` `<x-avatar><img ></x-avatar>` (In case we must have an additional ) so that it's easier to convey the semantic (especially when looking in the dom inspector)
for the css we've been using tailwind (and couldn't be happier), but for personnal projects I guess picocss would be a really nice fit with `<x-semantic>` tags
Better than using HTMX - 48KB of JS - use my PHOOOS technique (https://kodus.pl) with pure HTML out-ouf-order streaming, pure CSS framework Spectre.css (https://niutech.github.io/spectre/) and a sprinkle of 166B (bytes, not KB!) HTMZ (https://leanrada.com/htmz/) for extra interactivity.
I hope you are not a sole, and have the complete human embodiment of a soul. Otherwise, yes, I agree. My one off projects use more and more cdn loaded information. I love pico, bulma and htmx.
I do believe this is still in the first half of the rococo phase and that rubble is a long way off so by all means, carry on.
Why Pico specifically? Lots of classless frameworks.
> I am a simple sole [sic]
`href=#` + JS library + config file + setting routes for each tab button doesn't feel simple
As a more backend focused dev (though one who's touched a bunch of different JS / CSS frameworks over the years), seeing Pico in this article seemed pretty nice in comparison to what I've seen in the past. What are some of the similar frameworks that compete in your opinion?
> While HTMX is well suited to 90% of this, if you are building a webapp like FaceBook […], then it’s not for you
I completely completely disagree. This is all you need.
Agree, Facebook can be easily done with HTMX and similar things.
How would you do that with Figma, YouTube, etc?
Figma is mostly WASM, no?
That's not too HTMX-friendly technology, is it?
WASM isn't friendly with any other web technologies because it's compiled code. You can't interact with the DOM at all, so if you're doing rendering via WASM it's always gonna be in it's own little island.
I have been in web dev since 1999, and recently switched to a backend role.
I am never going back.
The endless thrashing on front end borders on psychosis. Something is clearly broken, and that thing is my feeble mind.
For me I'll never go back to normal front-end work after doing Blazor with C#. It's the nice bits of React (reusable code) but the flexibility of never having to decide between front-end only focused code, or some back-end powered AJAX style code, that is transparently rendered for you. You never have to touch JavaScript, but there's ways to do so.
WASM is the best thing that ever happened to the web. When other major web frameworks adopt template engines that compile to WASM, we will see a shift in focus on JS heavy frameworks, and just people building things instead of fighting and trying to remember all the weird quirks of JavaScript.
Go one step further. The programming model behind Blazor server is criminally under appreciated.
Spa-style interactivity without a need for an API is great.
Optional shared state between clients and effortless push-to-client is… basically magic as far as I’m concerned.
Can you share your experience with other frameworks beside Blazor that you had a good experience with?
I have seen Blazor and it looks good but I have an aversion to anything Microsoft.
LiveView in Phoenix is a similar experience, and I enjoyed (briefly) using it. https://pragmaticstudio.com/ has a good introduction.
Thanks! I took their Ruby and Rails courses and loved it. Great teachers!
I've done web dev with various other frameworks: Django, React (front-end only - no SSR), Vue, CherryPy, and a few others. Blazor is the only technology that allows me to use 1 programming language outside of HTML / CSS. You have component UI libraries like React does, so you have to think less about hand crafting HTML and can focus on per component logic / UI much like when developing with React or any "SPA Framework" out there.
You should try it out; microsoft makes good contributions to open source software, and C# is, in my view, the best (or maybe the only good) backend language put there
How do you do dom manipulation in wasm code?
One of the frontend problems is that too much frontend engineers think a web app should be a single page app. A lot of apps don't need to be that. Server-side endpoints and templating + lightweight vanilla JS and framework-agnostic web components works and is now even easier than ever.
It‘s a kind of collective hallucination. It‘s affected me too.
I just recently decided to go back in time and wrote a web app using Flask, all rendered server side, with a minimum of JS and JSON endpoints for a bit of client-side interactivity (e.g. autocompleting an input field). Very fast, iterative work. No duplication of data classes, no weird caching issues…
Felt like a breath of fresh air, sadly. Have we witnessed a full turn of the wheel?
That's a good old case of "the right tool for the job".
But let's be honest: the frontend dev rat race had the effect to make the base web technologies better. Better CSS (variables, nesting, effects, media support, etc), better JS (webcomponents), useful libs available as wasm and so on... all good things that can be used natively and allow us to make better MPAs.
I've seen so many marketing websites written in React. It's so confusing.
I think most people choose SPAs because they also maintain the frontend state of a an application. If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell. How do you manage the transition between one view and another on the same page? How do you pass state between two pages? I think webcomponents solve some of this but there's a lot of react developers out there who don't have the requisite software engineering skills to handle this
> How do you manage the transition between one view and another on the same page?
HTMX solves this, and it's mostly automatic. You get some nice transitions.
> How do you pass state between two pages?
You don't. You submit some data to the server, it generates HTML dynamically, you replace HTML on the frontend or redirect all together, you're done. The state is on the server.
So then you need some kind of state management on the server?
> So then you need some kind of state management on the server
Yes. You might call this an application, lol. You will require this no matter what, unless you have a fully client-side application. Like photoshop or something.
> If you're just serving templated html from a backend, you're probably also doing vanilla javascript which is it's own kind of hell.
How so ? Vanilla JS has never been easier and more powerful.
> How do you pass state between two pages?
Why is it even considered to be a problem ? This is basic stuff. All web frameworks since the 90s have had this concept of sessions where you can store data that will be available across pages.
Vanilla js is unstructured. It's very easy to write spaghetti code with vanilla js.
Sessions are a kind of global state. I mean temporary state, like when filling out a form and moving from one page to the other, but without submitting the results until the end.
> Vanilla js is unstructured.
Functions, classes, modules... everything is available to organize code. The mess some programmers make can be unstructured, but that's the case with any paradigm and yes, we've seen that with "modern" JS frameworks too. Spaghetti mess, lasagna mess, components mess or whatever pasta mess.
> I mean temporary state
What is the problem here ? It's as temporary as you need it to be.
Temporary state does not need need to be sent to the server, it can be managed in localstorage
clear boundary is good, I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense. They are just shifting complexity from a place they feel uncomfortable, to where they do, but at the cost of destroying their own nirvana. Certainly one way, but hardly the only one.
> I don't understand why people like to trash their back-end with templates, MVC and all the "view" nonsense.
Because the tooling has been here for decades and it works damn fine. No need to trash the frontend with ever changing piles of dependency and build nonsense.
> works damn fine
when? View code in the back-end always looks like crap and never able to achieve the interactivity the front-end can. People wrestling with it was the reason SPA was born. There was no dictator forcing people to move on from such "awesome" working "damn fine" pipelines to modern front-end for no reason.
> View code in the back-end always looks like crap
That's probably the fault of the people writing it. People can also write crap looking code using frameworks too.
> and never able to achieve the interactivity the front-end can.
That's what small sprinkles of javascript is for. You don't need incredibly beautiful interactivity in every pixel.
Commercial-grade applications need some grade of offline operativity that classic HATEOAS can't provide, often target users who won't learn or can't really use a web browser (tabs, back button, extensions, bookmarks besides whatever they can fit in the bar, etc), often want to give a UX which abuses and deforms a web browser by design. Yeah, FE engineers may all look like dumbasses with macbooks (i don't think this of them!), but they have real problems to solve.
Not denying that, but just because I browse the web I'm pretty sure not all websites with "modern" frontend stacks have modern frontend problems.
That's for sure, for example any blog software (a few SSGs included) is a failure for WWW and for itself (most of the interaction between author and reader must be mediated with third-party or big cloud to avoid spam and scam).
I think the churn and misery of front end development is the inevitable result of 30 years of path dependence on technologies that were either substandard to begin with (javascript, css) or were never designed for what they're used for (html, css).
> I am never going back.
For some reason, it sounds like someone being held against their will, which is exactly how I feel about it too
I must be a masochist because I love FE frameworks. I love learning them and comparing them. I love how they are changing all the time and things are always improving somehow. What was great 10 years ago now are ridiculous to think about, What is great now will be completely forgotten in a couple years time. It's beautiful and maddening at the same time.
My favorite stack right now is Astro + SolidJS. Maybe it'll change next week. Who knows?
I don't know if you're a masochist, but I bet you aren't writing large apps. At work, the last thing I want is the technology I'm using to be obsolete in two months.
At my day job, we use something called ClickUp for task tracking. Watching the UI elements load one at a time reminds me of those greybeard stories about using vi over 300 baud modems. ClickUp is supposed to be productivity software.
HTMX pretty much enforces a 'one user action, one HTTP request, one HTTP response' pattern, which is necessary for a usable UX for users who can't see the data centre from their office window.
Like the article's writer, I remember the Netscape days and when JS came into existence. I was only a kid back then, like 9 years old, and was _just_ getting into coding in C and playing around with HTML/CSS. The results I produced, as you might have imagined, were akin to the results a toddler would produce given a wet loaf of bread to play with: mess everywhere.
Anyway, back then the HTML was simple (but it was tables and spacer GIFs ha ha!) and the CSS even simpler. Now it's just such a chaotic mess that people actually think Web Assembley is a good idea; as if somehow they've invented something new: the sandbox and the machine code. Like running a process at the OS level and making _that_ better, more secure, etc. wasn't the right path.
HTMLx is as close to the UI as I'll come. Everything else is an absolute headache to get into.
this ... multiplied by the high exposure of front end devs to client side requests for bells and whistles and the web studio demands on throughput