Solid.js feels like what I always wanted React to be • Hacker News Board

Re: Solid.js feels like what I always wanted React to be

#111

Post by alskdjflaskjdhf » Tue, Mar 01, 2022, 7:44 AM UTC

lpghatguy wrote: post #13

New JS frameworks always make for compelling hello world examples. Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty! As an example of this point, check out the "Simple Todos" example for So…

>In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like that reinvents a concept that's already in the language.

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.

Re: Solid.js feels like what I always wanted React to be

#112

Post by lhorie » Tue, Mar 01, 2022, 7:47 AM UTC

preommr wrote: post #10

I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…

> react is fundamentally about 'inputs changed, render this'

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.

Re: Solid.js feels like what I always wanted React to be

#113

Post by VaxWithSex » Tue, Mar 01, 2022, 7:48 AM UTC

KronisLV wrote: post #108

preommr wrote: post #10

I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…

> All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sugar (vue has jsx support). 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.…

I enjoy React+MobX with class-based components, because they are nearly as nice as Seaside was, back in the day!

Re: Solid.js feels like what I always wanted React to be

#114

Post by ohgodplsno » Tue, Mar 01, 2022, 7:54 AM UTC

jillesvangurp wrote: post #80

preommr wrote: post #10

I swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sug…

I think for progress you need to look outside the js world. Fundamentally, people keep repeating the same mistakes there. 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 exa…

>GlobalScope.launch { ... }

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.

Re: Solid.js feels like what I always wanted React to be

#115

Post by alskdjflaskjdhf » Tue, Mar 01, 2022, 7:58 AM UTC

jorroll wrote: post #49

Like the author of this post, I appreciate Solid's API because component's only render (i.e. run) once by default and then you define which sections of the component should re-render on changes by using "signals" provided by the library (e.g. `createSignal()` and `createEffect()`). In react, the entire component re-renders on every change and you need to specify which code should _not_ re-run. This was necessary beca…

>Having used Solidjs for some pet projects, I've come to strongly prefer Solidjs over React. It's an evolution of react, so I've found my existing skills/knowledge transfers. This being said, Solidjs is brand new and the ecosystem is minuscule compared to React. For this reason, I plan to continue using React for the foreseeable future. One of the biggest weaknesses of Solidjs is the lack of a "nextjs" like framework. It appears work is being done in the solid-start[1] repo, but it looks like it's still years away from being fleshed out. I want Solidjs to succeed, but I'm not interested in being an early adopter.

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.

Re: Solid.js feels like what I always wanted React to be

#116

Post by thatswrong0 » Tue, Mar 01, 2022, 8:02 AM UTC

masterofmisc wrote: post #95

thatswrong0 wrote: post #74

Earlier quoted context omitted.

> The mechanism that enables code reusability is through composing components If you think that this: return ( {({ apple }) => ( {({ sliced: slicedApple } => ( ) } )} ); is more desirable than this: const apple = useApple(); const slicedApple = useSlicer(apple); return ; Then go for it I guess. Although you'd have to somehow ignore the fact that you'd end up with an even bigger mess if you want these intermediate fun…

Thats interesting. So in your 2nd example, am I right in saying the variables 'apple' and 'slicedApple' are react JSX that you are ultimatly passing through to to render on the screen? If so, yes, that is fairly intuitive.

'apple' and 'slicedApple' would more likely be strings / objects / arrays in the real world. Maybe this still woefully contrived version is clearer?

  function FacebookComment({ commentId }) {
    const comment = useGetComment(commentId);
    const likes = useGetLikes(comment);
  
    return (
      
        {comment.text}
        {likes.length} likes
      
    );
  }

I don't think deal with more braces right now to bring the alternative into existence unfortunately

Re: Solid.js feels like what I always wanted React to be

#117

Post by tempouser23 » Tue, Mar 01, 2022, 8:03 AM UTC

ryansolid wrote: post #109

tempouser23 wrote: post #100

Earlier quoted context omitted.

"UI state knows what its dependencies are automatically and only updates when they change" - you should check out [valtio]( https://github.com/pmndrs/valtio ).

There are a lot of React state libraries that do similar things with Proxies. I think the part that is not as emphasized is how that reactivity extends to the view. Instead of re-rendering components it uses that knowledge to directly update portions of the DOM. So while MobX, Valtio, Jotai, Recoil etc localize change in React, they still feed into the whole VDOM React cycle, instead of just updating exactly what cha…

Though you can use smaller components to minimize the changes. Valtio i feel is one of the simplest of those. But yes they are no way compared to solidjs. Of the numerous frameworks in recent years solidjs has the only which has interested me to pick up and use it. Though still not in production.

Re: Solid.js feels like what I always wanted React to be

#118

Post by bryanrasmussen » Tue, Mar 01, 2022, 8:06 AM UTC

Scarblac wrote: post #97

bryanrasmussen wrote: post #45

Earlier quoted context omitted.

In my personal opinion when there is a lot of complicated state in a component and there is no real benefit to splitting it up into smaller components then hooks are inferior to the older lifecycle methods (in creating understandable, maintainable code), however in my experience whenever I come to place nowadays this would be considered heresy and everything needs to be in hooks even if you have 10+ and growing numbe…

When you have multiple hooks in a component it usually makes sense to put them in a function with a good name - a custom hook. It's easy and almost always usually gives simple code.

sure, and sometimes it still would be simpler with the older lifecycle methods. Not saying it is always the case but for some reason it is assumed it could never be the case.

Re: Solid.js feels like what I always wanted React to be

#119

Post by andix » Tue, Mar 01, 2022, 8:08 AM UTC

Did anybody use Observable Hooks yet? https://observable-hooks.js.org/

This seems to be quite a good way to compute and apply complex state to a component. In my opinion better than useReducer().

But to be honest, for most components useState() and useEffect() are totally enough. And if you do something wrong like in the counter example, you see it right away.

Re: Solid.js feels like what I always wanted React to be

#120

Post by rk06 » Tue, Mar 01, 2022, 8:08 AM UTC

intrnl wrote: post #96

rk06 wrote: post #20

Earlier quoted context omitted.

The thing is that While react is against side effects, javascript is not. Which result in these impedance mismatch where what devs want is against react itself. Vue/svelte/solid do not fight against js, hence they do not end up in similar situation

i'm finding a hard time articulating what you said, if React is against side effects then useEffect wouldn't have existed and we wouldn't have data fetching. 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…

I mean side effects from a functional point of view. Let me explain in more details

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