Build time might be a bit of a red herring, as I bet it was webpack. esbuild is absolutely blazing fast and gets rid of that whole axis.
I do think that measuring what happens in practice rather than theoretical minimums is good, and like up until recently webpack was unfortunately “the thing”, but at least on that front there are ways to make improvements without having to manipulate the universe
Perhaps a more important change is that the entire team became “full-stack” developers, instead of having a hard front-end/back-end split. That’s huge, in my opinion
One challenge I’ve found in that front is that if you want good frontend developers it’s very hard to find those that are also willing to deal with backend development, or having much of any skill there. There are many good backend developers that are alright at dealing with frontend, but above a certain quality bar it’s basically impossible.
I do think it’s great to be able to have people who can really handle the entire stack, but there are issues with mandating fullstack-ness, so you gotta be a bit careful there. This is “solvable” by pairing people up but then you get into another can of worms based on who you have on the team.
Is that split really front-end vs back-end or infrastructure vs UI? I’ve not done serious web development, but my guess would be that it’s hard to find good interaction specialists but much easier to find people who can write code that runs on either end of a network connection. Are there teams where ‘UI designer’ is a separate role but the engineers work on the whole of the application stack?
Are there teams where ‘UI designer’ is a separate role but the engineers work on the whole of the application stack?
So I’ve worked on a team that ended up almost there. There was one “pure” UI designer, and another who was UI design but liked coding. There were a lot of growing pains because he couldn’t properly prototype stuff due to our backend being hard to run for people not used to the terminal.
They both could get work done provided the right tools! But the tooling we had was made (essentially) for backend engineers, so it was a huge amount of friction. That and there was just a different kind of workflow.
But yeah, the overall lesson was that there were people able to do the work we really were missing from the team (remember, the other engineers could write code in both domains! Just the frontend code wasn’t great), but those people could not really work on the team without us adjusting expectations about infra-related demands
Yes, but we have strong evidence from the old days, pre-SPA frameworks, that server-rendered templates are manageable for developers who also do back end work.
It was only when SPAs and their attendant complexity came along that the split between front-end and back-end became pronounced.
I haven’t observed that at all. Real frontend specialty, like advanced CSS and UX stuff, has always been taken care of by frontend specialists. Everything in between, pretty much anyone can do.
The evidence being that full stack development was a relatively common thing pre-SPA era.
Not saying that there won’t always be designers involved, especially once you start talking about externally facing applications. But htmx puts full stack back on the table as a potential option in a way that SPA libraries and their attendant complexity do not.
Early in the talk, the speaker said that having a “rich” UX has to do with making the user forget they’re in a web browser. I don’t think this is a good goal. To me, this suggests that web developers are trying to prove that the web is not inferior to native platforms. But I think the web is already better in some ways, and the strengths of the web shouldn’t be hidden or even negated beneath an attempt to mimic native apps. So in my web development, I work with the grain of the platform as much as possible, including real browser navigation between pages, and deviate from that only as much as is necessary to make customers and other stakeholders happy. So I don’t think I’d even use most of what HTMX has to offer, never mind the SPA approach that React is known for.
This point is moot. It’s not that the web is trying to emulate native platforms, it’s that web applications have totally outgrown the original hypertext model.
You can build “classic style” web sites if you want, but there is no world where that style can handle all application needs.
Hi there, I’m the author of the talk, sorry for the delay for answering your comment.
It was clearly not my intention to suggest that “web developers are trying to prove that the web is not inferior to native platforms”. I’‘m not into judging platforms, that’s irrelevant to me. My intention was to start from the idea that often justifies the decision of taking the SPA path. Many people talk about “Featuring a rich UX”, but often we don’t even know what they are talking about. I just tried to explain what is my understanding of a “rich UX”, which is, precisely, taking advantage of both web and native platforms. Maybe my way of saying it like “making the user forget they’re on a web platform” was clumsy.
It might be less code for this one application. But I feel like everyone agreed that Angular-style directives have a very low ceiling, and eventually you just want the power of a programming language to generate your actual markup. This way you’re not stuck wading through tons of documentation to figure out the arcane attribute syntax for some hyper-specific use case.
You have to find the specific attribute that you need (hx-trigger) and then you have to work with the inner scheduling DSL for when to poll (every 2 seconds). What if I want to poll every odd hour? What if I want to poll only on Mondays?
I’m sure there’s a place where this is useful, maybe for small applications or side projects. It probably is slightly quicker initially. But I’m not alone in abandoning this style of UI development a long time ago.
For more dynamic polling, I would write a small script to trigger an event, and then listen for that event.
The crux of htmx is hypermedia: exchanging hypermedia with a server and using hypertext as the engine of application state. It will work well for some types of applications, and size is less important than the flavor of the application: gmail would be great as a hypermedia application, google sheets would not. The core question is: can the UX I desire be achieved with hypermedia and my hope is that, with htmx, the answer to that question is “yes” for a larger subset of applications.
I definitely agree that there are appropriate hypermedia applications - for me, it’s static content like blogs. I always classified gmail as the exact kind of application that is not good for hypermedia. In fact, Gmail is the complete poster child for AJAX and SPAs. It’s always referenced as one of the first applications that used the SPA style, and I think that makes total sense.
I think you could build a very nice email client entirely in htmx, using hypermedia clients. I like to mention GMail because it was done as a SPA and, in my opinion, didn’t need to be. Certainly what react was created for, to append a comment to a comment list, didn’t require an SPA. Something like Sheets or Maps, on the other hand, would be hard to implement using the hypermedia network architecture.
In general my hope is to expand the class of applications, dynamism & the general UX level that people feel they can achieve with hypermedia:
This is the exact kind of considerations I’m trying to address with my talk. In the demo part I show a faceted search engine, with a special facet option that updates its results according to a change on server state which is the consequence of a user action elsewhere on the page. Pretty far from “static content”, “small application” or “side project”, don’t you think? It’s the same level of complexity that what you can find on Gmail UI.
Yeah, I tend to prefer Alpine.js because even though it is inspired by Angular/Vue, at the end of the day, it’s just JavaScript. If you wanted to make a polling directive in Alpine, you would just write the normal window.setInterval code for it, instead of going into some “inner platform” language.
As they say in the talk, when they were beginning they were told they had to use react for their application to be “modern”. Sadly, many people think that that’s true, and don’t realize that there are hypermedia-oriented options like htmx, unpoly and hotwire that can give you more interactivity within the hypermedia model. So they end up going react, because everyone else is, and that’s what HR hires for.
I’m not the speaker, I’m the creator of htmx, so not an unbiased source. :)
David mentions unpoloy and hotwire, two other excellent hypermedia oriented options in his talk, and he uses Stimulus for some javascript (rather than my own hobby horse, https://hyperscript.org) but he didn’t say why he picked htmx.
Generally, I would say:
htmx is lowest level, very focused on extending HTML
unpoly is more batteries-included and supports progressive enhancement better
hotwire is the most automagical of the bunch, and very polished (+ mobile support)
We chose htmx because of its simplicity (data-attribute driven, very few but very generic features). We evaluated:
hotwired, which would have been a great option since it works particularly well with Stimulus that we were already using on another project. It seemed just a bit too much complicated because it introduces new markup tags, and it has a strong emphasis on real-time stuff that we did not need.
unpoly, which was pretty similar to htmx at first sight. But it seemed to us that the community was less active, so we didn’t push the evaluation further
Hi there, author of the talk here, sorry for the delay.
Our application is not an article aggregator, it’s much more complex than that: it presents future laws being discussed in French parliament. The right part is the text that is being discussed, and on the left you have the amendments filed by parliamentarians, and which aim to change the text.
But still, you’re right: “Why would you have used react for a site like this in the first place?” is precisely the question I asked when I discovered the modern tools of the hypermedia approach. But not because our application is simple: because the hypermedia approach can achieve a lot more than what most people think. It’s not just for “article aggregators”, “student projects”, “quick prototyping”, “small personal websites” and simple CRUDs. All day long I use professional tools that would benefit the hypermedia approach: Gmail, Sentry, AWS console, and others…
And this is what my talk is about: breaking the FUD spread by some people about what is doable with “old-school” web apps (web pages) and what is not doable with that approach, thus requiring the whole API+SPA stack.
TLDR:
Took 2 months (21K LoC, mostly JavaScript)
No reduction in user experience
Reduced LoC by 67% (21,500 LoC to 7200 LoC)
They increased python by 140% (500 LoC to 1200 LoC), good if you prefer python to JS
Reduced JS dependencies by 96% (255 to 9)
Reduced web build time by 88% (40s to 5)
First load time-to-interactive was reduced by 50-60% (from 2-6 seconds to 1-2 seconds)
Much larger data sets were possible than react could handle
Memory usage was reduced by 46% (75MB to 45MB)
These are spectacular numbers that reflect that the application in question is highly amenable to the hypermedia approach.
I wouldn’t expect everyone to see this level of improvement, but at least some web apps would.
Build time might be a bit of a red herring, as I bet it was webpack.
esbuildis absolutely blazing fast and gets rid of that whole axis.I do think that measuring what happens in practice rather than theoretical minimums is good, and like up until recently webpack was unfortunately “the thing”, but at least on that front there are ways to make improvements without having to manipulate the universe
Yes clearly we switched from Webpack to esbuild. But this switch was made possible by having a lot less complicated JS stack.
Thanks for the summary! It’s impressive and I can’t wait to use HTMX on a side project
Perhaps a more important change is that the entire team became “full-stack” developers, instead of having a hard front-end/back-end split. That’s huge, in my opinion
agree entirely, splitting on features rather than “which side of the wire” is a huge boost in productivity
One challenge I’ve found in that front is that if you want good frontend developers it’s very hard to find those that are also willing to deal with backend development, or having much of any skill there. There are many good backend developers that are alright at dealing with frontend, but above a certain quality bar it’s basically impossible.
I do think it’s great to be able to have people who can really handle the entire stack, but there are issues with mandating fullstack-ness, so you gotta be a bit careful there. This is “solvable” by pairing people up but then you get into another can of worms based on who you have on the team.
Is that split really front-end vs back-end or infrastructure vs UI? I’ve not done serious web development, but my guess would be that it’s hard to find good interaction specialists but much easier to find people who can write code that runs on either end of a network connection. Are there teams where ‘UI designer’ is a separate role but the engineers work on the whole of the application stack?
So I’ve worked on a team that ended up almost there. There was one “pure” UI designer, and another who was UI design but liked coding. There were a lot of growing pains because he couldn’t properly prototype stuff due to our backend being hard to run for people not used to the terminal.
They both could get work done provided the right tools! But the tooling we had was made (essentially) for backend engineers, so it was a huge amount of friction. That and there was just a different kind of workflow.
But yeah, the overall lesson was that there were people able to do the work we really were missing from the team (remember, the other engineers could write code in both domains! Just the frontend code wasn’t great), but those people could not really work on the team without us adjusting expectations about infra-related demands
How does HTMX make full stack dev any easier? You still need to know about the browser, HTML, forms, etc.
Yes, but we have strong evidence from the old days, pre-SPA frameworks, that server-rendered templates are manageable for developers who also do back end work.
It was only when SPAs and their attendant complexity came along that the split between front-end and back-end became pronounced.
I haven’t observed that at all. Real frontend specialty, like advanced CSS and UX stuff, has always been taken care of by frontend specialists. Everything in between, pretty much anyone can do.
What evidence is that? As amw-zero already said, we’ve always had UI experts for that stuff.
The evidence being that full stack development was a relatively common thing pre-SPA era.
Not saying that there won’t always be designers involved, especially once you start talking about externally facing applications. But htmx puts full stack back on the table as a potential option in a way that SPA libraries and their attendant complexity do not.
Early in the talk, the speaker said that having a “rich” UX has to do with making the user forget they’re in a web browser. I don’t think this is a good goal. To me, this suggests that web developers are trying to prove that the web is not inferior to native platforms. But I think the web is already better in some ways, and the strengths of the web shouldn’t be hidden or even negated beneath an attempt to mimic native apps. So in my web development, I work with the grain of the platform as much as possible, including real browser navigation between pages, and deviate from that only as much as is necessary to make customers and other stakeholders happy. So I don’t think I’d even use most of what HTMX has to offer, never mind the SPA approach that React is known for.
This point is moot. It’s not that the web is trying to emulate native platforms, it’s that web applications have totally outgrown the original hypertext model.
You can build “classic style” web sites if you want, but there is no world where that style can handle all application needs.
Hi there, I’m the author of the talk, sorry for the delay for answering your comment.
It was clearly not my intention to suggest that “web developers are trying to prove that the web is not inferior to native platforms”. I’‘m not into judging platforms, that’s irrelevant to me. My intention was to start from the idea that often justifies the decision of taking the SPA path. Many people talk about “Featuring a rich UX”, but often we don’t even know what they are talking about. I just tried to explain what is my understanding of a “rich UX”, which is, precisely, taking advantage of both web and native platforms. Maybe my way of saying it like “making the user forget they’re on a web platform” was clumsy.
It might be less code for this one application. But I feel like everyone agreed that Angular-style directives have a very low ceiling, and eventually you just want the power of a programming language to generate your actual markup. This way you’re not stuck wading through tons of documentation to figure out the arcane attribute syntax for some hyper-specific use case.
A concrete example of this is polling. Here is the HTMX documentation for polling: https://htmx.org/docs/#polling.
You have to find the specific attribute that you need (
hx-trigger) and then you have to work with the inner scheduling DSL for when to poll (every 2 seconds). What if I want to poll every odd hour? What if I want to poll only on Mondays?I’m sure there’s a place where this is useful, maybe for small applications or side projects. It probably is slightly quicker initially. But I’m not alone in abandoning this style of UI development a long time ago.
For more dynamic polling, I would write a small script to trigger an event, and then listen for that event.
The crux of htmx is hypermedia: exchanging hypermedia with a server and using hypertext as the engine of application state. It will work well for some types of applications, and size is less important than the flavor of the application: gmail would be great as a hypermedia application, google sheets would not. The core question is: can the UX I desire be achieved with hypermedia and my hope is that, with htmx, the answer to that question is “yes” for a larger subset of applications.
I definitely agree that there are appropriate hypermedia applications - for me, it’s static content like blogs. I always classified gmail as the exact kind of application that is not good for hypermedia. In fact, Gmail is the complete poster child for AJAX and SPAs. It’s always referenced as one of the first applications that used the SPA style, and I think that makes total sense.
I think you could build a very nice email client entirely in htmx, using hypermedia clients. I like to mention GMail because it was done as a SPA and, in my opinion, didn’t need to be. Certainly what react was created for, to append a comment to a comment list, didn’t require an SPA. Something like Sheets or Maps, on the other hand, would be hard to implement using the hypermedia network architecture.
In general my hope is to expand the class of applications, dynamism & the general UX level that people feel they can achieve with hypermedia:
https://htmx.org/examples
It’s a mindset change (reversion?), to be sure, but for many applications it can simplify things quite a bit.
This is the exact kind of considerations I’m trying to address with my talk. In the demo part I show a faceted search engine, with a special facet option that updates its results according to a change on server state which is the consequence of a user action elsewhere on the page. Pretty far from “static content”, “small application” or “side project”, don’t you think? It’s the same level of complexity that what you can find on Gmail UI.
Yeah, I tend to prefer Alpine.js because even though it is inspired by Angular/Vue, at the end of the day, it’s just JavaScript. If you wanted to make a polling directive in Alpine, you would just write the normal
window.setIntervalcode for it, instead of going into some “inner platform” language.I guess I’m a little confused as this site looks like some kind of article aggregator.
Why would you have used react for a site like this in the first place?
As they say in the talk, when they were beginning they were told they had to use react for their application to be “modern”. Sadly, many people think that that’s true, and don’t realize that there are hypermedia-oriented options like htmx, unpoly and hotwire that can give you more interactivity within the hypermedia model. So they end up going react, because everyone else is, and that’s what HR hires for.
Did y’all evaluate the different hypermedia oriented frameworks before choosing htmx? Just curious if there are significant differences.
I’m not the speaker, I’m the creator of htmx, so not an unbiased source. :)
David mentions unpoloy and hotwire, two other excellent hypermedia oriented options in his talk, and he uses Stimulus for some javascript (rather than my own hobby horse, https://hyperscript.org) but he didn’t say why he picked htmx.
Generally, I would say:
We chose htmx because of its simplicity (data-attribute driven, very few but very generic features). We evaluated:
Hi there, author of the talk here, sorry for the delay.
Our application is not an article aggregator, it’s much more complex than that: it presents future laws being discussed in French parliament. The right part is the text that is being discussed, and on the left you have the amendments filed by parliamentarians, and which aim to change the text.
But still, you’re right: “Why would you have used react for a site like this in the first place?” is precisely the question I asked when I discovered the modern tools of the hypermedia approach. But not because our application is simple: because the hypermedia approach can achieve a lot more than what most people think. It’s not just for “article aggregators”, “student projects”, “quick prototyping”, “small personal websites” and simple CRUDs. All day long I use professional tools that would benefit the hypermedia approach: Gmail, Sentry, AWS console, and others…
And this is what my talk is about: breaking the FUD spread by some people about what is doable with “old-school” web apps (web pages) and what is not doable with that approach, thus requiring the whole API+SPA stack.