React is currently the go-to choice for many devs when crafting interactive sites. But there's a new player in town catching the eye of devs everywhere - HTMX. It's fresh, it's exciting, and it's making old tech cool again. And it’s even made people interested in going framework-less.
I’ll outline the same functionality using Reach, HTMX, and vanilla JS, and then give you my thought process when selecting a frontend strategy.
For our sample scenario, we will build a “like” button. When it’s clicked, the number of likes is incremented by a backend call.
HTMX Example
HTMX is designed for simplicity, allowing you to enhance server-rendered pages with attributes directly in your HTML.
<div id="like-counter">Likes: <span>0</span></div>
<button hx-get="/update-likes" hx-trigger="click" hx-target="#like-counter">
Like
</button>
Clicking the button sends a GET request to /update-likes, and the response directly updates the inner HTML of #like-counter.
Vanilla JS Example
Using vanilla JavaScript gives you full control over the interaction but requires more boilerplate code.
<div id="like-counter">Likes: <span id="likeCount">0</span></div>
<button id="likeButton">Like</button>
document.getElementById('likeButton').addEventListener('click', function() {
fetch('/update-likes', { method: 'POST' })
.then(response => response.json())
.then(data => {
document.getElementById('likeCount').innerText = data.likes;
});
});
React Example
React's component-based approach allows for a structured way to handle state changes and UI updates.
import React, { useState } from 'react';
function LikeButton() {
const [likes, setLikes] = useState(0);
const handleClick = () => {
fetch('/update-likes', { method: 'POST' })
.then(response => response.json())
.then(data => setLikes(data.likes));
};
return (
<div>
<button onClick={handleClick}>Like</button>
<div>Likes: {likes}</div>
</div>
);
}
Which one should I pick?
The option you choose is is situational and depends on a number of different factors, such as the project requirements, your own coding preferences, and your skill level. Here are a few points to keep in mind when selecting a framework / design pattern:
Choose React when…
- You want advanced control over UI effects and DOM manipulation without having to code from scratch
- You would like to leverage a rich ecosystem of third-party libraries and pre-built components
- You are an experienced developer, or you don’t mind a learning curve as React concepts can be tricky
Choose plain JS when…
- You are a beginner and/or want to learn the fundamentals of browser programming
- You want complete control over your app
- You need to build without any external dependencies or you want to keep your build size small
Choose HTMX when…
- You want to do some frontend work with a low learning curve
- You need to implement simple interactions quickly
- You can render pages server-side and don’t want or need a huge JavaScript app
Conclusion
Choosing between HTMX, vanilla JavaScript, and React depends on your project's needs, team skill set, and the level of interactivity required. HTMX offers a simple way to enhance server-rendered pages, vanilla JavaScript gives you full control with more responsibility, and React provides a powerful framework for building complex user interfaces with efficient state management.
Was this approach helpful? Let me know what else you consider when making technology choices!
Top comments (14)
If the response is an object with the
likesproperty, how does HTMX know to read this property? Is the sample incomplete?HTMX works by receiving a html string as a response and replacing/ swapping the matching CSS selector in the dom. In this case the innerHTML of the #like-counter.
This is if course only a simple example and much more elaborate things can also be done.
Thanks. I don't debate HTMX's abilities. I just wanted to put out there that the article seems to have an intention to mislead readers making them think the code snippets presented produce equal/equivalent results. They don't.
Yes it is. It also needs to go to a server for each user click 😛
.... as opposed to updating the likes counter without going to the server?
If you were actually referring to building stateful SPAs, where not everything needs a server round-trip, here's how to do it, from the creator of htmx himself. There are also plenty of posts about combining htmx and react on the web.
Thank you for the article! great simple walkthrough!
Personally, I'd always advise starting developers to build stuff using vanilla js. It helps them gain a much more robust understanding of the browser and what happens behind the layer (or layers) of abstraction the framework provides.
Obviously react is still king in terms of popularity and support, but I quite like HTMX and an very optmistic about its future. you also missed a key aspect of its popularity; the memes are hilarious!!
I never knew about HTMX. Thanks for this blog.
Only html, javascript, css will endure.
htmx,axml, scss, sass, less, react, vue, angular, all are temporary.
They are of no future.
This article has great content about modern web development. I would like to mention a few things I found out about reading about other dependency-free JavaScript libraries.
HTMX, Alpine.js, and Knockout are all JavaScript libraries that simplify front-end interactions and make web apps more maintainable and performant. Despite having different approaches, they share common characteristics:
So, when might you choose HTMX over Alpine or Knockout? As always, it will vary based on the needs of your project, your team’s expertise, and the particular features you’re looking to build. Here are three instances where HTMX might be preferred:
I recommend reading this article from Facundo Corradini that describes more about HTMX perks and limitations: scalablepath.com/front-end/htmx. He also provides a clear comparison between the libraries I mentioned. I think it’s worth a read for anyone that is interested in modern web development.
Its making old tech cool again because people are realising with all these frameworks you get a ton of dependencies, code bloat and just a huge and completely un-necessary ton of complexity.
Software development is going backwards, everything takes so much longer now which is why this is an echo back to classic ASP/PHP.
Another option is alpinejs.dev/. I like its way to do the things.
Chose JS when:
"- You are a beginner and/or want to learn the fundamentals of browser programming
Isn't a bit contradictory?
This is my opinion:
Even React is an overkill for small and medium sized projects , Svelte, Vue make more sense. React lacks good template constructs as well.
Random standards note - a GET should always be a 'safe' call, non-modifying. I believe POST/PATCH is the proper verb.