311–320 of 404 posts
Can you build a $derived from multiple other $derived? If yes, how do you deal with two $derived sharing some dependencies? Will the end result see temporary, half-updated values?
Yes
> Will the end result see temporary, half-updated values?
No. It uses a push-pull mechanism — dependency changes don't result in a re-evaluation until something asks for the value, meaning derivations are 'glitch-free'
One of Svelte's biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want. Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Transpile it to let count = $state(0) under the hood? If that can w…
We evaluated somewhere close to 50 different design ideas (seriously) before settling on this one, and what you describe was one of those ideas. But one of our goals was for you to be able to use Svelte's reactivity inside .js/.ts files, since that's one of the things people have been crying out for since we released Svelte 3. For that to work, reactivity has to be opt-in, not opt-out. And that's how it _should_ be —…
I can't find an issue for that among top 50 open issues on Svelte's GitHub repo. I've also been a member of Svelte's Discord server for years and do occasionally hang out there, I haven't seen people "crying out" for this at all.
On the other hand, there are things like `` or `forward:class`, etc. that people have ACTUALLY been crying out for (literally one of the most upvoted issues in the repo) which haven't been addressed at all.
As a recent adopter of Svelte, these changes are intriguing but I don't really have a grasp of how I feel about it quite yet. One thing that I am definitely happy to see is the removal of $: as it should help Typescript users. Personally, I was quite sick of writing: let input = 'Hello'; // ... let loudInput: string; $: loudInput = `${input)!`; Instead of: let input = 'Hello'; // ... $: loudInput: string = `${input)!…
Earlier quoted context omitted.
React is the pragmatic answer. Most devs are of average talent and will hang themselves and everyone else with the stateful webs they weave. Even with careful PR reviews, these things have a way of sneaking in and becoming permanent hinderances. Performance hasn't been a dealbreaker in most JS apps for years now. What HAS been a problem is getting good code out the door as fast as business needs. MOST React code is d…
> What HAS been a problem is getting good code out the door as fast as business needs. MOST React code is disposable based on the whims of the company. I know you're right; but this still deeply saddens me. I want well crafted software. I want the code I write and the code I depend on to be made in a way that holds reverence and honor for the craft of software engineering. I don't want to be running crappy, badly per…
Earlier quoted context omitted.
I'm replying to you, but I'm asking the room: what, if anything, stops vue3 from compiling down to pure JavaScript like svelte does and reaping the speed benefits?
I think the main thing is the existence of alternatives. Svelte is cool, but it has the key flaw that the more Svelte you write, the more compiled code appears - generally, Svelte compiles to a size somewhat larger than the original source file. For Svelte as an "island" tool (i.e. for building islands of interactivity in otherwise static pages, like, say, graphs for the New York Times), that's not a problem, because…
Can you build a $derived from multiple other $derived? If yes, how do you deal with two $derived sharing some dependencies? Will the end result see temporary, half-updated values?
> Can you build a $derived from multiple other $derived? Yes > Will the end result see temporary, half-updated values? No. It uses a push-pull mechanism — dependency changes don't result in a re-evaluation until something asks for the value, meaning derivations are 'glitch-free'
I 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.
Earlier quoted context omitted.
Yes, Vue and Solid — like Knockout — use a dependency tracking mechanism. Back in the day it was called `ko.observable`, nowadays we call them signals. That's the part Knockout was right about. It's absolutely true that you can mishandle them and create a spaghetti mess, _if your design allows it_. Svelte 5 doesn't — it uses signals as an implementation detail, but in a way that prevents the sorts of headaches you're…
I always found observables need better nomenclature. I know its not anyones fault (RxJS is amazing), but it does seem to invoke some gray area in the brain, thinking observables would do more heavy lifting around change tracking of inputs / sources, when its not that straightforward. They more rightly should be called SubscriptionStreams maybe I think its always been somewhat poorly named, based on how often I've had…
On the other hand, on the other side of the learning curve, Observable is a great name. It's a simple English word that you can say and write a million times (and you will need to when working with them) without extra PascalCase or things like that. Also, when you look at the overall "family" that Observables fit into, it is a name that fits the family: Iterable/AsyncIterable ("PullStreams") versus Observable ("PushStreams"). (In .NET LINQ the family uses Enumerable/AsyncEnumerable and also extends to Queryable and the strangely named but makes sense in context Qbservable. [QueryableObservable; often pronounced like "cube-servable".]) As a family of tools that all generally work well together and are essentially related in a "four quadrant" way, it helps that they all have a nice -able names that sound related.
Earlier quoted context omitted.
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 req…
Earlier quoted context omitted.
Pretext: I'm a backend developer that often needs to stare into the abyss that is frontend. I used to say these same things about reactivity. It was highly confusing to me years ago; as a backend developer doing frontend tasks was always reaching outside of my cookie jar and testing the boundaries of what I knew vs what I thought I knew. Many headaches ensued. That said, using Vue 3 and Svelte 4 has made utilizing st…
Seems like your comment cut off there, but if you're using class components in React, there will be repeated code, yes, which is why hooks were invented and why they enable you to reuse such code.