[HN Gopher] Show HN: uJS, a 5KB alternative to Htmx and Turbo wi...
___________________________________________________________________
Show HN: uJS, a 5KB alternative to Htmx and Turbo with zero
dependencies
I built uJS because I wanted AJAX navigation without the verbosity
of HTMX or the overhead of Turbo. It intercepts links and form
submissions, fetches pages via AJAX, and swaps fragments of the
DOM. Single <script> tag, one call to `mu.init()`. No build step,
no dependencies. Key features: patch mode (update multiple
fragments in one request), SSE support, DOM morphing via idiomorph,
View Transitions, prefetch on hover, polling, and full HTTP verb
support on any element. At ~5KB gzipped, it's smaller than HTMX
(16KB) and Turbo (25KB), and works with any backend: PHP, Python,
Go, Ruby, whatever. Playground: https://mujs.org/playground
Comparison with HTMX and Turbo: https://mujs.org/comparison About
the project creation, why and when: https://mujs.org/about GitHub:
https://github.com/Digicreon/muJS Happy to discuss the project.
Author : amaury_bouchard
Score : 94 points
Date : 2026-03-07 08:59 UTC (14 hours ago)
(HTM) web link (mujs.org)
(TXT) w3m dump (mujs.org)
| ohghiZai wrote:
| Would love to see a comparison with Datastar too
| amaury_bouchard wrote:
| Thanks for the suggestion! I'm considering adding more
| libraries to the comparison page (Datastar and Unpoly are on my
| radar).
|
| That said, uJS and Datastar have quite different philosophies.
| uJS 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, uJS delivers it.
|
| Datastar is more of a reactive hypermedia framework. It brings
| client-side signals (reactive state in HTML attributes, a 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 uJS 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!
| recursivedoubts wrote:
| heya amaury, great library!
|
| i have added it to the htmx alternatives page:
|
| https://htmx.org/essays/alternatives/#ujs
| tagfowufe wrote:
| Sneaking in real quick to thank you for your contributions and
| positive attitude you bring to the space.
| amaury_bouchard wrote:
| Wow thanks a lot! That's very kind, I really appreciate it :)
| nattaylor wrote:
| 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.
| oso2k wrote:
| This looks interesting. Thanks for sharing.
| ok_dad wrote:
| Yay someone already mentioned my favorite "framework"!
|
| htmz is a masterclass in simplicity. It's gotta be the all time
| code golf winner.
| majorchord wrote:
| https://sfconservancy.org/GiveUpGitHub/
| networked wrote:
| 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.
| majorchord wrote:
| Hard disagree, multiple forges does not solve the problem of
| being unable to opt-out of AI training from your code.
| networked wrote:
| 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.
| hombre_fatal wrote:
| 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.
| satvikpendem wrote:
| If your code is in any way public, it will be trained on.
| That ship has already sailed.
| ranger_danger wrote:
| 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.
| WesolyKubeczek wrote:
| 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.
| williamcotton wrote:
| Browser -> your server route -> server calls API -> server
| renders HTML -> htmx swaps it?
| scuff3d wrote:
| 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.
| gaigalas wrote:
| 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.
| 0x20cowboy wrote:
| 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
| oso2k wrote:
| 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.
| amaury_bouchard wrote:
| Thanks for the list! Yes, the name is used by several projects.
| Mine is the browser navigation one -- hopefully the "uJS" name,
| the .org domain and the use case make it distinct enough.
| pwdisswordfishy wrote:
| Not to be confused with https://mujs.com/ I guess?
| lioeters wrote:
| 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.
| heddycrow wrote:
| 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.
| amaury_bouchard wrote:
| I haven't tried it personally, but I don't see any reason why
| they wouldn't work well together. uJS 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 uJS
| 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!
| captn3m0 wrote:
| I'd like to see a comparison with pjax as well:
| https://github.com/defunkt/jquery-pjax
| amaury_bouchard wrote:
| 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. uJS is dependency-free and covers a much
| broader feature set.
| josephernest wrote:
| 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!
| scuff3d wrote:
| 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.
___________________________________________________________________
(page generated 2026-03-07 23:00 UTC)