Live data from Hacker News

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

typeofnan.dev

51–60 of 444 posts

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

#51
post #14

What was wrong with the class component? It was very understandable and predictable.

Class components are fine for the simplest examples, but the moment they start increasing in complexity, they become a bit of a mess. Sharing functionality across multiple components becomes tricky with class components (with the only real option being HoCs / render props). You necessarily have to spread logic across different lifecycle methods. Hooks allow you to bundle code together by functionality, and consequent…

Thanks for the viz, haven't done React in a while so it's interesting to see how things have improved. The new paradigm seems alot better modularized and the logical structure seems easier to follow, combined with it taking advantage of newer JS features.

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

#53
Honestly my hope (and I admit as a full-stack but leaning back-end developer to be biased against JS) is that the future is in things like turbo-stream, stimulus reflex, phoenix liveview etc - or in things like all_futures (essentially an ActiveRecord wrapper around kredis) - that we move towards building reactive-apps by firing off events from the back-end and figuring out how to subscribe to them on the front-end

the amount of confusing boilerplate I've seen to keep updated and maintained when a JS framework is loading front-end state by making API requests against a backend and then trying to figure out how to keep those in sync when we could just be firing off SSR HTML over the wire and/or very thin events that FE components can subscribe to or emit for literally no gain in functionality is beyond me

even better, just add reactive sprinkles over what you need reactive and do the rest with standard MVC/REST patterns, if most of what you are using react for is glorified forms, you don't need react for that! user your reactive sprinkles of notification toasts, and chat channels...

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

#54
post #32

This feels a lot like knockout.js but with a jsx syntax.

It kinda is, but it's more than just JSX. Solid was basically born out of Knockout and is in many ways a continuation of Knockout, but it has some relatively significant changes and additions to make this approach more viable, especially for large long standing projects. JSX is more of a quality of life thing, you don't even have to use it, Solid's runtime exists completely separately of JSX and can work great without it or even potentially be integrated with other templating languages.

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

#55

Honestly my hope (and I admit as a full-stack but leaning back-end developer to be biased against JS) is that the future is in things like turbo-stream, stimulus reflex, phoenix liveview etc - or in things like all_futures (essentially an ActiveRecord wrapper around kredis) - that we move towards building reactive-apps by firing off events from the back-end and figuring out how to subscribe to them on the front-end t…

What about apps that have no backend? What about apps that should work both online and offline?

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

#56
For anyone who wants a thorough understanding of how to think about React hooks in the context of things like setInterval, Dan Abramov wrote a great piece breaking it down in detail several years ago: https://overreacted.io/making-setinterval-declarative-with-r...

This post helped hooks "click" for me, and once it did, I've absolutely loved them and now thoroughly enjoy writing custom hooks that greatly simplify my code.

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

#57

I always wonder why all JavaScript client-side frameworks have such distinct design. No other dev environment for building GUIs has react-like components. What’s so special about the web that we keep creating frustrating frontend frameworks for?

Flutter, Jetpack Compose, and SwiftUI all have React-like components.

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

#58
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…

> 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 because of the way react was created, but strikes me as fundamentally flawed.

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.

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

#60

I always wonder why all JavaScript client-side frameworks have such distinct design. No other dev environment for building GUIs has react-like components. What’s so special about the web that we keep creating frustrating frontend frameworks for?

I personally love the front end frameworks, and I don’t find them frustrating at all. Knockout was a workhorse until angular came along. And then vuejs. And now I use sveltekit for pretty much any web app.

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.

Post reply on HN