I've always been a fan and supporter of HTMX, but lately I've wondered how beneficial it is now that LLMs can generate JavaScript for us. HTMX was especially useful when I wrote JavaScript by hand because I appreciated its higher level of abstraction and simplicity. I also struggled to make it work with AlpineJS and eventually had to resort to plain JavaScript, which gave me finer control. Normally, switching to JavaScript would have been a hassle but since an LLM can produce it as easily as any other text, I’m less clear on HTMX’s advantage. I’ve been getting along fine without it. If computers didn’t write code for us, I would still choose HTMX, but now I find it hard to justify the trade‑off.
There's definitely something to this: I expect LLMs to hurt the adoption of htmx and most smaller web libraries. That's fine: it's always been a labor of love and is BSD 0, so I hope the ideas are interesting and that the people who decide to use it enjoy it.
I think, at least for the next few years, certain preferences and consensuses were accidentally embedded in the models to your benefit.
They love htmx! Claude will independently suggest using it instead of more general js frameworks for smaller projects. A gpt model told me, and I wrote this down because it was striking, "htmx won the argument it was making."
It's the same thing with rust. I'm an ocaml expert and ocaml genuinely fits a lot of the problems I work with better regardless of that. But because of when the models were trained and what they were trained on, a certain sort of alt-consensus opinion is frozen into them, and it believes rust is a better choice for nearly everything!
I think you're good for the next few years at least. It's an open question what happens after that dead internet theory recursive loop of llms trained on llm output etc so who knows you might be good forever.
We will see. Changing things around a bit (especially flipping attribute inheritance to explicit by default) may confuse a lot of models. Oh well, it's the right thing ¯\_(ツ)_/¯
Please don’t misunderstand my comment, I wasn't trying to diminish the brilliant work you’ve done on HTMX, which I’ve personally benefited from. I could have probably worded it better than I did. I'm also not saying you _did_ misunderstand it, only asking that you please don't. I was just sharing an observation that I realize is not everyone’s experience. I’m still a fan + supporter, even though I now reach for JS more often because the pain of writing it has largely disappeared. I’m still not a fan of it by any means, but LLMs have been a major mitigator. I'm always happy to see the HTMX updates when they come out.
It may do the opposite! My sense of LLMs is that simplicity beats training.
If you have 1/5th the context to consume, that's going to generate better code than the comparable typescript, even if the language is an esoteric one.
I've yet to see anyone try to finetune one of these qwen models on a specific framework, but if you guys care, qwen3.5-35B-A3B is rather fast and reliable for a lot of what I'd call "copy/paste" task and might be worth while to see if a fine tune could excel at HTMX universe tasks.
By default LLMs will start creating a tangled hard to test mess of javascript. But if you ask them to do TDD they will, and if you give them access to Playwright and have them write playwright tests this can all work.
The advantage for the LLM is the same for humans. With the right abstractions, code can be written quicker and more robustly.
To get more hands off with LLMS you really want to have a lot of engineering rigor. A big part of that is a focus on tests. If your abstractions make testing easier, your results will be a lot better. For Javascript the more you can test logic without DOM manipulation and without playwright tests, the better.
I found LLMs to be default to and be pretty good at working with HTMX, but not great (mostly lots of state synchronization issues). The focus on DOM markup of HTMX does not lend itself well to simplifying testing. I don't claim to be an expert at HTMX, but I don't see a separate section on testing in their documentation.
I am trying out the foldkit framework because it makes a lot more testable outside the DOM. Its probably too heavy weight for most humans (and for simple apps- it only seems appropriate for client-side apps), but I will see how well LLMs can work with it.
The main issue HTMX address is reducing complexity and LLMs doesn't solve it.
I'd expect it to be the other way around: LLMs will increase HTMX(and similar solutions) adoption because alongside of being excellent at writing HTMX there are also excellent writing web components.
React, vue and similar still have their use case, but htmx + web components can drive you really far.
I recently used Alpine.js (client-side, I know), and, as a person that does backend most of the time and is not super knowledgeable in frontend, I was amazed.
I think that, combined with Htmx it can be a really powerful thing for lots of deployments (basically most things that do not need API/Json talking).
Depends how you set it up. Like any other project I guess. Funny enough, if you are able to produce maintainable code with an llm you could aswell lead a team of humans. LLMs shift your focus on project management and architectural choices.
I let the llm write components which are independent to each other. This works great and keeps everything clean. The times that llm would only generate unmaintainable code are long gone with OPUS, Fable and sol 5.6
> LLMs shift your focus on project management and architectural choices.
And a comfortable sense of short term productivity that make you tend to ignore the middle and long-term trade-offs.
It is unmaintainable unless you create a very modular architecture (read here: modules written by LLMs that will not get in the middle of others bc of their extra fat).
And even with a modular architecture, I am not convinced.
However I had a couple of success stories in the generative area, maybe bc I am so stupid that I do not detect the problems: SQL query/code generation and frontend Alpine.js-based for a small website.
Also good for one-off scripts.
But when it is about a project where you iterate for weeks, things get out of hand.
As a powerful search engine, exploring alternative solutions or doing code review, great. But the reason is not that it is extremely good at it. It is bc it is extremely fast at it and it is easy to recognize bogus stuff if you have been doing this for many years, so it saves you time. But still gives you inaccurate stuff.
It's hard to answer because I don't personally use HTMX as a way to avoid Javascript. HTMX is a Javascript library. And I don't know if I even find using HTMX easier/harder than writing JS, because they are fundamentally different approaches to building apps. It really just depends on what I'm trying to do.
One is a programming language used for writing client side code, and the other is a minimal library that makes server sent documents more ergonomic. Yes, it's a JS library with a few nice conveniences, but the main draw of HTMX encourages a completely different app architecture than what the average dev would arrive at with plain JS.
They're just two different things to me, and so it seems irrelevant if LLMs can help you write one faster. If you're only using HTMX to avoid JS, I don't see how LLMs discourage you from doing that. Wouldn't it be better to vibecode something you have an easier time reading than vibecode a language you don't even understand enough to use? What are you going to do if it blows up?
The last time I made a website about a year ago, Gemini used HTMX. It was actually my first experience with HTMX, so in a way, LLMs led to me adopting it. :D
apologies, i thought you were saying you were switching to SPAs because LLMs understand it better. I see some version of that comment nearly daily now. Carry on!
Not in those words, but the decision did give absolute immunity from criminal prosecution and civil damage suits for all core official acts and presumptive immunity for all acts "performed within the outer perimiter of his official responsibility". It also severely restricted the ability to gather evidence for acts that do not fall within this scope.
This is extremely broad, and not unreasonable to summarize as the president being able to do whatever they want without fear of criminal/civil consequences.
Suggesting that everyone should read the 120 page, highly technical decision and come to their own conclusions is not helpful.
A lot of what the President does is ineffectual. And this is speaking with generality, including Presidents Obama, Biden, Clinton, et. al.
The modern method of "ruling by Executive Order/Action" is a clever political ruse. It garners a lot of attention to decree an EO on some wedge issue, doesn't it? It stirs the pot quite effectively, even if the EO isn't, in fact, effective to do anything at all.
Ruling by EO is a way to keep campaign promises. It's a way to assuage constituents and donors and benefactors, "hey, I'm doing what you wanted from me!" and it's a way to keep ahold of the narrative. What it isn't, is effective governance. The USA is not ruled by decree. The EOs, if they are on subjects that are normally the remit of the judicial or legislative branch, may not do much, if anything at all. The President can say he's meddling with the national budget; the media can say he's meddling; the citizens can all complain that he's meddling, but only Congress can actually do budgetary things. The "#nokings" protests are attacking a straw man, because the USA has no king indeed. We uphold the Constitution in this house.
A lot of EOs simply get blocked or countermanded or never take effect, and remain as Presidential Suggestions or Presidential Wishful Thinking entirely. And nobody notices when they fizzle: they only notice when the pen hits paper and they supposedly take effect. They fulfill his promises. They galvanize the base. They assuage benefactors.
Don't be fooled, though. Ruling by EO is simply another layer of lawfare. It's not effective governance and it's not intended to be. It's intended to confuse and beguile you. What is it that Sun Tzu and Saul Alinsky said about having power? Check on that first.
Interesting. I wonder how those who were laid off by the Government feel about this. Or those who are harmed by ICE Agents. Maybe those who are stuck in limbo because their visas aren’t going to be renewed.
You’re point about /effective/ governance makes sense. To that I agree, often the EOs are overturned or have little affect.
However, the damage EOs cause is very real, lasting, and can be disastrous. For example Trumps tariffs, while ineffective at their (stated) goal, were eventually overturned. But the damage they caused will be very long lasting. Supply chains are organic, they respond to outside forces, when those forces cause them to shift and change. Rarely do they on their own shift back.
It's the other way around for me: as 99% of the stuff I develop is .NET (and I use EF Core for database stuff), I can get away with SQLite for local development, prototyping (and even staging), and then just "flip a switch" for it to run on production PostgreSQL.
I can't recommend this "switch". If you are not testing locally with the same relational database as in production, you can miss mistakes and bugs. This is not just theoretical. One example where I thought I will be fine using SQLite was with a small Django project. But time and time again I ran into limitations of either SQLite or Django's database adapter for SQLite, when it came to dealing with many to many relationships in the model and through tables, requiring me to work around the limitations. There is no guarantee, that these workarounds in turn will work the same in PostgreSQL in production.
Anyway, it is a basic practice of keeping test and dev environment as close as feasible to production, to avoid missing issues and wrong assumptions.
> Anyway, it is a basic practice of keeping test and dev environment as close as feasible to production, to avoid missing issues and wrong assumptions.
Containers are great for this during development.
Testcontainers are great for tests in particular when you don't want to use some mocked in-memory DB because those have the same issues as using a different DB during development: https://testcontainers.com/
Agreed, and it is easy to have a Postgres container for local tests or in CI as well. I don't really see much need to avoid Postgres in testing. Also if production runs in containers, testing can and probably should just run in containers as well. Also makes for a cleaner test setup usually.
That's kind of risky considering the radical differences between types in SQLite and Postgres. There are plenty of situations where EF will need to be configured differently in order to map your .Net types correctly to each DB. Or subtle differences in behavior due to storage differences (particularly SQLite's predilection for storing things as strings). It's so trivially easy to run Postgres in Docker that I don't really see the advantage of using SQLite for local dev.
Yeah this really isn't so true anymore. I was a diehard Dapper fan for a long time, but the performance of EF Core is comparable to Dapper now. Dropping down to SQL in EF Core is super easy and parameterized. I just don't even bother with Dapper anymore. I have an app with ~200k users with the slowest query being ~6ms and of 1000s of queries only 3 are hand rolled complicated SQL written for perf executed via EF Core.
if you knew how to cook it, you could use make older EF Core (and original EF) go brrr. you sound like you do know. my problem is that it is hard to find out what exactly is the best without dropping down several abstraction layers, sometimes, as you noted, to raw SQL.
why not just construct SQL queries in a type-safe DSL, like, say, JetBrains Exposed does? you are writing what's basically SQL that your compiler understands and your existing tooling checks for free. (granted, C# may need an additional Roslyn analyzer, but it's still simpler than either guessing what transaction LINQ will make or writing SQL in strings.)
Yes, especially for a web app where there’s realistically only a need for one VM/server. By the time you outgrow that approach, a very straightforward migration to Postgres is probably the least complex problem you face.
I made it specifically to bring back what was amazing about the old internet, and do it as authentically as possible. takes inspiration from old internet messageboards, usenet, bbs, and pubnix hosts. it has sealed mail, boards, an rss reader, built-in media player, custom profiles, a links directory, and quite a bit more.
it's just a little hobby art project for me but i've really appreciated talking to like minded people in a calm space.
I just registered, this is such a delight! I love the auto dithering for the profile pics & that you can select a file for your profile music. I'm building in an adjacent space (slow-web, your house on the internet), let's be friends. Hell, let's be BEST friends!!!
Haha that's awesome. Would love to hear more about your project. Share it on the boards if you want, I bet others would be interested too and you may be able to pick up a few new users! Hit me up anyway, always happen to swap notes, thanks for stopping by to check it out :]
Thank you! That's the idea, and even though its been a slow burn, the conversations have been interesting and rewarding. One of the funniest proof of concept so far was, someone asked how to route a guitar body to fit a new bridge on a network with maybe a dozen active people at the time. Within like a day, a total stranger with an actual woodshop and eight spare guitars showed up with real technical advice and offered him a discount on one of the guitars. Maybe it was a fluke, but it really struck me, and there have been a number of small interactions since that one that really remind me why I loved the early web so much.
Awesome, looking forward to seeing you on the boards. Yeah, we have a decent little group of active posters and we've been adding to that number slowly but consistently since I put it online a few weeks ago.
It's been fun and I've learned starting a community is a lot harder than it looks. Maybe I'll write a post on what I've learned sometime. TLDR and probably no surprise to most: making the software is the easy part.
I have a robust set of moderation tools built into the network and I check it several times per day. There is nothing automated setup yet because I don't need it. We have just under 200 members at the moment so this is working well. If the growth of the network ever outstrips my ability to moderate it effectively then I'll look at introducing new methods. So far, I've only had to delete 1 wall post and 1 thread, so it's very manageable.
I think it does. I know this is through Microsoft, but they give you a month free of Cowork which is currently Opus 4.8 (or at least they did for us) and I doubt we'd ever go back. When I say "we" it's the enterprise organisation "we", but this also where this sort of spending won't stop anyone. I can't go into exact details, but if our first month had not been free, then our most expensive user would've hit around $1000, while our average (among users who've adopted it and actually use it) is around $100. Neither of those numbers would matter in a budget.
I've had the pleasure of setting up limits because Microsoft needed billing policies before our C-levels have even gotten it on their agenda. So I set up a sort of conservative $200 personal limit, but then setup a $1m shared limit pool that anyone can be moved into with management approval. I suspect our limits will be much higher than this once the C-levels make the decision on an actual company policy. I think we'll see these spending limits mainly used as guardrails to prevent accidental spending, but that there will not really be a ceiling, just some approval gates. Some managers are already requesting usage reports, but not to track spending, they want to see who uses too little AI.
This is the difference between enterprise and small companies and individuals. When you spend $500k a month keeping your toilets stacked with papertowels, toiletpaper, soap etc. then $1m a month on AI isn't going to raise any eyebrows.
Your most expensive users consuming $1,000 dollars a month doesn't matter in the budget? That seems like FOMO activity or something, I feel like even big teams require proof of ROI for an investment like that (1M). BTW, the ROI of toilet paper + soap is pretty easy to prove (you GET to have employees if you provide those two things).
FWIW we are a smaller company and we had a user run through 500$ in a DAY. Had to put a stop to that. I'm hopeful that our company gets better at asking what the ROI is, what is being built, how much time is it taking, etc... It's no big deal when it's 20 / 100$ a month - but if the prices end up higher we will need to start seeing some returns other than "I feel faster".
> Your most expensive users consuming $1,000 dollars a month doesn't matter in the budget?
An average employee cost around $30000 a month in my country. So it would be 3.3% in the budget for this single employee. I looked up average cost on a company our size and an IT budget of 5mil in Microsoft expences, and a max AI spending limit on 150k across the organisation would be a 5% increase of the IT budget on Microsoft services. Please note that these numbers are not ours, but averages from organisations in my area of the world.
Now I can say that the IT budget is one of the smaller budgets in non-tech enterprise. The cost of a 5% increase in the budget would not even trigger the audit margin for error in the big picture. I don't think you're necessarily wrong about the FOMO. I think that for many organisations this level of spending might trigger questions about why we aren't spending more.
This is the difference between small companies and enterprise. I once worked in a place that spent a million a year on unused Adobe licenses. The c-levels didn't even send an acknowledging reply to the email sent informing them it had been shut down.
I can honestly say that as a paying customer, I'm getting a bit tired of being jerked around by this company. It's on again, off again. Snip snap snip. And by the way, telling people there's a deadline so they all scramble to use their "Fable allowances" before being cut off, only to then be told "just kidding, here's 5 more days" without getting a usage reset is just another frustrating and disappointing customer experience.
Seriously, all OAI needs to do at this point is just release GPT 5.6, have it be a solid model and then not jerk it out of the hands of their customers, and they're going to eat Anthropic's lunch.
I don't think that exculpates the Trump administration for its arbitrary and capricious use of export controls, an ill-suited legal mechanism, without reasonable process or justification - thereby forcing Anthropic to scramble.
reply