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

#281

Post by dsego » Tue, Mar 01, 2022, 2:17 PM UTC

toshk wrote: post #209

littlecranky67 wrote: post #169

Earlier quoted context omitted.

People always use the setInterval() issue as a footgun. The real footgun is people not reading the documentation for the framework they use, because the exact example is handled in the official react docs [0]. I always advice aspiring react devs to understand why this exact setInterval() doesn't work (and why there is the need for the rule-of-hooks), because it will automatically create an understanding how hooks and…

When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case. React was easy coming from jQuery, Backbone other frameworks at the time. With effects, i've read the docs many times. I still don't fully understand how it's supposed to work. I don't seem to get the feeling / abstract concept behind it and it still surprises me a…

This is my understanding, but I just use hooks, don't know the implementation details. Pure react functions receive props and render output. Each time the component is rendered (basically a function call), it reads the props and spits out some DOM nodes (simplified). But you loose the ability to have lifecycle events. So they invented a mechanism that keeps some hidden state that's tracked for us behind the scenes, and we can then "hook" into that lifecycle state.

The main issue is that it's not a native language construct, but a mini-dsl sort of so you need to have this state machine in mind even thought it's implicit and hidden from you.

Instead of reading the docs, you might want to search online how to write hooks from scratch. It's one of those concepts that needs to click.

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

#282

Post by fuzzy2 » Tue, Mar 01, 2022, 2:19 PM UTC

ramoz wrote: post #276

fuzzy2 wrote: post #133

Slightly OT: I’m always amused coming to discussions like this one, where people are (basically) complaining about the Virtual DOM and its implications. It’s bad for performance at scale, updates aren’t minimal. And other stuff: SFC are hard to wrap your head around, I don’t want to write explicitly reactive code and so on. Some framework solves this by looking (somewhat) like React but in the end doing something ent…

The whole "I hate angular" is a bit old at this point. The latest versions are really quite simple/powerful. We act like it's still 2015 and we're jumping from angularjs 1.x to React. The jump was nice, yet turns out production-grade engineering in React was not so nice.

I don’t like the separation between template and code, I don’t like the developer experience (slow and often malfunctioning VS Code extensions and slow builds, bad in-browser debug helpers), I don’t like how creating “ad-hoc” components is basically impossible.

I think Zone.js is insane.

I know Angular very well. That’s why I’m confident I can create high-performance applications using Angular. I firmly believe Angular has far too many pitfalls for inexperienced developers.

So yeah, I hate Angular.

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

#283

Post by bstar77 » Tue, Mar 01, 2022, 2:19 PM UTC

This is really interesting. I'm happy the author covered the effects side of things because this is where I've had some challenges with non-trivial React apps. Sometimes effects can be very complicated and result in React getting stuck in an infinite loop.

Before you say it's because I'm "doing it wrong", Material UI's website had this problem for quite a long time. That issue required doing manual refreshes to not trigger the infinite loops (something you would only see in the debugger). This problem in reactivity is a issue in React that even the best devs can struggle with. My solution was simple... use useEffect less. Depend less on reactivity.

The bottom line for me is that I feel like I can accomplish anything in React, but the devil is in the details. There are so many scenarios that I would need to vet with Solid.js, but if it works better at managing a complex app's reactivity, it could be very compelling.

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

#284

Post by nateroling » Tue, Mar 01, 2022, 2:20 PM UTC

After years of using Knockout and Angular/RxJS, I'm not at all convinced that adding Observables to React is going to lead anywhere interesting.

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

#285

Post by imtringued » Tue, Mar 01, 2022, 2:20 PM UTC

ricardobeat wrote: post #149

seer wrote: post #61

Earlier quoted context omitted.

Maybe, but in my experience whenever I encounter an incomprehensible mess of hooks it usually ends up because devs were not using all the tools that react provides. 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…

> For example a flurry of setStates could be wrapped up in one single state. If it gets too complex - into a reducer 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',…

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

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.

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

#286

Post by dhucerbin » Tue, Mar 01, 2022, 2:23 PM UTC

_ezrr wrote: post #201

This reminds me a lot of Clojurescript's Reagent https://reagent-project.github.io/ (link also has a counter example) I've tried using bare React in the past (after using Clojurescript), because I wanted my project to be more approachable for outsiders. But I couldn't really handle the (to me, and the author) unnecessary complexity that's added. I would even say the Reagent version is even simpler than the Solid.js v…

Imagine if we could have runtime characteristics of solid, dsl of hiccup and simple semantics of clojure atoms and refs!

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

#287

Post by thomascgalvin » Tue, Mar 01, 2022, 2:23 PM UTC

StevePerkins wrote: post #277

The author lost me in the introduction. > "Ohhh, an OO pattern with a couple of one-liner lifecycle methods is just WAY too much code! Higher likelihood for errors and worse developer experience." ... > "So instead, I'm going to replace this with a functional pattern, that crams a couple of lifecycle functions into a closure, and is riddled with edge cases and common developer mistakes." This article perfectly crysta…

UI development seems determined to repeat every mistake we've made on the backend over the past thirty years, while adamantly refusing to ask us about any of those mistakes.

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

#288

Post by prea » Tue, Mar 01, 2022, 2:23 PM UTC

I worked in React for a few years, although not enough to ever feel like I was an expert. This article resonated with me because I also got off the bus because of React hooks.

I've been using Lit.js for about a year now and something about it just clicks. I just wish it were more mainstream.

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

#289

Post by jimmont » Tue, Mar 01, 2022, 2:23 PM UTC

StevePerkins wrote: post #277

The author lost me in the introduction. > "Ohhh, an OO pattern with a couple of one-liner lifecycle methods is just WAY too much code! Higher likelihood for errors and worse developer experience." ... > "So instead, I'm going to replace this with a functional pattern, that crams a couple of lifecycle functions into a closure, and is riddled with edge cases and common developer mistakes." This article perfectly crysta…

I didn't find the word "think" in the article. Did you mean "feels like this looks cooler"? Feeling does appear to be the prevailing way decisions are made and put forward in the community. I think that's a problem. And one that won't be going away anytime soon.

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

#290

Post by schwartzworld » Tue, Mar 01, 2022, 2:23 PM UTC

christophilus wrote: post #248

schwartzworld wrote: post #233

I love solidjs, but the similarities to React are the hardest part for me. The semantics are so similar, but the mechanics are the polar opposite. In react, everything is a function and all your code runs on every render unless you specifically tell it not to. This really encourages a certain style of writing code and provides a lot of guarantees about safety and scope. Solid is literally the polar opposite, your cod…

I had the same problem: spending time trying to figure out why something didn’t paint. You also can’t use restructuring the way you might expect. It’s a cool library, though. I think you just need to keep a different set of nuances in mind when using it.

Agreed, and typescript is essential. I'm still new enough to the patterns used in solid that I can't always tell whether a prop is a value or a signal, but with TS it's trivial.