Show HN: µJS, a 5KB alternative to Htmx and Turbo with zero dependencies

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.

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 :)

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.

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!

  Browser -> your server route -> server calls API -> server renders HTML -> htmx swaps it?

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.

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

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.