Hacker News Reader

Comment by satvikpendem | Hacker News Reader

This is basically what Vue and Solid do, no? Same sort of state and derive/computed variables, it seems like.

Also, I will never understand why people like reactive signals. The article even quotes "Knockout being right all along" which, no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place unless you're really careful is why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way. React will soon get its own compiler as well which will made regenerating the DOM even more efficient.

It's like every other framework is slowly rediscovering why React made the decisions it made. I am assuming it's because the users who are making these frameworks now have not used or do not remember the times where "signals" were called observables, or the usage of Rx libraries, and how having too many of these would cause you to lose your mind debugging the intricate webs you inadvertently spun.

View on HN

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 describing.

Signals and observables (e.g. RxJS) are related but separate concepts. The framework world is converging on signals as the appropriate mechanism for conveying reactivity — even Angular (which has historically been most closely tied to RxJS) is moving in this direction. I promise you it's not just a mass delusion.

> 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 describing.

Care to elaborate or do you have a link to a blog post explaining further?

I'll try — I'm currently fielding a zillion messages so excuse brevity!

Basically, you can only modify state _where it's declared_. If you want to allow the 'outside world' to modify that state, you need to expose a function that does so. This is unlike cases where you're passing around an observable object where anyone with a reference, which they need for reading, can also write to it by doing `thing.value += 1`.

This is something Solid gets right — you can only change a signal's value if you have a reference to its setter.

> fielding a zillion messages

Surely you mean signals? :)

Thanks for the reply, Rich. It seems that, given a large enough codebase, that sort of spaghetti mess will emerge on its own, as not everyone will be so thorough. Granted, I haven't used runes and based on your blog post here, I'm not reading where it would prevent such headaches as there's not much mention of that there, so I don't know exactly how it'd work, but just based on my experience using things like Vue and Knockout in the past, it wasn't too clean.

I was just mentioning in another comment how Rust has a similar problem where, as in C, you can mutate variables via pointers anywhere in the codebase, but Rust counters that by having a borrow checker that explicitly tracks the changes made and makes sure that only one user can modify a variable at any one time. An analogous concept might be quite interesting to implement in all these signal based frameworks as well.

> An analogous concept might be quite interesting to implement in all these signal based frameworks as well.

Which is what Svelte 5 is doing with its compiler.

> […] given a large enough codebase, that sort of spaghetti mess will emerge on its own, as not everyone will be so thorough.

LOL! You've just described React projects! Yes, of course you and your team are wonderful and have all the FP experience, so obviously this isn't an issue for YOU.

Most React codebases however turn into big balls of mud. Enormous balls of useMemo-y, useEffect-y, re-render the world-y, spaghettified mud without even any compiler-enabled guardrails that get re-written every 18-24 months but "this time we'll do it right."

I think the true lesson here is that if you fundamentally dislike a programming paradigm, then everything written in it looks like a big ball of mud.

That's completely true. A concede the point.

Based on your profile and comments, it seems you have some particular grudge against React, so I'm not sure I can convince you of anything React related that you have not already convinced yourself of. Nevertheless, I (nor you, it seems) have not used Svelte 5 yet so I cannot judge, just that based on my, yes, personal experience, 2 way data binding based frameworks create messes. Even though you can shoot yourself in the foot in any language or framework, some are simply better at preventing it, such as C versus Rust, as I analogized.

I’m not expert in Svelte or React and have been following your conversation. You stress the point that two-way data binding creates mess. I tend to agree since I did my share of desktop programming long time ago. However, I don’t see how React solves the problem fundamentally. When you combine React with Redux or hooks IMHO you get exactly the same thing. The big difference is syntax that makes it easier to reason how view would re-render in response to change. But in a large enough project I can see how this became less and less true as distant modification trigger cascades of model updates/reducers/hooks and result in an unexpected behavior.

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 to explain the concept to other developers.

Huh? It's called observable because it can be observed (that's what "-able" means). If it were actually meant to observe something (as you say), it would have been named "observer." But it's not - it's the callback that's the observer.

Also observables are more like streams than arrays.

I don't think I'm entirely out of band to say there could be a better way of naming them, like why not call them SubscribableStream.

Saying its an observable invokes a messy gray area in people's brains. I know this because I've had to explain observables to co-workers more times than I can count in my career (I'm a big fan of RxJS, I didn't mean what I said as a dismissal), and I like them for async work vs promises in many many cases, but the nomenclature does not invoke easy understanding

Maybe it would be easier for you (and your colleagues) if the function to "observe" observables was called... observe, instead of "subscribe ?

not particularly, I think it would make it more confusing.

When I break it down to folks explaining its stream processing over iterables or async work and you subscribe (and can unsubscribe) a pipeline that runs over that stream, people get it quickly.

When I say you can "observe a stream" people start getting other connotations, for some reason. I have ran into this over and over and over. Smart people too, not talking about just juniors here

Because RxJS made at least one huge mistake: it made its observables lazy.

When does it start? How do you deal with oversubscription? Late starts? Double subscriptions?

On top of that streams are always a pain in the butt to debug.

The fifteen million obtuse methods/operators didn't help either (I see there are significantly fewer now).

And to remind you: it took the author of RxJava several months to understand the programming model: https://twitter.com/dmitriid/status/811561007504093184

Indeed !

`observers` do exist in RxJs by the way: https://rxjs.dev/guide/observer

I think it is definitely a learning curve thing: when teaching/learning Observables it can help to use a name like EventStreams or PushStreams. (An RxJS "competitor" is named XStream for this among other reasons.) Observable is a simple English word and the meaning of the English word is complicatedly "shadowed" by what the tech means by it.

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.

Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app. Most of us deal with average teams where half the devs are at or below par while managing very tight deadlines. The spaghetti from everything in the whole system mutating always comes back to bite.

You call signals an "implementation detail", but if someone doesn't know that's what they are, then they'll wind up doing very bad things. This means they either aren't just an implementation detail or they are a hyper-leaky abstraction.

What I mean by 'implementation detail' is that you _literally can't get a reference to a signal_ in Svelte 5. This alone prevents people from mutating things in unexpected ways.

> You call signals an "implementation detail",

You haven’t even seen Svelte 5 yet, I don’t think it’s fair to say its internals will create trouble yet.

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 stores and reactivity a lot more obvious in my opinion. Things render when they're supposed to and my applications remain performant. As a non-frontend person, I mainly like the APIs that Vue and Svelte bring. In React I'm almost always switching to class based components for what I can do in the compositional API in Vue or what's natively possible in Svelte. That brings a lot of repeated code and doesn't look as clear to people not as familiar with React.

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.

And lose most of the 'reactivity' since you'll now be doomed to manually track your own dependencies everywhere.

Can you explain why that is?

I find hooks are flexible enough that I tend to be able to implement more sane and manageable reactivity, not the opposite.

Maybe I’m misunderstand your issue, though.

I’m referring to the dependency array you pass into hooks, and any hook being able to trigger updates.

With classes there was no manual dependency tracking (except comparing old props?) and all re-renders were triggered by state, context or prop changes.

Not making a judgement either way, just stating the trade-offs.

The dependency array strikes me as far safer and more reliable, but it has been a bit of a foot gun for a lot of people. I still encounter code where dependencies are missing, which virtually never makes sense or should be intentional. I suppose the compilation step that’s proposed would address that, but it’s yet to be seen.

There does seem to be an aspect to modern react where it’s great if you’re willing to put in the effort to figure out all the quirks, but for everyone else who just wants to get things done/has other priorities, it’s a bit of a minefield at times.

> Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app.

Yes, but having gone through this at previous companies, the average/non-front end specialist developers definitely had an easier time understanding 2 way binding ala Knockout, MobX, Svelte, etc. The Redux style stuff was only pushed by the frontend brainiac types.

More like so easy to shoot themselves in the foot. React’s one-way data binding philosophy is defensive position against spaghetti code.

MobX with React is quite fine, haven't seen the problems you describe tbh

Qt was always right.

Yes, the API is very similar to Vue's. $state is ref/reactive, $derived is computed, $effect is watch/watchEffect.

> why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way

This last part is why Vue and now Svelte didn't adopt React's model. Yes, reactivity and two-way data binding give you enough rope to thoroughly hang yourself, but it also gives you a very explicit picture of how and when components will update. React, on the other hand, expects you to trust its smart algorithms, which definitely removes a lot of the pain from day-to-day coding but also makes troubleshooting performance problems harder.

I see the distinction as similar to GC languages vs something like Rust: if all you need is to have an app that does a job and you don't care about how it does it, React is a good choice. If you need to have control over exactly what will update and when, Vue's model gives you fine-grained control over updates that's hard to achieve in React.

EDIT: And with that in mind, it's obvious why Svelte, which prides itself on being lean and fast, would avoid the React smart-but-complicated runtime model in favor of the Vue model.

Now if only we had an analogous borrow checker in Vue and Svelte so that we don't hang ourselves with 2-way binding. That might a good research project, actually.

React & redux both come standard with tools to dynamically observe behavior. A flurry of updates is easy to pin down & fix.

Static analysis seems like a nice to have. All in all I class this category of concern as very far down the list of concerns, one way or two way. Yes bad things are possible. But the martial attitude that oh no people will do it wrong this tech is horrible is, in my view, actively harmful.

99.99999% of times it goes great. We don't need to make coding environments were bad things are impossible.

> 99.99999% of times it goes great.

I'll disagree with you on that. I've seen and used enough 2-way binding in various projects to know that even the best of devs can create tangles of effects everywhere. At some point, you gotta blame the tool for having footguns, which is why Rust was created over C and C++, to solve such footguns. In the same vein, something like that should be made for frontend frameworks too.

But have you used 2-way binding with a more modern framework? Or are you still hanging on to your experience with a defunct framework like Knockout from over a decade ago?

And don't get me started on React's "put all the logic you want in our templating language that doesn't even target HTML5" elephant-footgun. Oh! Sorry! Forgot that React's footguns are aKeats elegant and reasonable while everything else's footguns are dealbreakers.

> And don't get me started on React's "put all the logic you want in our templating language that doesn't even target HTML5" elephant-footgun.

Sorry, but how is JSX a footgun? I have a lot of issues with React, but JSX doesn't even come close to making the list.

You obviously keep the amount of JS logic to a minimum in your templates. I have encountered many React codebases that did not do this.

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 disposable based on the whims of the company. The bits that aren't disposable are used enough to justify having them designed and maintained by your best devs who should also have the skill to write performant code.

> 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 performing javascript made by average talent in react, that exists to serve someone else's transient business needs. Gross.

I don’t know about you, but I have bills that need paid. I’ll clutch my pearls over something else

I have a friend who's a car guy. He bought some fancy Mazda that he just adores and he takes to the track sometimes.

He's not pearl clutching. He's in love with that car. He keeps it immaculate and he has a sparkle in his eye when he talks about it.

Some people are the same with furniture. They buy super expensive, custom stuff and look after it for decades. Not me! All through my 20s I didn't care at all and my various homes were full of cheap ikea furniture. I had bills that need to be paid, and why should I pay more? Most of it is probably in landfill by now.

I'm not an expensive furniture guy. And I'm not an expensive car guy - I don't even own a car. But I am into software. Software is kind of my thing. When software works fast and well, when its clean, reliable, tested and memory efficient - its the best. I know deep down everything is right in the world.

And, obviously, I hate disposable, cheaply made software. I hate when software runs slowly. I hate seeing my expensive computer working hard to do basically nothing because of lazy code. And I hate running into stupid, avoidable bugs. I don't want to create work like that. And I don't want to use with software like that. When software is laggy and unreliable, my skin crawls and I feel disgusting.

Intellectually, I recognize that there's a place for the cheap ikea furniture equivalent in software. But craftsmanship matters to me. And I personally, hate bad software and I don't want it on my computer.

Does that make me a pearl clutching, elitist snob? Sure, whatever. But I'm done acting like I'm sorry for what I like.

My comment was meant to be a more humorous jab at my own efforts as a software engineer but in re reading I think it came across as rude and I apologize.

I think if you feel strongly about something you should defend it!

Was not funny at all FYI. Trotting out overused clichés about how little pride you have in your work is never funny.

Gotta love how people trot out this crap on Hacker News, a place they ostensibly self-selected into.

it may have been true in the Knockout days, however signals in Solid is very very similar in feel and reasoning to React hooks.

It makes it straightforward to reason about, because you aren't dealing with globals, undeclared deps etc. like in the Knockout days

Counterpoint: https://ericwbailey.website/published/modern-health-framewor...

Performance does matter to the people who depend on our products. Can we please stop throwing people under the bus in the name of churning out more crap?

The real-world performance difference between Svelte and React outside of the tiny benchmark apps isn't very much. The fact that React can prioritize rendering of some things over others means that it can be slower overall, but still feel faster to users.

> The real-world performance difference between Svelte and React outside of the tiny benchmark apps isn't very much.

I don't know, IME it's pretty easy to run into bottlenecks with React. To resolve these, you have to spend time optimizing data flow and preventing unnecessary re-renders, and it can be really difficult to trace where an update originally comes from. Svelte and other reactive frameworks give you good performance by default, so it's very unlikely you ever have to do this in the first place.

I agree with you on this.

I never had to deal with `useMemo` and `useCallback` equivalents in Vue apps. The framework is implemented in such a way that it can let me focus on the task at hand. If I have errors in Vue apps, they are logic errors not "you didn't cater to the framework's rendering model" errors

What is the actual difference between React and Svelte? People don't actually know, but this isn't like the old days where React offered 10x (or more) performance increase over AngularJS without even trying to optimize. We're arguing "better" using very slim margins.

Looking at the geomean benchmark suite everyone uses, it's 1.33 for Svelte 4 and 1.67 for React. That's a mere 0.2x difference and most of that is due to row swapping performance from React iterating lists of thousands of elements -- hardly typical in most apps.

Your team will make THOUSANDS of decisions in your app that will make WAY more difference than 20%. Incorrectly nest some loops in your data processors and the performance difference will almost instantly outshine the update differences.

And all of this is without mentioning that the React team is working on a compiler that will offer many of the benefits you get from the custom Svelte compiler (though TBH, I dislike needing a special compiler for custom JS).

EDIT: I'd also add that the Stage 2 record/tuple proposal will make comparing props many times cheaper and should give a massive performance boost to React as this comparison is one of the things that slows it down.

The statistical performance difference is somewhat irrelevant. The measure should really be the extra time spent optimizing your code, and that value can be far higher in React than it is in Svelte. It doesn't matter if the raw performance difference is only 20%—if that 20% means the difference between a smooth UX and a janky experience, it's still extra work you have to do with React that you don't need with Svelte.

Now, I'll grant you that it really depends on the project. Building a simple admin interface? This probably won't matter. But for an interactive dashboard with dynamic charts and data being updated in realtime? You're almost certainly going to spend some time making it fast. And optimizing React code is currently a pretty poor experience.

For the record, I'm not arguing that the performance difference alone makes Svelte worth using over React. In fact, I think the developer experience with Svelte is far better, which is (in the majority of cases) a much better reason to use a framework. I just want to dispel this myth that React is so fast that you'll likely never have to think about performance, because I've had to do a non-trivial amount of optimization work on just about every React codebase I've worked on.

I've seen people hang themselves with (or should I say on?) hooks.

Performance was the main issue because one incorrect usage of a hook can make a huge difference.

Average devs struggle with useEffect, useCallback, useMemo and other hooks. If anything, Svelte, Solid and Vue are significantly easier.

You make it sound like react is a dark box with a lot of magic behind the curtains, but I always found the react model very easy to reason about. Modifying state is explicit and is the only thing that can trigger a rerender. These rerenders can only happen down from where in the tree the state change happens.

I mostly agree with you.

Unfortunately, many React apps use Relay (another Meta product) and it opens up a world of “magic” that is sometimes a real pain to reason about.

What do you mean by "many?" While I like Relay, I've almost never seen Relay used in the wild. It's sad as it's quite an elegant concept; just as you define your props for your React component, you define your "props" coming from the server as well, through the GraphQL notation. I've been looking at ways to combine both concepts so that there is no client- or server-side state at all, it's all just state, from a cache that determines whether to refetch from the server or to keep the state local.

Maybe it's isolated to me and my work here on this repo:

https://github.com/coralproject/talk

I agree that Relay CAN be simple, but it isn't for what we do. Have a look at this ReplyListContainer and its nested Relay logic. I didn't originally write this, but I can see what they were trying to do and how Relay made it difficult for them. Your thoughts are welcome, I won't judge you for being critical of our code and welcome any other Relay dev's opinions.

https://github.com/coralproject/talk/blob/develop/client/src...

Relay tries to solve the problem of: let a component define its (server) data dependencies. It indeed does this with more magic. But it's not exactly the same problem and you can't really fault react for it. It's also a problem other frameworks don't try to solve.

React is honestly how I used to write my code in jQuery too, for some pages that had a lot of state. Basically, just like in game dev, I had a render() function that I'd call at the end of the file that would re-render everything. The pattern itself is very easy to understand, re-rendering efficiently is the hard part, but for React users today, that's an implementation detail.

Hooks are also very interesting, they're basically functions that run at specific times, or that is to say, they're `f(...parameters, state)`. They hold state inside the function, sort of like a closure.

Indeed, seeing hooks as closures helped me to understand how they are use for state management. It's really a "poor man's object" with all the advantages of FP in terms of reasoning about state changes, lack of side effects etc.

Same here. For complex UIs, I almost always had my own 'render()' function.

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 already easy to reason about on their own. I'm glad you've found peace with React's basic notion of state, but it's a far cry from optimal. And the "state ecosystem" of React is a dumpster fire. Layers upon layers of madness that acolytes peer through and proclaim insight.

> These rerenders can only happen down from where in the tree the state change happens.

Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.

React isn't a state manager and why should everyone be forced to use the one "blessed" manager?

Despite there being so many, only a handful (redux toolkit, jotai, zustand recoil, and mobx) see much real-world use and they are basically just 3 approaches (reducers, signals, and directed graphs) with varying levels of complexity and features.

> Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.

Not true. It only needs to diff the leaves of the part that changed and some of those sub-trees can be skipped too if they are functionally pure (or uses shouldComponentUpdate). This is how they reduce complexity down from O(n^3) to something generally closer to O(n)

I use vue, so I’m assuming that is the “signals approach”. I use pinia btw

Can you explain how all 3 state mechanisms you mentioned, and how they are different ?

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.

That was something that React Server Components definitely got backwards. The default state of the world before RSC was client components. If a mark is needed it should have been "use server" for the new style of components.

I don't mind that, because I think server components should be the default. They're better. But the profusion of CSS-in-JS solutions (which always seemed unwise to me) take it on the chin because of it.

I just write my first fairly complex react app. As a mostly backend/tool Dev with good knowledge of functional programming I agree with this. I could solve almost any problem using hooks + context and memo. I briefly considered using Redux but I quickly realised that a few changes in certain components would take care of most of my state management problems

> hooks + context make all of these libraries pretty much unnecessary for most react apps as they are not that complex

To be fair, context is not a state management tool [0], an article by acemarke, the Redux maintainer. It does work as a dependency injection tool and for many people, that's enough, but it's not a true state management tool.

[0] https://blog.isquaredsoftware.com/2021/01/context-redux-diff...

React context is is just a way to bridge props deep down a component hierarchy. By combining it with an appropriate hook you can almost obtain the effect of a state manager like redux. There are limits to this however; being just a way to pass props it doesn't give you any fine control over reactivity

Yes, that is indeed what the article I linked says.

I did specify hooks + context, not just context. Hooks + context together can be cobbled together into an adequate state management solution for most apps, this article even agrees with me. So not sure what your point is lol

> That's an article listing the top 18 state management libraries for React.

> 18?!?

I mean, the top library has more weekly NPM downloads than every other library in the list combined.

> Yes, after it has DIFFED the whole tree to see where the changes occurred in the first place. Madness. Layers of utter madness.

That is not how rendering works in React.

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 the extra generated code is made up for by the lack of a bulky runtime dependency. But if you scale that up to complicated SPAs - which has been Vue's main stomping ground - you can end up shipping larger files with Svelte than with other small frameworks.

That said, SFCs in Vue are an ideal source for compile-time compilation, and my understanding is that they're heading more down the route of SolidJS. SolidJS has a similar goal of using a compile step for optimisation, but it leans on its signals library implementation much more heavily, which means the compiled code tends to be much smaller, but you also need to include a runtime. (In practice, there's not much size difference between Svelte and SolidJS at all, but it shows itself at the more extreme ends of very small components and very large apps.)

Vue already has a runtime that's very similar in some ways to Solid's (read: it's all signals, baby), so adopting the rendering ideas from there is an obvious next step. That should drastically speed up rendering, as well as reducing bundle sizes significantly. They've already demoed this a bit, but I think it's not fully released yet - they gave a name for the new system, but I've forgotten what it's called.

This is exactly what I was looking for, cheers.

Looks like early experiments were called Vue 'vapor'

> the more Svelte you write, the more compiled code appears - generally, Svelte compiles to a size somewhat larger than the original source file.

This is one of those things that's more of a problem in theory than in practice, but nevertheless it's worth mentioning that Svelte 5 output is _much_ smaller than Svelte 4 output.

I assume that the Svelte 5 output is smaller because more stuff is being handled internally by signals, rather than the compiled output. Does that mean that the shared "runtime" code is larger, or have you just managed to shrink everything down here?

I'm very impressed by this stuff - I'm still not sold on the implicit reactivity, but I'm really excited about the pressure this is putting on the ecosystem as a whole and where that's going to go.

What is the difference between $derived/computed and $effect/watch?

I don't know about in Svelte, but in Vue watch is for taking some sort of action when things change, while computed is meant to return a value.

There was/is a state management lib called Mobx that was released years ago and was usually combined with React. It was kind of reactive, very easy to use and fast. It normally only updated the components that was effected by a state change.

It was a bit sad that it didn't get more popular and possibly improved. Some devs liked it but we were a minority compared to those who liked/used Redux.

One strange thing they did was to release a new "version" called Mobx State Tree which was very different. It had a great api but was different and slower.

I recently took Solid for a spin and I found none of that 2-way data binding mess you complain about. To be fair, I think you’re assuming is has behavior that it doesn’t.

Eg if a form input changes, that change triggers an onChange and in a handler function, you can let the change just flow through the data layer (ie through a signal or a store, which is just a hierarchy of signals). This then updates the input, but it already had that value so nothing happens. It’s pretty much the unidirectional loop that React people love to talk about.

Sorry, I should have been more clear, I was talking more about Vue and Svelte rather than Solid, which explicitly says they don't have 2-way binding due to learning about how dangerous it is and how React doesn't have it: https://www.solidjs.com/guides/faq#why-can-i-not-just-assign...

These discussions are so tiring.

React has as much two way binding as vue - in vue v-model is just syntactic sugar for setting up event listeners and setting the value on an input element.

Per the docs [0]

Becomes

It's such a small thing that it's crazy it's being discussed this much.

[0] https://vuejs.org/guide/components/v-model.html

React has no data binding at all, let alone 2 ways.

What you’re talking about is unidirectional data binding, and what you’re replying to specifically mentions its failure to scale with complex applications.

It’s not the kind of problem you can appreciate when taking any framework for a spin with a form input.

No, what I replied to said that about 2-way data binding. React also (just about) forces you to do unidirectional data flow, just like Solid.

> It's like every other framework is slowly rediscovering why React made the decisions it made

Nope. More like every other framework is slowly rediscovering that observables and dependency tracking offers the best DX and most of the innovations that React introduced have better alternatives.

Yeah, I have no desire to go back, regardless of "performance" gains. React keeps me sane and it's fairly simple to keep it performant.

second this, plus its mature ecosystem, which is very valuable for the long term.

though, the SSR madness movement including React concerns me, everyone tries to mix CSR and SSR into one now, which makes things way more complex than it needs.

I could not agree more. There is a huge push to make both side of the rendering “the same”. Next.js is pushing it really hard for their edge level rehydration.

I get it, it gives you flexibility to hydrate the view as close to the user, as late as possible. That sounds cool, but I wonder how many folks really use it and how much you pay for not clearly defining where and when each bit is happening.

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.

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.

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.

The "ecosystem" is taking vanilla js libraries that work without modification in other frameworks and making them work with react via a wrapper. The react ecosystem is nothing.

React Three Fiber is a good “wrapper” library that proves the ecosystem is far from “nothing”

https://docs.pmnd.rs/react-three-fiber/getting-started/examp...

I know what react three fiber is and I find the idea of using xml for 3d rendering to be terrible.

I disagree—I regularly find (and use) libraries that are built specifically for React and don't have a vanilla JS analog. As someone who uses Svelte on personal projects, I actually find this really frustrating and wish most of these libraries were just wrappers over some core functionality built without React.

I have a similar feeling. I keep up to date on changes to these other frameworks but in my work we've never run into React performance issues that couldn't be fixed by approaching things with good principals. Signals are brought up in convo every now and then as an approach to fix an issue, but stepping back we always seem to find a better solution but just re-writing bad React code. I'm sure if you're on a certain scale of users or extremely custom UI you could run into circumstances where signals would help you, but for our system that serves hundreds of thousands a day, we don't need them yet.

I've worked on react codebases, and non-react codebases. Maybe it's a coincidence, but I find the react ones in general to be harder to debug. And not great for my sanity either.

My experience is it tends to depend on the folks who made the application. Regardless of what framework you chose, they can't save you from yourself in a lot of cases.

> It's like every other framework is slowly rediscovering why React made the decisions it made.

Definitely there is convergence in DX now. No need for everyone to admit one or another framework was right first or not - that is just creating antagonism or negating people lived experiences and innovation. But I do find it pretty weird that this convergence is happening. Initially I thought it was diverging with svelte but it seems to be reserving direction.

> * But I do find it pretty weird that this convergence is happening. Initially I thought it was diverging with svelte but it seems to be reserving direction.*

Convergent evolution [0]. Just as a shark, dolphin, and ichthyosaur all have the same body shape which is efficient for swimming and hunting in the water, so too do technologies converge when the problems are all the same and the solutions are understood, only as humans we can learn from each other rather than randomly mutating our codebases [1]. It's the same reason why we see a lot of languages starting to adopt more functional features such as not using `null` and having exhaustive pattern matching, such as Rust (from OCaml), Dart 3, recent versions of Java, etc.

[0] https://en.wikipedia.org/wiki/Convergent_evolution

[1] https://en.wikipedia.org/wiki/Genetic_programming

But for every similar shaped organism, there exist as many, if not more dissimilar ones, either alive or preceding. Convergence is not a given, and for every instance of convergence there are just as many divergences, even when appearing similar on the surface. For each degree of software 'carcinization' [1], I'd contend there are as many evolutionary offshoots going against the grain.

[1]: https://en.m.wikipedia.org/wiki/Carcinisation

That's true, but perhaps just like in biological evolution, the ones that are against the grain don't survive, for whatever reason. So it could even be that convergence occurs via selection.

I think this somewhat inevitable given the flexibility of javascript. The lack of convergence on one single paradigm as a long-lasting set of best practices speaks to all of things that a web framework needs to have in order to accommodate all developers.

In Svelte's case, it feels like they went as far as they could without directly addressing observables until they reached a point where it became one of the largest features that had yet to be addressed.

Open source frameworks, not unlike companies, need to continue attracting new users to grow the ecosystem, which means pleasing an ever-growing user base.

Svelte Stores are observables, just without the extra boilerplate.

> reserving direction

autocorrect style typo, i think

It's not convergence, it's the cycle of development patterns. Patterns come and go leaving bad memories that become anecdotes. Anecdotes become "misunderstanding the paradigm" and even the misunderstandings are long forgotten when the pattern that made them comes into vogue again.

I wonder if it's due to how new people are to the industry, as well as how new the industry itself is. In disciplines like mechanical or chemical engineering, you don't see nearly this much reinvention of the same patterns. I imagine most people these days using React, Vue, Svelte, or Solid have never even used jQuery or Knockout, as those are almost 15 years or older at this point.

If you're an engineer, physics are always there to smack you in the face. As a result, engineers collect sets of things that physics seem to be fine with and reuse them. If engineering were programming, a woodpecker in Central Park would bring down the Eiffel Tower.

Programming is not physical. It is generally bound by Turing completeness, the halting problem, 2 generals problem, and the like, but most developers don't even write code on that level. That leaves them with an infinite number of ways to solve problems with the real limiting factor often being the humans instead of the fundamental limits. If you use 5 different design patterns in 5 different frameworks, they all still work, so now you must decide (based on ever-changing factors) which one is actually the best.

Complicating this is the issue that not all people were taught the same or think the same way either, so an approach that makes sense to some people might not make sense to other people. The extremes here based on education and what you learned first are massive even when there are objectively better answers too. An entire generation of devs either retired or died rather than move from assembly to Fortran or C. That generation retired or died rather than move to OOP and the OOP people are retiring/dying rather than moving on to more functional approaches to programming.

Indeed, design patterns in physics and chemistry is a matter of the laws of nature, one cannot try something that doesn't follow such laws. In software, design patterns are simply guidelines, as there are no laws of nature in the realm of virtual space. It reminds me of mathematics but even mathematics has its own laws to follow, so software is even more unconstrained.

> no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place

Honestly never understood this - 2 way is less code and way more understandable to me. Redux style codebases are very difficult for me to understand, and never saw benefits praised for. More frequently was "why isn't this updating?".

Different strokes I suppose.

Indeed. You can get all the main benefits of two-way binding in a one-way dataflow system like React by using cursors... i.e. whenever you access a property `state.foo.bar`, also derive the setter/updater, `setBar(…)`.

With proper memoization, this is both fast and ergonomic, and it even allows you to turn mutations into data and pass them to a server. I've implemented this as a stand-alone state helper [1] based on JSON patch/diff, and it's magical. Undo/redo, multiplayer, it's all within reach.

[1] https://usegpu.live/docs/reference-live-@use-gpu-state

> implying react codebases aren't spaghetti mess

> React will soon get its own compiler as well which will made regenerating the DOM even more efficient.

This will be amazing if works as people are hoping it will. I suspect it's an impossible task (in the general case). My hope is a certain coding style will be the path forward, and not a new version of putting shouldComponentUpdate (and others) all over the place.

Architecture and the used reactivity mechanics are different things.

You need architecture to avoid a big ball of mud or spaghetti code. Organising your code in layers, modules, each with its own API. Rules which layer can access what other layer. Like backend does for ages. You can and should do this in large frontend SPAs as well. No matter if written Svelte, Angular or React.

> I am assuming it's because the users who are making these frameworks now have not used or do not remember the times where "signals" were called observables

And also a tendency to not have experiencing working on large web apps (I’m talking 100k+ cloc) where issues arise, and why those React engineers made the decisions that they did

I work on Svelte 5 and I was also a React engineer on the core team previously FWIW.

Two way data binding and signals are such bad ideas when dealing with large real-world apps. I feel they only make sense in small code snippets that are cool to tweet.

For me they're a dealbreaker when considering a new framework.

Is it not possible to write Svelte code with one-way data-binding? Would that not give you the best of all worlds: compiled javascript, no virtual DOM, and easier to debug code?

Reply on news.ycombinator.com