[thatswrong0]

This feels like we're trading complexity here for complexity there, and it seems impossible to judge which way is actually "better". I use loops in React all the time but only have used `setInterval` in a component a handful of times..

[ctvo]

Most of our jobs is determining the right trade offs.

I don’t see the big deal here. Error boundaries, suspense, context, very popular routing libraries all have used components to encapsulate functionality. That’s to say first party and third party functionality in the React ecosystem have gone down this path.

[orenelbaum]

We are not trading some complexity here for some complexity there. We are trading a huge amount of complexity for a framework that is simpler by an order of magnitude. Simplicity is one of the really undeniable benefits of Solid once you gain a decent understanding of the framework. React at times might appear simple on the surface but the overall complexity is pretty huge compared to Solid.

[wokwokwok]

I believe there’s a finite, fixed amount of complexity in problems; that there is, categorically, no way to solve problems without that amount of complexity that is inherently part of the problem domain.

So, what you have here does not remove complexity from problems, it moves the complexity from one place to another.

So, when you have a simple task, and a straightforward framework, what you see is “it’s easy!”. …because when you use the complex framework you get a bunch of “solutions” to problems that don’t exist on your problem.

That’s why it appears overly complex.

…but for a complex problem, when all you have is a simple framework (like <For…>) you have to implement the complexity yourself, which makes you view the framework as feeble and under whelming.

So, you are just moving the complexity from one place to another; the question is, is the complexity of react really something most people need, or can a framework like solid solve the 90% of simple problems most developers have?

It’s hard to tell.

Most new frameworks excel at solving simple problems because it makes for cute demos.

Is solid any different?

That’s my question. How does it work at scale, for large complex projects? Is there a whole design system implemented in it? Who’s using it and for what?

The claim that it’s “not complex” doesn’t help.

All that means is there are probably a crap load of things it doesn’t include I’ll have to do myself.

There is no magic bullet that removes complexity from tasks.

React is a complex beast, and a nice clean framework to replace it would be welcome.

…but you have to approach this kind of discussion honestly.

Hello world examples are a dime a dozen.

[thatswrong0]

I feel like if it were actually an order of magnitude less complex, it would be eminently obvious from a blog post about it? Maybe I'm just tired and don't "see it" for whatever reason, or maybe I need to find some better examples.

From the moment I saw a post about immer.js, I was sold because it seemed like an obviously better solution for the vast majority of cases where I would otherwise grab Immutable.js, a library that I wanted to like but inevitably struggled against.

This.. isn't quite as revelatory. I'm not saying it's not all that you claim it is, it's just that from a glance, I don't see how this somewhat different approach addresses the problems I run into often with React in a major way (beyond the claimed performance boost).

[_0w8t]

immer.js can have terrible performance for data structures starting already with 100 of elements. Using JS proxies is not cheap.

We have found that continuing to use immutable.js Map and List but using plain JS objects, not Records is sort-of a sweat spot. But one needs to enforce immutability with Flow/TypeScript read-only types and use the latest immutable.JS to make it work.

[leonardopainter]

My library (see other comments) has components that are about half the amount of code as react or solid and in pure javascript. The javascript shows exactly was is happening, as opposed to the "simplicity" of react that shows a pretend version of what is going on, then 5 years later people discover that is a bit of a problem and now we are onto the next library (solid?).

I wonder if I could have your opinion on my library, and why half the code, native performance is actually more complicated in the long-run. I don't know the answer at the moment. Documentation isn't complete... it is just web components. eg hello world just becomes a function like const component = hello('Andrew'); document.body.append(component); in the example on github. Anyway, the todo shows a more typical real world example I guess.