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

#371

Post by svachalek » Tue, Mar 01, 2022, 5:43 PM UTC

Izkata wrote: post #320

jameshart wrote: post #252

Earlier quoted context omitted.

I don’t understand why people think react hooks are meant to be ‘functional’. They are highly , deliberately , emphatically procedural. The order they are called matters! The time of when they are called matters! The number of times they are called matters! You get a different result from calling the same hook with the same arguments at different times! You get different results if the call site for them is in differ…

> I don’t understand why people think react hooks are meant to be ‘functional’. Because when function components first came along that's what the whole of React was supposed to be: "functional" UI, using things like redux or mobx for state. Plenty of guides still use that terminology even though React's homepage now uses "declarative". That said I think they were always misusing the term, I remember this because I us…

I'm not sure what happened over there but they completely lost the plot with hooks. And now you're not "correct" or "modern" if you don't use them. They're ... fine, I guess. Most of the time. But not at all in line with the fairly clean and consistent vision of early React.

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

#372

Post by svachalek » Tue, Mar 01, 2022, 5:49 PM UTC

christophilus wrote: post #306

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've been in the industry since the days of VB6 (which I loved). I've never been more productive than I was with VB6 and WinForms. That said, UI has always been a mess, even then. The more feature-rich you want your UI, the gnarlier and messier it gets. Everyone always likes to blame the front-end engineers for being slovenly, but my experience is that; UI is just messy. It's just hard to program cleanly. Not to ment…

I've also been doing both sides since the 90s and it's funny how people speak of "just" frontend coding. It has lots of async/parallel issues with messy constraints, and it's the dumping ground for dirty data and error handling issues. It's often done poorly, but doing it right is a very complex problem.

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

#373

Post by aidenn0 » Tue, Mar 01, 2022, 5:49 PM UTC

matsemann wrote: post #79

aidenn0 wrote: post #58

Earlier quoted context omitted.

> 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 be…

That would be true if all a react component was dom output. But since it has side effects (rest calls, mutating state, effects), rerunning everything is the wrong thing to do in almost all instances.

Sure, if you put side effects in your react components, you're gonna have a bad time .

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

#374

Post by mst » Tue, Mar 01, 2022, 5:50 PM UTC

stocknoob wrote: post #67

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...

Speaking as a british programmer, if a given piece of software hasn't made me yell expletives at the screen at least once, I probably haven't done something sufficiently non-trivial with it to count as "used in production" yet.

But then again even by british standards I am unusually sweary when writing code.

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

#375

Post by mst » Tue, Mar 01, 2022, 5:56 PM 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…

Solid very much seems like "what would happen if somebody took the way I usually combine react + mobx and built something designed for that from the ground up".

The only thing it doesn't obviously do better is the JSON Patch generation stuff that I get from mobx-state-tree and I use the word obviously because it would not at all to surprise me to discover that solid already does that and I simply didn't RTFM hard enough yet.

The sheer level of ecosystem (and the "nobody ever got fired for" advantage that results) may keep me using react but solid is a bloody impressive piece of kit and whether I ever end up using it myself or not, "bravo, sir" applies.

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

#376

Post by mst » Tue, Mar 01, 2022, 5:58 PM UTC

dhucerbin wrote: post #286

_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!

I am already far too nerd sniped by other things to try building it myself but that does absolutely sound like fun.

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

#377

Post by mst » Tue, Mar 01, 2022, 6:05 PM 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…

The original angular worked perfectly for me, but that's because I loaded the source code onto my tablet and read the entire thing top to bottom over a few evenings in a pub beer garden with a cigarette and a pint to keep me company.

Newer frameworks are absolutely better for anybody who isn't sufficiently batshit enough to do that, but much though I enjoy react + mobx (especially react + mobx-state-tree) I've never got to the "I have the core source code in my head and can mentally dry run it as a desk check type operation when debugging" stage with them like I did with early angular so - with the level of jank inherent in its scope nonsense entirely acknowledged - I still occasionally miss it even so.

(this is mostly me being nostalgic, I think, the newer stuff is absolutely better but that was a fun few evenings and for its era damn but I could make that thing sing)

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

#378

Post by mst » Tue, Mar 01, 2022, 6:09 PM UTC

ricardobeat wrote: post #146

DougBTX wrote: post #142

Earlier quoted context omitted.

> react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc) React was absolutely a breath of fresh air when it was released. Knockout was similar to Solid.js in that they both have functions that you call which then log a data dependency, then when the data changes the UI updates. This led to lots of pain, because instead of a plain value, you have funct…

We also had ractive.js, we had mithril, intercooler.js (now htmx), we even had (fab).js as far back as 2010 with functional rendering. A 'breath of fresh air' pretty much depends on what you had been breathing.

React wasn't exactly innovative as such so much as it was a very carefully designed (I don't mean they didn't make mistakes, mind, only that they clearly put effort into making new and exciting mistakes) implementation of the model that successfully broke into the mainstream.

The phrase "an idea whose time had come" springs to mind.

(this comment is intended to read as professional respect, not fanboying - the extent to which I succeeded in that intension must inevitably be left as an exercise for the reader)

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

#379

Post by mst » Tue, Mar 01, 2022, 6:14 PM UTC

littlecranky67 wrote: post #156

ricardobeat wrote: post #149

Earlier quoted context omitted.

> 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',…

Why is performance always argument No. 1? The true rule is, code must be readable and maintainable first. THEN, if there are performance issue with the code (no theoretical ones, you HAVE to have a real-world profiling report of YOUR code in your hands when you argue about performance), you can refactor for performance.

A thing I remind myself of regularly: Avoiding worrying about optimisation up front too much is not avoiding caring about optimisation at all, it's reserving the number of hours you can expend on optimisation until you have enough working to have a profile available, because you are inevitably going to be wrong about which part is actually slow until that point so your optimisation hours budget will be better spent with a profile in hand.

There's a parallel here to "no, you did not find a bug in the compiler". Yes, ok, once every five years or so I actually did find a bug in the compiler, but assuming you aren't that smart is still a far far better default approach.

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

#380

Post by mst » Tue, Mar 01, 2022, 6:21 PM UTC

cehrlich wrote: post #155

KronisLV wrote: post #108

Earlier quoted context omitted.

> 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.…

Zustand has solved the complexity of state management for me, although getting {employer} to adopt it is of course a different problem altogether. It's really bizarre to me how poorly useContext works, in contrast to how good everything else in React is for the most part. Having a good, "official" global state management solution that requires little boilerplate would be a huge benefit.

I am currently most fond of mobx / mobx-state-tree which is a substantially different style but I am very much impressed by zustand as "take the redux style and do it really well".

There are enough different takes on how to state management that I am ... ambivalent ... about whether having a single official solution would in practice be better than the current situation. It's inevitably going to be a trade off and the react team not wanting to pull the trigger on such a thing until they're -really- sure is probably a good thing overall.

As a side note: I agree that useContext is weird, but jamming what (at least according to the mental model I use when working with it) is dynamic scoping into a language without native dynamic scope is probably always going to be at least somewhat weird.