DEV Community

loading...

Discussion on: Really, why React?

jackmellis profile image
Jack

I don't want to spark yet another library vs framework debate.

Your point is that's it's "easy" to make an app that's steeped in react-ness, but that doesn't mean that should be the right way.

I've been building apps for years now where react is only a part of the app, I treat react like a library. React is certainly not my application.

This is just another trap that people fall into, then other people copy them, and so on, until everyone just thinks this is how we write "react apps".

I absolutely promise, you can (and should) build applications with react, without react underpinning the entire architecture!

Thread Thread
peerreynders profile image
peerreynders

Your point is that's it's "easy" to make an app that's steeped in react-ness, but that doesn't mean that should be the right way.

Most of React's popularity is based on the perception that using it is "falling into the pit of success" - i.e. it's easy to do the right thing, hard to do the wrong thing. You are describing React as "falling into the pit of despair" - which in a way is what this article is claiming.

React is certainly not my application.

Perhaps you are in the minority. By and large pro-React developers judge it as too much work to keep the UI (React) and the client side application segregated.

And if a React application that is built "the React way" looks over-engineered then the segregated version is going to be worse. At that point one has to wonder whether it is the right tool to begin with.

Thread Thread
jackmellis profile image
Jack

I'm definitely in the minority 😅 and yes a cleanly segregated application requires engineering that would seem excessive on a small app. But your "too much work" comment strikes true with me as I think a lot of developers take the easy/lazy route, and then they wonder why their code is unmanageable further down the line...

Thread Thread
peerreynders profile image
peerreynders • Edited

yes a cleanly segregated application requires engineering that would seem excessive on a small app.

Given the level of engineering you have to invest anyway what does using React buy you? (Other than it being so mainstream that few would question the choice.)

Would it be more work to use something more lightweight (example: HN PWA - live - article).

Thread Thread
jackmellis profile image
Jack

Assuming I'm probably just blind to skme of the jarring aspects of adopting react by this point, I'd probably say it wouldn't.

However, what react buys you is 2 very important things: community support/ ecosystems, and job opportunities!

Thread Thread
jfbrennan profile image
Jordan Brennan Author • Edited

Underscore/Lodash are amazing libraries that offer TONS of value. So is Day.js. So is Riot.js. But no one ever thought of an "Underscore community" because good tools don't require a whole community to support you as you attempt to use it. The best tools are simple, self-explanatory, and effective on their own. React is not that, so people depend on community support.

A large ecosystem is not a benefit. It is a sign that the library is too finicky and non-standard to play nice with the thousands of other libraries out there, hence all the special React versions of those libraries. React's weirdness and excessive ecosystem is exactly why I couldn't get the standard Google Tag Manager snippet to work (same issue and hilarious thread where React devs try to figure out how to make a little snippet of standard code work inside Next.js github.com/vercel/next.js/issues/160).

Yes, job opportunities. When hiring managers don't know anything about frontend execpt the app was written in React and so they need a "React developer". This is not good for anyone!

Thread Thread
peerreynders profile image
peerreynders • Edited

However, what react buys you is 2 very important things: community support/ ecosystems, and job opportunities!

Completely understandable from a personal perspective - but potentially damning for the assessment of the industry's maturity when overall, real cost/benefit of the tool solving an actual problem barely influences the decision.

Thread Thread
jackmellis profile image
Jack

I wouldn't say they barely influence the decision. Just pointing out that at the end of the day, in any language, framework, business, whatever, there is more "real world" stuff than just pure programming pros/cons.

However I also still stand by my opinion that there's nothing wrong with react as a library, we just don't always use it in the best way. I mean, I've seen some pretty disgusting stuff made with just jQuery, far worse than any modern framework 😂 We as developers should be thinking about the tools we use, rather than assuming the authors will hand hold us or force us to do stuff the "right" way - which itself is super subjective

Thread Thread
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.