What you don't get about React is that, in React, the reactivity atom is the component itself, not those state in useState. It's encapsulated if you look from the outside. And what you really care is reactivity at the component level.
Svelte 5: Runes
241–250 of 404 posts
Re: Svelte 5: Runes
#242I dont use Svelte or react, im sure its lovely and solves real problems. And maybe im just getting old, but over the last 20 years all evidence I have is that "magic" is a trap. Its so strange to me to see such a high profile project leaning into it like this. Youre writing javascript, but the way you must reason about what your code is doing is so different than javascript.
React gets a bad rap because of all the rubbish built around it, but if you do ever want to try the declarative model over vanilla/jQuery, React is actually exactly what you want if you want to avoid compile time magic. The only thing happening at compile time with React is a line-for-line swap from JSX tags: {boop} to a createElement function call: React.createElement("foo", { bar: "baz" }, ...boop); Other than that…
And you can eschew the JSX syntax entirely with nothing but a small cost to dev ergonomics.
A company I worked at had a O(1 MLoC) React frontend with no JSX at all for a long period of time due to the Typescript compatibility issue, just `export const El = React.createElement`
Re: Svelte 5: Runes
#243Obviously there are huge similarities to solid-js and other signals based framework with creating a signal, creating computed/derived, creating effects, etc. Would it be fair to say that Svelte 5 is going to more "runtime reactivity" rather than compiled time?
Re: Svelte 5: Runes
#244If you collect them all, does Douglas Crockford magically appear to grant you three wishes?
Re: Svelte 5: Runes
#245Earlier quoted context omitted.
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
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.
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.
Re: Svelte 5: Runes
#246[deleted]
Re: Svelte 5: Runes
#247Earlier quoted context omitted.
Let's be honest: the state (see what I did there?) of React state management is a dumpster fire. https://fe-tool.com/awesome-react-state-management That's an article listing the top 18 state management libraries for React. 18?!? React devs can't even agree on a common development model for state, but you think it's explicit and very easy to reason about? Folks don't adopt utility libraries for things that were alread…
I’ve written a lot of react apps (first used it in a hackathon in 2014) and this list is really just fluff. hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex I think the more glaring criticism is the lack of any unified component library. The amount of different Button implementations alone is astounding
I agree on both points. I used to quite like Redux but, between NextJS simplifying the page model and hooks/context being a lot easier for CRA-style apps, I just don't need them anymore for the sort of things I do.
The real kick to the shins is that React Server Components did a number on most component libraries, too. I've been forced to go to Tailwind (and DaisyUI, which is pretty nice) just so my stuff doesn't require 'use client' all over the place. The end result will be way better, it already is when you actually can get there, but right now it's annoying and awkward.
Re: Svelte 5: Runes
#248This is cool, Svelte5 may be the lightest signal-based library. I hope that the old, outdated things mentioned at the end of the article will be finally removed in the future.
I like it's API for signals more than in SolidJS returning an array with setter and getter.
Re: Svelte 5: Runes
#249Now the only thing missing is JSX
Re: Svelte 5: Runes
#250All of these frameworks like react vue svelte solid are basically the same framework.
If you actually want something different and better look at Imba.