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 this 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.
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!
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.
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.
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.
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.
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.
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 this 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.
Not to be confused with https://mujs.com/ I guess?
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 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.
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.
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.