What dif­fer­enti­ates front-end frame­works

> To overcome the shortcomings of the default change detection paradigm, the Angular team is working on a new approach called Signals. Conceptually, signals are similar to Svelte stores (which we’ll get to later), and fundamentally, they solve the change detection problem the same way as React; the framework is taking control over the application’s state so that changes can be easily monitored and re-renders can be as efficient as possible.

I radically disagree with this statement. Angular Signals (and signals in general, as in SolidJS) could not be more different from React's change detection model, and they are not particularly similar to Svelte stores either.

In React, your component function is a render function, which reruns. React diffs the state object when `setState` is called, determining which part of the DOM to update.

Signals-based solutions are generally much more fine-grained: the framework knows which portion of the DOM was affected by the signal, and does not need to diff the entire state object. This "surgical" approach requires more explicit state management on the part of the developer, through the use of Signals to wrap the application state. However, DOM nodes can be updated without doing a large, expensive diff. (As a corollary, the component function is typically a create function, not a render function.)

The developer experience is quite different as a result.

Component isolation.

* State management is merely a sum of few parts: a state artifact (a big object), a means to update that artifact, a place where that artifact is saved, and finally a function to apply state on page reload. Its an isolated system. If anything wishes to update state it just calls a function.

* GUI: A window system (a big function and a bunch of supporting functions for events), content, and events specific to types of content.

* File system: A call to the file system library from a user interaction, a library to recursively walk the file system on the back end, a messaging payload to communicate the requested file system details, a function to populate the file system data into DOM artifacts for user interaction.

And so on.

I prefer to work without frameworks because they execute far more slowly, get in the way of solving real problems (complexity), and they slow me down in writing/testing code. Writing applications isn't about how to write code. It's about organization, flow control, and just connecting the dots between a problem and a solution. Its the difference between repeating minimum literacy and writing an original inspiring novel. Why would I think some giant abstraction would save me time or improve my code?

Adding "declaratively" doesn't make it true either.

You can declaratively pass objects between web components in every web components library out there like Lit or Stencil.

Now, you may claim that that doesn't count because the declarative part is implemented in non-standard userland libraries, to which I would reply:

1) So what? React is a non-standard userland library. You can't pass data declaratively between React components without React. At least with web components there's a standard _interface_ for the components so that many different libraries can implement the declarative parts in a completely interoperable way.

2) Yes, you can't pass objects around in plain HTML because plain HTML doesn't have references to the objects in the first place. Even if you did add a way to set properties in HTML, what would you set them to?

2b) This is actually likely changing as the Template Instantiation proposal moves along and possibly gets the ability to make property bindings. This will be useful for declaring custom elements that accept properties. But the question remains: where do those properties originate from? Most likely JavaScript, because HTML doesn't have any.

[dead]

firefox reader mode; works on mobile too