Reminds me a bit of the Seaside framework in Pharo. A lot of the things I programmed in Pharo at my previous employer was a lot of back and forth between front-end and back-end, because the back-end was managing the front-end state. For B2B apps that don't have a lot of latency requirements, etc., I'd say it's better. For high scalable B2C apps though? No.

Could you expand on why you think it (back-end managing the front-end's state) is better in the scenarios that you do?

Edit - rather than spam with multiple thank you comments, I'll say here to current and potential future repliers: thanks!

Not GP, but I would say, it’s the same reason someone would use React. If you keep you state in a single place, the rest of the app can become very functional and pure. You receive data and tranform it (or render it). The actual business logic that manipulate the state can be contained in a single place.

This reduces a lot of accidental complexities. If done well, you only need to care about the programming language and some core libraries. Everything else becomes orthogonal of each other so cost of changes is greatly reduced.

I would imagine the same arguments for Smalltalk like live coding and an IDE within your production application. So you get some overlap with things like Phoenix LiveView, but more smalltalk-y.

I assume it had backend scaling issues, but usually backend scaling is over-stated and over-engineered, meanwhile news sites load 10+ MB of javascript.

"Alpine or Stimulus features were natively included in htmx"

I'm contemplating using HTMX in a personal project - do you know if there are any resources out there explaining why you might also need other libraries like Alpine or Stimulus?

They're for client-side only features. Think toggling CSS classes, updating the index on a slider- you ideally don't want to have to hit the server for that

Thanks - I was having a quick read of the documentation for those projects and that makes perfect sense.

if you use alpine, make sure to get the morph extensions for both htmx and alpine.

I'm really just starting with htmx but came across datastar yesterday. This is a great comparison and is confirming some of my impressions, so thanks! I'll still look a bit more but if the main thing is that it's naively adding Alpine or Stimulus then datastar is not for me.

its not like that at all, read the guide and build something before passing judgement

:pointing-up-emoji:

> I'll still look a bit more

I was going to because I like the architecture, but then I saw the fact that licensing changes are going to be frequent, and that the developers seem a bit aggressive on another thread, and I've decided to skip it.

Datastar developers are free to do what they want with their code, but as someone who releases open source software, I'm tired of projects using open source simply to create a moat or user base then switch to a proprietary model.

> then I saw the fact that licensing changes are going to be frequent

What are you referring to here? Sounds important.

Edit: Looks like its this < https://drshapeless.com/blog/posts/htmx,-datastar,-greedy-de... >

NOTHING changed about the license. FUD

> 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'm not too strong in frontend, but wouldn't this make for a lighter, faster front end? Especially added up over very many elements?

100%. Datastar is just make HTML spec support reactive expression in data-* attributes, that's it. You will become stronger at web cause it just gets out of your way

I don't think the difference would be significant. How many of your HTML elements would become interactive with htmx? There's a limit to how much interaction you can reasonably add on a page. This will also limit the number of new attributes you will introduce in the markup.

Also, by this argument should we leave out the 'href' attribute from the '<a>' tag and let the server decide what page to serve? Of course not, the 'href' attribute is a critical part of the functionality of HTML.

Htmx makes the same argument for the other attributes.

The article stated that he no longer needs eventing to update other parts of the page, he can send down everything at once. So, I guess that is much less complex. Granted, eventing and pulling something down later could be a better approach depending on the circumstance.

You can send everything down at once with htmx too, with oob swaps.

yes you can, but the complexity is now moved to server side template wrangling. With SSE, its just separate events with targets. It feels much cleaner

Server side template wrangling is not really a big deal, if you use an HTML generation library...something like Python's Hpty/FastHTML or JavaScript's JSX. You can easily split the markup down into 'components' and combine them together trivially with composition.

I mean in practice you rarely target individual elements in datastar. You can sure. But targeting the main body with the entirety of the new content is way simpler. Morph sorts out the rest

A good example is when a page has expensive metrics specific to say a filter on the page. Let's say an action on the page shows a notification count change in the top right corner.

While morph will figure it outz it's unnecessary work done on the server to evaluate the entire body

Expensive queries on the server should be shared where they can be (eg: global leaderboard) or cached on the server (in the game of life demo each frame is rendered/calculated once, regardless of the number of users). Rendering the whole view gives you batching for free and you don't have to have all that overhead tracking what should be updated or changed. Fine grained updates are often a trap when it comes to building systems that can handle a lot of concurrent users. It's way simpler to update all connected users every Xms whenever something changes.

I agree on caching. But in general my point stands. The updates in question may not even be shared across users, but specific to one user.

Philosophically, I agree with you though.

Yeah so that was how I used to think about these things. Now, I'm. less into the fine grain user updates too.

Partly, because the minute you have a shared widget across users 50%+ of your connected users are going to get an update when anything changes. So the overhead of tracking who should update when you are under high load is just that, overhead.

Being able to make those updates corse grain and homogeneous makes them easy to throttle so changes are effectively batched and you can easily set a max rate at which you push changes.

Same with diffing, the minute you need to update most of the page the work of diffing is pure overhead.

So in my mind a simpler corse grain system will actually perform better under heavy load in that worst case scenario somewhat counter intuitively. At least that's my current reasoning.

> htmx is HTML-driven, Datastar is server-driven

As far as I understand, the main difference between HTMX and datastar is that HTMX uses innerHTML-swap by default and datastar uses the morph-swap by default, which is available as an extension for HTMX [1].

Another difference is that datastar comes with SSE, which indeed makes it server driven, but you don't have to use SSE. Also datastar comes with client-side scripting by default. So you could say the datastar = integrated HTMX + idiomorph + SSE + Alpine.

[1] https://htmx.org/extensions/idiomorph/