This is Learning

Thank you for correcting this. I was going to come and respond when I saw this earlier but hadn't had a chance. Yes the annoying part is not being able to destructure but you definitely don't have to (and it isn't our recommendation) to pass accessor functions down as props. I wrote an article on our perspective here: https://dev.to/this-is-learning/thinking-locally-with-signals-3b7h

React is not "reactive" according to the classic definition, but even the creator of Solid.js thinks that doesn't really matter. https://dev.to/this-is-learning/how-react-isn-t-reactive-and-why-you-s…

One thing to be very mindful of is that is a very limited application. The footprint of the various frameworks changes based on how big your application gets as shown here[1]. Swyx, I think you are probably aware of Ryan's article but it's worth contextualising for others who might not be familiar. The more components you have the more Svelte loses its edge. [1]https://dev.to/this-is-learning/javascript-framework-todomvc-size-comp…

> At least it shows that the technology is both scalable and battle-tested. So are all other technologies used on the web sites. It still doesn't make it good. You keep pretending that if something is used somewhere means it's good. > It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later. So what? Neither of these technologies have the laundry list of issues that web components have. And jQuery is still used on significantly more sites than React and Web Components combined. I'd bet on survival of jQuery more than on survival of Web Components. > Meanwhile, web components are the browser standard, which means that they are a model of UI code encapsulation that is here to stay. Unfortunately, yes. They are here to stay: a badly designed, barely working technology that needs increasingly complex and arcane hacks to make up for its deficiencies, sucking up human resources and making browser engines incomprehensibly complex. Oh, and they also infect other standards that have to cater to them now. E.g. Scoped CSS covers 80-90% of use cases WCs are used for, but now it has to be butchered to accommodate Shadow DOM. But yeah. It's here to stay. As Rich Harris, the author of Svelte said, "it's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1] There's a reason why very few, if any, of the major frameworks, and very few of up-and-coming web…

Another way of stating it is that Svelte doesn't attempt to plug any of the leaky abstractions that already existed in JavaScript. JavaScript is riddled with huge footguns that aren't even exotic use cases, and if you remove or paper over them, then it's not JavaScript any more. While React's biggest most obvious leaky abstraction is that React isn't actually reactive. Neither is Svelte, but at least Svelte doesn't have the audacity to falsly CLAIM it's reactive in ITS OWN NAME, like React does! I do give Svelte credit for being quite self-referentially svelte, though! And that's something great that React definitely isn't. How React isn't reactive, and why you shouldn't care https://dev.to/this-is-learning/how-react-isn-t-reactive-and-why-you-s… >[...] Is React not reactive? >Well, let's see about that. React components are driven off state, and setState calls are sort of like data events. And React's Hooks and JSX are basically declarative. So what's the issue here? >Well actually very little. There is only one key difference, React decouples the data events from component updates. In the middle, it has a scheduler. You may setState a dozen times but React takes notice of which components have been scheduled to update and doesn't bother doing so until it is ready. >But all of this is a type of buffering. Not only is the queue filled by the state update event, but the scheduling of processing that queue is as well. React isn't sitting there with…

At some point, the creator of SolidJS, Ryan Carniato did a stint helping developing Marko.js, a fine-grained reactive / compiled / a bit HTMX-like system, and blogged about that. It's a framework that originated from eBay. I'm now quite interested about the next version of Marko.js, Marko.js 6, and I'm gonna try it for my new project. I'm interested in fine-graned reactivity so Svelte and SolidJS have been on my radar, but the HTMX-style approach appeals to me. Here's something to munch on: https://dev.to/ryansolid/marko-compiling-fine-grained-reactivity-4lk4 https://dev.to/this-is-learning/marko-for-sites-solid-for-apps-2c7d https://www.youtube.com/watch?v=Z1dd09rxny4

Alien, Reactively, TC39 are all about the core semantics of signal, computed, effect. Much of the rest is implementation details. https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript… is a good intro.

Maybe SignalDB?: https://signaldb.js.org/core-concepts/#signals-and-reactivity I swear I read that MeteorJS and/or MongoDB implemented signals for the DB layer. While searching for the source, I found SignalDB. --- edit: Found the source: https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript… > ...Meteor Tracker is a good prior art on signals and effects history in JS (although not using the same terminology). The really magical thing about Meteor is that their "signals" and "effects" are database connected: you use variables in your frontend template, and those values can come directly from a backend DB...

There is an interesting debate about React and signals in the comments of this article, between Dan Abramov and Ryan Carniato - https://dev.to/this-is-learning/react-vs-signals-10-years-later-3k71

Per some tests as of last year[0], Marko[1] is much more performant than Svelte, which matters a lot for UX and for page rankings (especially in case of more complex sites). I’d expect Qwik to be faster than any of the above, but it seems not quite production-ready enough. [0] https://dev.to/this-is-learning/marko-for-sites-solid-for-apps-2c7d [1] In the Reddit the author mentions that, despite focusing on Solid+Astro in the article, Marko is actually still more performant than those: https://www.reddit.com/r/javascript/comments/ubs6i9/marko_for_sites_so…

> ... so you have true cross platform apps(from desktop to android and ios), it's the only way to achieve that. There are many other viable ways for creating a cross-platform app: https://dev.to/this-is-learning/the-different-strategies-to-building-a…

As a developer I like doing CSR apps. As an user I like when my sites are SSRed. There are people who are trying to bridge the gap. https://dev.to/ryansolid/server-rendering-in-javascript-why-ssr-3i94 https://dev.to/this-is-learning/conquering-javascript-hydration-a9f

Others are right to point out that this isn’t a problem with reactivity. But there’s an even more important correction here: React, perhaps in spite of its name, isn’t actually (fully) reactive. And while that’s sort of an academic nuance[1], it’s the underlying reason for implementing things like this. 1: https://dev.to/this-is-learning/how-react-isn-t-reactive-and-why-you-s…

I like the article, but it gets some things subtly wrong. > To grossly oversimplify things: React assumes that your entire virtual DOM tree needs to be rebuilt from scratch, and the only way to prevent these updates is to implement useMemo Not quite, on a state update, it rebuilds the component that was updated and all of its children. Not the entire virtual DOM; old versions of Angular did this, but it was wasteful. useMemo doesn't prevent that, but React.memo can (useMemo has a different role; it lets you choose when to recompute or recreate a normal JavaScript object. But on its own it won't stop rerendering of child components!) [0] This invalidates some of their assumptions. The reason why React isn't "push-only" isn't because it does that, it's because it sometimes buffers updates instead of always pushing them immediately. In fact, other frameworks like Svelte also aren't "push-only" and hence not strictly reactive! (Funnily enough, OP uses an article as a source that explains this correctly [1], but it seems they took the wrong lesson from it). The reason why signals are so cool is because the framework knows for any given state change which exact attributes in the DOM need to be re-rendered, even more specifically than "the element and all its children". But this neither implies reactivity nor the other way around. The two concepts are orthogonal. Anyways, kudos to the author for diving into this so deeply! [0] useMemo is useful in combination with React.memo…