Solid.js feels like what I always wanted React to be (typeofnan.dev)

But things like the site, docs etc.. are much more contributors making more substantial submissions: https://github.com/solidjs/solid-site/graphs/contributors https://github.com/solidjs/solid-docs/graphs/contributors

We would have never gotten the docs translated into 15 languages otherwise. I do agree that one should be cautious regardless. But I don't want to underplay the contributions of many contributors putting in improvements every day.

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

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.

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.

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.

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.

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.

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.

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)

Isn't this optional? Can't Solid use regular JSX loops?

Once you deal with larger amounts of data and need virtualised rather than fully-materialised lists, you start using different things in React as well. The fact of the matter is that if you care about performance at all, the simple ways are just insufficient, and the native language constructs were designed for procedural programming, not reactive interface rendering, which requires fundamentally incompatible semantics. It’s not even fair to claim that React uses regular JavaScript idioms—VDOM, hooks, the entire shebang is all about eschewing regular JavaScript idioms because they don’t scale. (OK, so there’s also the matter of transient state like scroll positions, element focus, and form field values; it’s not fair to say that React does all these things purely for performance’s sake, as the naive immediate mode approach would also break such functionality.)

I find this a totally bizarre complaint. I've spent the past few months working on Svelte stuff and I've seen people on HN make this same complaint about Svelte's templating language with {#if} and {#each}. Who cares? What is so wrong, exactly, with "reinventing a concept that's already in the language"? It does not make code any harder to understand or to write, and it does not harm performance (in this case, quite the opposite).

I would much rather have a reactivity model where I plug in completely standard concepts and patterns (a for loop) than one where I have to deal with a bunch of framework-specific, complicated ones (hooks). That Solid's reactivity primitives are familiar is an advantage, not a disadvantage.

Actually, that is only half the reason. You can do whatever you want in my library (github.com/thebinarysearchtree/artwork) and it doesn't have any kind of virtual DOM or whatever Lit does, because you just create elements with JavaScript. The second reason, that everyone just assumes is the default, is that React has to use HTML-like templates and not just JavaScript.

I'm right there with you, but when React invents a whole markup language inside of JavaScript, it's not in much of a standing to make purity criticisms.

What I like about the React monoculture is that it's one less thing I have to care about. I can focus on the other aspects of my programs, beyond turning JSON into HTML.

I haven't used SolidJS so I'm not going to put it on blast. However, hearing people compare its reactivity model to Knockout JS gives me the heebie-jeebies, because Knockout projects were horrific to reason about (and test) beyond a certain scale.

This argument is silly because it inevitably becomes a pissing contest of who can be most like vanilla JavaScript. In that case, why use JSX? Just write hyperscript calls instead. Why use React Router/React Context helpers? Just wrap your components using vanilla function providers instead. Why use React Hooks, which inevitably look like magic to a JavaScript veteran because the library inherently hides away some global state? I hope you can see what I'm getting at here.

I had/have your bias, but from playing with it I found a couple things:

1) Like React, you can swap out the template feature for a function call (or subcomponent). e.g. instead of

  return (
    <button...>
    ... 
    </button>
    <For each={state.todos}>
    ... 
  );

  function displayTODOs<T>(todos: T[]): any {
    let arr: any[] = [];
    for(let [i, todo] of todos.entries()) {
      const { done, title } = todo;
      let elem = (/\* JSX \*/);
      arr.push(elem);

    }
    return arr;
  }
  ... 
  return (
    <button ...>
    </button>
    {displayTODOs(state.todos)}   
  );

Hooks allow you to bundle code together by functionality, and consequently allow you to easily extract and share said functionality in a very composable way.

This is my go to for visualizing the difference: https://i.imgur.com/e9K8vfz.gif

React's componentDidMount() is a lifecycle method that runs after a component mounts, once it's been inserted into the DOM. This is in contrast to componentWillMount() (now UNSAFE_componentWillMount(), because it breaks when async rendering is enabled), which is called before the component mounts.

This naming scheme becomes even more important for the update lifecycle methods-- in addition to componentDidUpdate(), there's a shouldComponentUpdate() called before it (where you can return true/false to tell React whether or not to proceed with the update) and UNSAFE_componentWillUpdate(), called between those two.

We are running an enterprise-scale Angular 13 "SPA" that blows the prior platform out of the water.

It just depends on the team and the goal.

I don't particularly like React, but this strikes me as the one thing it got right; the only "always correct" thing to do is to rebuild the VDOM on any change, so that's the default.

Then you can be more selective about which parts as performance dictates.

For all these reasons, while I do really love Solid's API, React + Nextjs + Vercel (or another React stack like Gatsby, etc) ultimately provides a smoother development experience for the time being. It isn't enough to build a better React, someone needs to provide an easy to use build and deployment process for it as well.

I ended up giving up on my Solidjs experiments because I spent too much time debugging the build process and porting React libraries. It's still not obvious to me how I could deploy a Solidjs app to, e.g., a Cloudflare Worker and provide a `/api` callable functions endpoint for the application. I have no doubt that I could figure all of it out, but I'm not interested in spending the significant amount of time necessary to do so. I love the fact that Nextjs just gives me all of this. All of this is to say that, while the core Solidjs library is really "solid" (pun intended), I still don't think Solidjs is ready for new projects (unless you really like doing things from scratch).

The chicken-and-egg ecosystem problem for new frameworks is tough. I've been working on Svelte stuff lately which has a similar problem but less extreme--the ecosystem is still much worse than React's, unsurprisingly, but it's also much better than Solid's right now.

I think Solid's primary branding is around performance and Svelte's primary branding is around it being easy. For getting things off the ground, I think "easy" is a much more successful approach.

The frameworks are popular because you can build things incredibly quickly once you know the ins and outs of your framework of choice. The component-style design, the endpoint design, so much is just driven by the needs of web-based development and the framework creator’s preferred way of abstracting away some of the challenges.

In particular, HTML has a tree structure, which means that things that are semantically related on the page and update together are often miles away from each other in the tree.

And the page in the browser is part HTML, part CSS, part Javascript. Frameworks try to let the developer work in JS only and generate the rest.

And finally, much of the application's state is often kept in a backend, and access to it a asynchronous.

I think that's why Web development is so distinct from other UIs.

https://english.stackexchange.com/questions/30939/is-used-in...

What React has going for it, is that it is predictable. That is an extremely important part of any tool.

I haven't looked at Solid but I've used MobX extensively, and this sounds a whole lot like it. It integrates well with React, so you might give it a look if you've got an existing React codebase.

React.createElement('div', null, `The count is: {this.state.count}`).

With Solid you get the choice, you could use JSX, Hyperscript functions or template literals like in your example. Solid does recommend using JSX because there are some tradeoffs to using template literals without compilation, but it still maintains almost all of its qualities AFAIK and in the big framework benchmark Solid with template literals is the fastest template literals implementation.

With Solid you don't even have to use any templating languages, you can take care of rendering yourself using the tools that the framework gives you. Solid at its core is more of a capable state management library similar to MobX but designed to be used as the only reactivity engine unlike MobX which is usually used on top of React.

This is a subjective thing, right? Personally, I hate boilerplate: either it's a distraction because it's boring and superfluous, or worse it's long and it's wrong. Regardless, it adds to the cognitive load when maintaining code.

  [1]: https://www.solidjs.com/guides/faq#is-there-react-compat%2C-or-some-way-to-use-my-react-libraries-in-solid%3F
  [2]: https://github.com/solidjs/react-solid-state