DEV Community

loading...

Discussion on: Really, why React?

jackmellis profile image
Jack

Okay. I think using an active community as evidence that a library is poor is not the strongest argument but okay.

What you're talking about with 3rd party libraries though is part of the problem with people's understanding of react. They think everything must be react-ey. Everything must now be a component, or a hook. So library authors go in with highly coupled implementations when really we'd be fine with a vanilla js implementation that can be easily tied in to any app whether it uses react, jquery, whatever.

I've used gtm with no issues, mostly because I didn't try to jam I into my react code, I dealt with it thoughtfully and carefully and developed a solution that wasn't a react component or a hook.

Thread Thread
peerreynders profile image
peerreynders • Edited

We as developers should be thinking about the tools we use

Tools should support good practices (best practices are context dependent). Also tools go out of date while the fundamentals don't. Yet there seems to be a contingent of the community who is practicing some kind of "productivity cult" that pays little attention to the quality of their output while continually bypassing the fundamentals of HTML, CSS, JavaScript and (particularly) browser APIs in favor of investing more and more into techniques that are only valuable within the React ecosystem.

React's use rose with "native-envy" - the pursuit of a native-like experience in the browser with SPA. But MPAs have legitimate use cases - in fact most use cases would likely be better served with an MPA (Return of Multi Page Applications).

I remember a time when some job requirements listed "JavaScript (not jQuery)" and am wondering whether "Web Developer (not React)" is in our future.

Thread Thread
jackmellis profile image
Jack

Maybe one day, I'm all for change when something genuinely better comes along. I think web components will one day make react etc. at least partly obsolete. And I think we're surely all excited about the possibilities of wasm right?

However from a personal point of view, where I've spent several years developing, honing, and investing in my skills as a senior level react developer, any large sweeping changes bring with them the prospect of throwing a lot of knowledge and experience in the bin! I suppose this is what happened with jquery though?

Thread Thread
jfbrennan profile image
Jordan Brennan Author

Yeah, React is jQuery in many ways now. It's one reason I avoid going all-in with a framework anymore. I've learned to keep it vanilla and flatten out dependencies as much as possible. Vue gives me a solid structure and data reactivity and I don't want to use it for more than that.

Thread Thread
jfbrennan profile image
Jordan Brennan Author

MPA at a certain scale for sure! I've been met with more than a few blank stares when making such a proposal. "But React SPA is The One True Way" 🤖

peerreynders profile image
peerreynders • Edited

I think web components will one day

Update - article: About Web Components.

I got into Web Components about 2 years ago. There are some parts of the spec that will remain useful but:

  • They dropped the ball by ignoring (potential) SSR of web components. It is possible to write progressively enhanced components (in lieu of partial hydration) but I doubt that will become a common practice.
  • Other parts like the shadow DOM I don't see surviving in the long run (Eshewing Shadow DOM) - they'll likely go the way of applicationCache.

And I think we're surely all excited about the possibilities of wasm right?

What most people overlook (especially client Blazor proponents) is that most environments need a fairly hefty runtime to do their work which adds a considerable weight to the transmittable payload considering current budgets given that personal computing is moving steadily from desktop to wireless handheld devices. Also currently each web worker would need a separate copy of that runtime in memory taxing mobile device resources even further.

So WebAssembly will benefit certain niche applications, particularly in corporate environments but in terms of the public web it's more likely limited to performance optimizations implemented in C/C++/Rust which have a fairly minimal "runtime". So in the end WebAssembly will have much less of an impact than people are currently hoping for.

I suppose this is what happened with jquery though?

SPA happend.

People were actually looking for ways to keep jQuery (or any kind of DOM dependent technology) in check - Segregated DOM.