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

#331

Post by thr0wawayf00 » Tue, Mar 01, 2022, 3:43 PM UTC

marcellus23 wrote: post #310

christophilus wrote: post #306

Earlier quoted context omitted.

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…

> UI is just messy. It's just hard to program cleanly. I'm an almost entirely frontend dev (iOS + macOS now, web development in the past) and this is what I've come to believe. It's easy to program UI cleanly if it's extremely basic or not very usable — but the second you want an animated transition between states, or to remember what the user checked on the last page so that you can keep it checked on this page, or…

> My take is it's because building UI is building software for humans, and humans often want behavior that doesn't allow for clean abstraction. Backend dev is more about building for other software -- not that it's easier, just a different set of problems.

Never really thought about it this way but I completely agree

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

#332

Post by z5h » Tue, Mar 01, 2022, 3:44 PM UTC

toastal wrote: post #269

_0w8t wrote: post #191

Earlier quoted context omitted.

React hooks is another attempt to gain ergonomics. The idea is to try to spread the virtual DOM into native effects. In theory the code specifies or declared the effects once and the framework takes care about subscribing/unsubscribing as necessary. But in practice this became so messy that in any complex cases one better stick to classes and explicit subscribe/unsubscribe. The right way to do that exists in Elm. But…

Oh that's jumping the gun. TEA doesn’t compose and you can pretend you don't need components until you do and then you end up with big mess of hard-to-follow spaghetti code. It's not 'bad', and has good use cases but The Elm Architecture is not without flaws.

Elm composes just fine and you can get close to the semantics of components. I wrote this over 3 years ago, have been using it in many projects with no concerns. https://package.elm-lang.org/packages/z5h/component-result/l...

There are other ways to achieve similar. You don't end up with "big mess of hard-to-follow spaghetti code", you might end up with a "large amount of unfamiliar-looking code". Getting better at reading a larger-than-anticipated amount of unfamiliar code takes a bit of practice, then it isn't a problem. And then you have all the benefits of Elm with zero problems.

The actual hard thing about code is managing complexity, and working with "it just works" magic when it doesn't "just work".

I agree Elm has some flaws, and there is an initial up-front time investment which is unsavoury to many.

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

#333

Post by bgirard » Tue, Mar 01, 2022, 3:50 PM UTC

continuational wrote: post #265

How is the setInterval cleared when Counter is no longer rendered? It seems like a leak.

It's certainly a leak. That setInterval is going to be holding the closure context alive which will reference the component in many frameworks.

The setInterval will also keep firing causing, wasting CPU and battery.

It's hard to take any examples here seriously without showing proper cleanup that would pass code review.

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

#334

Post by dimgl » Tue, Mar 01, 2022, 3:51 PM UTC

I'm surprised to see so many negative opinions about React. Surely, I can't be the only one that truly likes React and finds myself being extremely productive and making impressive apps with it.

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

#335

Post by c-smile » Tue, Mar 01, 2022, 3:52 PM UTC

Instead of vDOM, solid.js uses - real DOM elements + cloneNode().

And that's doubtful decision. Each live DOM element is about 100-200 bytes in memory.

While in React (PReact, Mithril) this JSX expression:

is this:

   ["div",{},["a"]]

5 or so times less.

In other words: needs to be tested on large DOM structures.

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

#336

Post by jsmith45 » Tue, Mar 01, 2022, 3:55 PM UTC

imtringued wrote: post #285

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

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

Not all hooks are implemented in terms of reducers. `useMemo`, `useCallback`, `useRef` for example are not based on reducers, (or effects). Obviously the effect hooks are based on effects not reducers, and some like ` useDeferredValue` are based on both.

But you certainly are correct that useState is reducer based. I'm pretty sure one is only avoiding rerender via using multiple `useState` if they don't implement the reducer in a way where it returns the original object when there was no net change. If you are able to implement the such that it only returns a new object when there really is a change, then a single useReducer call is strictly more efficient than multiple useStates. (This might require more complicated code, as returning a new object every time is often the easy way to implement reducers.)

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

#337

Post by devmunchies » Tue, Mar 01, 2022, 3:58 PM UTC

christophilus wrote: post #246

iamleppert wrote: post #224

This article perfectly captures the essence of why I no longer work in web development. Never again!

Out of curiosity, what do you do now?

Google search says senior eng leadership.

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

#338

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

parentheses wrote: post #82

This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale…

> If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges.

Isn't the point of static analysis (including linters) that they catch those kind of bugs? Having that little red underline (or console warning) saves a lot of pain.

Hooks have completely changed the way I write React code. It's so much easier to test and reason about. Really the only problem is that the guardrails aren't more heavily enforced.

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

#339

Post by muttantt » Tue, Mar 01, 2022, 4:07 PM UTC

frolicker wrote: post #317

christophilus wrote: post #306

Earlier quoted context omitted.

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 have been in the industry since punch cards were a thing and servers took up multiple rooms. I've never been more productive. UI has gotten a lot better since those days and I have migrated my efforts to use frameworks such as Vue.js which is sofar the most elegant and modern approach for doing UI work. Creating a desktop app is very easy with electron js although beit a bit heavy and not the most effecient in term…

Hard to beat Vue, especially when combined with Quasar Framework. The absolute simplest way to deliver SaaS and enterprise apps.

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

#340

Post by joshribakoff » Tue, Mar 01, 2022, 4:10 PM UTC

parentheses wrote: post #82

This article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale…

The idea with hooks is a compiler could generate the dependency array. The flaw isn’t with the hooks paradigm