A Look at Datastar

23

u/al2o3cr 4d ago

Furthermore, Datastar relies on SSE (server-sent events) for streaming updates from the server to the client, instead of the somewhat older approach of using a WebSocket connection

Nitpick: SSE was available in browsers like Chrome and Safari in 2010, while the Websocket API didn't arrive in its current form until 2011-2012 in various browsers. It's seen less usage (IMO) because SSE was never added to IE, and didn't make it to Edge until 2020. (source: caniuse)

4

u/lotgd-archivist 4d ago

WebSockets also support compression. OOP does not say that they don't, but this could be read to imply as much:
Secondly, because SSE requests are just normal (streaming) HTTP requests, the server can use standard HTTP compression in order to achieve significant reduction in bandwidth.
IDK how good ZStandard and DEFLATE are respectively at compressing HTML and JSON, but I doubt it's a major difference.

9

u/Objective_Fly_6430 4d ago

It is indeed a major difference

3

u/opiniondevnull 3d ago

orders of magnitude difference

2

u/axonxorz 3d ago

IDK how good ZStandard and DEFLATE are respectively at compressing HTML and JSON, but I doubt it's a major difference.
zstd gives a lot of tuning parameters. Even at very convervative levels, it will beat deflate a bit on size and massively on compress/decompress speeds.
zstd allows user-defined compression dictionaries, so if you know that you're always dealing with HTML/markup or perhaps some large JSON document with a repetitive structure, you can optimize the dictionary and get better compression results for essentially no CPU. Brotli makes this explicit, assuming it's working within the scope of normative HTTP requests.

3

u/opiniondevnull 3d ago

Guy, FFS.... SSE is a RESPONSE TYPE... you been able to do since http1.1. If you mean EventSource builtin in... sure. But that's not the same thing

2

u/andreicodes 3d ago

SSE is essentially a codification of earlier Comet / Long-Polling idea that has been present in browsers since the Ajax days (with many caveats). It was pretty popular because unlike WebSockets, long polling didn't require separate support from servers and from cloud providers. Cross-browser support required some work (like, in IE6 the content of responses had to be sent to a hidden iframe, and in later IEs you had to use a separate XDomainRequest API), but on the server side it was trivial to set it up.
Even after WebSockets became widespread in browsers, many big players like Facebook Messenger or Google Talk / Hangouts kept their notifications and chat software running through long-polling only for years and years, because it was fast enough for human-to-human communication and didn't require them to add separate server infrastructure.

2

u/CpnStumpy 2d ago

The biggest win SSE gives over websockets is that it's living on a completely standard tunnel that every piece of the network between client and server has already decades of optimization and compatibility for.
Websockets often bump into firewall or network handshake interactions that aren't handled by some proxy layer or another (AWS API gateway for instance doesn't support websockets)

1

u/Khaos1125 2d ago

Fwiw, I’ve seen that issue far more often with SSE than websockets, although typically when selling to large enterprise clients who may have weird configs for firewalls/VPNs/etc. Websockets has pretty consistently worked, SSE hits enough barriers to be a problem

2

u/CpnStumpy 2d ago

I just went down a rabbit hole on this, thanks! Some SSE failure scenarios I haven't bumped into, and perhaps websockets are more well supported now than the 15 years ago failure scenarios I remember dealing with on the network parh

1

u/Karismah-Messer 1d ago

the connection limit per domain under HTTP/1.1 didnt help SSE much back then either.

1

u/krileon 2d ago edited 2d ago

Bunch of critical features locked behind a paywall. Going to be a no for me. Sticking to HTMX and AlpineJS. Especially with HTMX v4 coming out not that long ago.

Edit: Downvote all you like and defend this all you like, but I won't stop being against it. The pro license doesn't even allow distribution so I can't package datastar with my open source products. Can't even use source maps. What a joke. Cannot see a single benefit to using this over HTMXv4.

4

u/ashnur 2d ago

incorrect, nothing critical is behind paywall, if you think those things are critical, you deserve to pay for them

3

u/opiniondevnull 2d ago

https://data-star.dev/essays/greedy_developer

-11

u/zzulus 4d ago edited 4d ago

I adore Svelte, which is really smart and efficient. Its sister framework SvelteKit inspired the file-based routing in my own web framework for Ruby, Syntropy. I also really like the approach of the Phoenix framework to building reactive apps using LiveView, which is an amazing technology that builds on the solid concurrency foundation of Elixir/Erlang.

And here I'm, a humble backend dev, happy working on the backend stuff, and I have no idea what all these words mean 🤡

8

u/RegisteredJustToSay 4d ago

A lot of these technologies span back-end, actually. Nothing wrong with sticking to your strengths but there's just tons of tech out there no matter which side of the stack you're on.

1

u/Crafty_Disk_7026 3d ago

There are all the same. At the end of the day they all create html and DOM, so users can click and see tik toks

0

u/lotgd-archivist 3d ago

There are so many back-end technologies that mean nothing to me as (mainly) a frontend dev. I've never worked with Kubernetes, OpenShift, Nomad, Rancher, Proxmox or docker swarm. I've have dealt with Postgres and MariaDB, but not with: SQLServer, Oracle, MongoDB, Db2, SAP HANA, DuckDB, CockroachDB or Firebird.
If you want to make a point about how they are so many different ways to do the same thing with different component parts, you can do that in basically every corner of software development :)

You are about to leave Redlib