Svelte 5: Runes

Re:Svelte 5: Runes by satvikpendem on Wednesday September 20, 2023 @11:37AM (#37585552)

As someone who tries to limit their client-side JS usage through uBlock/uMatrix, websites that aren't just blank <div id="root"></div> with JS disabled would be nice to see, which is why I like React Server Components. Of course, if it's a useful enough web app, I'll enable JS, but if someone's writing a blog, ecommerce site, or really any site that may not require a full blown SPA. Sending minimal unneeded JS to the client is best, as it saves bandwidth and battery, as well as feeling faster due to loading faster, in my opinion.

[ Parent | on HN ]

Re:Svelte 5: Runes by pcthrowaway on Wednesday September 20, 2023 @12:48PM (#37586527)

You can also achieve this with Astro, which will render your React islands statically and also enable client-side JS for interactivity / progressive enhancement when the client has JS enabled

[ Parent | on HN ]

Re:Svelte 5: Runes by satvikpendem on Wednesday September 20, 2023 @01:12PM (#37586825)

True, however it's wrapped up in a nice DX in NextJS. In Astro, if I have multiple components that need React interactivity, are they all separate React apps basically? Or are they the same but with different roots? In NextJS, they're the same and Next can intelligently figure out which to render server side and which to render client side.

[ Parent | on HN ]

Re:Svelte 5: Runes by pcthrowaway on Wednesday September 20, 2023 @01:47PM (#37587305)

If I understand correctly, the React runtime is shared between islands (and you can share state between them if necessary), but they're also pre-rendered for their initial state at build-time.

So you can't do as much in Astro as you can in Next.js, but it will definitely scratch the itch of compile-time rendering.

[ Parent | on HN ]

Re:Svelte 5: Runes by softfalcon on Wednesday September 20, 2023 @05:24PM (#37590392)

I agree with you. It seems wasteful to spending a whole "wait around period" for that <div id="root"/> to eventually load once the js gets around to it.

I also agree that server components make a lot of sense to solve this problem. It's the obvious optimization (and in some ways, a good re-learning from past wins with PHP, Ruby, etc).

I also still feel we have a long way to go before it becomes elegant and obvious how all this is working. It hasn't become standard in the way that everyone easily groks the concept of how it all works and expects it everywhere on every web stack.

Still waiting to see if we go down another rabbit hole of complexity, or see more cautious and careful improvements towards an easier, more maintainable environment.

[ Parent | on HN ]