I mean, pretty much all frameworks these days have that fundamental declarative model, react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc)

What the setInterval example highlights is that newer subsystems in React like useEffect and Suspense are bolted on top of earlier iterations that weren't originally designed to support these kinds of semantics, and the dissonance between API design iterations has become noticeable. This is a pain point that is relatively unique to React.

The growing popularity of Svelte and Solid are largely because their API designs align naturally with how people expect features to work, without people falling into pits of failure like stale closures and incorrectly wired dependencies. React is popular and it puts bread on your table and all, but pretending it doesn't have warts doesn't do anybody any favors.

React was absolutely a breath of fresh air when it was released.

Knockout was similar to Solid.js in that they both have functions that you call which then log a data dependency, then when the data changes the UI updates. This led to lots of pain, because instead of a plain value, you have functions which return values, and you need to be very careful about when those functions are called, otherwise the data dependency might not be tracked properly.

Angular had a similar issue, as its state-based observation relied on special scopes. Updates in the wrong scope could be lost or delayed.

React’s approach of only diffing the rendered UI rather than trying to drive updates based on diffs of the input data was vastly simpler, it was much easier to understand the data flow through explicit state and props.

The phrase "an idea whose time had come" springs to mind.

(this comment is intended to read as professional respect, not fanboying - the extent to which I succeeded in that intension must inevitably be left as an exercise for the reader)

Very good.

IMHO, historically, the bigger pain point with the reactive model was data marshaling/unmarshaling (e.g. updating some subtree of data and then needing to send the root of the data tree to the server while maintaining reactive bindings across a large app and being careful not to fragment source of truth). Ironically, React can also end up in this predicament, because the encapsulation model of its `state` mechanism means extracting the actual state of the component tree is non trivial unless you're using a third party state lib to avoid it altogether in the first place, or at least use useReducer, which is a relatively new addition to React (and even then, it's kinda jank).

These days, React is a hodge podge of many different implementation approaches. Yes, there are props, but Context also exists - and is used extensively in the wild - precisely because props get clunky, and then there's data diffing happening to support `memo`, on top of the virtual dom change tracking. Suspense basically requires your code to adhere to semantic restrictions, i.e. you're not even in control of when your component function is called, which leads to having to tip-toe around that scope w/ extra closures, which in turn leads to all the issues that the article touches on.

The hodge podge issue isn't specific to React; Vue is also seeing pain points from having so many ways of doing things now that they're trying to push a v3 and realizing ecosystems tend to slog.

To your point, yes React was relatively simple when it came out, but as I mentioned, it wasn't the first to take a stab at the declarative model, nor the simplest. It just benefited greatly from the popularity wave of the golden years of Facebook OSS engineering. And from a practical perspective, it doesn't really matter what React was. Idiomatic usage is a thing, and React development today isn't like React development 7 years ago.

For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer.

Components that don’t benefit much from splitting up could have their business logic wrapped into a context, and let the view code be just jsx without all the interweaving of code and templates.

Maybe the one benefit of classes was like it forced you to think in business logic, then render. React still has that, you just need to dive a bit deeper into its toolbox.

The result usually turns out much more flexible - contexts neatly wrap business logic for all of its descendants, classes don’t.

I think this was maybe because react actually allows you to write messy code, and it’s still performant and works. But in the end it just kinda postpones the inevitable maintenance burden.

I guess solid.js from the looks of it might postpone it a bit more. I just worry that solid looks more like magic, and some invariant somewhere will just break and I wouldn’t know what sequence of reactions actually led to that infinite loop that crashed the page. Haven’t tried it myself though, might more understandable in the end…

You've just deoptimized your app, and your whole component will re-render on every change.

> Components that don’t benefit much from splitting up could have their business logic wrapped into a context

You did it again. More unnecessary re-renders.

> it’s still performant and works

True that 'it works', but it's usually not as performant as you think - we just have really fast computers and phones now.

If you have 3 useState each of those will use 3 useReducer internally (every hook is implemented on top of useReducer), If you consolidate them into one useReducer then you will end up with the same thing performance wise. Maybe even better. Whenever an event is pushed into the hook's queue it marks the component as dirty. The next call to useReducer will then reduce all unprocessed events into the current state. It's entirely possible that having less hooks and therefore less metadata in the background can improve performance more than avoiding the theoretical cost of rerendering a component that most likely would have to be rerendered anyway.

But you certainly are correct that useState is reducer based. I'm pretty sure one is only avoiding rerender via using multiple `useState` if they don't implement the reducer in a way where it returns the original object when there was no net change. If you are able to implement the such that it only returns a new object when there really is a change, then a single useReducer call is strictly more efficient than multiple useStates. (This might require more complicated code, as returning a new object every time is often the easy way to implement reducers.)

There's a parallel here to "no, you did not find a bug in the compiler". Yes, ok, once every five years or so I actually did find a bug in the compiler, but assuming you aren't that smart is still a far far better default approach.

On top of that, profiling and optimizing a real world application with a dozen hooks in every component is pretty painful.

It’s understandable to stumble into this difficulty though, and a bit of deceptive marketing on the part of the hooks folks. They should be upfront that using hooks well in a real app requires a lot of careful thinking of the kind that many “typical” programmers do not have much practice in, and then the maintenance of whatever code comes from the effort. The functional-programming-mindshare situation seems to be improving slowly, but still.

If the lifecycle methods you're referring to are things like componentWillReceiveProps or getDerivedStateFromProps then the React blog covers why they were problematic https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d.... It was very common for developers to make things that would repeatedly rerender when other parts of their app updated. Hooks make that far less likely to happen.

That said, I agree that a getDerivedStateFromProps method is more readable and much clearer than useEffect(()=>{ // stuff }, [big, list, of, props]);

when, as I often encounter, organizations mandate all hooks all the time they are not throwing the baby out with the bathwater, but they are maybe throwing out the baby's rubber duckie without considering that might be useful to have around at times.

Vue/svelte/solid do not fight against js, hence they do not end up in similar situation

With React, "plain JS" works just like I expect it to. If I have an event handler that does `x = foo` then I don't expect my component to re-render. Why should it? I'm just changing the value of a local variable. If I want to re-render, there's no way to express that in plain JS, so I'll use React's API and write `setX(foo)` instead. Now it's clear that it's not just changing the value of a local variable, but using React's API to do something else.

With Svelte, writing `x = foo` doesn't just change the value of a local variable. Maybe it's going to run a bunch of magic to update a piece of the DOM instead. Or maybe I need to prefix it with `$: ` which in plain JS is a label for a continue or break statement, but here doesn't mean that at all and means reactivity instead.

Oh, and to conditionally render an element, instead of writing idiomatic JS like `condition && <Element />`, I now have to write `{#if condition} <Element /> {/if}`.

WTF. What looks like plain JS is now magic, and what should look like plain JS such as conditional rendering and lists are now some contrived templating constructs.

And almost everyone here is telling me that I should find that simpler somehow.

It makes zero sense.

Especially when I compare it to Svelte and Vue (not solid, solid.js is just... good), if I look at a component, with react it's way easier to say what's going to happen.

Aren't there gotchas? Yes, but sometimes it's just stuff JS lacks, and so does React.

I'm very excited about Records and Tuples in JS to help with the immutability, for example: https://github.com/tc39/proposal-record-tuple

SolidJS splits it between <For> and <Index>. <For> is equivalent to passing the object as the key and <Index> is equivalent to passing the index as the key.

https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_index

That's one of the design decisions I don't fully understand. It knows that there should be a key there so why just not put it there silently and let me override it when I need, instead of screaming at me when I omit it.

And it also goes into why index is a poor key (it's basically the same behavior as with no key).

Using object identity to detect inserts doesn't work either, because the map function is returning new React element objects on each render.

Practically speaking if you know your items won't change, then omitting the key or using index is fine.

Don't omit the key in React unless you want warnings.

... you can add a new ID property to your model or hash some parts of the content to generate a key.

It is just plain wrong to ask me to change my data model because of this. This is part of the housekeeping that I expect the framework -- pardon, library -- to take care of for me.

Now this does require special process for intaking immutable or big data snapshots where we can't do reference comparison. So we do have a data diffing capability in our nested reactive stores to propagate only what changes. But for the most part common actions like partial updates highly optimized. As well as simple list operations like sorting.

Could it silence the warning? Yes. However, the React devs choose not to. I think it’s the correct default, but likely needs a more educational warning message.

React is unique in that everything in the component is within the render path, while the rest of the frameworks (that you've mentioned) doesn't.

you might be mistaking "side effects during render is bad" for "side effects is bad", the two statements are not the same.

React’s philosophy is View = F(data)

I.e. view is a pure function of data. By “pure”, we mean F() does not do console.log, ajax calls, date time and other stuff which is not consistent every where.

This assumption is ingrained in React. You see it when you are told that react can overrender and your code should handle overrendering. And react works well when user code is pure. However, real world does not work that way. So, there is a need to handle side effects, so that “side effects” works well with pure function assumption of react. This “handling of side effects” is the over head introduced by react.

Other js frameworks (svelte, solid, vue) do not assume full immutability or pure functions, hence User code does not need special handling for these cases

That's just how templates are meant to work. Underscore.js templates don't allow making an AJAX call before calling render() either. https://underscorejs.org/#template

User is entering an account register form. When the user has entered a value in nickname, your app must check if it is in use and display error message if the nickname is already in use.

Sounds good, and ubiquitous right? Well, that also require an ajax call to server for validation, so it breaks the pure function assumption right there. Now, you what do you do?

When you display the error message, yes, React provides a way to do that without re-rendering the input box and while keeping the contents, but many react devs are skipping the traditional React way of doing that and using react-hook-form instead.

I get what you're saying about the component's data updating the state of the DOM in a way that resembles pure functions, but I think AngularJS did it before React, and that Backbone was not far from this vision. Certainly there are a zillion JavaScript frameworks that do this now, and only React has you jumping through silly hoops like "className" and "htmlFor". https://preactjs.com/guide/v10/differences-to-react/#raw-htm... https://www.solidjs.com/tutorial/bindings_classlist

There's no pure function assumption being broken here. React is a framework for rendering UI from state and coordinating updates to that state. That's why we have things like `useEffect`, contexts, and so on. The only part of React that is expected to be free of side effects is rendering.

Put another way, given your example, React just says that you shouldn't issue your Ajax call in your rendering code. Instead, you should do it in response to an appropriate action, such as a change event on your form controls.

Yeah internal component state throws all of that out the window.

That's lit-htmls philosophy, not react. React is all about bundling the view and state and then marathon profiling sessions to figure out why everything is re-rendering all the time.

Honestly, the boon of React is just how easy it is to create components, or at least how simple things were back in the day - it is exceedingly composable, moreso than AngularJS, Angular or Vue have been, at least in my experience. In React, your component can fit within a single file, containing simple syntax, especially for when you're making a pure functional component with no side effects or hooks. And even when you need to add something more complicated, you just have a method or two to change, essentially "progressive enhancement" for your code.

Though admittedly state management, or at least our current approaches to it ruin everything with endless boilerplate (Redux, Vuex etc.) to address an issue that may or may not be easier to represent, though some libraries certainly try (MobX comes to mind).

Of course, my experience leads me to agree with the article, in how React in combination of hooks sometimes is problematic, although in my case that was primarily because of render loops and how the stack traces are akin to JDK 8 NullPointerExceptions, where you couldn't see exactly what's causing you problems: https://blog.kronis.dev/everything%20is%20broken/modern-reac...

I'm probably wrong in liking class based components since those have other issues and Vue/Angular both feel a bit less productive in comparison, even if sometimes easier to reason about, with different tradeoffs to them. Maybe i should check out Svelte some day, but i guess it's all just one long slog of finding what works for you and what doesn't, much like it is with back end programming languages or even relational DBMSes.

It's really bizarre to me how poorly useContext works, in contrast to how good everything else in React is for the most part. Having a good, "official" global state management solution that requires little boilerplate would be a huge benefit.

There are enough different takes on how to state management that I am ... ambivalent ... about whether having a single official solution would in practice be better than the current situation. It's inevitably going to be a trade off and the react team not wanting to pull the trigger on such a thing until they're -really- sure is probably a good thing overall.

As a side note: I agree that useContext is weird, but jamming what (at least according to the mental model I use when working with it) is dynamic scoping into a language without native dynamic scope is probably always going to be at least somewhat weird.

Furthermore, a lambda local to a function can be a full-blown component (visible in DevTools etc.).

So if you need a component that is used in only one other component, you can neatly encapsulate it and make it invisible from the outside, which can be useful on occasion.

The actual article acknowledges that when it's read: "React isn’t truly reactive."

And the author also claims to love React and to think it made things better.

You're arguing with phantoms.

The 'inputs changed, render this' paradigm (and by this I mean reactivity, not the declarative model) has been around for much longer and is exactly what this post is about - React doesn't really do that, since it relies on you to explicitly tell it, via dependency arrays or setState calls, when to re-render. It is not fundamentally different from `.on('change', this.render)` code we were writing back in 2010, just a lot of syntax sugar on top.

That React managed to sell itself so well, while not actually delivering on the reactivity or performance promises, is the surprising part. I'm excited for the future as we finally move on from this era.

"React as Schelling Point" ?

If you have some recommendations or want to share your experience with working only with web standards I want to read them :)

Loads fast, easy to debug without tons of layers in the middle.

And yes, I also do manually make use of script and vendor JS libraries.

Naturally it only works when doing side gigs on my own, on big Web projects where my role is mostly BE/DevSecOps, I go with the flow.

Lit takes care of templating and reactivity. Web components don't have those, it's expected that you use other methods, including what you already use, to create DOM and react to state changes.

The DOM may eventually add templating and reactivity, but that's a pretty big question given how many approaches and syntaxes there are. Until then libraries are fine and allow for multiple opinions.

Just look here at how much overall code is needed to do it right: https://github.com/ing-bank/lion/blob/master/packages/input/...

After you get through all the inheritance and mixins it's thousands of lines

There are proposals for this and most of the other issues I have with web components. But they all feel like issues that could have been covered from the beginning.

Also if you go all Lit on an app with many nested shadow doms it becomes fairly painful to test with tools like cypress.

My point is that you were entirely wrong. Web Components are not ready for primetime, they are half baked. If they were the easiest and most pragmatic way possible to build web applications people would do so.

The only thing they are the easiest and most pragmatic for is to build a simple non-form associated component that can be used across frameworks. Like a card.

> It has always been a chore in one way or another.

It's actually never been a chore to make an <input> behave properly. Something that literally every component library needs to do.

The transition to functional components was to reduce the coupling between abstract functionality and DOM-related lifecycle events.

React hooks are mostly about expressing where and when you want to memoize a value, with the default being not to.

Once you learn what to look out for, and properly designing and review codebases at scale, these trivial issues don't happen all that often. Additionally, being able to specify memoization parameters explicitly brings extra flexibility and some additional design patterns.

https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-...

That was really my point, don't do that.

Newer frameworks are absolutely better for anybody who isn't sufficiently batshit enough to do that, but much though I enjoy react + mobx (especially react + mobx-state-tree) I've never got to the "I have the core source code in my head and can mentally dry run it as a desk check type operation when debugging" stage with them like I did with early angular so - with the level of jank inherent in its scope nonsense entirely acknowledged - I still occasionally miss it even so.

(this is mostly me being nostalgic, I think, the newer stuff is absolutely better but that was a fun few evenings and for its era damn but I could make that thing sing)

I'm having a lot of fun lately using Kotlin-js for example. We use the Fritz2 framework, koin for dependency injection (popular on Android as well for good reasons), and fritz2 relies on kotlin's co-routines and StateFlow for state management. It makes for a surprisingly concise code base. For example, the counter example from the article with that would look something like this:

  class CounterStore : RootStore<Int>(0) {
    val koinCtx by lazy { GlobalContext.get() }

    // handler that you can bind events to or invoke directly like below
    val inc = handle { old -> old + 1 }

    init {
        // launch co-routine to keep on incrementing the counter
        GlobalScope.launch {
            while (true) {
                inc()
                delay(1000)
            }
        }
    }
  }

  val koinCtx by lazy { GlobalContext.get() }

  fun RenderContext.counterComponent() {
    val counter by koinCtx.inject<CounterStore>()
    h1 { +"A Counter" }
    // react to changes in the counter
    counter.data.render { currentCount ->
        p {
            +"Current count: $currentCount"
        }
    }
    pushButton { 
        icon { arrowUp }
        events {
           clicks handledBy counter.inc
        }
    }
  }

  fun main() {
    startKoin {
        modules(
            module {
                single {
                    CounterStore()
                }
            })
    }
    render("#target") {
        counterComponent()
    }
  }

Using koin here, just means keeping glue code out of places where it doesn't belong. It's technically optional but makes a lot of sense in larger applications. Because components are extension functions on RenderContext, I use a global variable to get to the koin context. That allows me to inject my dependencies into components with a minimum of fuss. Where Fritz2 gets fun is with more complex state using data classes, lenses, validators, routers and a few other things. And they also take care of styled components and they even have a nice component framework that you can use. Not for everyone and there's a bit of overhead in terms of download size. But great if that less of a concern.

I would not at all be surprised or troubled if, having studied it, you still dislike it, but there are definitely ideas in there that I consider to be at worst -interesting-.

I can't begin to express how sad that makes me. Your component should have its own scope that it destroys when it gets destroyed, otherwise your coroutine leaks to the outside world when your component is gone from view.