Threads for David-Guillot
-
Agile does talk about sprints [1]. Scrum does. Scrum is only one interpretation of Agile, and is, most of the time, poorly executed (and that makes me think that it’s either very badly explained or irrelevant, maybe both).
Other ways of searching for agility exist, and some of them tend to implement the kind of focus that you describe, like Shape Up at Basecamp [2]. My team works with something like that, and we’re quite happy about it. The focus that we get makes us very productive, and there’s the “cool down” thing that allows us to recover and get ready for a new batch.
-
Lol the typo: I meant “Agile does NOT talk about sprints”
-
-
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
-
-
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:
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.
-
-
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.
-
True, but who wants to compose frameworks? If you’re thinking composition, you’re already thinking libraries (and there’s nothing wrong with that, but this cannot be an argument against frameworks).
True again, but it actually is their biggest strength: they are not all about the code (the “how?”), they also care about:
Clearly there’s room for libraries and frameworks in this world, why calling one of them “evil”?