The Most Important Lesson From HTMX

Sources

S/O Ph4se0n3 for the awesome edit 🙏

[Nikoline_The_Great]

From another angle I think server components and HTMX make web programming way more accessible to people like me that come from a non web background. Unlike react and many other frameworks I think that HTMX just makes sense. There is no nonsense. It is simply works.

[choilive]

As someone who has been doing a lot of Rails dev since Rails 3... I love seeing everything come back full circle to server rendered html.

[mateja]

This is a common pattern in software and elsewhere. The trend shifts from one extreme to the polar opposite, until finally balance is established. Exactly where on the spectrum the answer lies, always depends on the context.

[evancombs]

I think there is value in both. I remember the old days when everything was done on the server side. I found it to be a pain to develop compared to desktop applications. One of the great things that happened with the SPA frameworks is they made web development feel like desktop development. That is a major reason why these frameworks were adopted. I do not think that is something that we need to drop, but we do need to recognize in a web environment that may not always be the best solution. That is where something like HTMX comes into play. From what I have seen HTMX looks like a huge improvement over the old way of doing things on the server side.

So I think the right approach would be to start your development off with a focus on the client side, and then when appropriate you add HTMX, or something similar, into the mix.

[DarenC]

As an old guy who wrote his first Web page and cgi-bin programs in 1995, I'm tickled pink to see the trend back towards doing more stuff on the server. Huzzah!

[RobertWHurst]

I've been a software engineer since 2008. We used to build applications much like how htmx advocates. The most popular pattern was MVC, a pattern the industry largely moved away from because it deeply tied the implementation of the backend to the frontend and vice-versa. For small projects, this approach is fine, but for complex projects or larger teams, this pattern became frustrating as even small changes to the frontend could have implications for how controllers and models (data and logic) were implemented. It was difficult to iterate on the frontend as it meant iterating on the server as a whole.

I would be willing to bet a vast majority of engineers trying out htmx are either as old as me and really liked MVC - a minority of mostly backend engineers I'd imagine, and young people who never experienced the bad old days of MVC. In any case, I think a lot of people are going to find out. It's going to be interesting to watch them run into issues similar to the ones we did and figure out solutions. These issues are what drove us to use json communication and to separate our view logic from the server in the first place.

[JT-mrdb]

Lovely thing about HTMX is that you can point the requests at any server that returns HTML, it doesn't care. Really frees up the front end, and means you can use whatever server technology makes sense for your app.

[TheBuddilla]

Yes please do a HATEOS video, also graphql apis are not going away if you need to offer public api support for backend services. So even if your CRUD site is totally built the "old school" way with htmx and you offer any backend services it will need api's for customers. At least now you can have a separation of concerns and you can use a "securer" public api where it makes sense. In the end, just use the right tools for the right job. There is no one size fits all framework or programing language. Use what works for you, gets the job done and gives the least amount of headache.

[eric-seastrand]

Those enormous JS and JSON payloads were never a hard requirement. They are merely consequences of the so-called “JavaScript ecosystem” which made it way too easy to saddle up my project with thousands of dependencies-of-dependencies I never knew existed. Then somehow it became “best practice” and .. well you know the rest. It was always possible to build a good interactive UX with realtime refreshment of relevant bits. We devs have only ourselves to blame for over complicating that goal.

[TheNewton]

Can't wait the next trend to be just using the canvas element to stream the render directly from the server.

[simonegiuliani]

I was waiting this moment! Those who entered in the programming field 15-20 years ago never understood the shit show that was happening on the front-end side of things.

[pietrosanchez]

Man I love memeing on PHP and Laravel but when I see how messy the JS ecosystem is, I'm glad we use JS for the frontend only.

[dstinYwOw]

Video on HATEOAS/HATEOS would be great, waiting for it! Your channel teached me to not hate frontend development :)

[unom]

I mean, no one is forcing anyone to send "massive" json, often people are sending data that is not needed for the current operations - graphql _is_ a way to slice that, as is jsonapi for that matter.

[etexas]

I thought the idea behind single page applications was instead of sending the whole page including all the html and css back and forth, we just need to send the data... what happened to that? Why are we talking about giant payloads?

[erlend]

The problem with returning HTML (and not JSON) from your server is that you'd probably also like to serve mobile apps and don't want to duplicate your API

[davidsiewert]

I think the better solution is upgrading frontend devs to fullstack devs and allow them to customize the api/db schemas to meet their needs.
Next.js currently in not a great choice (slow HMR, buggy caching, major breaking changes, bad SSR performance).
Static sites with Astro combined with SPAs using Solid.js/Svelte/React for dynamic parts using something like TRPC/react-query is a much better solution.

[DeveloperChris]

I got my first graphql job a couple of weeks ago. I successfully told them its not a good idea for ongoing security, a simple mistake by a future developer exposes your internals to the world. So we are doing things properly now :)

[crowdozer]

I've been having a lot of fun working with simpler SSG's like astro and using htmx + partials. Something about it just feels so right compared to the SPA approach. It's not a magic bullet for everyone, but it is for me and it might be for a lot of others too. Then throw on Tailwind and you've got rocket fuel 😁😁

[elmertsai]

Maybe someone can help me understand this... Isn't the View component of MVC literally what they were referring to? like the intermediate layer between the API and the html that is eventually served to the client?