Hacker News new | ask | show | jobs
by tomtomtom777 1988 days ago
There is an additional cost to such a dependency that isn't expressed in bytes.

Javascript/CSS/HTML forms the common basis of web development. You may assume every reader of your code is familiar with it.

If you use a specific library, you are restricting (easy) readability to those that know the specific library.

This has merit if the library provides sufficiently useful abstractions or shortcuts, but it's only a drawback if the library provides merely an alternative way to write something already possible in the base layer.

1 comments

That's fair, but I also think that JQuery is often judged much more harshly than other libraries that have a significantly higher learning curve.

I know plenty of developers who would view inclusion of JQuery as some cardinal sin due to reasons like the ones you state, but don't apply the same logic to React, Redux, or other more modern, significantly more complex libraries.

I think a lot of that is the "problems they are solving" and "problems they left behind for the developer". JQuery was built to solve "browser compatibility issues" and left behind things like "component structures of code/code organization", "data-flow organization", and more as out of scope.

Browsers have since mostly fixed "browser compatibility issues" at the standards level, so that problem technically no longer needs solving.

As applications have grown larger those other things that were out of scope for JQuery have become bigger and bigger problems that developers face. (Of the big two I mentioned React solves one, Redux solves the other.)

Some people see JQuery as a "cardinal sin" for the first issue: browsers have already "solved" this, this is a deadweight because it fixes a problem I no longer have. They would have fewer problems with React/Redux/whatever because they solve new problems.

Some people see JQuery as a "cardinal sin" as much for the latter issue: because JQuery was so unopinionated on code structure, data flow, component structure, it led to a lot of real world code that was "JQuery spaghetti" littered with anti-practices like relying heavily on global or might as well be global variables for state information, with no structure to which code might impact which variables and when. Componentizing a JQuery system was often a lot of hard work that JQuery itself didn't help with (and given it's own common usage as a window.$ global with sometimes surprising bits of hidden state inside it, in some cases directly hurt those efforts). Given libraries like React or Redux were designed to solve some of the problems that JQuery once created, it also seems clear why some developers might be very vocally antagonistic to JQuery but have no problem bloating a project with tools that solved those problems and/or have more structure and opinions on building "good" componentized/compartmentalized structures.

Not a front-end developer, but could this simply be a generational issue? Every framework invented before my career is a clumsy dinosaur, every framework invented during my career is the silver bullet that will solve all problems...