Live data from Hacker News

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

typeofnan.dev

181–190 of 444 posts

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

#181

Earlier quoted context omitted.

>In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like that reinvents a concept that's already in the language. I find this a totally bizarre complaint. I've spent the past few months working on Svelte stuff and I've seen people on HN make this same complaint about Svelte's t…

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.

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

#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 estate, at the latter case it first needs to wait for the spa to release references to the underlying html objects, then the gc needs to run, at which point it can get rid of it.

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

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

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

#184
post #98

Earlier quoted context omitted.

I keep my sanity by ignoring all of them, focusing on mastering pure Web standards only, and delving into such frameworks only when I am required to collaborate with Web FE devs.

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.

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

#185
post #125

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…

Hooks triggered my code smell detector so bad that I didn't even bother finishing the tutorial. That said, I still preferred React.createClass so I guess I'm somewhat off the beaten path when it comes to React.

Back when they were initially released my teammate started rewriting everything in them. Little did he know, if you're not careful with hooks, you can severely damage performance.

My take is that if a feature requires a linter to be properly implemented then it's obviously giving the developer too much rope to hang themselves with.

Also it appears that they were introduced mainly for performance, but for some reason sold as the new "better" way of writing applications.

I actively avoid React and its ecosystem, because I believe there's just too much FOMO and "fashion"(for lack of a better word) in what drives its development and not enough meritocracy.

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

#186

Earlier quoted context omitted.

For the other Americans, “used xyz in anger” means “used xyz in production”. https://english.stackexchange.com/questions/30939/is-used-in...

Weird. I'm not British by I say "used xyz in anger" because I read lots of other programmers saying it. Had no idea it was regional, thought it was hacker lingo like "grok".

I'm not an English native speaker and today I learned that I misinterpreted a lot of what was said to me in the past.

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

#187

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.

I believe there’s a finite, fixed amount of complexity in problems; that there is, categorically, no way to solve problems without that amount of complexity that is inherently part of the problem domain.

So, what you have here does not remove complexity from problems, it moves the complexity from one place to another.

So, when you have a simple task, and a straightforward framework, what you see is “it’s easy!”. …because when you use the complex framework you get a bunch of “solutions” to problems that don’t exist on your problem.

That’s why it appears overly complex.

…but for a complex problem, when all you have is a simple framework (like ) you have to implement the complexity yourself, which makes you view the framework as feeble and under whelming.

So, you are just moving the complexity from one place to another; the question is, is the complexity of react really something most people need, or can a framework like solid solve the 90% of simple problems most developers have?

It’s hard to tell.

Most new frameworks excel at solving simple problems because it makes for cute demos.

Is solid any different?

That’s my question. How does it work at scale, for large complex projects? Is there a whole design system implemented in it? Who’s using it and for what?

The claim that it’s “not complex” doesn’t help.

All that means is there are probably a crap load of things it doesn’t include I’ll have to do myself.

There is no magic bullet that removes complexity from tasks.

React is a complex beast, and a nice clean framework to replace it would be welcome.

…but you have to approach this kind of discussion honestly.

Hello world examples are a dime a dozen.

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

#188

New JS frameworks always make for compelling hello world examples. Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty! As an example of this point, check out the "Simple Todos" example for So…

>The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty!

Actually, that is only half the reason. You can do whatever you want in my library (github.com/thebinarysearchtree/artwork) and it doesn't have any kind of virtual DOM or whatever Lit does, because you just create elements with JavaScript. The second reason, that everyone just assumes is the default, is that React has to use HTML-like templates and not just JavaScript.

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

#189
I've been using React since around 2016 and when Hooks were introduced I played around with it but didn't like it at all exactly because of the reasons mentioned in this article. Sure it reduced quite a bit of boilerplate code that came with class based components and enabled better code re-usability outside of class inheritance or mixins but the disadvantages were too big for me personally to really consider using Hooks in a "greenfield" setting.

In my current project I'm using Vue with Composition API which gave me the exact same "aha" moment the author of this article had with SolidJS. Vue + Composition API is way more similar to SolidJS in principle than React + Hooks.

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

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

This is about "feels like" and me too--the little newsletter popup and lack of substance shows this. React became obsolete over the past few years as browsers increasingly adopted the mix of web components features (eg componentDidMount vs connectedCallback). Just using React, and the explanations for why a technology is and isn't used in an organization speaks to the level of practical knowledge and detritus in proj…

That is a big call regarding web components. I did some looking into web components for a recent project and React is just way ahead in many areas. You could use a framework like Lit to help smooth things over, but that just speaks to the underlying standard being somewhat cumbersome to use. I totally want web components to succeed and be the new way of doing things, but I get the feeling that is still a while away.
Post reply on HN