I built J-CSS, a small runtime engine for Tailwind-like utility classes.

It requires no Node.js, CLI, bundler, or build step. It scans the DOM, generates CSS for recognized classes, and watches class/DOM mutations. Works out of the box with HTML injected by HTMX.

It also has a scoped <css> tag that lets you apply utility classes to component selectors without putting every class directly in the markup.

The minified script is about 16 KB gzip (roughly 7.5x smaller than the Tailwind CDN runtime).

https://github.com/Jipok/jcss

Made from Moxi's implementation of relative selectors. Moxi's proxy handling was causing some friction with my other JS functions. I wanted selectors that I could use anywhere even without Moxi.

Note that q will always try to grab the element context, but can also take a supplied context. Has quick alias for doc = document and .ael = .addEventListener

With it you can do goofy stuff like this:

<input oninput="inputfunc()">
<button onclick="console.log(q().textContent) //starting context is mybutton">mybutton</button>
<button>otherbutton</button>
<script>
    function inputfunc() {console.log(q())} //context is input
    q('prev sib -> prev sib').classList.add('ready') //starting context is script then traverse to mybutton
    q('prev sib').ael('click',_=>{console.log(q().textContent)}) //function context in listener is otherbutton
</script>
//This is why it's important to manually set context to `doc` if you want to select/traverse on the document.

Code is here (only first 40 lines of code): https://github.com/figuerom16/fixi/blob/master/mofix.js

Copy out the code you want. I'm too lazy to split the library up / don't want to maintain copies.

Documentation for q() and qa() is at the start of: https://github.com/figuerom16/fixi/blob/master/mods.md

Maybe Nintendo would be willing to offer you their legal team.

Two years ago I started an open-source project named Lamx - for Laravel + htmx integration - but the project was inactive for a looong time.

I want to resurrect it! Who is interested?

The goal of the project was to have components similar to Livewire, but with htmx.

It makes the worst part of hypermedia driven development , being bigger bandwidth use and bigger cpu use when compressing things with gzip or brotli, even worse. and this isn't even a "this goes agaisn't the design" or a "this isn't ergonomic" thing; it's just pure resource usage.

Tailwind output is 7x bigger than non tailwind html or json output.

Even trought the tailwind output is "only" 50% bigger than the json/normal html one when compressed, the raw output is 950kb, more than 7 times the json/html alternative, meaning it uses way more cpu power/takes longer to compress.

For many situations it makes way more sense to just have defined styles with elements having classes (or not even having them when selectors can do the job)

bandwidth usually has three prices:
First, the monetary one; on vercel, 100 gb costs 15 dollars, on aws it is 9 dollars, on oracle ,0.85 cents.

Second, ecological one;Even when you aren't paying it (eg project still within free limit) there's always infraestructure behind your stuff, and it is preferable that we don't throw resources away.

And third but not last, user experience; bigger files take longer to download and decompress,trought this should be impossible to notice on anything that isn't a slow mobile network, you probably expect your site to also be used by people in slow mobile networks.

Yes, you probably won't have 1000 things appearing at once for your user, but tailwind uses so much more resources than needed that it might as well use 1000 times more bandwidth.

PS: Of course you can just choose to pay the tailwind tax or just not think about such things if you're not developing something that is not supposed to be used by thousands of people at once. There's no reason to police what other people are doing with their own money. Still, i think it is important to keep the drawbacks of using these libraries with one another in mind when developing your applications.

Carried out by all kinds of 'stacks' lately i read, I’m proud (not) to announce a simple static stack suited for creatives:

- a HHTAG stack!

This stands for: HTML, HTMX, Tailwind, Alpinejs and GSAP.

When you know how to design by default and without a component library or a CSS framework and you can do everything vanilla, using hosting on platforms like Cloudflare Pages, this stack works like a kickstart-on-2T-motorcycle charm.

Please note: this is not an app driven approach but more creative ux/ui/fe one.

*

ps: satire use to be a joy, then came js framworks, bootcamps and covid .. now we have specialists everywhere

Before I started using this stack, I used Sveltekit and found it too complex. I also got quite tired of writing js/ts. I Find the language quite nuanced and hard for me to work with. I guess I did not learn it good enough. I felt I could not continue writing js/ts so I tried Go+HTMX and later added Alpine,js. I quite enjoy the stack because it is simple and easy to learn, and I do not have to do as much js ;)

It is quite enjoyable to use HTMX in the frontend, so one can focus on writing code in the backend (which I enjoy more). I used HTMX with go lang's html/template and it worked quite well. In Sveltekit, the inheritence of all the layouts and pages can become quite complicated and structure feel scattered. It is rather hard to understand the data flow between the layouts and pages. With HTMX+html/template everything feels more focused towards backend, which I enjoy.

I used the stack to create an app. I wanted to start with a small project:

https://finalfantasy6pixelremastercoliseum.com/

which let users check info about items from a game. I wanted the app to be easy to use and compact. When user clicked on something or made a search, I used HTMX to update other parts of the html code, which worked quite well. In sveltekit you have to create runes and depending on when things should be initialized and how the runes depend on other runes, you have to write different functions to update the ui. This I found quite complicated, but in HTMX you just send back and html server response of how you want the html to be. Together with go lang's templating system you can write less code I think.

My takes:

• Around 353 lines of go code and less than 250 lines of template html.
• HTMX is simple to learn and get started in creating something fast
• It can get little complicated of you want to update html from different parts of a template, like if you have 2 divs placed far from each other and have stuff in between them (that you do not want to update). You will probably have to use hx-swap-oob

Made this after getting and reading through a third of Hypermedia Systems, it's a simple chat room where you can post your status and see what others are posting in random spots across a board.

The more participation, the more true to form it will function. Give it a try if you have a sec.

Conclusion first: HTMX is VERY production ready for a large-scaled project. And thankfully I ditched Vue.js 2/3 and Svelte 4 for HTMX. (Never used React though.)

I literally cried when HTMX mentioned they’re trying to be the next jQuery, that might not need to change for the next decade.

In the AI era, adding features becomes easy, but people just don’t know how to make things simple and “just work.” I really hope HTMX stays this way. (please u/_htmx 😭🙏)

The startup is basically an old Twitter clone, from when social media felt friendlier and the web didn’t feel like a bunch of boring mobile apps. Sorry for the mixed-language screenshots, I hadn’t finished internationalization yet.

Here are a few of my experiences with HTMX:

1. Make the website stupid and just make it work

We don’t use a cool dialog library like SweetAlert.js. The native alert(), confirm(), and prompt() just work. With hx-confirm, it’s even simpler.

If you need a form, just use <form>, and refresh the whole page if you can (or hx-post if you don’t want to), so you don’t have to worry about partial updates or syncing what changed.

2. We don’t use Alpine.js

It’s a very good solution if you want some hybrid JS, but it reintroduced the state management problem.

We had server-rendered JSON inside <script type="application/json"> so Alpine.js could load the data back. It worked, but caused some flickering since Alpine runs after the page is rendered, and introduced another state we had to manage.

so we decided to keep everything server-side rendered. (yea, fuck the network latency 🥳🎉)

We took this pretty far. When you upload photos in a post creation form, normally you’d just spawn the previews with JavaScript. Instead, we turn the images into blob URLs, pass those URLs to the server, and the server returns something like:

<div class="photo-preview">
    <img src="{{ .ImageURL }}">
</div>

So when the user edits the post later, we can render the exact same “photo preview” component on the server. One component, one rendering path.

ℹ️ But there are also things you can just ditch.
.　
We had a post poll where you could use +/- buttons to add or remove option inputs with Alpine.js. Turns out we only support up to 4 options anyway, so we ditched the +/- JS and just put 4 fixed text inputs in the poll form.
.　
Now we can render the option text directly into the inputs, instead of outputting it as JSON in a <script> for Alpine.js to load back into them when user is editing the poll.

It sounds stupid. That’s kind of the point. You sacrifice some UX (user experience), but get much better DX (developer experience).

3. We don’t use Templ or framework with HTMX with Go

Since Templ requires build-tools, learning special syntax, IDE extensions, we decided to just use Go’s html/template and split the HTML into layouts, pages, and partials. The definitions look roughly like this:

type AppLayout struct {
    Navbar *Navbar
}

type ProfilePage struct {
    *AppLayout
    User         *User
    FollowButton *FollowButton
}

type FollowButton struct {
    IsFollowing bool
}

Then compose the data in the page handler:

user, err := db.GetUser(c.Param("username"))
if err != nil {
    return c.Abort(http.StatusInternalServerError)
}

layout := &AppLayout{
    Navbar: NewNavbar(),
}

// Tada- now you have a full page! 🎉
page := &ProfilePage{
    AppLayout:    layout,
    User:         NewUser(user),
    FollowButton: NewFollowButton(user.IsFollowing),
}

And if you want to render the Follow Button component:

{{ template "follow_button" .FollowButton }}

Since AI can write the boilerplate now, code can be stupid and boring, but easy to debug. And with HTMX, you can just return any partial when needed.

There’s no "runtime magic" to trace if error occurred, back when Vue.js + hot reload pointing stack traces to some generated chunks.js instead of the actual code.

The appeal for me is:

• PHP remains the backend and renders HTML
• HTMX handles partial page updates/AJAX
• Alpine.js handles small client-side interactions
• No React/Next.js application required
• No npm install, bundler, Node server, etc.
• Can deploy directly to normal PHP/shared hosting

I've been feeling nostalgic lately for the days before AI, back when building a simple TODO app was a genuine joy, a way to explore a new stack, and a way to relieve fatigue.

HTMX was one of those libraries for me.

Does anyone else miss that hands-on discovery phase?

I really enjoy htmx, and using it without any type of lsp features is fine. however, it would still be better to have such.

I use neovim with the lazyvim distribution/setup, and the htmx lsp made by Primeagem (and available in mason) makes my html code completion stuff just not work anymore; other lsps seem to also just not work.

Anyone here got a working setup? i already posted about this in the neovim sub a while ago, but i figure it makes sense to post it here too.

edit: got an lsp working

Another talk from BSDC

I wrote this for the Staffbase dev blog. In the second half of the article, I talk about some work I did to use HTMX to embed "sandboxed" applications inside intranet content. To do this, I have some code that "neuters" HTML being returned from HTMX to prevent it -- HTML or script -- from "leaking" outside the original container.

I show an example of a small app to track the International Space Stations and ask an AI chatbot some questions about it.

You might find it interesting. I think it's a neat use of HTMX.

Gameplay starts a 2min