The current state of web application development
User expectations of the web are now that you have this super-smooth no-reload experien...
For further actions, you may consider blocking this person and/or reporting abuse
I have checked the htmx-Reference. There are about 120 new keywords introduced to do things, that can be easily done with Javascript. What is so bad about Javascript? As far as I have seen, you cannot even count from 1 to 10 with htmx......
You seem to be mistaking htmx as a programming language. This post is also not explicitly about language, but about architectural approach.
I´m just asking, if you need a new tool to do things, that can already be done in a more efficient way, just to avoid Javascript? Does this make our life better or simpler?
Over the last years we have seen new tools every week, and each comes with a new syntax, new keywords, and new limitations.
Well, one of the points of the argument is, yes, it can make life simpler.
Also it's disingenuous to say it is purely to avoid writing JavaScript. It's a simpler approach by returning to RESTful principals, rather than fat clients.
With this logic we can say, do you really need a high-level language to compile to assembly, when you can already write assembly in a more efficient way, just to avoid assembly? Does this make our life simpler or better?
It is not really an homologous situation. @efpage is explicitly making this claim in the context of htmx adding 120 new keywords in order to achieve its goal. Their point being that this may have significant overhead in terms of complexity.
Whether that is correct is a separate issue, but you cannot really compare it to assembly vs high level languages, although I will posit that yes, whether or not a high level language makes things easier than assembly (or C, for a more realistic case) should be a metric that all high level languages are measured by.
...AND avoid writing JavaScript.
It was meant as a tongue-in-cheek comment. ;P
htmx offers a hypermedia-first counterpoint to the js maximalist trend of the last decade. Of course, one can always leverage javascript for islands of interactivity, where necessary.
There are some interesting pieces of misdirection here.
First one: "React even recommend using a framework on top of their tech".
Yes, React, the front end library, recommends using a full stack framework if you need to do server side rendering.
The second one is this claim: "The hypermedia approach of building websites led to the world-wide-web being an incredible success." Not sure if that is an assertion that can be made so casually. So many things contributed to the success of the web, and if this hypermedia paradise (that I'm not sure we ever had) had been instrumental to it, maybe it would've collapsed without it?
The third one is the waxing poetic about the browser as the magical app that allows you to do anything... as if this had happened in spite of JavaScript as opposed to because of it.
Ahh, it didn't happen because of javascript. Your claim is just ridiculous. You keep raising objections that are not substantiated.
Well, maybe not just because of JavaScript, but certainly many successful web applications rely heavily on it. You can't have Google Docs without JavaScript. You can't have live chat in the browser without JavaScript. You can't have sophisticated graphical interactions without JavaScript. Without it, you can have things like email clients, bank clients, news readers, etc. Yes. But Apps that did all that already existed even before the Web browser (CompuServe, anyone?) and the Web did not dethrone it because it was necessarily better, but because it was open. Now, was hypermedia instrumental to that opennes? Maybe. It surely is a smart way of building an open system, but it is not the only way.
To reiterate: my comment was directly related to the assertion that the Web browser was this unprecedented "universal client", which is only true in a meaningful way if you acknowledge the big boost the JavaScript layer adds to it. Without JS, the web is more like a universal BBS: a wonderful thing to have, for sure, and unprecedented in terms of scope... but hardly breaking new ground in terms of client side capabilities.
In fact, during the early 2000s embedded front-end technologies were striving to be the missing link between HTML and real interactivity. Things like Java applets and Flash. Eventually, through things like AJAX and the canvas tag, the browser managed to provide those interactions on its own (through JS), and it drove those complementary technologies away. But there's a reason they were seen as a necessary component in the first place.
I get your point now. I was like "other stuff existed before JavaScript".
I am surprised, that nobody considered UnPoly (unpoly.com) as common reference of htmx.
In my understanding, the challenge is, to provide server side rendered-page simplicity with a modern UX.
Now you got three choices:
It's only about terminology, but HTMX and Hotwire are SPA, whether you like it or not. They expect server-side rendered HTML though rather than doing client-side rendering like, e.g., React; but the fact that they switch content in-place without reloading the whole page make them SPAs.
Naming things is hard, SPA edition
Thomas Broyer ・ Mar 28 '23
About HTMX, I 100% agree with that progressive-enhancement approach, particularly for forms, edit-in-place, or possibly "load more" buttons (for navigation though, unless you have a very good reason not to –e.g. playing video or sound–, I think MPA is better)
No they are not SPAs, SPAs are not the tools you use in building your app. An app isn't a SPA because it uses React, it's because of how it's built. React doesn't expect server-side rendered HTML.
Your comment is confusing. I can't tell if you agree or disagree with me 😅
What I was saying: HTMX and Hotwire Turbo are for making SPAs (using HTML over the wire). React is for rendering (most likely CSR), and most if not all React frameworks and apps are SPAs too.
Do browsers have built-in HTMX support, or how does this work without javascript enabled? I can see how easily this approach can prevent needing to write any javascript for a new HTMX app, but how does it work with no javascript at all?
You need JavaScript for HTMX to work, after all it is a JavaScript library. However the architectural approach makes it simpler to do progressive enhancement, as mentioned in the text.
Check out the clojure repo in the links for an example
Got it, thank you for the reply! That clears up a lot for me. This seems like something that Browsers should have built-in support for!
It's what HTML was supposed to evolve into. Give it a try. After using it... kinda automatically clicked in my mind "this is what HTML is supposed to be"
There's a typo in your headline. It should be HTMX is A future - not HTMX is THE future.
What you are describing is a different separation of concerns that may, or may not, be applicable in someone's use case.
Here's a thought experiment - imagine if HTMX becomes as popular as React. Why will the coding world be a better place? Won't there be lots of articles describing the best way to structure your hypermedia responses? And won't there be a gazillion libraries for the best way to construct complex HTML on the server side (I mean you skip over the whole part about what it takes for the server to construct fragments)? And let's not forget the benchmarks and handling large data. And what about the misuse of tags? (In your very first example you are arguably misusing dl because dl is a description list (with dt for description term and dd for description , but you're abusing it as a key value pairing).
None of the above is a deal breaker - but it just reinforces that the future will be as messy as it is today. There will be some more good choices for us to pick from and some less-good-choices will fade into oblivion.
Yes, a fat client is more expensive than a thin client. But then an SSR backend is more expensive than a vanilla data backend. And what about the middle tier? And microservices? And loose coupling? And a lot of other things that people much smarter than me will be listing. There are way too many holes in this article for it to be a good argument for THE future.
Take the lack of SEO as a "ding" against other approaches as a key argument for SSR. The first question is always "what's my use case?" and SEO often isn't one for a large number of "traditonal applications" (I don't want my email or my bank account details to turn up on Google thanks all the same).
Sure, there are also plenty of apps where SEO is necessary/desirable. But that's just another example of why to NEVER believe an article that says (or implies) that there is one future.
Most of my "beef" is the way the article is written/positioned. HTMX may be an interesting approach for some use cases.
If you have a Design System that follows a Design Language:
This is why React/Svelte/Solid/Angular/Vue are so popular.
Although I don't agree with most of the article, this part made me think
I never considered how much time and effort me and my peers have to do to coordinate responsibilities and JSON contracts
That's why you have standard REST implementations like OData and GraphQL. The contract between frontend and backend should be standardized to make life easier for both parties involved.
I've recently listened to Is HTMX the way to Go and since then I also think I'll replace alpineJS with HTMX.
Especially when you focus more on SSR (server-side rendering) and don't have complex front-end workflow, HTMX and tailwindCSS can be a beautiful combo. And if you need more spiciness you can still use alpineJS for more advanced stuff.
I'm reading hypermedia.systems now, and while this is clearly an interesting resource and htmx an interesting technology, I'm baffled by some of the authors assessments of front end development... Or I would be, if I hadn't encountered them before in the wild by JavaScript developers. Namely, statements like this:
What? Yes, I know there are people who think this way... But they are wrong. The reason Node is good for backend development is because it is a robust technology coupled to a great programming language. Even server side rendering with React frameworks is primarily about optimization and SEO, not about code reuse or overcoming of any hurdles of having code on the UI and the server, which will always happen.
Which brings me to the htmx concept of decoupling, which is also weird: the claim being that by returning html/x, a hypermedia, since the client doesn't need to know about it in advance to render it, it decouples server and client. Which I guess it is true in a way, but it also couples them in the sense that now this can only be changed by altering the server side code. If I get html from the server then I cannot really change it all that much, but if I get an object I can parse it however I want and present it in different ways. The convenience here is mostly that one method empowers the server and the other empowers the client, and I think they both have their use cases, but saying that one of them is more decoupled than the other seems wrong to me.
Still, I'm glad I came across this resource, and will continue to read with a critical eye.
Yep, it's so obvious that HTMX is for backend centric developers that hate frontend.
These kinds of teams would have flocked to projects like: Bootstrap.js, Foundation.js.
Anything that helps them avoid writing .js or .css files.
Interesting, TIL.
It is a different direction of the current frontend stack development.
Funny, I used this approach pretty much exactly in an application that was built before the SPA craze, using jQuery to power it. In the frontend I used regular HTML forms and links with data- attributes to declaratively add submit/click listeners that would make the POST/GET with AJAX, and in the backend I checked for the JSON request header and either returned an HTML partial, or rendered a full page for a GET request or returned a redirect for a POST request. It worked great and was considered progressive enhancement as the application still worked if Javascript was disabled.
Interesting how things are coming full circle!
This was a simplifiction. HTMX adresses a lot of topics, but as content more and more comes from a server, it seems to be the most important aspect to reflect changes in the UI without page reload.
Assume, someone wants to build a simple calculator app, which is a pretty simple thing in Javascript. Can you describe, what is necessary to do this with HTMX, if you do not use any JS?
Sure, but who said you can't use 'any JS' if you use htmx? Many people, including myself, sprinkle some custom-written JS in our apps to handle corner cases or special functionality that we don't feel is a fit for htmx. It's not all or nothing! Use the right tool for the right job.
This doesn't get rid of JavaScript. It just uses a JavaScript library to do the heavy lifting. The browser still has to know JavaScript.
I haven't checked out HTMX, but I do think SPAs are far from being the perfect version of what a web app can be. It feels like the need for dynamic content, paired with the high speed of processors and bandwidth, nudged us in adding lots of dependencies for all needs, big or small. Hopefully we'll keep working on simpler solutions with great UX.
Isn't HTMX something like Alpine.JS ?
They're similar in approach, but complementary: htmx is about navigation and form processing (everything that makes HTTP requests) whereas Alpine.JS is for every other kind of interactivity on your page. There's of course a bit of overlap, but they have different goals.
htmx.org/ more focused on AJAX, WebSocket, and Server Sent Events. hyperscript.org/ more focused on interactivity.
Both came from bigsky.software/
What is the mime type for a html fragment ? It cannot be text/html since it is not, or at least it is not designed as a standalone page. We need it in both headers so the server know when to serve a standalone page and when to serve a fragment.
text/html? It's valid HTML that is accepted by any browser.HX-Request: truein all requests that it sends, so the server knows when to serve a full page or fragment.Save this for reread later.
"How did you feel when class components became "bad", and everyone wanted you to use hooks instead?"
For me, this now doesn't matter anymore, because I now like Hooks.
As for REST, one of its constraints that I still don't really know how to implement is :
Hypermedia as the Engine of Application State (HATEOAS). I haven't seen real example code of it in application examples. It seems that only few people who implement it in their apps.
There's also Hotwire from Basecamp
If you like this way of coding, look at :
MavoJS
Regards
HTMX adds a custom HX-Request header to every request so your server can make the distinction and render the proper content (full page or fragment).
You can add Alpine.js for JS. It works perfect with HTMX. I recommend reading hypermedia.systems/
And, how do you count from 1 to 10?
If we are going to argue ignoring the abstractions and semantics of the technology, then we can ask, how do you write to a file on the computer with JavaScript in the browser?
You know, this is a limitation "by design", but referring to fetching dynamic content from a server, I totally agree that using plain javascript is far from being ideal. But the question is: do we create a new wrench for every bolt we have?
We already have an inflationary use of keywords:
Not counting the overwhelming number of attributes and properties you may need. HTMX adds another 120 elements to this alphabet soup, and we should not forget CSS. Tools like tailwind tend to push every kind of logic also into html attributes. I´m just asking, if THAT is our "future"?
The problem I have with this criticism is, what is constructive about it? You are criticizing an arbitrary metric that you are saying htmx is exceeding, but what's the point? Each attribute, request and response header, and event in htmx exists for a specific reason. And it's not growing unboundedly. If you have a problem with abstractions in general then this may come as a surprise to you, but in computing the main problem-solving strategy is abstraction. So it's not really helpful to say 'but this introduces new keywords'. So what? The number of new names introduced doesn't really matter at the end of the day, what matters is–is each concept solving a problem?
The number of new keywords introduced matters, as somebody has to learn how to use them. Programming languanges intoduce a relative small and universal set of keywords, that are intended to let you solve any possible problem by using algorithms or API´s.
Let me take counting as an example. Loops are a very basic concept of any programming language that let you increment numbers in a certain range.
The people at google, that invented angular, saw the need to display the content of a list in the UI, so they introduces a new keyword: ng-for. The same did Evan You, that introduced v-for. Svelte introduces EACH, wich is similar to React, that only lets you use map.
So, here we have four new keywords for looping, but each of them introduces a different concept.
Now, you may have a task where you need to use a reverse order, oder display only every second element of a list or start with 7. Well, this is not so simple. You will find hundreds of web pages that explain, how to solve this "not so simple" problem in Angular, Vue, Svelte and React. Well, in Javascript we already had more than one solution, why can´t we use it? All four frameworks are built ontop of JS.
Now we have HTMX, that is intended to extend the HTML standard by introducing another 120 new keywords just to solve the problem of dynamic page reload in a way, that is similar to what we alredy know from react. For every keyword a user will have to read the manuals, learn how to use it, not talking about the tools on the server side that is needed to make htmx work.
Maybe htmx is a nice gimmick for a certain class of web pages. But if you state "THIS IS THE FUTURE", I would like to set a questionmark at the end.
It's hard to take your argument seriously when you are exaggerating to this extent by saying that we need 120 keywords 'just to solve the problem of dynamic page reload'. The core functionality of htmx is in a couple of task-oriented attributes that you add to the HTML, almost everything else is set to a good default and is there to allow you to override defaults. You should maybe use it before critiquing–your argument might be taken seriously.
using the browser javascript api?
I mean just a little bit of googling will have brought you to developer.mozilla.org/en-US/docs/W...
React only introduces JSX. and so
[].mapis not a new concept.HTMX is just a time saver for people who hate writing javascript.
It'll create the same "corner painting" problems that bootstrap and foundation does.
All these wireframing tools promise faster roadmaps for your projects, but then you get the "10% takes 90% of the projects time" problem.
The reason for the "10% takes 90%..." is the lack of universality.
Think of a system that introduces 10 new commands:
It was created by people that usually only need to count from 1 to 10. They find in handy to have a shortcut for every common task, much easier thant writing all this complicated for (;;)-stuff.
But now you need to count from 0 to 10, or want to skip 5, count reverse or whatever. So, now you need a workaround....
What about all kinds of stuff JavaScript can do client-side without the need of a server, so potentially even offline trough service-worker?
is HTMX just django feature ? I'm from JS world
htmx is backend agnostic. See this and this
XD
You might not have an opinion, but what are your thoughts on good CSS approaches (whether a guideline or a library) to make the most of HTMX?
There's a valiant CSS library who is HTMX' squire.
missing.style
There's a fine book too:
hypermedia.systems