Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

typeofnan.dev

Post reply on HN
Print view View original

61–70 of 444 posts

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

#61

Post by seer »

bryanrasmussen wrote: post #45
joeyjojo wrote: post #24

Earlier quoted context omitted.

This is just iteration on the awesome groundwork that React laid, and shows that things can still be much better. React has some very peculiar patterns that don't really jive well with javascript as a language, or its ecosystem. If the setInterval example is fundamentally against what React is, then IMO that really hammers the point the author is making. I have a few React projects under my belt, and often times stil…

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…

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 jsx without all the interweaving of code and templates.

Maybe the one benefit of classes was like it forced you to think in business logic, then render. React still has that, you just need to dive a bit deeper into its toolbox.

The result usually turns out much more flexible - contexts neatly wrap business logic for all of its descendants, classes don’t.

I think this was maybe because react actually allows you to write messy code, and it’s still performant and works. But in the end it just kinda postpones the inevitable maintenance burden.

I guess solid.js from the looks of it might postpone it a bit more. I just worry that solid looks more like magic, and some invariant somewhere will just break and I wouldn’t know what sequence of reactions actually led to that infinite loop that crashed the page. Haven’t tried it myself though, might more understandable in the end…

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

#62

Post by EMM_386 »

e-dant wrote: post #44

I hate the whole javascript ecosystem to the core. Hey I just finished my progressive web app with these 10 cool react components I found on NPM which fit surprisingly well into our startup’s cloud-native Vue interface. I tried to put the code up on GitHub but it wouldn’t let me upload a 10gb repository (and that was without our proprietary fork of mysql :)

Too much snark.

We are running an enterprise-scale Angular 13 "SPA" that blows the prior platform out of the water.

It just depends on the team and the goal.

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

#63

Post by valtism »

I've used React for ~3 years, primarily with function components and hooks. I think that hooks were a wonderful addition and I think the framework has made smart choices with checking object equality to decided if components re-render.

That said, I think that easily the most difficult aspects of react revolve around how re-renders are triggered. Maintaining referential equality to stop unnecessary renders gets tricky when you are passing functions or objects. Suddenly you need to be using `useMemo` and `useCallback` and passing dependency lists that all have to be primitive values unless you want to memoize them as well. It can become such a headache that the official line around it mostly seems to be "make the render fast, don't worry about unnecessary re-renders" – good advice, until you hit a use-case where you need to worry.

Solid takes these problems and just vanishes them. UI state knows what its dependencies are automatically and only updates when they change – even in a sub-component level!

To be fair, I've never used Solid in anger, and moving to it would be a big ask when there is such a good ecosystem built up around react. That said it is easily one of the most exciting projects on my radar, and the developer Ryan Carniato seems extremely knowledgeable in the area.

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

#64

Post by jakelazaroff »

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…

This is where I’m at, too — it’s faster and simpler than React, and less magical than Svelte, but it’s just too immature. As another commenter pointed out, there’s basically one contributor: https://github.com/solidjs/solid/graphs/contributors

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

#65

Post by lawrencechen »

rezonant wrote: post #55
llamataboot wrote: post #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 t…

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

^ What about Figma? Photoshop? Not everything is only a CRUD app.

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

#66

Post by seanmcdirmid »

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 was about bringing a more immediate mode UI programming model to the web, as opposed to retained UI programming models are a PITA to work with. Retained doesn’t work well in games, it doesn’t work for productive UIs either.

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

#67

Post by stocknoob »

valtism wrote: post #63

I've used React for ~3 years, primarily with function components and hooks. I think that hooks were a wonderful addition and I think the framework has made smart choices with checking object equality to decided if components re-render. That said, I think that easily the most difficult aspects of react revolve around how re-renders are triggered. Maintaining referential equality to stop unnecessary renders gets tricky…

For the other Americans, “used xyz in anger” means “used xyz in production”.

https://english.stackexchange.com/questions/30939/is-used-in...

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

#68

Post by TekMol »

What feels like complete insanity when it comes to React is that it needs compilation to work:

    render() {
        return The count is: {this.state.count};
    }
This is not Javascript and it will need to be compiled into Javascript before it gets executed.

But you can do the same in Javascript:

    render() {
        return `The count is: ${this.state.count}`;
    }
Using regular Javascript makes my life a thousand times easier than having to go through a compiler to make things work in the browser.

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

#70

Post by jorroll »

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…

I think a challenge for new javascript libraries/frameworks is that, for many developers (including myself), we're evaluating the whole architecture. The question isn't, "Which library has the best API and is most performant for rendering components?" It's which choice gets me to "usable app" quickest and most pain-free? Included in the calculation is the ecosystem, the build tools, the documentation, the deployment strategy.

For all these reasons, while I do really love Solid's API, React + Nextjs + Vercel (or another React stack like Gatsby, etc) ultimately provides a smoother development experience for the time being. It isn't enough to build a better React, someone needs to provide an easy to use build and deployment process for it as well.

I ended up giving up on my Solidjs experiments because I spent too much time debugging the build process and porting React libraries. It's still not obvious to me how I could deploy a Solidjs app to, e.g., a Cloudflare Worker and provide a `/api` callable functions endpoint for the application. I have no doubt that I could figure all of it out, but I'm not interested in spending the significant amount of time necessary to do so. I love the fact that Nextjs just gives me all of this. All of this is to say that, while the core Solidjs library is really "solid" (pun intended), I still don't think Solidjs is ready for new projects (unless you really like doing things from scratch).

Post reply on HN