JS people be like: "86K jQuery dependency is wasteful!"
Also JS people: "why do you care that an SPA loads 2M of JavaScript? Are you stuck on a 56k modem or something?"
You are also putting a heavy burden of proof on your readers: it generally sounds implausible that exactly the same people would complain about <100kiB being bloat and >1MiB not for the same use-case, but I am not going to go and fact-check that (with the implausibility of the claim, I would expect you to give direct pointers yourself or will simply distrust your claim).
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.
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.
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.
All I know is that you can build a custom jQuery build with grunt, as described in their README, which is what I do. I mostly use JavaScript as if the last ten years didn't happen, so I'm hardly an expert on any of this :-)
In those cases, I'd argue pReact is superior. It's almost 10x smaller (29kb vs 3.5kb gzipped). It's faster and more structured leading to less maintenance cost and more code reuse. If you use hyperscript, there's also no JSX compilation required.
It gets around a half-million downloads per week according to NPM stats while hyperapp gets under 3k per week.
But looking at the repo https://github.com/hyperhype/hyperscript I have a hard time imagining how preact can work together. They seem to overlap in functionality.
https://preactjs.com/guide/v10/tutorial/
or you can use the full hyperscript markup library
Yes, absolutely. That's a total no-brainer.
> Hidden complexity you don't control is the most expensive kind I think.
There's oodles of hidden complexity you don't control in any modern CPU, but most developers (rightly!) don't care. Complexity you have to fix bugs in is the expensive type, but IME you're far more likely to hit bugs in your custom implementation of whatever it was than in jQuery.
I'm curious - would you be able to elaborate, please? Thank you.
Run into a couple of examples of such complexity, and the dependency is well worthwhile.
A jQuery that can be tree-shaken would be awesome, as there are parts I use regularly and others I have never used. Ironically the -lite bundle leaves outs parts I use frequently...
> Yes, absolutely. That's a total no-brainer.
That's what we've been thought but it's not a no brainer at all. Context matters, but you disregard it and only focus on the lines of code, just as the author of the comment you respond to is saying people do.
You're building a marketing page that's not gonna be updated after completed and only gonna be valid for X days? Sure, the code doesn't matter.
You're trying to build a fast and slim UI that's gonna be deployed on routers and possibly loaded on low-power devices? You better care about every single line that gets loaded on the device.
I'm not saying dependencies are always wrong. I'm also not saying it's always right. I'm saying why you need the dependency and the quality of the code it includes is important to consider, and knee-jerk reactions of "of course I'd use it" is hurting the profession more than the library reuse saves us currently.
Unless you've gone out of your way to buy a (more expensive) part with less memory, your router will have enough memory to make 86.1Kb an utter irrelevancy; so will most of what were traditionally considered "low-power devices". Yes there are extreme cases where it matters, but we're talking about a vanishingly rare proportion of use cases.
> I'm not saying dependencies are always wrong. I'm also not saying it's always right. I'm saying why you need the dependency and the quality of the code it includes is important to consider, and knee-jerk reactions of "of course I'd use it" is hurting the profession more than the library reuse saves us currently.
I think this is backwards, and the knee-jerk reaction of "of course it's important and you need to carefully think about it" is what's holding back the industry. The overwhelming majority of the time, the right thing is to use the dependency; the best development practice is to default to using dependencies and reassess if and when it you hit an actual problem.
That's called encapsulation. :)
Seriously, encapsulating complexity is the foundation of most programming paradigms.
https://en.wikipedia.org/wiki/Encapsulation_(computer_progra...
Encapsulation/abstraction should really be a tool of last resort. From experience, it doesn't actually help reduce complexity if overused, but just makes it hidden and more likely to surprise you when you're debugging.
Does jQuery (est. 2006) have more bugs in it than your code?
jQuery's not a very good example of this though. It's one of the most widely used, and hence most tested and least buggy pieces of software out there. Nowadays the web APIs are pretty solid, but back in the IE6/7/8 days the jQuery API was a lot less buggy than using the built in APIs directly.
To me this seems a comment that only stands for one-developer projects.
I don't actually use jQuery any more but obviously if you are using it, you are saving the 10-15 lines every time you use one of these methods, not 10-15 lines in your whole application. I have a hard time believing that the savings of code lines will not be close to the weight of the dependency in any medium sized company codebase.
Jquery is a thin wrapper over javascript, whereas React has a comparable size but is a significantly higher level abstraction.
There's projects like https://umbrellajs.com/ which are very similar to jquery's APIs for DOM manipulation and it's only 2.5kb gzipped.
IMO it's a nice balance between having a convenient API without bringing in the world.
If I could write 2-5x less code and it's easy to remember I would make that trade off every time.