Live data from Hacker News

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

typeofnan.dev

211–220 of 444 posts

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

#211
post #183

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.

Great article. The fact that Angular, the framework built by the company who also builds the world's most popular browser, does not have a virtual DOM, is very telling.

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

#212
post #203

Earlier quoted context omitted.

If the state comes from the user, they can add script tags into the html How is that different with React? And how is it a problem? A rendering engine would set the html of some element to the html I think? This ... document.body.innerHTML=' alert(1) '; ...does not execute the script.

https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...

True.

But the same issue with reacts way.

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

#213
post #43
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.

As far as I could tell, around that time (and even now to some extent) the amount of activity on StackOverflow is used to measure the popularity of a project.

Angular had a "made by google" kind of logo on its website, indicating to many people that it's of high quality and worth adopting.

But Angular was also so convoluted and had so many problems that so many people kept running into random problems all the time and had to ask questions about them on SO. This signals (incorrectly) that Angular is popular, driving more people to believe it's worthwhile to adopt it.

Knockout had neither. It was not sponsored by a corporation. And it was so good that you hardly ever run into random problems.

Ultimately it was eclipsed by React and Typescript because lack of type checking for the html templates means it's hard to scale it will to large projects.

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

#214
post #203

Earlier quoted context omitted.

If the state comes from the user, they can add script tags into the html How is that different with React? And how is it a problem? A rendering engine would set the html of some element to the html I think? This ... document.body.innerHTML=' alert(1) '; ...does not execute the script.

https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...

In terms of the placeholders in JSX, no they are escaped.

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

#216
post #184

Earlier quoted context omitted.

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.

The craziness of SPA frameworks running headless browsers, rediscovering SSR as if they are inventing something that no one else thought about, proves otherwise.

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

#217

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 have the same complaint about hooks. Most people seem to ignore that tidbit, but to me it's really frustrating. Plus I recently hit more hook issues when putting a setInterval inside a useEffect. There's no way to do a normal didMount/willUnmount workflow without other hacks (i.e. useRef) just to set up a simple timer. Maddening! Edit: after writing this I went and read the article. Same scenario I was bitching abo…

I think I ran into a very similar issue recently too, stale closures right? didMount/willUnmount worked perfectly, but useEffect got screwy very fast, even posted a SO article trying to see the best workaround, nothing great.

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

#218

Earlier quoted context omitted.

This feels like we're trading complexity here for complexity there, and it seems impossible to judge which way is actually "better". I use loops in React all the time but only have used `setInterval` in a component a handful of times..

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.

My library (see other comments) has components that are about half the amount of code as react or solid and in pure javascript. The javascript shows exactly was is happening, as opposed to the "simplicity" of react that shows a pretend version of what is going on, then 5 years later people discover that is a bit of a problem and now we are onto the next library (solid?).

I wonder if I could have your opinion on my library, and why half the code, native performance is actually more complicated in the long-run. I don't know the answer at the moment. Documentation isn't complete... it is just web components. eg hello world just becomes a function like const component = hello('Andrew'); document.body.append(component); in the example on github. Anyway, the todo shows a more typical real world example I guess.

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

#219

I wonder if there's an immediate mode framework for Js, in the vein of IMGUI for C. If people are wondering what that is, it's basically this: function renderGui() { label('hello') if(button('click me')) { console.log('I have been clicked') } }

This seems like a huge step back from declarative UIs, any reason why you would say it’s preferable?
Post reply on HN