David-Guillot

> These "we cut 70% of our codebase" claims always make me laugh.

There's also a slide in my talk that presents how many JS dependencies we dropped, while not adding any new Python. Retrospectively, that is a much more impressive achievement.

Thanks to Chris to continue challenging his comfort zone (and mine!) and sharing his impressions and learnings with us!

I may be a little biased because I've been writing webapps with htmx for 4 years now, but here are my first thoughts:

- The examples given in this blogpost show what seems to be the main architectural difference between htmx and Datastar: htmx is HTML-driven, Datastar is server-driven. So yes, the API on client-side is simpler, but that's because the other side has to be more complex: on the first example, if the HTML element doesn't hold the information about where to inject the HTML fragment returned by the server, the server has to know it, so you have to write it somewhere on that side. I guess it's a matter of personal preference then, but from an architecture point-of-view both approaches stand still

- The argument of "less attributes" seems unfair when the htmx examples use optional attributes with their default value (yes you can remove the hx-trigger="click" on the first example, that's 20% less attributes, and the argument is now 20% less strong)

- Minor but still: the blogpost would gain credibility and its arguments would be stronger if HTML was used more properly: who wants to click on <span> elements? <button> exists just for that, please use it, it's accessible ;-)

- In the end I feel that the main Datastar selling point is its integration of client-side features, as if Alpine or Stimulus features were natively included in htmx. And that's a great point!

Of course, but when you'll get to build your web UI, server-side generated HTML will not be the right choice.

My feeling as an old-time "web developer" who has been bullied into becoming a "back-end dev" is: thank you, I think I know quite well the basics of standard front-end technologies, but suddenly some people started yelling at me "you're a grandpa, now you can't send HTML from the server anymore, it's lame, you have to send to the browser a JS app that will manipulate the DOM live instead". This new (in 2015) approach has flooded our brains with a deluge of libs, frameworks, tools, concepts, problems, etc. which are a lot more than 5% of the effort of bootstrapping a React app, let alone optimizing it and maintaining it. I know people who's main job is creating React apps and who are overwhelmed with the complexity of the stack. If you don't hire someone dedicated, the rest of your product (domain rules, database optimization, infrastructure, devops, etc.) will suffer.

I know so-called "senior frontend engineers" whose speciality is React, and who can't handle React. So all others...

This thing (and others like Vue, let me be clear) adds many layers of complexity over the web platform (client-side routing, data fetching, state management, rendering, etc.) and many third-party JS libs that you have to constantly update. You just can't say that it's standard/base web development.

To be accurate in the past year we went from 3 to 7 in that team, and I think everyone has been using htmx at least once, and 4 of us are using it on a regular basis.

Cost.

React will require you to hire a React dev to handle all the complexity.

htmx will be mastered by your "back-end" devs (who actually are web devs) less than a week.

Hi! Sorry for the delay. I'm the one who gave this talk.

Yes, rendering HTML on server-side increases server load, for the simple reason that the server-side templates contain some display logic. But:

- Most SPAs I've seen generate useless server load: either by fetching too much information, or by fetching information too often. And that's not because SPAs are a bad idea per se, it's because many small companies have very small teams, and very small teams just don't have time to build a custom-tailored API ("backend-for-frontend"). We chose jsonapi with Django-Rest-Framework, which was crazy-easy to implement from the back-end perspective (as we had many other challenges), but which made the front-end developer implement twisted stuff on client-side, like prefetch-on-hover, or plugging react-query with crazy refresh settings generating hundreds of API calls when only 2 or 3 would have been enough. At the end of the day our servers load is not higher now. Each request costs a little bit more, but there are a lot less of them.

- Another thing is: the idea of delegating template processing to the client may seem good from a wallet perspective. But if you also think of the environmental impact of what we do as developers, you might notice that many people get a new laptop on a regular basis just because some applications are more and more CPU and memory greedy. And when you think that about 80% of environmental impact of the digital industry is generated by building and shipping new terminals, it might make you realize that being part of the solution implied reducing the amount of client load you ask your users. And yes, this implies that your company accepts to reduce gross margin to take a very small action in the battle for a cleaner industry.

As I said in my other answer: our facet filters are nothing more than hidden inputs in a form. So nobody consults "the state of multiple facet dropdowns", except htmx when it generates the URL of its XHR call. Everything else (filtering items according to querystring parameters, fetching user favorites, etc.) is done on server-side.

I don't see facet filters and favorites as "client-side state": to me it's "application state", changed by a user interaction. And you're right, it's related to how the state is stored.

As you anticipated, favorites are stored in a database on server-side, so that makes "show me my favorite items" or "show me items related to my favorite articles" the exact same feature as selecting an option in a facet filter.

The state of "I have selected options 1 and 2 in this facet filter, and option B in that other filter" is simply stored in... the URL. And this is why I think it's "application state" rather than "client-side state", and this is why the hypermedia is great IMO: this whole search+facets+favorites+sorting feature becomes nothing more than a <form> with hidden inputs, generating GET requests which URLs are put in the browser history (keywords search, selected options from facet filters and sorting are put into querystring parameters). And that's great, because it happens that one of our features is to send our users custom e-mails with deep links to this the UI, with facet filters pre-selected. All we have to do is generate links with querystring parameters pre-configured, and the user directly gets to a screen with pre-selected facet options, sorting, etc. To me, such behavior cannot be called "client-side state management".