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

191–200 of 444 posts

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

#191

Post by _0w8t »

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…

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 I do not think there is a way to translate that into JS without requiring either a lot of boilerplate or very messy code

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

#192

Post by leonardopainter »

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. Lints are not rounded edges!

Those linter warnings with React hooks show just how much of a disaster it is. All of the "simplicity" that comes with hooks is just complexity that is now completely out of sight, and only appears once the code is run in a linter. That is even worse than having the complexity in the code.

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

#193

Post by cies »

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…

I like Elm. :)

On the JS/TS planet there's https://cycle.js.org , which comes close.

Looks even better than Solid IMHO.

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

#194

Post by leonardopainter »

drewrv wrote: post #43
hsn915 wrote: post #32

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

Knockout.js was/is wonderful, I'm not sure why it never took off the way angular or react did. I do appreciate jsx though so I'll be looking into Solid.

The problems with knockout were:

very hacky syntax embedded into html. Sometimes you had to even use some kind of comment notation because there was no entry point into the html to add data properties or whatever it had.

it was slow.

the observables weren't variables you could use like plain JavaScript variables

it has the same problem as React - state-based algorithms are not very good ways to solve problems (if (showDialog && !open && ranOnce). You have to keep creating more variables to represent more states instead of using normal programming language concepts, and then all of the observables ping around and become complicated.

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

#196

Post by mlajtos »

Kuinox wrote: post #183
torginus wrote: post #182

Can anyone explain the point of the virtual DOM and why it’s not a source of huge performance issues? What I mean as soon as you retain a reference to a DOM element, it’s lifetime becomes managed by the JavaScript gc - let’s say you build a paginated gallery app in pure HTML and an spa - in the first case, the browser knows that as soon as you navigate away from the page, all those image thumbnails are free real esta…

https://svelte.dev/blog/virtual-dom-is-pure-overhead It is a huge performance issue. I tried to do a pokedex in react, you have to use a virtual list, because react/virtual dom is too slow, doing any operation on a plain list with 1k element, like filtering lead to multiples seconds freeze. This also lead to a lot of issues, like not being able to ctrl+f text being out of screen in a virtual list.

I also did sort-of Pokedex a long time ago [0], but haven't seen any performance issues. No virtualization whatsoever. Code [1] is rather simple.

[0]: https://mlajtos.github.io/lb-pokedex/build/

[1]: https://github.com/mlajtos/lb-pokedex

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

#197

Post by Aeolun »

tjchear wrote: post #181
sbergot wrote: post #173

Earlier quoted context omitted.

Because you sometimes want to filter, sort or project your data. Then you have to handle this in viewmodels or invent more and more features for the templating language. Then you want to refactor into components. So you need facilities for invoking subcomponents. Maybe you want something recursive to display tree-like data. So you end up with a secondary full featured language usually with worse IDE support, worse er…

Haven't used solidjs before, but I paid the doc section a quick visit and saw that it's basically where foobar can be whatever javascript code you want. So you can certainly do filter/sort/project on your data before rendering.

You’d probably not want to project inside that loop though, but before it, in a reactive effect.

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

#198

Post by leonardopainter »

pjmlp wrote: post #184
norman784 wrote: post #139

Earlier quoted context omitted.

I recently started to look at native web components (custom elements), at first I thought I could replace {insert your framework here} with it, but it seems that it doesn't solve the issue, you still need some kind of framework built on top of it to achieve the same goal. If you have some recommendations or want to share your experience with working only with web standards I want to read them :)

Easy, Java and .NET SSR frameworks (which support components for two decades now), + vanilaJS for Ajax like behaviours. Loads fast, easy to debug without tons of layers in the middle. And yes, I also do manually make use of script and vendor JS libraries. Naturally it only works when doing side gigs on my own, on big Web projects where my role is mostly BE/DevSecOps, I go with the flow.

That isn't a solution. Everybody moved away from this approach for web applications for good reasons.

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

#199

Post by _0w8t »

thatswrong0 wrote: post #90
orenelbaum wrote: post #47

Earlier quoted context omitted.

We are not trading some complexity here for some complexity there. We are trading a huge amount of complexity for a framework that is simpler by an order of magnitude. Simplicity is one of the really undeniable benefits of Solid once you gain a decent understanding of the framework. React at times might appear simple on the surface but the overall complexity is pretty huge compared to Solid.

I feel like if it were actually an order of magnitude less complex, it would be eminently obvious from a blog post about it? Maybe I'm just tired and don't "see it" for whatever reason, or maybe I need to find some better examples. From the moment I saw a post about immer.js, I was sold because it seemed like an obviously better solution for the vast majority of cases where I would otherwise grab Immutable.js, a libr…

immer.js can have terrible performance for data structures starting already with 100 of elements. Using JS proxies is not cheap.

We have found that continuing to use immutable.js Map and List but using plain JS objects, not Records is sort-of a sweat spot. But one needs to enforce immutability with Flow/TypeScript read-only types and use the latest immutable.JS to make it work.

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

#200

Post by [deleted] »

torginus wrote: post #182

Can anyone explain the point of the virtual DOM and why it’s not a source of huge performance issues? What I mean as soon as you retain a reference to a DOM element, it’s lifetime becomes managed by the JavaScript gc - let’s say you build a paginated gallery app in pure HTML and an spa - in the first case, the browser knows that as soon as you navigate away from the page, all those image thumbnails are free real esta…

[deleted]
Post reply on HN