It's just the hype moving on.

Every generation has to make similar mistakes again and again.

I am sure if we had the opportunity and the hype was there we would've used k8s in 2005 as well.

The same thing is true for e.g. JavaScript on the frontend.

I am currently migrating a project from React to HTMX.

Suddenly there is no build step anymore.

Some people were like: "That's possible?"

Yes, yes it is and it turns out for that project it increases stability and makes everything less complex while adding the exact same business value.

Does that mean that React is always the wrong choice?

Well, yes, React sucks, but solutions like React? No! It depends on what you need, on the project!

Just as a carpenter doesn't use a hammer to saw, we as a profession should strive to use the right tool for the right job. (Albeit it's less clear than for the carpenter, granted)

>Just as a carpenter doesn't use a hammer to saw, we as a profession should strive to use the right tool for the right job. (Albeit it's less clear than for the carpenter, granted)

The problem is that most devs don’t view themselves as carpenters. They view themselves as hammer capenters or saw carpenters etc…

It’s not entirely their fault, some of the tools are so complex that you really need to devote most of your time to 1 of them.

I realize that this kind of tool specialization is sometimes required, but I that it’s overused by at the very least an order of magnitude.

The vast majority of companies that are running k8s, react, kafka etc… with a team of 40+, would be better off running rails (or similar) on heroku (or similar), or a VPS, or a couple servers in the basement. Most of these companies could easily replace their enormous teams of hammer carpenters and saw carpenters with 3-4 carpenters.

But devs have their own gravity. The more devs you have the faster you draw in new ones, so it’s unclear to me if a setup like the above is sustainable long term outside of very specific circumstances.

But if it were simpler there wouldn’t be nearly many jobs, so I really shouldn’t complain. And it’s not like every other department isn’t also bloated.

Along those lines, I am building https://github.com/claceio/clace for teams to deploy internal tools. It provides a Cloud Run type interface to run containers, including scaling down to zero. It implements an application server than runs containerized apps.

Since HTMX was mentioned, Clace also makes it easy to build Hypermedia driven apps.

> Just as a carpenter doesn't use a hammer to saw, we as a profession should strive to use the right tool for the right job

I think this is a gross misunderstanding of the complexity of tools available to carpenters. Use a saw. Sure, electric, hand powered? Bandsaw, chop saw, jigsaw, scrollsaw? What about using CAD to control the saw?

> Suddenly there is no build step anymore

How do you handle making sure the JS you write works on all the browsers you want to support? Likewise for CSS: do you use something like autoprefixer? Or do you just memorize all the vendor prefixes?

It's actually kinda hilarious how RSC (React Server Components) is pretty much going back to what PHP was but yeah proves your point as hype moves on people begin to realize why certain things were good vs not

where does tailwind stand on this? you can use it without a build step but it's strongly recommended in production

[dead]