Hacker News Reader

Comment by spapas82 | Hacker News Reader

Why? I think mainly FOMO. When react was out with the blessings of Facebook people wanted to use the same library. Of course most people didn't really care/understand that their internal crud app for editing invoices wouldn't need that complexity.

I think my answer should answer your second question: This kind of complexity is actually needed on some apps but these apps are a minority.

Programmers love shiny new things and most managers aren't technically competent enough to lease them...

View on HN

> these apps are a minority.

I disagree with this. Almost all front-end projects I've worked on in the last 10 years or so have had some requirement that made pulling in react a better choice than trying to push back on business and/or get buy in to do everything server side. Providing users the kind of tighter feedback loops for their workflows is only possible with JavaScript.

You don't need to do everything on the server side. You can use Svelte or Solid.JS and have the same DevX as a framework, while compiling down to lean and blazing fast JS code on the client.

JavaScript in proper doses and places? Absolutely. Agreed.

But that's not the same as taking on a trendy library (e.g., React) and associated tooling...unnecessarily.

And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load, buttons simply not functioning, and god forbid you try to use the back button. I know some expert will say none of those things have to happen and has nothing to do with react, but the reality of it is that these things are incredibly common in modern front end development, and I blame all the over-engineered frameworks.

Or simply wanting to browse without JS enabled.

Like 30% of pages just give me something along the lines of "enable js to make this site work"

> And this is why half of the internet is borderline unusable. Page layout jumping around for 5-10 seconds after what appears to be a full page load

This is not why half the internet is borderline unusable. React will happily do a full page render in under a second (including network load time). The primary reasons for that are:

1. People writing code that does many network requests in series. 5-10 seems to be not uncommon for many apps.

2. Adverts and as SDKs.

The app I inherited at my last job was a huge 2MB bundle (due to including both the firebase SDK and a large charting library), which I assumed was the cause of the slowness (it was taking ~3-4 seconds to load). But it turned out that was serial network requests that were slowing it down. The app is still 2MB (we made good progress on removing firebase, but hadn't quite gotten there when I left) but it now loads in around a second.

Also add in cookie banners, analytical tracking, newsletter popups.

React is a small library that loads quickly for most people.

It's a mix of this FOMO and a lot of people not knowing how to wire up AJAX well. I've seen entire teams reach for react just because there is a portion of the page where some AJAX was required and react is the only way this new crop of devs knows how to do DOM stuff with server side effects.

In what way is react related to ajax calls? I don't get it :(

The GP is saying that people use react as an ajax abstraction library.

It does make some sense. People used to use jquery exactly that way, and react provides an even better interface for ajax. I wouldn't be surprised if most of the usage of react is there just because people don't want to query their servers by hand.

> react provides an even better interface for ajax

how does react provide an interface for ajax? react does literally no calls at all...

I feel like 50% of the people complaining in this thread have never touched react or their last interaction with frontend code was jquery 15 years ago and they're still carrying those learned paradigms around and applying them to every new framework/ frontend lib they come across

Just want to highlight something from my original post:

> react is the only way this new crop of devs knows how to do DOM stuff with server side effects

DOM stuff with server side effects, they think they need react to do dynamic DOM stuff, especially if that dynamic DOM stuff affects server side state. So this isn't just about AJAX

React today, Angular before that, JQuery, Knockout, All the gloriously bloated .net AJAX controls from Webforms, etc. There's been ways to wrap AJAX calls pretty much since XMLHttpRequest was implemented.

I'd argue "Wiring it up well" is a task better suited for these vetted and highly used libraries than rolling your own code in vanilla JS.

Difference being jQuery was well suited and really necessary back in the day. Browser incompatibility meant that pretty much any non-trivial DOM operation needed to be wrapped by jQuery to be done safetly. Now every browser is just chrome except for firefox and firefox and chrome have played nicely standards wise for nearly a decade now.

Vanilla JS being viable on the frontend without jQuery or some wrapper probably didn't happen until HTML 5 so around 2014 by my reckoning.

Reply on news.ycombinator.com