7 ms·

I'm impressed. I don't think the web would be where it is today without JQuery, and being able to completely pull it out is pretty awesome. Not because of JQ-ha

by jotato 8y ago

I'm impressed. I don't think the web would be where it is today without JQuery, and being able to completely pull it out is pretty awesome. Not because of JQ-hate, but web standards have improved that much.

RobertRoberts 8y ago
jQuery was awesome, and needs to be entered into some kind of web-tech historical hall of fame. But it's time has come to be replaced. I had used Prototype.js, and just a couple years ago finally gutted it from our code base. And shortly after started removing jQuery. It's a long slow process. After starting with Vue.js, I completely understand why jQuery is no longer needed. Vanilla JS/CSS3 does 98% of what jQuery did for us, and our own micro-library fills in the blanks. And Vue is replacing all the jQuery scaffolded apps. If it weren't for reactive interface libraries though, jQuery would still be a staple. One example, I use a jQuery library for sorting tables. When I saw how sorting a table is so basically easy in Vue.js, that no plugins or 3rd party code needed, I saw the downfall of jQuery in general.
- thermodynthrway 8y ago
  I don't even bother with vanilla JS. Babel and Typescript let you magically use the latest features without caring about compatibility at all really, except CSS
  - StavrosK 8y ago
    How big is the compiled output?
    - munchbunny 8y ago
      In my experience (compiling TS + babel down to ES5), the compiled output is generally fine. Unless you're trying to squeeze every last kb out of it, asset optimization and NPM dependency bloat are much bigger optimization opportunities anyway.
    - thermodynthrway 8y ago
      Haven't looked at Babel's, but the output from Typescript is human readable and not much bigger than the original. The more polyfills (lower your target lib aka ES3 vs ES2015) The bigger the output. Even targeting the oldest crappiest browsers doesn't add that much. Some maybe 50kb for polyfills injected and code bloat of 30% ish. Not much price to pay to use the latest features without caring about compatibility
  - marktangotango 8y ago
    People often promote this but there’s a huge gap between script tag to include jquerg.min (for example) and requiring the entire node/npm ecosystem to cross compile etc everything else (provided you weren’t already). This is a high tax to pay.
    - thermodynthrway 8y ago
      Typescript is super easy to bring into a project. Just rename .js to .ts and turn the validations off. Any valid JS is also valid TS. Build step is one command to run tsc. You can turn things on slowly as you refactor into idiomatic typescript. React is a PITA to setup and learn, as is Angular. They're the modern equivalent of Java EE. "Heavy" but if you have something complex to do and know your way around they make hard things easy. The learning curve is tough but so worth it
  - irrational 8y ago
    How are these ("vanilla JS" and "the latest features") different things? By vanilla JS, do you mean prior to 2015 JS?
    - thermodynthrway 8y ago
      Transpiled JS specifically. JS is the only popular language with a great deal of differences between versions and runtimes, mostly due to rapid improvements. If you use "vanilla" ES2017 without transpilation you're in for a deluge of bug reports. Instead of worrying about browser Y supporting feature X, I just ram everything through Babel or Typescript compilers and use all the newest features. We haven't had a single browser specific JS bug since we started using Typescript on ny project last year. And async is so damn nice. Babel's output is a bit obtuse sometimes, but Typescript was designed to output idiomatic JS, so even with no sourcemaps code is perfectly readable before minification
- meesterdude 8y ago
  I don't understand what you're talking about. Jquery is still a highly effective library and nearly every project I use ends up using it in one way or another - even with vue.js. Jquery is JUST jquery. There is no pulling in 300 other packages to support it. It's also very stable, reliable, efficient enjoyable. this is how you might sort a table using a Jquery library: $("#myTable").tablesorter() And here's how to do it in Vue (first search result for vue table sort): https://www.raymondcamden.com/2018/02/08/building-table-sorting-and-pagination-in-vuejs https://www.raymondcamden.com/2018/02/08/building-table-sort... You'll note that it is a lot more code to sort with Vue than with a jquery library. Don't get me wrong; I like Vue; But Jquery offers one line of code that enhances the existing HTML you have, where doing it with Vue.js requires delegating the entire table render to Vue, which may not be easy or even doable depending on the project. I think things like Vue.js or stimulus.js let Jquery do more with what it's good at and less of what it's not. I'm very happy to have Jquery in my toolbox and I doubt I'll ever stop using it at this point. You're welcome to hate on it, call it dated or what have you - i still love it and it's still the best tool for quite a lot of jobs.
  - ljm 8y ago
    Well, you’re delegating the entire rendering to jQuery and hiding all of the manual work in a dependency. The lines of code are still there, you just didn’t write them yourself. It’s not a fair comparison.
    - meesterdude 8y ago
      What? no you're not. You're augmenting existing, already rendered HTML with Jquery. have you never used Jquery before?
  - RobertRoberts 8y ago
    I just ran into this quote somewhere (I am rewording cause I can't find it) "It's like eye glasses, you'll know when you need them" - Some smart guy I needed something jQuery could not provide, easing my work load. Let's look at this from 2 different perspectives: 1. You're building an app, and work with multiple tables to render and work with. And you have integrated form elements with the table cells that affect other cells. You need to add/remove items using AJAX data calls to the server and sync the display with the server data. And you fully expect to be making more changes in the future. 2. You have a table on a website(s) as content you want sorted. I've used jQuery to do both, but with Vue.js I cut my code base down by 1/10th at least, and it works smoother and easier and way easier to extend and add new features. I have used jQuery exclusively for all my front end work, but I have an app that just kept needing more and more features. And every time I had to add a feature I went through so many hoops and patching stuff and dealing with edge case uses, and _hoping_ the jQuery plugins I was using had my back when I upgraded jQuery, or when I needed just a slight tweak on how a table was to be manipulated. With Vue.js, adding sorting to a table was literally 5-10 lines of code, that I have total control over. This is possible because I don't have to deal with the html directly. I was a die-hard jQuery man just last month, if you have the time, read my other comments, I defended it to death. And yes, it still likely has it's uses, but in my experience (full stack dev for almost 20 years) I can do everything jQuery can, and often times better, on my own now. jQuery can "simplify" some code, but that doesn't make the code easier to work with or extend, it just makes it "shorter", which isn't much value anymore to me. Regarding this example: https://www.raymondcamden.com/2018/02/08/building-table-sorting-and-pagination-in-vuejs https://www.raymondcamden.com/2018/02/08/building-table-sort... That's not extra work because I replaced my server side render of the table (which had a library for rendering tables) to doing it entirely on the front end. I just get to pass it data. (yay!) Also the jQuery plugin I use is hugely bloated, and I only need a fraction of the features. I have thousands of lines of code using jQuery still active in my code base. I just started with Vue.js last week, and I only tried it because I was so daunted by my tasks ahead to build a version 3 of an app. Within a couple of hours of development everything got easier. If you don't experience this when using Vue.js (or other reactive library), then jQuery is obviously perfect for you. -- Edit: This is the jQuery table sorting plugin I used, because I needed heavy duty features. https://github.com/Mottie/tablesorter https://github.com/Mottie/tablesorter In total, 240k MINIMIZED code plus css, images, etc... The file size alone is incredible. When I am done making a proper component with Vue.js to do the work I use this for, I bet it will be 10k or less easily, and that will include the html scaffolding and rendering to boot. For a blog post jQuery is just fine. For a fully supported long term app that produces income? Vue.js all the way, even for something as simple as sorting a table. -- Edit: Consider if you want to change from a table to divs with grid? Or list? You can't with jQuery because you only have a table sorting plugin. All it's classes and rendering are for tables. https://jsfiddle.net/rg50h7hx/788/ https://jsfiddle.net/rg50h7hx/788/ Look how little code it takes to sort the data in that example. This was just crazy to me when I first ran into this. Here's the actual example I ran into that opened my eyes to the simplicity of using data to render the html through Vue.js http://www.developerdrive.com/2017/07/creating-a-data-table-in-vue-js/ http://www.developerdrive.com/2017/07/creating-a-data-table-... 57 lines of js code for sorting, pagination AND data for the table!
munchbunny 8y ago
I think it's a testament to jQuery's influence that, even though many of us don't use it today, we still often think in a jQuery way. The most useful common bits of jQuery's approach got baked into standards. I think it's impressive that even when I'm not using jQuery (haven't in many years), I find myself writing code using features/capabilities where jQuery was an obvious inspiration.
- Macha 8y ago
  I mean, when you think about how many people were using jQuery for (a) cross-browser compatibility, which mostly works now (except for cutting edge stuff, which is pretty optional) (b) $.ajax (uses that could be replaced by window.fetch) (c) Sizzle (Replaced by document.querySelector[All])
  - floatboth 8y ago
    (d) the plugin system, which is replaced by Custom Elements (but unfortunately the React crowd is there with their own custom private component system)
  - Piskvorrr 8y ago
    Yeah. And IIRC, all of this came about as "let's take these awesome pieces of jQuery (which were written because browsers sucked) and reimplement them natively." Now the roles are apparently reversed, with jQuery being the Big Bad?
- mhink 8y ago
  Very much this. There are very few scenarios in which I’d recommend jQuery nowadays, but I still have mad respect for the project itself, for its legacy, and for the positive impact it’s had on front-end programming.
- kotapi 8y ago
  Yeah think of how many Javascript questions on Stackoverflow have jQuery answers

by jotato 8y ago

RobertRoberts 8y ago

jQuery was awesome, and needs to be entered into some kind of web-tech historical hall of fame. But it's time has come to be replaced. I had used Prototype.js, and just a couple years ago finally gutted it from our code base. And shortly after started removing jQuery. It's a long slow process. After starting with Vue.js, I completely understand why jQuery is no longer needed. Vanilla JS/CSS3 does 98% of what jQuery did for us, and our own micro-library fills in the blanks. And Vue is replacing all the jQuery scaffolded apps. If it weren't for reactive interface libraries though, jQuery would still be a staple. One example, I use a jQuery library for sorting tables. When I saw how sorting a table is so basically easy in Vue.js, that no plugins or 3rd party code needed, I saw the downfall of jQuery in general.

thermodynthrway 8y ago
I don't even bother with vanilla JS. Babel and Typescript let you magically use the latest features without caring about compatibility at all really, except CSS
- StavrosK 8y ago
  How big is the compiled output?
  - munchbunny 8y ago
    In my experience (compiling TS + babel down to ES5), the compiled output is generally fine. Unless you're trying to squeeze every last kb out of it, asset optimization and NPM dependency bloat are much bigger optimization opportunities anyway.
  - thermodynthrway 8y ago
    Haven't looked at Babel's, but the output from Typescript is human readable and not much bigger than the original. The more polyfills (lower your target lib aka ES3 vs ES2015) The bigger the output. Even targeting the oldest crappiest browsers doesn't add that much. Some maybe 50kb for polyfills injected and code bloat of 30% ish. Not much price to pay to use the latest features without caring about compatibility
- marktangotango 8y ago
  People often promote this but there’s a huge gap between script tag to include jquerg.min (for example) and requiring the entire node/npm ecosystem to cross compile etc everything else (provided you weren’t already). This is a high tax to pay.
  - thermodynthrway 8y ago
    Typescript is super easy to bring into a project. Just rename .js to .ts and turn the validations off. Any valid JS is also valid TS. Build step is one command to run tsc. You can turn things on slowly as you refactor into idiomatic typescript. React is a PITA to setup and learn, as is Angular. They're the modern equivalent of Java EE. "Heavy" but if you have something complex to do and know your way around they make hard things easy. The learning curve is tough but so worth it
- irrational 8y ago
  How are these ("vanilla JS" and "the latest features") different things? By vanilla JS, do you mean prior to 2015 JS?
  - thermodynthrway 8y ago
    Transpiled JS specifically. JS is the only popular language with a great deal of differences between versions and runtimes, mostly due to rapid improvements. If you use "vanilla" ES2017 without transpilation you're in for a deluge of bug reports. Instead of worrying about browser Y supporting feature X, I just ram everything through Babel or Typescript compilers and use all the newest features. We haven't had a single browser specific JS bug since we started using Typescript on ny project last year. And async is so damn nice. Babel's output is a bit obtuse sometimes, but Typescript was designed to output idiomatic JS, so even with no sourcemaps code is perfectly readable before minification
meesterdude 8y ago
I don't understand what you're talking about. Jquery is still a highly effective library and nearly every project I use ends up using it in one way or another - even with vue.js. Jquery is JUST jquery. There is no pulling in 300 other packages to support it. It's also very stable, reliable, efficient enjoyable. this is how you might sort a table using a Jquery library: $("#myTable").tablesorter() And here's how to do it in Vue (first search result for vue table sort): https://www.raymondcamden.com/2018/02/08/building-table-sorting-and-pagination-in-vuejs https://www.raymondcamden.com/2018/02/08/building-table-sort... You'll note that it is a lot more code to sort with Vue than with a jquery library. Don't get me wrong; I like Vue; But Jquery offers one line of code that enhances the existing HTML you have, where doing it with Vue.js requires delegating the entire table render to Vue, which may not be easy or even doable depending on the project. I think things like Vue.js or stimulus.js let Jquery do more with what it's good at and less of what it's not. I'm very happy to have Jquery in my toolbox and I doubt I'll ever stop using it at this point. You're welcome to hate on it, call it dated or what have you - i still love it and it's still the best tool for quite a lot of jobs.
- ljm 8y ago
  Well, you’re delegating the entire rendering to jQuery and hiding all of the manual work in a dependency. The lines of code are still there, you just didn’t write them yourself. It’s not a fair comparison.
  - meesterdude 8y ago
    What? no you're not. You're augmenting existing, already rendered HTML with Jquery. have you never used Jquery before?
- RobertRoberts 8y ago
  I just ran into this quote somewhere (I am rewording cause I can't find it) "It's like eye glasses, you'll know when you need them" - Some smart guy I needed something jQuery could not provide, easing my work load. Let's look at this from 2 different perspectives: 1. You're building an app, and work with multiple tables to render and work with. And you have integrated form elements with the table cells that affect other cells. You need to add/remove items using AJAX data calls to the server and sync the display with the server data. And you fully expect to be making more changes in the future. 2. You have a table on a website(s) as content you want sorted. I've used jQuery to do both, but with Vue.js I cut my code base down by 1/10th at least, and it works smoother and easier and way easier to extend and add new features. I have used jQuery exclusively for all my front end work, but I have an app that just kept needing more and more features. And every time I had to add a feature I went through so many hoops and patching stuff and dealing with edge case uses, and _hoping_ the jQuery plugins I was using had my back when I upgraded jQuery, or when I needed just a slight tweak on how a table was to be manipulated. With Vue.js, adding sorting to a table was literally 5-10 lines of code, that I have total control over. This is possible because I don't have to deal with the html directly. I was a die-hard jQuery man just last month, if you have the time, read my other comments, I defended it to death. And yes, it still likely has it's uses, but in my experience (full stack dev for almost 20 years) I can do everything jQuery can, and often times better, on my own now. jQuery can "simplify" some code, but that doesn't make the code easier to work with or extend, it just makes it "shorter", which isn't much value anymore to me. Regarding this example: https://www.raymondcamden.com/2018/02/08/building-table-sorting-and-pagination-in-vuejs https://www.raymondcamden.com/2018/02/08/building-table-sort... That's not extra work because I replaced my server side render of the table (which had a library for rendering tables) to doing it entirely on the front end. I just get to pass it data. (yay!) Also the jQuery plugin I use is hugely bloated, and I only need a fraction of the features. I have thousands of lines of code using jQuery still active in my code base. I just started with Vue.js last week, and I only tried it because I was so daunted by my tasks ahead to build a version 3 of an app. Within a couple of hours of development everything got easier. If you don't experience this when using Vue.js (or other reactive library), then jQuery is obviously perfect for you. -- Edit: This is the jQuery table sorting plugin I used, because I needed heavy duty features. https://github.com/Mottie/tablesorter https://github.com/Mottie/tablesorter In total, 240k MINIMIZED code plus css, images, etc... The file size alone is incredible. When I am done making a proper component with Vue.js to do the work I use this for, I bet it will be 10k or less easily, and that will include the html scaffolding and rendering to boot. For a blog post jQuery is just fine. For a fully supported long term app that produces income? Vue.js all the way, even for something as simple as sorting a table. -- Edit: Consider if you want to change from a table to divs with grid? Or list? You can't with jQuery because you only have a table sorting plugin. All it's classes and rendering are for tables. https://jsfiddle.net/rg50h7hx/788/ https://jsfiddle.net/rg50h7hx/788/ Look how little code it takes to sort the data in that example. This was just crazy to me when I first ran into this. Here's the actual example I ran into that opened my eyes to the simplicity of using data to render the html through Vue.js http://www.developerdrive.com/2017/07/creating-a-data-table-in-vue-js/ http://www.developerdrive.com/2017/07/creating-a-data-table-... 57 lines of js code for sorting, pagination AND data for the table!

munchbunny 8y ago

I think it's a testament to jQuery's influence that, even though many of us don't use it today, we still often think in a jQuery way. The most useful common bits of jQuery's approach got baked into standards. I think it's impressive that even when I'm not using jQuery (haven't in many years), I find myself writing code using features/capabilities where jQuery was an obvious inspiration.

Macha 8y ago
I mean, when you think about how many people were using jQuery for (a) cross-browser compatibility, which mostly works now (except for cutting edge stuff, which is pretty optional) (b) $.ajax (uses that could be replaced by window.fetch) (c) Sizzle (Replaced by document.querySelector[All])
- floatboth 8y ago
  (d) the plugin system, which is replaced by Custom Elements (but unfortunately the React crowd is there with their own custom private component system)
- Piskvorrr 8y ago
  Yeah. And IIRC, all of this came about as "let's take these awesome pieces of jQuery (which were written because browsers sucked) and reimplement them natively." Now the roles are apparently reversed, with jQuery being the Big Bad?
mhink 8y ago
Very much this. There are very few scenarios in which I’d recommend jQuery nowadays, but I still have mad respect for the project itself, for its legacy, and for the positive impact it’s had on front-end programming.
kotapi 8y ago
Yeah think of how many Javascript questions on Stackoverflow have jQuery answers