Live data from Hacker News

React is the new jQuery

bradfrost.com

111–120 of 206 posts

Re: React is the new jQuery

#111

> React is the new jQuery Anyone who uses "the new jQuery" as some sort of insult (as it seems Sara did in her tweet) probably hasn't been a developer for more than a few years or is just trying to sound smarter than they are by bashing an easy target. The reason jQuery got so popular is that it made common tasks so much easier than anything else at the time. Anyone who was doing web development before jQuery knows w…

Back when browsers were wildly incompatible jquery was a life saver. Sure you could do painful dom code and then have all kinds of libraries that have to be loaded in the right order to support all browsers or you could just include jquery. Now in the era of the progressive web app SPA jquery is outdated. Even for low level dom its still outdated because modern browsers follow standards really tightly especially compared to the bad old days. Frameworks are starting to get outdated in the face of tools like Svelte as well as Polymer 3. You can pull off a SPA with Polymer 3 on modern browsers with no shims at this point, except maybe shadow dom, but Polymer 3 has selective shimming so you don't have to download one huge shim file.

Re: React is the new jQuery

#113

Moved from Vue to React. A couple things drove this: Typescript support for Vue was kind of weak, and the interception of events and reactive elements ended up creating more bugs. I do love how Vue is easy to get up and going fast, but React seems more compatible with a growing team where you want stronger guarantees.

First time I read someone moving from Vue to React. I thought trend was only from React/Angular to Vue?

Re: React is the new jQuery

#114
post #103

Earlier quoted context omitted.

I agree jQuery was very useful early on, especially since it abstracted cross-browser differences and APIs. However in my experience, a couple of things were key to creating a negative view of jQuery: 1. Security and unsafe defaults, for example: evaluating remote JavaScript by default [1]; and unsafe DOM parsing by default [2] 2. Not really to blame on jQuery, but its ease of use for DOM manipulation led to programm…

To be fair, when jQuery was growing up PHP with magic auto global variables was the fury. Times were different

I think by 2006 magic auto globals was already off by default (4.2, which was released in 2002, was the one that turned it off, and though 4.2 was still widely used by the time jQuery came about, register_globals was considered bad practice in general by at least 2004, if not even earlier).

Re: React is the new jQuery

#115
post #66

Earlier quoted context omitted.

Well kids these days. They said webkit is the new IE, and said the IE era was IE7. Sigh I cant even name a similar piece of software in web development history that is as important as jQuery. Despite Web development as a whole, back end or front end is still no where near being good enough, it is still many times better then the old days.

>cant even name a similar piece of software in web development history that is as important as jQuery. Php?

Nah, there were always tons of alternatives to PHP. What real alternatives were there to jQuery? There were none.

Re: React is the new jQuery

#116
post #66

Earlier quoted context omitted.

Well kids these days. They said webkit is the new IE, and said the IE era was IE7. Sigh I cant even name a similar piece of software in web development history that is as important as jQuery. Despite Web development as a whole, back end or front end is still no where near being good enough, it is still many times better then the old days.

> I cant even name a similar piece of software in web development history that is as important as jQuery. Apache?

There were other web servers, there weren't other jQuerys.

Re: React is the new jQuery

#117

Earlier quoted context omitted.

> A charitable explanation of Sara's tweet might be that, like with jQuery, it is becoming difficult to convince new developers that React may not be necessary for their next project. That's fair. > The other comparative downside of JQuery was that components started to rely on it as a shared library, which meant developers suddenly needed to do dependency management. That is (usually) a bad idea. React absolutely do…

> Who is going to want to use a dropdown component that has the entire React 15.3 lib bundled into it? ...Nobody? Which is why peer dependencies exist. NPM/Yarn aren't perfect by any stretch, but maybe mind Chesterton's Fence and refrain from reflexively assuming the developers of them are idiots?

Peer dependencies are a very valuable tool, and I'm glad that they exist, but most developers should avoid them in most scenarios. If a package requires a peer dependency, it's probably not worth using. There are exceptions but... in general.

This has been reinforced over and over again throughout JS history. jQuery, Grunt, Gulp, Angular, Bootstrap, and eventually React will join that list as well. You almost always end up with the nightmare of having to do package management because widget A and widget B interfere with each other. This is the same exact reason why it's good practice to avoid defining JS variables in the global scope.

Peer dependencies are just global variables at the package level.

To be clear, the people who built NPM were not idiots. Node handles packaging really intelligently - via a node_modules folder. There was a lot of thought put into how to make this system flexible: for example, you can have a node_modules not just at your root, but even in subfolders. This allows you to have custom implementations of a dependency that's isolated to a single folder in your source code, and to easily check your implementation directly into your VC.

None of that is accidental - the Node developers learned from languages like Ruby and Python, where gems and packages would be installed globally to the system, not locally to your project. They wanted a system that got rid of the majority of peer dependencies.

Jump outside of the web world and you'll see the same trend in the broader software ecosystem as well. The big hotness around Linux packaging right now is Flatpack, which is mostly copying Node's strategy of bundling dependencies into the app and then de-duplicating them after installation. Docker is an even more extreme example of this trend.

Peer dependencies are sometimes useful, and they're an important concept. But people use them and abuse them too much. They sound like they should be a good idea, so developers often don't realize the downsides until after they've gotten bitten - and even then they often just assume they were using a bad library or something.

9 out of 10 times you should avoid them, and you should avoid frameworks that introduce them.

Re: React is the new jQuery

#119
post #68

I find myself defending myself a lot these days here. I use vanilla js. Never had any trouble, I literally have no bundle, no dependencies, the amount of code I have to write is basically the same either way, no trouble syncing state with DOM either. Have done so in two moderate projects (40k, 15k). Everyone I meet looks at me like I'm crazy. But in the same breadth say the site feels so smooth and responsive. No shi…

Not a snarky comment, but have you had to share this code with other developers? If so, how did you find getting them up to speed without shared conventions?

Re: React is the new jQuery

#120
JQuery is a great tool, it got a lot of buzz and people started to abusively use it out of its nominal scope. This does not say anything about jquery, only about people. React is having a lot of buzz, and the same abuses happen in places where it is nowhere needed. Same cause, same symptoms.

You can replace jquery/react with any technology or concept, OO programming, functional programming, MVC, blockchain, machine learning, and every technology or concept having its momentum is or will be misused in some way at some point.

This happened, is happening, and will always happen.

Post reply on HN