281–290 of 553 posts
I use sometimes, but for the most part is overused feature.
I think thats a symptom of a problem with the front end community, people get too attached to the new thing and try to make it the standard instead of building something stable and concise.
Im tired to having to rewrite a code because one library that I had to upgrade decided to migrate to the "new thing"
Earlier quoted context omitted.
> All blow up events come from a loud and extremely small minority. But whether they are making noise or signal, does not depend on number of people! Fair, this instance is 100% noise imo. We're engineers - we should be able to judge when something is silly. > React continues to dominate others because it has corporate backing while Vue doesn't. And angular was popular for the same reason before angular 2. I have nev…
"Doesn't reinvent the wheel" they literally created a whole new language called JSX, I have 13 years writing JS and I dislike React and JSX is one of the reasons. As far I can tell reason it's picked a lot of times now it's market share, people see that is more popular than the competition so they try to learn it, creating a feedback loop that just makes it more popular.
Take React form libraries for example [1], redux-form used to be the most popular by far, was followed up by react-final-form from the same authors so people naturally flocked to that. But that is now clearly seeing a decline as react-hook-form, a library that started from zero, is a lot more pleasant to use.
[1] https://npmtrends.com/final-form-vs-formik-vs-react-final-fo... (set to 5 years)
I have been using react since 2015, hooks for the most part seems like a miss. I use sometimes, but for the most part is overused feature. I think thats a symptom of a problem with the front end community, people get too attached to the new thing and try to make it the standard instead of building something stable and concise. Im tired to having to rewrite a code because one library that I had to upgrade decided to m…
And using it professionally for years now, there's still some cases I can't wrap my head around. And the mental model is just a bit "off". Like, the same function is ran multiple times, but with different behavior (like a useState only uses the parameter the first time the function is ran) which is very unclean.
React had some obvious red flags; it seemed unwise to re-render entire components each time and regenerate the DOM instead of trying to work with it; it's a hack. It's not difficult to think of scenarios were it fails; for example think of what happens to an element's scroll bar after it has been re-rendered from scratch; it resets... Yet people kept coming up with workaround after workaround to all these kinds of issues. If they had tried PolymerJS (which was going for a native Web Components approach and interfaced nicely with the DOM instead of bypassing it), they would have questioned React's merits. When the useEffects hook was introduced in React, to me, that was a vindication of Polymer's stance (which it had figured out years earlier) that you couldn't completely pretend that DOM elements don't exist, yet React's solution was not as elegant as Polymer's as it was tacked on as an afterthought rather than as a carefully thought out design decision.
Nowadays, with native Web Components (HTMLElement) in most browsers, I don't see why people would still start projects with React, especially given the massive number of dependencies it typically introduces and how often they keep changing stuff and breaking compatibility.
They promised a simple component library which would be the answer to our prayers. What we got instead is a 7 year religious pilgrimage which involved a million developers simultaneously trying to make sense of it; attempting to discover its true form by inventing abstraction upon abstraction and growing increasingly fanatical as it devolved into a wicked monstrosity which should have brought the wiser among us to our knees, begging for JQuery.
I wonder how many of the issues people have with React are due to it not being built on a state management library - like Vue is, and Mercury was.
The rendering is whatever. Templates, JSX, it doesn't really matter. Mercury used hyperscript and we got by just fine. But state management is critical, and React seems to leave it completely up to you.
Vue added a hooks-like API. While I haven't used it in anger, I've toyed with it. And it sidesteps some of the weird React hooks caveats... because of Vue's reactivity system. Huh.
*With a brief interlude using the original Angular, which I did not understand then and still do not understand looking back from today.
Earlier quoted context omitted.
In my experience redux-toolkit + redux-saga for async stuff usually work really well. In case of performance problems one can go with profiling + targeted optimisations (e.g. a separate store, some locally managed state).
Glad to hear RTK is working well for you! FWIW, we actually specifically recommend _against_ using sagas in almost all cases. Instead, we recommend using our RTK Query API for data fetching and caching, and the RTK "listener" middleware for reactive logic: - https://redux.js.org/usage/side-effects-approaches#recommend...
What I like about sagas are their simplicity & power (once one understands how generators & effects work), plus the eventChannel feature which lets one integrate with non-redux events. Good TypeScript support is a problem though, and I've had to resort to typed-redux-saga :/
For reasons that I can't quite explain fully, I like angular much better. For me it's a shame that react won the battle and is used at every company now.
``` The quickest obstacle you’ll run into as someone new to React will be something like this function MyComponent() { const [num, setNumber] = useState(42); // infinite loop setNumber(n => n + 1); return {num} } Trying to make state updates at the top level of a component will result in an infinite loop. ``` I've taught React to dozens of people without ever seeing someone try this. A render function is an idempoten…
I like the mental picture of the comparison. Consider, that you might have taught a boased selection of people, and that others might not be so diligent to have read the docs and actually thought about it in depth to also understand it ; )
I like how you say "others might not be so diligent to have read the docs"... As opposed to? Picking up a UI framework and just winging your way through LSP autocompletions until something happens on your screen?
Earlier quoted context omitted.
No, when you mention js libraries you are already starting the clock way too late. The UI problem is not new. People were already building clunky UI cars long ago. MFC was introduced by Microsoft in 1992. Of course the emergence of the web platform and mobile/touch devices complicates the matter as you now have a proliferation of platforms to address (desktop native, desktop web, mobile native, mobile web) but my arg…
The NextSTEP/Cocoa family tree has lasted long enough to be interesting. No first-hand experience with it myself though.
"1990 CERN: A Joint proposal for a hypertext system is presented to the management. Mike Sendall buys a NeXT cube for evaluation, and gives it to Tim Berners-Lee. Tim's prototype implementation on NeXTStep is made in the space of a few months, thanks to the qualities of the NeXTStep software development system."
I'm lucky that I am an independent developer so I can choose to use Solid JS in my projects.
React has so many gotchas and they keep changing the 'best practices' I can't believe people still stick with it.