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…
Solid.js feels like what I always wanted React to be
51–60 of 444 posts
Re: Solid.js feels like what I always wanted React to be
#52No 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?
Re: Solid.js feels like what I always wanted React to be
#53the 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
#54This feels a lot like knockout.js but with a jsx syntax.
Re: Solid.js feels like what I always wanted React to be
#55Honestly 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…
Re: Solid.js feels like what I always wanted React to be
#56This 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
#57I 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?
Re: Solid.js feels like what I always wanted React to be
#58Like 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…
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
#59Re: Solid.js feels like what I always wanted React to be
#60I 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?
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.