Live data from Hacker News

Datastar: Web Framework for the Future?

chrismalek.me

101–110 of 161 posts

Re: Datastar: Web Framework for the Future?

#101
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.

Svelte only requires a CSP hole in its default config as a standalone library; SvelteKit does proper CSP by default, and if you're not using SvelteKit you can build CSP handling into whatever you are using instead. I assume the others are the same way.

Re: Datastar: Web Framework for the Future?

#103
post #102

This is probably a silly question, but how do I use loops? For example, if my backend returns an array of TODO items, how can i iterate through that and display on the frontend?

Htmx and datastar use backend rendering. So you write the html in the backend and serve that. In the case of an array, you render them as Todo ítems.

You might be using a template system for that. E.g. Jinja2, moustache, askama, templ, etc depending on your backend language and libraries.

Re: Datastar: Web Framework for the Future?

#104

Earlier quoted context omitted.

This is a Wirth's Law solution - the reasoning goes: "computers are fast enough to deal with it, so why not?"

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.

Re: Datastar: Web Framework for the Future?

#105

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?

Re: Datastar: Web Framework for the Future?

#106
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

idk if I'd put it quite that strongly. https://data-star.dev/examples/dbmon

Also, multiplayer for free on every page due to SSE (if you want it).

Re: Datastar: Web Framework for the Future?

#107
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.

Re: Datastar: Web Framework for the Future?

#109
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

I think the happy place is somewhere in-between. Use JS to allow the user to build up a request/form (basically DHTML circa 2000), but use one of these hypermedia frameworks when interacting with the server. I think that these are successfully showing that BFFs were a mistake.

Re: Datastar: Web Framework for the Future?

#110

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.

That's the number of divs combined with the CSS transition animation on each cell. If I remove the animation on each cell it runs much better on lower end devices (looks a lot worse though). In general though older devices can't handle as many cells.

I'm sure you can write hyper specific hand tuned code for this example that will run better, but you'll lose all of the flexibility (and you have to load that hand tuned code first too). I could send down purely a string of data and have either an expression swap classes or wrap it in a web component (you can do both in Datastar). But, in short passing json and running your logic on the client adds up.

Like anything though test and measure.

Post reply on HN