Comment by masfoobar | Hacker News Reader

Comment by masfoobar | Hacker News Reader

I enjoyed reading this. It follows a similar experience with our first htmx website, away from using modern frontends, or just simple jQuery with ajax json data.

I remember, working with a co-worker, we planned out the process (a step-by-step on the application like this post) and it made sense to me - but this journey was much harder for my co-worker.

Why is this? Simply because he is familiar with MVC pattern of sending json data back and forth, and getting the frontend to update and render it, etc. The idea of html flying with htmx as the behaviour (inside html tags) was just too much.

For me, I always preferred the old school way of just letting the server-side generate the html. All htmx does is adds extra functionality.

I tried hard to explain that we are sending html back, and to break things down one at a time but each new task was left scratching his head.

In the end, our website had somewhere around 20-50 lines of javascript! Much smaller footprint than over 400 lines in our previous project (that being generous). Sure, our server side code was larger, but it was all organised into View/PartalView files. To me, it made really good sense.

In the end, I dont think I won htmx over with my co-worker. As for another co-worker, who had a chance to build a new project with htmx, decided on some client javascript tool instead. I dont think I got a legit answer why he did that.

With all this above, I learned that some (perhaps most... perhaps all) struggle to adapt to htmx based on their many years building websites a particular way, with popular tools and javascript libraries. Overall htmx does not really change anything - you are still building a website. If anything htmx just add an additional layer to have website really work.

Yoda's words now have new meaning :- "No! No different. Only different in your mind. You must unlearn what you have learned."

For some its just not happening. I guess Luke Skywalker really shows his willpower, being able to adapt to htmx easier than others. :-)

I remember someone on HN puts it really well. There is a whole generation of developers that thinks frontend = React. And more importantly they are in much larger number than those of us who went through DHTML and Ajax.

We are now the minority, and they are the norm.

In 10 years, the people that knows React will be the minority compared to the ones that only know vibecoding.

True, but all the FE generated by that will be echoes of React, so my head will still hurt

Not only that, but interviewers will only value one particular vibecoding framework with a silly name, and will expect 10 years of experience in it.

Not just developers, but designers. Finding designers who understand hypermedia in that way is nearly impossible.

A team that decides to shift towards this approach to development has to get buy-in from the designers as well. It's not just the devs who have to retrain.

> Not just developers, but designers. Finding designers who understand hypermedia in that way is nearly impossible.

This is true. 100%

The difference for me and my AppDev career history is -- I never worked with a team of dedicated frontend developers. We are primarily backend developers who are frontend devs as well (though we can admit it is secondary to our backend skills)

Personally, the change for us was placing our html on the server side. So, to me, styling is not a problem and easy to test. It should be, with some training, easy for a dedicated frontend developer to jump in as well... though we might have to shuffle things around with their tools, to gel nicely with the backend team.

If anything, I think this transition would keep the two departments closer together - communication is needed especially for htmx webapps.

I think it can be difficult to win over other backend developers with htmx, as my original post suggests. Adding a frontend layer as well... it is unlikely htmx will be taken seriously when the majority want to stick with what they know.

It's best to not sell it as using HTMX the way you would sell using React as a framework. Instead, I say "let the web be the web."

Building things using standards and not fighting the paradigm with a new paradigm. What's great about HTMX is that it fits alongside the standards in a way that SPA frameworks generally don't.

But focusing on the web itself and everything it's capable of without a framework means you can easily move off of HTMX if need be.

"let the web be the web."

100%

You're acting as if "hypermedia" was some kind of standard everyone should know. It is not.

It is hard to know our future. What I am about to write could be wrong, but I will try...

At a basic level - it is all html, css, javascript and a server side language at the end of the day. Whether we are talking today or back in the early 00's.

For few years now, we add nodejs, typescript, React, etc.. on top of it. Personally, while I understand the purpose of using such tools for complicated web development, I still believe good websites can be created without them. It keeps is simple, small in size, etc.

Of course, a few years before that the push was angular or knockoutjs. Before that the push was jQuery, etc.

For the future. Lets say in the next 15 years, while I still believe that html, css and javascript will remain.. I do think react, like angular, will be replaced by something else.

Honestly, I think its just a matter of time before WASM takes over or the evolution of such technology. Personally, I have toyed WASM builds in compiled languages and think it will win for web development for speed, performance, and lack of fluff. However, we are not there yet.

For example, I had to build a internal web application for staff. They have a number of drop downs and text fields, etc. I was experimenting implementing it with (something like) immediate mode UI such as IMGUI in Go. While the results were great, it reached a deadend not because of WASM, langauge, but lack of UI features. I needed to include OpenStreetMap, which is not supported. I had to bite the bullet and accept writing it as a typical Website.

I went with htmx + leafletjs in the end. Again, it worked out well.

The change was mobile. Once you had multiple clients, with varying levels of thick state (e.g. offline first for Android), it started making sense to streamline around a data-driven API and rich client apps.

That's honestly the main reason. It's so you can build all three channels the same(ish) way

Reply on news.ycombinator.com