Live data from Hacker News

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

typeofnan.dev

341–350 of 444 posts

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

#341

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". I do not want this handled at the framework level though. There are plenty of times in my day-to-day where that linter is wrong. If I were to add one of the dependencies (it's sure I should add) my component would re-render over and over. Sure, one could argue, "well,…

Read the hooks FAQ, the linter is not wrong, you are :) https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-f...

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

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

I've been maintaining a web component library with Lit for a while. Web components overall don't feel ready for primetime. Just making a custom input field and have it work with a is chore.

Just look here at how much overall code is needed to do it right: https://github.com/ing-bank/lion/blob/master/packages/input/...

After you get through all the inheritance and mixins it's thousands of lines

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

#343

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

But those dependencies would be static. This goes beyond that. I won't call hooks flawed, they are suitable for React's model, but looking at what reactivity does is a different sort of thing. It is a subtle difference at first.

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

#344
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!

It should be possible to build an idiomatic cljs layer over solid. Solid’s compilation step can be implemented with clojure macros.

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

#345
post #123

Earlier quoted context omitted.

Maybe the name is trying to communicate it happens after the component mounted instead of just before

`on_mount_complete` sounds more professional

Agreed; the existing name is not great.

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

#346
post #209

Earlier quoted context omitted.

People always use the setInterval() issue as a footgun. The real footgun is people not reading the documentation for the framework they use, because the exact example is handled in the official react docs [0]. I always advice aspiring react devs to understand why this exact setInterval() doesn't work (and why there is the need for the rule-of-hooks), because it will automatically create an understanding how hooks and…

When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case. React was easy coming from jQuery, Backbone other frameworks at the time. With effects, i've read the docs many times. I still don't fully understand how it's supposed to work. I don't seem to get the feeling / abstract concept behind it and it still surprises me a…

I had the opposite experience. I started with classes, and anytime I had to do anything even slightly complicated I had to go running for the docs. The lifecycle methods are byzantine and frequently require not only overriding the method, but checking the values of parameters to determine the proper sequence of operations.

In contrast, useEffect() is "exactly what I want" without having to figure out what combination of lifecycle methods to implement.

I'll grant you that this could have been done differently - I'm not a fan of the "order of calls represents hidden state" mechanism for hooks. It's possible to imagine a different API for class components that provides ergonomics similar to useEffect() and useState(). But hooks are still an improvement over the old class component API.

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

#347

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…

I've not used Svelte, but when I've used such DSLs the problem tends to be that they're not very flexible, and as soon as you step outside of the provided helpers you're stuck and you just can't do the thing.

Do you have an example you've run into where a DSL such as Svelte's or Vue's has actually stopped you from doing something? Would be genuinely interested to see it as I've never run into such a situation myself.

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

#348

Earlier quoted context omitted.

The purpose is well-documented here: https://reactjs.org/docs/reconciliation.html#recursing-on-ch... And it also goes into why index is a poor key (it's basically the same behavior as with no key). Using object identity to detect inserts doesn't work either, because the map function is returning new React element objects on each render. Practically speaking if you know your items won't change, then omitting the key o…

I know, I've read it. I'm still not convinced. React could just as well generate and insert missing key on build instead of asking me to do this: ... you can add a new ID property to your model or hash some parts of the content to generate a key. It is just plain wrong to ask me to change my data model because of this. This is part of the housekeeping that I expect the framework -- pardon, library -- to take care of…

It can't. Not in a consistent manner. When diffing user provided immutable data you need a user provided key. Otherwise it can't tell the difference between a new list entry and a nested update. You could treat every nested update as a new item but that is incredibly wasteful as it throws away all descendants. This is something all non-fine-grained rendering libraries have to deal with be it React, Vue, Svelte, or Lit.

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

#349
post #209

Earlier quoted context omitted.

People always use the setInterval() issue as a footgun. The real footgun is people not reading the documentation for the framework they use, because the exact example is handled in the official react docs [0]. I always advice aspiring react devs to understand why this exact setInterval() doesn't work (and why there is the need for the rule-of-hooks), because it will automatically create an understanding how hooks and…

When I started with classes, I hardly had to read the docs, few hours and was good to go. For many developers I worked with at the time this was the case. React was easy coming from jQuery, Backbone other frameworks at the time. With effects, i've read the docs many times. I still don't fully understand how it's supposed to work. I don't seem to get the feeling / abstract concept behind it and it still surprises me a…

Right there with you. I've been building React apps full time since 2016. I used to convince people to switch to React because of how easy it was to learn and how quick it was to get through the docs. Props, state, setState, done.

I've built some really complex frontends with React. But now here I was, struggling with setInterval, ha.

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

#350

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. Once you deal with larger amounts of data and need virtualised rather than fully-materialised lists, you start using different things in React as well. The fact of…

What JS framework would you choose to work with big datasets like, e.g. a data grid with half a million rows that should have a "filter as you type" functionality?

You shouldn’t do that kind of work from the rendering thread, and you should use occlusion culling to only render the needed DOM
Post reply on HN