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,…
Solid.js feels like what I always wanted React to be
341–350 of 444 posts
Re: Solid.js feels like what I always wanted React to be
#342I 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…
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
#343This 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
Re: Solid.js feels like what I always wanted React to be
#344This 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!
Re: Solid.js feels like what I always wanted React to be
#345Re: Solid.js feels like what I always wanted React to be
#346Earlier 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…
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
#347Earlier 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.
Re: Solid.js feels like what I always wanted React to be
#348Earlier 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…
Re: Solid.js feels like what I always wanted React to be
#349Earlier 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'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
#350Earlier 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?