I'm curious to understand, why would you build your website this way vs. say jQuery. I've never really understood the HTMX ecosystem. Is this just to avoid javascript and replace that with html pages, id's and attributes? It feels like the DOM is a very clear abstraction and scripting is a more powerful way to manipulate it. What do people like or prefer about this approach and paradigm?
What's the best way to handle having multiple frontend components respond to events from a single SSE connection from some parent node data provider? Ideally we do not what many SSE connections within a page for each component.. right? Then what's the best practice to handle that single SSE handler on the server and frontend? If that makes sense...
Nice project, always interesting to see HTMX-inspired frameworks.
If you want something even more minimalistic, I did Swap.js:
100 lines of code, handles AJAX navigation, browser history, custom listeners when
parts of DOM are swapped, etc.
Thanks for the list! Yes, the name is used by several projects. Mine is the browser navigation one — hopefully the "µJS" name, the .org domain and the use case make it distinct enough.
I haven't tried it personally, but I don't see any reason why they wouldn't work well together. µJS manipulates the DOM via fetch and swapping, while web components live in the DOM like any other element. The only thing to be aware of is that if µJS replaces a fragment containing a web component, connectedCallback will fire again, which is the expected behavior. Would love to hear your feedback if you give it a try!
pjax is actually listed as an inspiration in the README. It's a great project, but it hasn't been maintained since 2018 and requires jQuery. µJS is dependency-free and covers a much broader feature set.
Looks useful! I skimmed through the docs and had a question.
Is there a mechanism for loading HTML partials that require additional style or script file? And possibly a way to trigger a JS action when loaded? For example, loading an image gallery.
Thanks for the suggestion! I'm considering adding more libraries to the comparison page (Datastar and Unpoly are on my radar).
That said, µJS and Datastar have quite different philosophies. µJS is a lightweight AJAX navigation library (~5 KB); it intercepts links and forms, swaps fragments, and stays out of your way. There's no client-side state: your server renders HTML, µJS delivers it.
Datastar is more of a reactive hypermedia framework. It brings client-side signals (reactive state in HTML attributes, à la Alpine.js) and uses SSE as its primary transport: the server pushes updates rather than the client fetching them. It's a different mental model: Datastar manages state and reactivity, while µJS is purely about navigation and content replacement.
Both are small, zero-build-step, and attribute-driven, so the comparison is definitely interesting. I'll look into adding it!
I don't do a lot of frontend work, but I'm glad to see more of this stuff popping up. Anything that combats the normal framework insanity is a good thing in my book. And this looks like a really cool idea. The default routing approach is an awesome idea, swapping the entire body by default is also really interesting. It seemed odd to me at first, but the more I thought about it the more it made sense.
Not exactly what you’re saying, but a bit closer. With this library you set what css classes on the page are “hot”, it fetches the next page state and replaces that part of the page with the new state: https://github.com/robrohan/diffy
Does it automatically parse JSON responses from servers into objects? This is my one big gripe about htmx, even though the devs and other users keep telling me I shouldn't want that as a feature and that it "doesn't make sense".
Sorry if I need to use existing APIs I cannot change.
They're right through, the entire point of HTMX is to use "HTML as the Engine of Application State". Shipping JSON to the front end to be rednered is antithetical to that.
As someone else mentioned, having your own server backend act as an intermediary between your front end and the API that serves JSON is probably the most straightforward solution to keep everything HTMX-y.
I came to a conclusion that when you have an SPA with JSON-spitting backend where you cannot make the backend spit out chunks of HTML, htmx and similar libraries/frameworks are not suitable. They are suitable if you already have a multi-page application like we used to in 2006, or if you design it from the ground up.
This is bad advice to a new FLOSS project that wants to have users. Avoiding GitHub with its user base (meaning issues and discussions), search, project topics (tags), trending repository lists, etc. will make a fledgling project even less likely to gain adoption.
A better thing to suggest is to use multiple forges, including GitHub, and mirror your projects across them. This way you will have exposure and options; you won't be as tied to any one forge.
If that is your problem with GitHub, then I agree, you should avoid GitHub, though someone can still mirror your repository there. I assume most new FLOSS projects that want to have users don't consider it a dealbreaker.
If your problem is with your code appearing in training data, then you cannot release your code anywhere.
That link you provided only points out GitHub has integrated "create pull request with Copilot" that you can't opt out of. Since anyone can create a pull request with any agent, and probably is, that's a pretty dated complaint.
Frankly not very compelling reasons to ditch the most popular forge if you value other people using/contributing to your project at all.
I'm curious to understand, why would you build your website this way vs. say jQuery. I've never really understood the HTMX ecosystem. Is this just to avoid javascript and replace that with html pages, id's and attributes? It feels like the DOM is a very clear abstraction and scripting is a more powerful way to manipulate it. What do people like or prefer about this approach and paradigm?
What's the best way to handle having multiple frontend components respond to events from a single SSE connection from some parent node data provider? Ideally we do not what many SSE connections within a page for each component.. right? Then what's the best practice to handle that single SSE handler on the server and frontend? If that makes sense...
Reminds me a little of htmz
htmz is a minimalist HTML microframework for creating interactive and modular web user interfaces with the familiar simplicity of plain HTML.
Yay someone already mentioned my favorite “framework”!
htmz is a masterclass in simplicity. It’s gotta be the all time code golf winner.
This looks interesting. Thanks for sharing.
heya amaury, great library!
i have added it to the htmx alternatives page:
https://htmx.org/essays/alternatives/#ujs
Sneaking in real quick to thank you for your contributions and positive attitude you bring to the space.
Wow thanks a lot! That's very kind, I really appreciate it :)
Nice project, always interesting to see HTMX-inspired frameworks.
If you want something even more minimalistic, I did Swap.js: 100 lines of code, handles AJAX navigation, browser history, custom listeners when parts of DOM are swapped, etc.
https://github.com/josephernest/Swap.js
Using it for a few production products and it works quite well!
There’s several other (well) known examples of the use of mujs.
There’s Artifex’s interpreter from muPDF. It’s also the basis of several JS related projects: https://mujs.com/
There’s also a lesser known interpreter: https://github.com/ccxvii/mujs
And IIRC, there was a CommonJS library of the same name.
Thanks for the list! Yes, the name is used by several projects. Mine is the browser navigation one — hopefully the "µJS" name, the .org domain and the use case make it distinct enough.
It's about time browsers start supporting something like this natively. Fingers crossed.
I'll be checking this out. Any chance you (or anyone) has had a run with this lib + web components? I'd love to hear about it.
I haven't tried it personally, but I don't see any reason why they wouldn't work well together. µJS manipulates the DOM via fetch and swapping, while web components live in the DOM like any other element. The only thing to be aware of is that if µJS replaces a fragment containing a web component, connectedCallback will fire again, which is the expected behavior. Would love to hear your feedback if you give it a try!
I’d like to see a comparison with pjax as well: https://github.com/defunkt/jquery-pjax
pjax is actually listed as an inspiration in the README. It's a great project, but it hasn't been maintained since 2018 and requires jQuery. µJS is dependency-free and covers a much broader feature set.
Looks useful! I skimmed through the docs and had a question.
Is there a mechanism for loading HTML partials that require additional style or script file? And possibly a way to trigger a JS action when loaded? For example, loading an image gallery.
Would love to see a comparison with Datastar too
Thanks for the suggestion! I'm considering adding more libraries to the comparison page (Datastar and Unpoly are on my radar).
That said, µJS and Datastar have quite different philosophies. µJS is a lightweight AJAX navigation library (~5 KB); it intercepts links and forms, swaps fragments, and stays out of your way. There's no client-side state: your server renders HTML, µJS delivers it.
Datastar is more of a reactive hypermedia framework. It brings client-side signals (reactive state in HTML attributes, à la Alpine.js) and uses SSE as its primary transport: the server pushes updates rather than the client fetching them. It's a different mental model: Datastar manages state and reactivity, while µJS is purely about navigation and content replacement.
Both are small, zero-build-step, and attribute-driven, so the comparison is definitely interesting. I'll look into adding it!
I don't do a lot of frontend work, but I'm glad to see more of this stuff popping up. Anything that combats the normal framework insanity is a good thing in my book. And this looks like a really cool idea. The default routing approach is an awesome idea, swapping the entire body by default is also really interesting. It seemed odd to me at first, but the more I thought about it the more it made sense.
Not to be confused with https://mujs.com/ I guess?
I like the idea. DOM morphing is nice.
I've done this previously with morphdom to AJAXify a purely server-driven backoffice system in a company.
I would love something even smaller. No `mu-` attributes (just rely on `id`, `href`, `rel`, `rev` and standard HTML semantics).
There's a nice `resource` attribute in RDFa which makes a lot of sense for these kinds of things: https://www.w3.org/TR/rdfa-lite/#h-resource
Overall, I think old 2015-era microdata like RDFa and this approach would work very well. Instead of reinventing attributes, using a standard.
Not exactly what you’re saying, but a bit closer. With this library you set what css classes on the page are “hot”, it fetches the next page state and replaces that part of the page with the new state: https://github.com/robrohan/diffy
Does it automatically parse JSON responses from servers into objects? This is my one big gripe about htmx, even though the devs and other users keep telling me I shouldn't want that as a feature and that it "doesn't make sense".
Sorry if I need to use existing APIs I cannot change.
They're right through, the entire point of HTMX is to use "HTML as the Engine of Application State". Shipping JSON to the front end to be rednered is antithetical to that.
As someone else mentioned, having your own server backend act as an intermediary between your front end and the API that serves JSON is probably the most straightforward solution to keep everything HTMX-y.
I came to a conclusion that when you have an SPA with JSON-spitting backend where you cannot make the backend spit out chunks of HTML, htmx and similar libraries/frameworks are not suitable. They are suitable if you already have a multi-page application like we used to in 2006, or if you design it from the ground up.
https://sfconservancy.org/GiveUpGitHub/
This is bad advice to a new FLOSS project that wants to have users. Avoiding GitHub with its user base (meaning issues and discussions), search, project topics (tags), trending repository lists, etc. will make a fledgling project even less likely to gain adoption.
A better thing to suggest is to use multiple forges, including GitHub, and mirror your projects across them. This way you will have exposure and options; you won't be as tied to any one forge.
Hard disagree, multiple forges does not solve the problem of being unable to opt-out of AI training from your code.
If your code is in any way public, it will be trained on. That ship has already sailed.
If that is your problem with GitHub, then I agree, you should avoid GitHub, though someone can still mirror your repository there. I assume most new FLOSS projects that want to have users don't consider it a dealbreaker.
If your problem is with your code appearing in training data, then you cannot release your code anywhere.
That link you provided only points out GitHub has integrated "create pull request with Copilot" that you can't opt out of. Since anyone can create a pull request with any agent, and probably is, that's a pretty dated complaint.
Frankly not very compelling reasons to ditch the most popular forge if you value other people using/contributing to your project at all.