Escape the nightmare, embrace the zen, use Joystick: https://github.com/cheatcode/joystick.
Solid.js feels like what I always wanted React to be
361–370 of 444 posts
Re: Solid.js feels like what I always wanted React to be
#362I'm used to react and hooks,and right now I can't do any better. Doesn't mean I like it. The solid example here seems to have a similar complexity and implicit knowledge as hooks just a slightly different syntax
There's light at the end of the tunnel. Don't fret, traveller: https://github.com/cheatcode/joystick.
Re: Solid.js feels like what I always wanted React to be
#363I tried several React alternatives. At this stage, size of community is a really important factor, overriding many other factors. It's just incredibly important for there to be tools support, questions answered on stack overflow and a community of people developing related software. At this stage there's only really VueJS, Angular and maybe one or two others with community large enough to justify changing.
Just started back in October, but you can talk to me directly and get questions answered pretty quick: https://github.com/cheatcode/joystick
Re: Solid.js feels like what I always wanted React to be
#364Earlier quoted context omitted.
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 don't understand your issues here. I built a community app for a hockey league that manages around 120,000 players in the DB. I do tons of loading, sorting and various algorithms on the data. I've never once had React be my bottleneck. Rendering a page server-side and delivering it to users is about as inefficient a process as you can get unless you have massive resources dedicated to an optimization almost no one…
I bet you don't display the 120k players at once on the front, you use some sort of virtualised component (like ag-grid) thats put in the DOM only what is displayed on screen, and keep the whole set in memory.
It cause an issue: now the search in document browser feature will not work properly.
This is acceptable the usecase you are describing(due to the huge dataset), but a lot of interfaces use such virtual list, and it's an PITA for the user.
Take Azure DevOps for example: In a lot of place, you can't ctrl+f a project outside the screen, even if it exist, you have to scroll to it.
> Rendering a page server-side [...]
Nobody talked about server side rendering there.
> The virtual DOM is extremely efficient
Did you read the article I linked ?
The virtual DOM is not "extremely efficient" it's only good at removing uneeded DOM modifications. Not doing these uneeded modifications in the first place is faster.
Re: Solid.js feels like what I always wanted React to be
#365Earlier quoted context omitted.
>"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...
No post body was provided.
Re: Solid.js feels like what I always wanted React to be
#366Earlier quoted context omitted.
> react is fundamentally about 'inputs changed, render this' I mean, pretty much all frameworks these days have that fundamental declarative model, react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc) What the setInterval example highlights is that newer subsystems in React like useEffect and Suspense are bolted on top of earlier iterations that wer…
> react wasn't particularly innovative on that front (e.g. the declarative model already existed in angular, knockout, etc) React was absolutely a breath of fresh air when it was released. Knockout was similar to Solid.js in that they both have functions that you call which then log a data dependency, then when the data changes the UI updates. This led to lots of pain, because instead of a plain value, you have funct…
React also requires that you call functions to trigger rendering (be it via setState or `[, setFoo] = useState()`) and it definitely has warts that trip people up too (e.g. semantics of calling setState twice synchronously). The dependencies array in useEffect is also conceptually the same mechanism you claim causes pain in Knockout.
IMHO, historically, the bigger pain point with the reactive model was data marshaling/unmarshaling (e.g. updating some subtree of data and then needing to send the root of the data tree to the server while maintaining reactive bindings across a large app and being careful not to fragment source of truth). Ironically, React can also end up in this predicament, because the encapsulation model of its `state` mechanism means extracting the actual state of the component tree is non trivial unless you're using a third party state lib to avoid it altogether in the first place, or at least use useReducer, which is a relatively new addition to React (and even then, it's kinda jank).
These days, React is a hodge podge of many different implementation approaches. Yes, there are props, but Context also exists - and is used extensively in the wild - precisely because props get clunky, and then there's data diffing happening to support `memo`, on top of the virtual dom change tracking. Suspense basically requires your code to adhere to semantic restrictions, i.e. you're not even in control of when your component function is called, which leads to having to tip-toe around that scope w/ extra closures, which in turn leads to all the issues that the article touches on.
The hodge podge issue isn't specific to React; Vue is also seeing pain points from having so many ways of doing things now that they're trying to push a v3 and realizing ecosystems tend to slog.
To your point, yes React was relatively simple when it came out, but as I mentioned, it wasn't the first to take a stab at the declarative model, nor the simplest. It just benefited greatly from the popularity wave of the golden years of Facebook OSS engineering. And from a practical perspective, it doesn't really matter what React was. Idiomatic usage is a thing, and React development today isn't like React development 7 years ago.
Re: Solid.js feels like what I always wanted React to be
#367This 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…
Sure there is. Set the interval on mount, clear it on unmount:
useEffect(() => {
const interval = setInterval(() => {
// whatever
}, 1000)
return () => {
clearInterval(interval);
}
}, [])Re: Solid.js feels like what I always wanted React to be
#368Earlier quoted context omitted.
I love vue’s concept of computeds. It makes me think back to knockoutjs when things felt like they “just worked” as long as you knew where the ES5 footguns were. It’s nice to have a concept “ground truth” in data and props and then computeds that sort of tie it all together.
Yes, and those are available as well with MobX (in React), Svelte, etc. You can do same/similar with React hooks, just not as clean or obvious.
You can 100% do these things in React, I don't believe React is a less able framework by any means. If anything it gives you a powerful toolbox and pulls down the guard rails.
I do, however, think that working with React changes your mental model somewhat, and when I'm working with React I catch myself doing a lot more data wrangling close or in the rendering loop than I would in any other modern framework. Certainly since class components have fallen out of favour, you're working with a function designed to be run hundreds of times, while Vue and Svelte both provide clear patterns to deal with data at the point of change, then separately deal with updating the display of that data as required.
It takes using something like MobX to really push a React codebase to a data-driven model and that means many inexperienced developers fall into the common pitfalls far more easily than if they're using an alternative framework imo.
Re: Solid.js feels like what I always wanted React to be
#369I'm surprised to see so many negative opinions about React. Surely, I can't be the only one that truly likes React and finds myself being extremely productive and making impressive apps with it.
Have you tried solid/vue? If so, consider adding your perspective of what react does better.
Re: Solid.js feels like what I always wanted React to be
#370The author lost me in the introduction. > "Ohhh, an OO pattern with a couple of one-liner lifecycle methods is just WAY too much code! Higher likelihood for errors and worse developer experience." ... > "So instead, I'm going to replace this with a functional pattern, that crams a couple of lifecycle functions into a closure, and is riddled with edge cases and common developer mistakes." This article perfectly crysta…
> "I think this looks cooler." You're using this straw man to demean the author, but I think you miss an interesting point: it can be very hard in software developer to articulate the good and bad. "Uncle Bob" refers to this as "code smells", where you can't quite say immediately what's wrong here, just that you don't like it much. Something smells bad. And maybe the point of Solid is to point out a mistake React mad…
Super subjective.
To people who know what they are doing more code than necessary to accomplish a task is the code smell.
To people who are super insecure vanity code is required because patterns are memorized, so any deviation from the unnecessary boilerplate is the code smell.