Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Datastar: Web Framework for the Future?

chrismalek.me

Post reply on HN
Print view View original

121–130 of 161 posts

Re: Datastar: Web Framework for the Future?

#121

Post by rapnie »

The other day I bumped again into Markus Lanthaler's hypermedia adventures with Hydra [0] "Hypermedia driven web API's" dating back from Semantic Web days, and later revived and stalled again as the W3C Hydra Community Group [1]. Though very different it hinted at the great power of hypermedia at the time. And I am very happy to see things getting explored again, in this different and refreshing approach. Greatly enjoyed watching the interview [2] of Delaney Gillilan on the hypermedia-tv Youtube channel.

[0] https://www.markus-lanthaler.com/hydra/

[1] https://www.w3.org/community/hydra/

[2] https://www.youtube.com/watch?v=HbTFlUqELVc

Re: Datastar: Web Framework for the Future?

#122

Post by disgruntledphd2 »

akdor1154 wrote: post #104
andersmurphy wrote: post #39

Earlier quoted context omitted.

But, you can learn a lot doing dumb stuff. I learnt a lot about compression. If you go to google chrome and throttle the site to 3G it will still run fine. Rendering on the server like this will be faster for low end devices than rendering on the client (as the client doesn't have to run or simulate the game). It just gets raw HTML it has to render. Effectively, the bulk of the work on the client will be done by the…

> Rendering on the server like this will be faster for low end devices than rendering on the client (as the client doesn't have to run or simulate the game). It just gets raw HTML it has to render. I'm not sure about that - it's a hypothesis with merit, but as an anecdote, my Firefox on a new reasonably beefy Android gets quite laggy and unresponsive.

Really? That's interesting. On a Pixel 7 with FF, it all renders nicely. A tiny bit of heat but that went away.

Re: Datastar: Web Framework for the Future?

#123

Post by nchmy »

sudodevnull wrote: post #76
nchmy wrote: post #69

Earlier quoted context omitted.

Its possible to run the datastar TS/JS SDK in a service worker, if you want to do (isomorphic with the backend) templating from there or just returning pre-cached html fragments.

Datastar is fully plugin based. If you don't like my take on SSE, cool let's talk. The core is just making data-* attribute into reactive expressions, everything else is a plugin by design. I want it to be OK for me to be wrong without losing the declarative approach

Did you mean to respond to another comment? Because I'm not following either the relevance or tone of your comment.

The parent comment wanted a way to "serve" requests on the client device, so I suggested a way to do that that is also compatible with normal d* usage...

How to get the data to the client and keep it in sync is an entirely other problem that they'd face with any framework/approach. Would be foolish for some applications and perfectly possible for others. Offline/local-first apps are getting considerable attention these days, for good reason.

I'm a big fan and cheerleader of everything you've done. Keep up the great work.

Re: Datastar: Web Framework for the Future?

#124

Post by tauroid »

dalmo3 wrote: post #72

Reading tfa I kept wondering "is this yet another framework where every click is a server round trip?" Judging by the demos¹, the answer is yes? If this is "the Future", I'm branching off to the timeline where local-first wins. ¹. https://data-star.dev/examples/click_to_edit

Counterexample with just local signals: https://data-star.dev/guide/getting_started#data-on

Re: Datastar: Web Framework for the Future?

#125

Post by tauroid »

sudodevnull wrote: post #16
j13n wrote: post #6

This is the second post I’ve seen praising Datastar in the last 24 hours, and once again no mention of the requirement to punch a gaping hole in one’s Content-Security-Policy. If this is the framework of the future, cyber criminals are going to have a bright future!

That's the nature of anything that does this kind of work. React, Svelte, Solid. Alpine has a CSP version but it does so little that I recommend you just accept being a Web1 MPA basic site. I have ideas around ways around this but it's a per language template middleware.

Could you avoid eval by having a CSP mode that forces reactive expressions to only allow functions users have registered with datastar in a lookup table?

Re: Datastar: Web Framework for the Future?

#126

Post by andersmurphy »

fbn79 wrote: post #107
dalmo3 wrote: post #72

Reading tfa I kept wondering "is this yet another framework where every click is a server round trip?" Judging by the demos¹, the answer is yes? If this is "the Future", I'm branching off to the timeline where local-first wins. ¹. https://data-star.dev/examples/click_to_edit

Every time I read "Web Framework" I run. Ripley: These techs are here to protect you. They're frameworks. Newt: It won't make any difference.

Here's the thing datastar isn't really a framework in the traditional sense (ruby on rails), you can bring your own backend and use it in a variety of ways. I use it a push based CQRS style, but you just as easily do request/response, hell even polling if that's your thing.

Re: Datastar: Web Framework for the Future?

#127

Post by andersmurphy »

postepowanieadm wrote: post #105
sudodevnull wrote: post #14

Datastar author here... AMA, but know that Datastar is pure yak shaving for me to do real work stuff so I have no golden calves, just approaches I've seen work at scale.

So how are your server bills? Does Datastar supports caching/prerendering?

So being on the front page of hacker news twice in 24 hours. The multiplayer game of life game is running on a 15.59$/month 4 core AMD 8GB ram shared VPS (hetzner) and only at about 30% load. That's with a Clojure backend running very naive code.

Re: Datastar: Web Framework for the Future?

#128

Post by andersmurphy »

j13n wrote: post #6

This is the second post I’ve seen praising Datastar in the last 24 hours, and once again no mention of the requirement to punch a gaping hole in one’s Content-Security-Policy. If this is the framework of the future, cyber criminals are going to have a bright future!

Please don't cargo cult CSP without understanding it.

unsafe-eval constrained to function constructors without inline scripts is only a concern if you are rendering user submitted HTML (most common case I see is markdown). Regardless of your CSP configuration you should be sanitizing that user submitted HTML anyway.

Re: Datastar: Web Framework for the Future?

#129

Post by reneberlin »

One idea i found interesting on top: why not use a service-worker to mock the backend completely (https://mswjs.io/) and mock the server answers with the service-worker. Then you still have a local-only PWA-style frontend and can choose yourself, how to sync it back to a server if you really like or need to.

What datastar is great for is: throw all that overcomplicated frontend-junk away and concentrate on the real innovation or simply get things done. Not to forget: ignore the dependecy-hell of every nodejs-based project you can encounter. After the lowcode-initiative, now it's time for the "nodeps"-initiative. Deprecate npmjs.com.

Re: Datastar: Web Framework for the Future?

#130

Post by xyzzy_plugh »

andersmurphy wrote: post #116
resonious wrote: post #78

Nitpicking but > SSE enables microsecond updates, challenging the limitations of polling in HTMX. How is this true? SSE is just the server sending a message to the client. If server and client are in opposite sides of the world, it will not be a matter of microseconds...

You can have microsecond updated, once the connection is established you can stream. Regardless of your latency. Say your ping is 100 (units are irrelevant here). It will take you 100 before you see your first byte but if the server is sending updates down that connection you will have data at whatever rate the server can send data. Say the server sends every 10. Then you will have updates on the client at 100 110 12…

That's still 100 irrelevant units later than the server sent the update. This is like saying the first byte of the packet takes 100ms to arrive but the subsequent bytes in the packet are instant!

It's not quite right. You'll never have updates in microseconds even if your ping is, say, 7ms.

At best you can be ~2-4x as fast as long polling on HTTP/1 -- an order of magnitude is a ridiculous statement.

Post reply on HN