4 ms·

> Is it just me, or using jQuery for a complex web app in 2015 looks like, mmm, a bit strange choice? This statement is everything that is wrong with the Javas

> Is it just me, or using jQuery for a complex web app in 2015 looks like, mmm, a bit strange choice? 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.

nothrabannosir 11y ago
I'm there with you, except that jQuery in 2015(/2016) is not just about fashion; it's about technical merit. 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.
- FooBarWidget 11y ago
  jQuery is still a whole lot easier to use than native DOM APIs.
  - tlrobinson 11y ago
    jQuery is a thin wrapper on the DOM APIs. React and similar tools are entirely different (better, IMHO) abstractions.
    - PSeitz 11y ago
      That problem is that it is not a thin wrapper. You can see that in various performance comparisons that jquery is much slower. http://stackoverflow.com/questions/11503534/jquery-vs-document-queryselectorall/21539115#21539115 http://stackoverflow.com/questions/11503534/jquery-vs-docume...
- spinlock 11y ago
  You should tell Gordon Moore that speed and size have become constant. He'll shit himself.
- Too 11y ago
  Agree, there are technical merits, jquery is not designed to separate model and controller code from the view. It can obviously be done but most jquery code i've seen are injected smack middle inside the business logic, selecting a few elements from the DOM based on their css-classes(?!) and then modifies them in place. I wrote shit like this myself a few years ago but the more i think about it today the more absurd it sounds. It simply doesn't invite you to write good code and almost requires another framework on top for you to do so. It's a much more low level tool than other frameworks, and might therefor be the perfect job for something as complicated as a spreadsheet.
nine_k 11y ago
The latest commits to jQuery.sheet were done in 2015, thus the date. 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.
- alextgordon 11y ago
  It's interesting to hear jQuery being criticised for being at to low an abstraction level. I thought the hip thing to do was to revisit the stone age: http://youmightnotneedjquery.com http://youmightnotneedjquery.com If jQuery is low level, what is high level? SproutCore? Cappuccino? Angular 1? These high-level frameworks have a bright future ahead.
- tim333 11y ago
  >higher levels, ... giving more performance, are available for years. Any data to back that? In most tests I've seen React, Angular and the like are slower than just using jQuery
JustSomeNobody 11y ago
> Since when are we so obsessed with looking trendy and keeping up with fashion? 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.
TheAceOfHearts 11y ago
jQuery is a poor choice for building larger modern web apps because it has a large legacy of plugins that rely on globals and script tags. This becomes problematic as an application continues to grow. 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.
creullin 11y ago
Oh man I so agree with you. Just finished a mini app build with React. I don't understand the popularity.
frik 11y ago
JQuery is too big and its raison d'être is no more. All useful ideas have been integrated in JS5 and HTML5. Plus IE6-8 and Android 1-2 are dead. 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)
- matthewmacleod 11y ago
  I can't agree with any of this. 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.
eitland 11y ago
Yes, being plain jQuery is a major plus in my book until the cool javascript frameworks manages to switch to Maven (haha :) or otherwise sort out their build and dependency mess. 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)

nothrabannosir 11y ago

I'm there with you, except that jQuery in 2015(/2016) is not just about fashion; it's about technical merit. 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.

FooBarWidget 11y ago
jQuery is still a whole lot easier to use than native DOM APIs.
- tlrobinson 11y ago
  jQuery is a thin wrapper on the DOM APIs. React and similar tools are entirely different (better, IMHO) abstractions.
  - PSeitz 11y ago
    That problem is that it is not a thin wrapper. You can see that in various performance comparisons that jquery is much slower. http://stackoverflow.com/questions/11503534/jquery-vs-document-queryselectorall/21539115#21539115 http://stackoverflow.com/questions/11503534/jquery-vs-docume...
spinlock 11y ago
You should tell Gordon Moore that speed and size have become constant. He'll shit himself.
Too 11y ago
Agree, there are technical merits, jquery is not designed to separate model and controller code from the view. It can obviously be done but most jquery code i've seen are injected smack middle inside the business logic, selecting a few elements from the DOM based on their css-classes(?!) and then modifies them in place. I wrote shit like this myself a few years ago but the more i think about it today the more absurd it sounds. It simply doesn't invite you to write good code and almost requires another framework on top for you to do so. It's a much more low level tool than other frameworks, and might therefor be the perfect job for something as complicated as a spreadsheet.

nine_k 11y ago

The latest commits to jQuery.sheet were done in 2015, thus the date. 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.

alextgordon 11y ago
It's interesting to hear jQuery being criticised for being at to low an abstraction level. I thought the hip thing to do was to revisit the stone age: http://youmightnotneedjquery.com http://youmightnotneedjquery.com If jQuery is low level, what is high level? SproutCore? Cappuccino? Angular 1? These high-level frameworks have a bright future ahead.
tim333 11y ago
>higher levels, ... giving more performance, are available for years. Any data to back that? In most tests I've seen React, Angular and the like are slower than just using jQuery

JustSomeNobody 11y ago

> Since when are we so obsessed with looking trendy and keeping up with fashion? 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.

TheAceOfHearts 11y ago

jQuery is a poor choice for building larger modern web apps because it has a large legacy of plugins that rely on globals and script tags. This becomes problematic as an application continues to grow. 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.

creullin 11y ago

Oh man I so agree with you. Just finished a mini app build with React. I don't understand the popularity.

frik 11y ago

JQuery is too big and its raison d'être is no more. All useful ideas have been integrated in JS5 and HTML5. Plus IE6-8 and Android 1-2 are dead. 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)

matthewmacleod 11y ago
I can't agree with any of this. 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.

eitland 11y ago

Yes, being plain jQuery is a major plus in my book until the cool javascript frameworks manages to switch to Maven (haha :) or otherwise sort out their build and dependency mess. 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)