> htmx ~ Is htmx Simply One other JavaScript Framework?
One of the vital widespread criticisms of htmx, often from folks listening to about it for the primary time, goes like this:
You’re complaining in regards to the complexity of contemporary frontend frameworks, however your answer is simply one other advanced frontend framework.
This is a wonderful objection! It’s the proper to query to ask about any third-party (3P) code that you just introduce into your challenge. Although you aren’t writing the 3P code your self, by together with it in your challenge you’re dedicated to understanding it—and refreshing that understanding if you wish to improve it. That’s an enormous dedication.
Let’s break this criticism down into its constituent elements, and decide precisely how a lot htmx indulges within the harms it claims to resolve.
#The distinction between a library and a framework
Some htmx defenders leap to our assist with: “htmx isn’t a framework, it’s a library.” That is in all probability incorrect.
“Framework” is a colloquial time period—there’s no onerous rule for the purpose at which some third-party code evolves from a “library” right into a “framework”—however we should always nonetheless attempt to outline it. On this context:
- Library – 3P code whose API doesn’t considerably affect the remainder of the appliance
- Framework – 3P code whose API dictates the general construction of the appliance
Should you want metaphors: a library is a cog that you just add to your machine, a framework is a pre-built machine that you just management by customizing its cogs.
This distinction, fuzzy although it could be, is necessary as a result of it describes how simply some third-party code may be changed. For instance, a JavaScript service that makes use of a CSV parsing library can in all probability swap in a special CSV parsing library with out an excessive amount of bother; a JavaScript service that makes use of the NextJS framework, nevertheless, might be going to rely upon NextJS for its complete helpful life, since an unlimited chunk of the code is written with the idea that it’s interacting with NextJS constructs.
Subsequently, in case your service is constructed atop a framework, its helpful lifespan is tied to the helpful lifespan of that framework. If that framework is deserted, or despised, or in any other case undesirable to work on, the issue of modifying your challenge will steadily enhance till you hand over modifying it, and ultimately, mothball it altogether.
That’s what individuals are fearful about once they ask is “is htmx simply one other JavaScript framework?” They need to make sure that they’re not committing to a system that shall be out of date quickly, like so most of the previous net improvement frameworks.
So: is htmx a framework? And is it going to be quick made out of date, leaving a path of un-maintainable web sites within the wake of its meteoric demise?
#htmx is (often) a framework
With apologies to our group’s ongoing debate about this query—I feel htmx is fairly clearly a framework, at the least within the majority use-case. However it does rely upon how you employ it.
Wherever you make use of htmx in your challenge, you’re together with htmx attributes in your HTML (i.e. hx-post, hx-target), writing endpoints which are known as with htmx-formatted information (with sure request headers), and returning information from these endpoints that’s formatted in ways in which htmx expects (HTML with hx-* controls). All of those attributes and headers and endpoints work together with one another to create a system by which parts enter and exit the DOM by way of community request.
Should you use htmx to deal with a non-trivial variety of your web site’s community requests, then the inclusion of htmx in your utility has important implications for the challenge’s construction, from the way in which you construction your frontend markup, to the database queries your endpoints make. That’s framework-like conduct, and in that situation, htmx can’t be trivially changed.
You possibly can undoubtedly use htmx in a library-like method, so as to add dynamic performance to just some sections of your net web page. However you may write React in this library-like manner too and no person argues that React isn’t a framework. Suffice to say that many individuals who use htmx of their purposes are doing so in a approach that bends to the calls for of htmx, as a framework for constructing hypermedia purposes.
As they need to! Constructing with htmx works quite a bit higher in the event you play to its strengths. You possibly can ship JSON-formatted type our bodies, if you really insist. However you shouldn’t! It’s less complicated to simply use utility/x-www-form-urlencoded our bodies, and write an endpoint that accepts them. You possibly can write an endpoint that’s re-used throughout a number of totally different shoppers, if you really insist. However you shouldn’t! It’s less complicated to split your data and your hypermedia APIs into separate URLs. Sure, htmx can be utilized as a library, however perhaps let or not it’s your framework too.
That doesn’t imply, nevertheless, that htmx is Simply One other JavaScript Framework, as a result of htmx has an enormous benefit that the opposite frameworks don’t: HTML.
#htmx is for writing HTML
Let’s say you’re utilizing htmx as a framework—is it a JavaScript framework? In a single apparent sense, sure: htmx is applied with ~4k traces of JS. However in one other, way more necessary sense, it isn’t: React, Svelte, Stable, and so forth have you ever write JS(X) that the framework converts into HTML; htmx simply has you write HTML. This removes complete classes of upkeep that may make you abandon different frameworks with time.
Codebases are inclined to get caught whenever you need to improve or change some dependency, however the framework you employ is incompatible with that change. Java is probably the most infamous offender right here—there are untold thousands and thousands of traces of Java in manufacturing that can by no means depart Java 8 as a result of upgrading Spring is simply too onerous—however the npm bundle ecosystem is an in depth second. Whenever you use the htmx “framework” you’ll by no means have this drawback, as a result of htmx is a zero-dependency, client-loaded JavaScript file, so it’s assured to by no means battle with no matter construct course of or dependency chain your server does rely upon.
Browsers render HTML, so no compiler or transpiler is ever essential to work with htmx. Whereas many htmx customers fortunately render API responses with JSX, htmx works very properly with classic template engines, making it moveable to whatever language you like. Say what you’ll about Django and Rails, however they have been related in 2008 they usually’re related right this moment—htmx integrates seamlessly with them each. This can be a recurring theme with htmx-driven improvement: htmx works properly with improvement instruments outdated and new, as a result of the widespread denominator in all these instruments is HTML, and htmx is for writing HTML.
Pushing the consumer to outline the conduct of their utility primarily in HTML, reasonably than JS, has too many benefits to cowl on this essay, so I’ll keep on with the one folks hate most about JavaScript fameworks: churn. Relying on whenever you wrote your React utility, you might need written your type with controlled class components, or react hooks, or this experimental <form> extension. That is genuinely maddening, particularly in the event you—like me—first realized how you can make an online type with class elements.
Irrespective of whenever you wrote your htmx utility, nevertheless, the conduct of an htmx type has at all times been outlined in largely the identical approach a daily HTML type is: with <type>. With htmx including further community performance, you may lastly use PUT requests and management the place the response goes, however in all different respects—validation, inputs, labels, autocomplete—you could have default <type> factor conduct.
Lastly, as a result of htmx merely extends HTML in a really slim area (community requests and DOM replacements), a lot of the “htmx” you write is simply plain outdated HTML. When you could have entry to advanced state administration mechanisms, it’s extremely straightforward to implement a customized collapsable div; whenever you don’t, you may cease lengthy sufficient to look up the <details> factor. At any time when an issue may be solved by native HTML parts, the longevity of the code improves tremendously because of this. This can be a a lot much less alienating option to study net improvement, as a result of the majority of your information will stay related so long as HTML does.
On this respect, htmx is way more like JQuery than React (htmx’s predecessor, intercooler.js, was a JQuery extension), however it improves on JQuery by utilizing a declarative, HTML-based interface: the place JQuery made you go to the <script> tag to specify AJAX conduct, htmx requires solely a easy hx-post attribute.
Briefly, whereas htmx can be utilized as a framework, it’s a framework that deviates far less from the web’s semantics than the JavaScript frameworks do, and can profit from enhancements in these semantics with no further work from the consumer, because of the net’s excellent backwards compatibility guarantees. If you wish to construct a web site that lasts for a very long time, these qualities make htmx a considerably higher guess than lots of its contemporaries.
NOTE: Regardless of agreeing with this evaluation, discovering no logical flaws within the essay, and permitting me to publish it on his web site, Carson continues to insist that htmx is a library.
</>