Live data from Hacker News

Why I don't miss React: a story about using the platform

jackfranklin.co.uk

121–130 of 279 posts

Re: Why I don't miss React: a story about using the platform

#121
post #102

Earlier quoted context omitted.

Does React itself have edges, or do your issues derive from other parts of the ecosystem (Redux, styled-components, MobX, whatever)?

React has edges. Hooks are an anti-pattern with all kinds of footguns. Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework. And this isn't an issue of me not understanding React or hooks, I would consider myself to be as expertly acquainted with hooks as it's possible to be. Now, do I still use React for everything? Yes. Do I pref…

> Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework.

Okay I can criticize React and its weird solutions until the cows come home, but this is a pretty weird one because it’s entirely an implementation detail. No one working with Suspense ever needs to know that’s how it works unless they’re building a library to be compatible with its behavior. Otherwise it’s just trivia.

Re: Why I don't miss React: a story about using the platform

#122
post #84

Earlier quoted context omitted.

And jQuery is still used in lots of places without any problems AFAIK. Even if the React development team would stop the framework will for sure be around for a couple more years and receive at least security patches.

jQuery has faded into the background, no longer interesting. React has too many sharp edges, it'll only be here until something shinier supercedes it.

jQuery was and continues to be just about as successful as it is possible for a project to be. The reason it’s no longer as widely used is because it essentially became part of the platform. Most of what jQuery does is now possible with platform APIs, and those APIs exist mostly thanks to jQuery proving their utility.

A similar thing happened to CoffeeScript: no one uses it anymore because nearly all of its good ideas made their way into JavaScript itself.

Re: Why I don't miss React: a story about using the platform

#123

Earlier quoted context omitted.

This is categorically false. If you want to update props in a stateful component it is exactly the same - just pass new props. If you instead are talking about syncing props with state, there are ways to do this as well without changing the key, but this is considered an anti-pattern in the first place. This sounds more like bashing react without even knowing it very well in the first place.

If you pass new props, it swaps out the whole instance of the element in the document. Probably.

What's more, if you want it to only do this when passed new props and not at other times, you have to use things like React.memo:

"If your component renders the same result given the same props, you can wrap it in a call to React.memo for a performance boost in some cases by memoizing the result. This means that React will skip rendering the component, and reuse the last rendered result."

https://reactjs.org/docs/react-api.html#reactmemo

Re: Why I don't miss React: a story about using the platform

#124
post #72
post #69

Earlier quoted context omitted.

> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition. The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.

That's like saying I should use a steam engine today because the electric motor will be superseded someday.

The way it played out with jQuery is that there was a transition period; gradually more and more classes of app didn't need to be built with jQuery and it was easier to build them without it.

The implication was that we're in a transition like that presently.

Re: Why I don't miss React: a story about using the platform

#125

Both React and Lit's approach (that requires schedulers and user uncontrolled updates) are completely unnecessary for most if not all of the applications currently using React and I bet nobody even knows why they exist. Facebook made React like this because of these requirements: they wanted their chat application that requires various real time small updates to multiple parts of the page to run quickly where a wipe…

Would love to see some comparison between yours and React, Svelte, Riot, Angular and Vue (or others)

Re: Why I don't miss React: a story about using the platform

#126
post #118
post #73

Earlier quoted context omitted.

That’s a pretty funny stance. The library has a gigantic developer share and is supported by a tech giant. A world where React isn’t used and remembered is one where the web isn’t based on the same primitive. The idea of a thin layer on top of JS offering composition is not complex, and the execution by react is still trend setting. Remember when they introduced hooks and now tons of libraries have the same thing? Th…

Applies the same to jQuery or Bootstrap?

Just a friendly reminder that React is approaching a decade in life. There are no other competing frameworks that look to be taking it’s place.

Not saying it will never go away, just that, maybe the front-end world has finally, significantly slowed down in churn. Things could always be better (Svelte is nice) but overall, React does what I need and I rarely curse at its design.

Re: Why I don't miss React: a story about using the platform

#127

I admit I don't really understand the web components/cusotm elements "story". (I'm not even totally sure the right terminology, or what OP is talking about specifically). Are these now useable on any contemporary browser? Or do you use some kind of polyfill? Anyone have a good from-zero tutorial for the approach OP is talking about?

Yes, they are usable without polyfills in any modern browser. The general idea is that you can register new element types whose behavior is defined in JavaScript classes. They interact with the rest of the DOM in the same way other HTML elements do: by emitting and handling events.

They can also maintain a “shadow DOM” with its own HTML subtree and CSS scope, so that you can make complex elements whose internal state is encapsulated from the rest of the DOM.

Re: Why I don't miss React: a story about using the platform

#128

React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish. You might a…

> Stateful components don't work so well in React.

They work fine, though managing state outside of components via a state management library is common.

> If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key.

Where do you find this recommendation? I’ve never seen anything like it, and keys are usually only used for repeating sets of elements, and you would generally only use a different key if something is not the same logical entity as the thing that previously had the key.

There might be some cases where you want to force a new rather than updated component by the kind of key manipulation you describe, but it's not the general case of prop updates for stateful components.

> It doesn't have incremental screen update, but neither does React, if your components are interactive and stateful.

React does have incremental updates for interactive, stateful components. You can deliberately negate it the way you’ve described, but you should not, generally.

Re: Why I don't miss React: a story about using the platform

#129
post #49

The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like ). Even though v8 is extremely fast at string operations, it's just not a good practice and doesn't sc…

> Web Components is it's slower than React or other vDOM implementations > To re-render, you have to manipulate the innerHTML--usually replacing the string every update "Usually" is relative, I guess, but nothing's stopping you from using the imperative DOM APIs to update the component's contents; I daresay this would be the typical thing to do. These APIs will be just as performant as anything else out there. What y…

[deleted]

Re: Why I don't miss React: a story about using the platform

#130
post #49

The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like ). Even though v8 is extremely fast at string operations, it's just not a good practice and doesn't sc…

Every real world use of Web Components that I’ve seen uses elements and/or imperative DOM methods to implement rerendering. These are blazing fast and exactly what React uses. It’s possible to build a slow app using Web Components, but that’s true of every library, including React.
Post reply on HN