Hono and Htmx and Cloudflare is a new stack
blog.yusu.ke
blog.yusu.ke
These "stacks" ONLY work if you are building hobbyist apps, or if you want to sell services. A fast-moving product company has many better alternatives that are probably far more tailored to their business objectives and team composition.
Maintaining these things in production for many years is often painful and cumbersome. Moreover, they usually are introduced by a single person who has a lot of enthusiasm to maintain it, but when that person leaves all hell breaks loose. Even more fun is when the underlying infrastructure provider decides to deprecate an API that requires a ton of bespoke fixes (e.g. Netlify's Next.js edge plugin which recently had a behind-the-scenes change to how Lambdas are spun up causing bugs with state leaking between requests).
With that said, it's good to explore new technologies. I just wish these sorts of posts (which are thinly veiled product marketing/tutorials) would expand to actual direction/feedback about how to use new tools in production effectively.
New tools are, by definition, new, and full of unknowns. There are roughly only two ways to use them in production effectively: either you understand what they are trying to do and take the risk because you are convinced it is The Way, or you wait until the tool/tech settles and becomes not so new anymore as the experience reports from the first group trickles in.
People got so stuck on JS for decades that they've forgot that HyperText in HTML is there for a reason. It was always supposed to be more than just UI descriptor markup.
It is JS who is out of place in web. A little script in form of DHTML that grew into becoming a cancer that it is now.
Having used inline styles in the past, there is no comparison to tailwind. Tailwind is a good and productive, though certainly not ideal tool. But it’s miles ahead of whatever else has been produced by css frameworks, in terms of productivity and maintainability.
React is nothing like Vue or Svelte.
If you find yourself using a library as quick fix to avoid learning or investing time into something, your end result will be forever limited by that. Real systems have hundreds or thousands of parts and they are always eventually complex, so complexity and the underlying tech cannot be avoided for long.
Think twice before building a house of cards, that's the wrong kind of stack.
Complexity can definitely be reduced and maintenance complexity is the real killer in software these days — both in price, wasted resources and stunted careers.
Simple means supportable, and we should encourage more people to explore systems that “just work” even if they sacrifice some elegance.
This may not be it, and your point about not confusing simplicity with progress is valid as heck, but there are good reasons to explore this stuff and I love seeing new combinations like this on HN.
It looks very similar to a Flask (Python), Sinatra (Ruby) or Express (JavaScript) server-side application. It is very straightforward to use a traditional MVC-with-HTTP-verbs architecture.
These end up being way cleaner than whatever happens when you split up the backend and front end into separate coupled applications.
The downside has always been that your website seems a bit sluggish when doing full page reloads… but that’s where edge compute comes into play and it starts to feel as snappy as a server-side rendered web app feels when running locally.
This is a neat combo i guess it is fast but other than being neat I’m not sure this is feasible beyond some small examples.
In this specific case, the point is to run the backend on the Cloudflare edge, and that only runs V8, so using a JS backend makes particular sense.
But yeah, would be interesting. Actually, I'd also be interested in a perf+efficiency comparison between JS and $lang+WASM on the backend, because this discussion makes me realize that the JIT tradeoffs are wildly different for a long-running process servicing many requests per second compared with many copies of a single-user client.