Clojurians Log v2

I probably don’t understand DataStar (or Electric) well enough, but isn’t DataStar pure RPC? Seems like it would be apples-to-pears with Electric if so.

I wonder how it would fare in expressing something like

(e/client (println (e/server (+ 1 (e/client (* 2 3 (e/server 4)))))))

https://clojurians.slack.com/archives/C7Q9GSHFV/p1744196532655349?thread_ts=1744118647.551529&cid=C7Q9GSHFV Datastar author here... cheating seems disingenuous. I could at 100s without much issue. At the time I did it the Go SDK didn't have compression by default so I was afraid of getting kicked from the free tier on http://fly.io. Now though i probably should update it

you're right that technologically they're very different. I think the question is more high-level though, i.e. given a project how would one deliver it with datastar and how with electric. The "how" can be many things, time it took, lines of code, performance, meeting all the requirements, maintenance etc.

Yeah, absolutely. But I often feel like many frameworks, including the LiveView-like ones, will get you quite far, until you hit a certain level of domain/business/other complexity, and then it gets really hairy. To me, it feels like Electric is walking the path of web UI being a special case of a more general model of computation. Theoretically, if you solve computation, rather than solving web UI specifically, any problem encountered is solved in the language of computation rather than, for example, extending the framework DSL (or switching to another when it falls apart). My example above looks contrived, but we have instances resembling that shape in our codebase, where a small dance between client and server is required to express the job that needs to be done, and how clearly and directly it can be expressed would be one benchmark for me.

Let, me start with I'm a big fan of Electric and I stumbled on Datastar because I was wanting something similar to electric with a tiny bundle (there were other considerations: I didn't want websockets, I wanted to be able to patch with a production repl, not have a compile step and use hiccup). These are not negatives of the project, just my personal trade offs. I'd say datastar, and/or the hyperlith approach to Datastar has a few small insights that may or may not be useful to Electric (Datastar is a lot less elegant/sophisticated): • Morph means you return the whole page view and it will be efficiently merged into the DOM. Replacing is actually faster (with modern browsers). But, then you lose scroll position, video stops playing, you don't get fine grained animations etc. So morph solves those things for you. • When you have minimal JS on the client and are not parsing HTML instead of JSON the browser is wicked fast (like really, really fast). • Network, returning a lot over the wire makes things slow. But rather than backend diffing you can let compression over a stream be much more efficient and performant diffing for you. So you get tiny packets for good latency. • State you keep it all on the backend, so there is no managing distributed state. There are escape hatches for this. • Push, using SSE you still have a reactive system. So the model fundamentally stays as view = f (state). • Reactive signals on the client let you do the cute client side things if/when for whatever reason you think the network isn't fast enough. • You can use it to drive web components. Delaney (the author of datastar) has talks where he's driving a game engine wrapped in a web component on the client from the back end. The UI is composable because everything is on the back end. You get simple state management because everything is on the backend. There's still the question of how you manage those updates on the backend, the ideal would be reactive queries/view maintenance and or something like missionary. In practice, I've mostly settled on defining a granular resolution (max refresh rate), and caching. This is much less elegant than something like missionary, but it allows the programming model to be kept simple in user land. Anyway, not here to promote (hyperlith is not intended to be used by anyone but me, as it makes a bunch of other quirky decisions and was only open sourced because people wanted Clojure examples of a CQRS approach to Datastar). Just thought this might be useful for your discussion.

my main objection to datastar (as compared to Electric!) is that this hypothesis has been invalidated imo for the types of apps Electric is designed to solve: > State you keep it all on the backend, so there is no managing distributed state. There are escape hatches for this. If datastar has specific insights as to how its escape hatches do not result in the same problems that HTMX, LiveView have, then I am listening! Electric has users who have come from those approaches and abandoned them

the page load perf stuff is nice to have. from a business perspective page there are page load times and there are interaction response times. Electric page load times are fast enough (relative to, like, the database queries, and relative to our primary competitor React) that we dont even bother to measure.

differential dataflow is not just about efficient transport, it's about efficient effects and efficient use of the platform. the electric frontend does not perform O(n) loops over anything ever. not in userland, not internally, the computation is incremental from end to end. diff-by happens on the server. Whether this hypothesis pays off, we will see, but we at least have state-of-art enterprise demos that afaik zero other teams have, i.e., electric is the current world leader for our target app category and it does not seem particularly close. Datastar is not even part of this comparison, as it has provided zero competitive demos!

and if we are hyperoptimizing interaction times (Delaney brags about pushing 1gbps through the web GPU or something, the claim was vague), the Datastar table scroll demo is a text-only table with fixed layout. When Electric renders a text-only static layout grid, the browser engine is able to move the DOM rendering to the GPU. the scroll flies. My jaw dropped when I felt it. And this is over remote collections. We haven't published the demo yet because text-only tables are really uninteresting from an enterprise perspective

Completely agree with the incremental computation/dataflow and that's why I'm still bullish on where Electric goes next. I'd caution the examples on Datastar website are entry level, to help regular web devs do regular web dev things. With any backend (rather than a more tuned CQRS style backend). The backend is also very much up to you. There are some more realtime examples: https://data-star.dev/examples/bad_apple and: https://data-star.dev/examples/dbmon This talk gives you a better idea of what you can do (especially when it comes to using the GPU). It's a bit dated Datastar has got much smaller and faster since (also before I went super deep on SSE compression): https://youtu.be/0K71AyAF6E4?feature=shared&t=1150

dbmon is still cheating, electric v2 had fast virtual scroll over 20 rows, this table is tuned to 12. electric v3 can do fullscreen

I've not used Electric or Datastar. But I'm a backed dev that's done desktop apps, and was trying some web frontend development. One thing that I've always found jarring in web apps, is that the entire page is coupled together. Maybe it's just OCD for me. But I like being able to create independent widgets that then expose hooks and events for the rest of the page to interact with. For example, a search box simply captures search and publishes the search term. And can also be pushed auto-complete. Another widget might display search results in real time, but it's unaware a search widget even exists. It doesn't know its ID, or if it's even present on the same page. It only cares to show search results. Now when you build up a page, you compose it with all these independent widgets, and connect them together with some glue as well as connect them to possible backend effects like performing a DB query, sending an email, running a compute, etc. I've found it very tricky to organize things this way for web apps. My first impression with Datastar is that, it's geared towards the full page approach, and so not towards what I'm describing. Maybe if used with web components, or if there's a way to decouple how I'm explaining fully on the backend side. And so I'd have a similar question with Electric. And I'm also willing to maybe just be outdated in my view of organizing front ends. Maybe embracing full page apps is better, and I'm just not used to it.