Not my observation. If you never look at the code and dont have basic guardrails in place (linters, architecture tests, some guidelines for best practices) - probably.
But as soon as you do minimal reviews and high-level corrections, applications turn out just fine.
Can there be bugs? Sure. That's the price of not reading or understanding every line. It should depend on the criticality of your software how much of these you tolerate and how much you don't (reviewing, understanding, testing everything 100% like you were used to if you had written it yourself will kill most if not all of your gained speed)
But I never got the impression of unmaintainability or unfixable bugs.
Actually the other side around: A really good cleanup pass, architectural changes, or bugfixes are seldom more than a few prompts and 2 hours away, provided your overall base is decent and you actually gave a fuck from the start.
Indeed, though I find the distribution is different.
The humans may skip unit tests and need reminding; the AI always write unit tests once it's in AGENTS.md or whatever, but my experience* was that 5-10% of the time the LLM's attempt at a "test" would, instead of executing the code and examining the results, open the source code as a text file and run a regex to find/exclude certain substrings.
* At the start of this year, because Anthropic and OpenAI were both offering free trials. IDK how much things have changed since then, some things change fast in this domain, other things don't.
I’ve been piloting LLMs for the past six months non stop and we’re at the point where formally verified models generated as an intermediate step between spec and code are very good value.
Riding the exponential means you have to update priors more often.
What I'm hearing is "thoroughly reviewing AI generated code would defeat the purpose, so we give it a cursory glance and it seems to be decent code", and that's my point - it does indeed seem to be decent code but I think we're all kicking the can down the road when we operate this way. If the alternative means there's no gain to be had by using LLMs to write code, so be it. Maybe that's the answer. Maybe we shouldn't be relying so much on AI to write our code.
I think LLMs are great for writing small snippets of code that really only have one "best answer" (something simple like writing an array to a CSV), and internal tools, where bugs and security vulnerabilities usually aren't a big deal.
Do you have a source for that? As to my knowledge advanced systems (such as lights on the twy directing you) are only present at very few airports. Recent incidents even happened due to RWY incursion without a ground controller noticing under bad visibility. So we are at a level where your runway is not even protected accordingly, let alone your 50+ taxiways.
But there are third party options availabe that to the very same thing (e.g. https://aider.chat/ ) which allow you to plug in a model (or even a combination thereof e.g. deepseek as architect and claude as code writer) of your choice.
Therefore the advantage of the model provider providing such a thing doesn't matter, no?
Microsoft has something very similar (i did not do a full feature comparison, just speaking about apis and auth) which is mit licensed. Works also with on-prem databases despite it's name. https://github.com/Azure/data-api-builder
I think it brings forward all the low-performers and people who think they are smarter than they really are. In the past, many would just have stayed silent unless they recently read an article or saw something on the news by chance. Now, you will get a myriad of ideas and plans with fatal flaws and a 100% score on LLM checkers :)
It's great and I'm never going back as long as it stays great. But I have one complaint: Maps. I have no solution to offer, but google maps is so damn good, the maps in Kagi which appear when clicking certain results (e.g. looking for a doctor) are almost unusable for me (slow, outdated).
You are right, BUT: Those denials have to follow contractual terms. I know a local (Europe) real world example where a friend of a friend (insurance company area manager) literally was told "this is your sum of money on claims that you can accept in this quarter, it cannot go above that". Which either you get lucky and make the quota, or you screw people over and hope they don't sue. And since we live in a world where the company wants "a little more" each year, well.. I don't see how this ends well.
The same problem does not apply to our social services (including health insurance) as they dont have to make profits at all costs.
I am still trying to get HTMX adopted in a ~ 800 employee software development company. And while we do not yet have a project using HTMX in production, I like to use it a lot in thought experiments with mentees: Could you do it with HTMX / Fragments? If yes, how would you design it? Do we REALLY need an SPA?
I do think "use HTMX" is a tough sell for a 800 employee company, just because it doesn't really solve issues on it's own. (Imagining the pitch is "add HTMX to an existing project") Going all-in on hypermedia definitely means the service that serves your application needs to be more than just a JSON parrot. Templating HTML and sending the right chunks back is hard to do if those services aren't built around being hypermedia services.
I really like turbo-rails [0] (the ruby gem that Rails 7+ bundles in for turbo support, meaning helpers that make turbo frames/responses a native "thing" rails understands) because it's a complete solution. There's at least some obvious structure to build off of, and I'm not stuck trying to build up my own framework on the BE for my newly simpler FE.
django-htmx [1] also fits in this case too. I feel like any honest pitch of HTMX should involve some BE solution as well.
I dont intend it to be an all-in, but I do believe it could do the job in 50% or more cases just as well as any SPA framework. A lot we do is "just crudl" with some sprinkles on top.
A large chunk of our business comes from Spring Boot, so we are experimenting with JTE - looks decent so far (Thymeleaf feels just old nowadays).
My sell is pretty simple: You have regulations coming up in europe which will require you to keep applications up-to date and secure. Extending your SBOM by 1k NPM libraries is a huge cost. I want to get rid of that.
I tried to get HTMX adopted for a new project but the unanimous response was "what is this? why not React? everyone knows React. period" and most of my arguments for HTMX were ignored, because to most people, HTMX looked like some obscure, yet another JS framework created last week, with questionable future.
The reason is because all new technology is a staffing and training problem management needs to solve. Someone has to maintain your thing after its built and be ready when you leave the organization. If React can solve the issue in a similar timeframe and level of effort and it is easy to source React developers then obviously your proposal will be rejected because React is simply far easier to deal with from a training and staffing perspective for what you are trying to do. You need more merits to warrant the introduction of new languages and frameworks.
Very anti React person went for Svelte but the kind of modularity React offers, HTMX can't hope to match especially on larger projects.
Modern React is too simple. A component is just a pure function taking arguments and returning UI as JSX. The only other thing you need to know is few hooks.
maybe you can send me to the right tutorial. I'm a backend, distributed systems engineer. I have worked on eye-watering scale. React is anything but simple to me.
I tried create-react-app, the thing built and downloaded for several minutes, and then there was a nest of file relationships that I didn't grok. It seemed like any change required three files to be updated. Lots of ancillary things like bundlers, packers, tree shakers, lions, tigers, and bears, oh my. After an hour, I didn't get what I was doing. Somehow, altering this function over here made this other thing over there go "moo."
I used to do web development back in like 2001. I understand the web, http, css, html, and basic js. I'm not up on all the latest, but I have a very firm base.
I got htmx working and pretty much fully digested in the same amount of time I wasted on React and have produced a working prototype. I find htmx to be like how the web used to be. It makes sense.
FWIW, create-react-app is overloaded with every package you could ever potentially want to use for some weird reason. It's way overkill and I wouldn't recommend using it.
It's much better just to use Vite with React as a plugin. Then you only need to install three React packages to get your app going.
The best tutorial I've used was "Road to React" by Robin Weiruch. His example app you learn is how to build a Hacker News front page. Very clear and it goes step by step.
Most of the tutorials online are all over the place, or mix Class tutorials with Hooks tutorials, or starts adding in things like Redux (which aren't needed).
The person you're responding to is correct, at it's core React is very simple, especially if you just stick to hooks. Most of my code is just bog standard HTML (as JSX), CSS and JS with a few React hooks thrown in.
FWIW, I've been doing frontend dev since '94 and personally find React jives the most for me and how normal HTML/JS/CSS work. I can see why people would like HTMX, but I've never liked overloading HTML attributes as some strange event model. But it's good there are choices.
React has very good documentation and an excellent tutorial. Here is a link to it: https://react.dev/learn . I recommend doing the exercises. They really help you learn React.
Create React App should not be used because it is no longer maintained. Here is its GitHub repro: https://github.com/facebook/create-react-app/commits/main/ . It has had very few updates since July 2022. This is bad because it needs constant updates because it depends on a large number of packages and those packages are constantly releasing security updates.
To be fair, this would be more analogous to some random person creating a crate called 'create-rust-app' and then abandoning it. Hardly a signal that Rust is dead.
I understand your confusion and dismay over React because I'm myself a backend developer and the kind of complexity doesn't exist in backend tech stack.
But this all or none of it has anything to do with React rather with a broken language design which never imagined anyone would write JavaScript worth more than a few paragraphs in a single file.
That's where tons of bundlers come into play from parcel and webpack to vite.
But then there are some language extensions that must be transpiled before they can be bundled. Your JSX comes to mind.
Typescript can be considered in the same league.
Minus all that - Modern React has a very minimal surface area, very few concepts and that's about it.
> Modern React is too simple. A component is just a pure function
React is simple only in some mathematical theoretical sense, but not for understanding by human minds which fundamentally operate imperatively ("if I click on this, load data X from the server and show them to the user...").
You can get some hello world example relatively easily, but you hit the complexity wall quite quickly (need to know "some hooks" - some, like useEffect() are very complex, yet often needed for basic things). The worst of all is debugging with stacktraces making no sense with it all being from the React itself, not your code, not tracking some logical pathway.
(I'm saying that as someone who generally likes React and would choose it for a new project)
useEffect is simple. If I recall correctly, with no arguments it is like onMount and with the dependent variables listed in array, it would be executed every time any of the listed variables change.
try passing state around the component hierarchy and see how simple it is. HTMX makes it easy but centralising the state in one place ie the server. try coming back to your code base in a year or two and see how simple it seems then :D
Fully ack. But this can actually be turned into something good imho: I try to challenge all layers (Analysis, UI / UX design) on simplicity: "Do we really need X parts of the page all be affected / updated by something? How could we design it differently with locality in mind? Can we simplify the state somehow?" -> I think that the resulting solutions are often simpler, cheaper, and work just as well.
> It is not good for "and these other related elements need to update"
That seems a bit backwards, no? Why can't those other elements manage their own updates? You can have the server respond with an `HX-Trigger` header to dispatch an event and any elements that care about that event can listen for it. Far simpler than trying to coordinate surgical DOM updates in a single HTTP request.
Events form the backbone of the browser environment and leaning into that model makes a lot of things much easier
To a certain extent, it works, but there's definitely a point of complexity that you can hit in the app at which it becomes painful. Those are the kinds of apps where htmx is just not a good fit.
Of course you get pushbacks. Is there any *real* advantage, technical or otherwise, at an organization level, of adopting this new model of creating web pages, other than your personal preferences? You are moving away from an established system with tools that everyone is familiar with, to a system that much fewer people use, with no clear performance/maintenance/management benefit (at least not demonstrated). Maybe you don't like writing JS/TS, but plenty of other people do, and they don't need to cater to your preferences.
People need to spend time learning this tool. They need to be proficient with it. Your new stack might need to still work with existing code at some point. That means training, overhead, ramp up and potential risk in a less established area. Why would people do that?
You should be thankful you didn't get warnings from your boss for messing around instead of actually pushing features out.
To be fair, it's not an unfair response. Being able to hire for a technology, and having a large community around the tech stack you use has tangible value.
HTMX might not be something that will vanish in a week, but it's also nowhere close to a mainstream framework.
the reality is that the only way to prove htmx is around for the long term is to stick around for the long term, and I hope this essay contributes towards that.
We'll see how this years JS rising stars shakes out.
I built an HTMX fragment framework for Django. It allows you to render a fragment, and automatically serves the fragment separately for live-updates. I'll open source it tonight and post back.
In my opinion, HTMX + custom elements does everything React does but better, and is a billion times cleaner.
