This statement is everything that is wrong with the Javascript craze. It's not even 2015, it's 2016 and the argument for not using jQuery is that it's not trendy.
Since when are we so obsessed with looking trendy and keeping up with fashion? I still see people using php + jQuery to build apps that otherwise would've taken twice the time and twice the amount of bugs that take twice the number of developers.
Tech stack should be chosen based on merit that can only be built through the test of time. This is why I'm against using Node.js to write CRUD apps and why I'm against writing everything from scratch because it's the 'right' way. Guess what, 'right' or 'wrong' wont matter if the tech stack you chose slows you down or hurts other important requirements.
Why novelty is rewarded over reliability in SV, I'd never fucking get.
The biggest selling point for jQuery was unifying the mess of browser APIs under one, consistent API. Back in 2006 browser support for ecmascript was so haphazard that writing vanilla JS was an absolute ache. Or so I hear.
As years progress, browsers become steadily more conformant. In tandem, jQuery's value drops.
Meanwhile, cost (speed, size) remains constant.
This argument can be made without considering fashion; even if nobody had ever written a single library after John Resig did, jQuery in 2015 could still be considered an strange choice just for that.
http://stackoverflow.com/questions/11503534/jquery-vs-docume...
It adds a lot of complexity, because you end up relying on file load order and you typically don't know where stuff comes from. This is why most people have gone on to use module bundlers, because they want their code to declare its own dependency graph, instead of being implicit.
If I see "$.foobar" being used, how do I know where the "foobar plugin" got added to jQuery? If it's imported at the top of the file, it's very easy to look at the file that's being referenced.
This also complicates testing a lot: Instead of loading a test file that imports a library, you have to pull in the library with all of its implicit dependencies and then load the test file.
It's not about novelty, it's about writing code that's easily testable and extensible.
The problem is not in being trendy. The problem is working on a pretty low abstraction level when higher levels, streamlining the code while giving more performance, are available for years.
It's like asking why an app in 2007 would be written in plain JavaScript when e.g. jQuery is available.
Re 'no right or wrong': it does matter if you have to maintain the codebase for a long time. I've seen some legacy codebases, and I can appreciate some of the right choices done by their authors many years ago, as well as pity some of the poor choices made many years ago. Both significantly affect how easy it is to fix bugs and add features to many-yeas-old (or sometimes decades-old) code.
If jQuery is low level, what is high level? SproutCore? Cappuccino? Angular 1? These high-level frameworks have a bright future ahead.
Any data to back that? In most tests I've seen React, Angular and the like are slower than just using jQuery
I would love if more and more awesome JS libraries like FLOT (Canvas based chart library) would remove all JQuery dependencies and use just native DOM.
(raison d'être = most important reason or purpose for someone or something's existence; too big = 120KB of dead weight is huge, minified 1+MB JS file is bad for mobile users)
1. It's difficult to think it's too big. jQuery 1.x, compressed and minified, is somewhere around 35kB. jQuery 2.x is smaller. This is a relatively small proportion of a web page. It's smaller than frameworks like Ember or Angular.
2. Some of the useful ideas have been integrated (querySelector/querySelectorAll is a popular one) but that's not really the full story. jQuery is still good at abstracting over some of the differences in implementation, and the API is better (for example, doing an AJAX request in jQuery is much nicer than in vanilla JS)
3. 'IE6-8 and Android 1-2' aren't dead. True – if I were building a modern consumer-focused app or site, it might be possible to make the business decision that it wasn't worth supporting them. But you also have to remember that penetration is higher in some industries and countries, and if you need to remain accessible to these then you need to take that into account.
I don't doubt that we will start to see fewer libraries depending on jQuery as support for older UAs is phased out. But you're overstating the current case for it.
As for my bragging rights I wrote a dynamic maps implementation in ECMA-script back in 2005.
Today I'm a happy JavaEE user for anything backend (although I accept that Javascript in one form or another is the only thing that runs in the browser for now)
Have you seen MS, Apple and Google announce new products lately? It's more fashion show than anything else.
But, I'm with you, it's ridiculous.
This uses jquery, and isn't really slow. Why is it the wrong thing for this project?
/s
It's the same reason you use Python or C# for their higher-level abstractions instead of plain C.
>There has been a big push to move to native Dom rather than jquery, in pretty Much every way. The default wrapper is still jquery, but the internals are 99% dom only. The speed gained from that move are substantial.
He/she could choose a library/framework (say react or angular) but then you'll exclude people not using these libraries.
jQuery is the common denominator which would allow the broadest support.
EDIT: of course eliminating jQuery entirely would be even better
After reading through it fully, I found that if I wanted real IE 8/9 support then jQuery was the only answer for complex dom interactions because all the other systems not built on jQuery have either dropped IE8 support (like React), or are for business domains where IE8 support isn't an issue.
Anyways; there's no reason you can't use jQuery + React.
But feel free to implement your own virtualized table if you really don't want "abstraction on top of abstraction on top of abstraction"
The author has, of course, done a great job, for we see a working app; this trumps almost any objections. Kudos to the author.
But if you developed a spreadsheet of a similar functionality, would you choose plain jQuery and writing state machines by hand? Or would you be forced to use jQuery because you'd have to use key components based on it?