8 ms·

jQuery 3.0 Release Candidate

238 points by azazqadir 10y ago

vonklaus 10y ago
Major Changes: .load, .unload, and .error, deprecated since jQuery 1.8, are no more. Use .on() to register listeners. jQuery.Deferred is now Promises/A+ compatible Error cases don’t silently fail Animations now use requestAnimationFrame Massive speedups for some jQuery custom selectors
- yread 10y ago
  Is anyone using custom selectors? quick googling only returns 5+ years old results
  - balac 10y ago
    I use :input (https://api.jquery.com/input-selector/ https://api.jquery.com/input-selector/) occasionally
  - klean92 10y ago
    I use :visible. The notes say it can increase speed 17x in certain cases.
    - vonklaus 10y ago
      The notes say it is computationally expensive and bad for performance. Using this selector heavily can have performance implications, as it may force the browser to re-render the page before it can determine visibility. Tracking the visibility of elements via other methods, using a class for example, can provide better performance. To be clear, it is 17x faster than it was.
  - ashmud 10y ago
    I did at one point in time for flagging links to show a "leaving site" prompt. Now the JS simply checks any link when you click it (no more custom selector for flagging).
- arcatek 10y ago
  > jQuery.Deferred is now Promises/A+ compatible Finally. Our old codebase is using quite a lot of jQuery deferreds and, well, Promises/A+ clearly improved a lot of things API-wise.
  - crescentfresh 10y ago
    jQuery.Deferred was such a convoluted api for me. I polyfilled a Promises lib and felt bad having multiple libraries that on the cover said they did the same things.
Olscore 10y ago
jQuery sizes by version and compression: https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size
- tajen 10y ago
  This is the first time I can justify a move from a version 1.8.0 to 2.0 or 3.0 of a product with "it has fewer code".
- rtpg 10y ago
  Wow compression ends up working really well for JQuery. Almost all the post-2.0 code size increases get totally absorbed.
  - jmcomets 10y ago
    I'm not surprised, JavaScript is compression-friendly. Usually minification brings the file size down by about a x3 ratio, and gzipping does the same. What always impresses me with jQuery is the amount of features they're able to pack in 250 Mb of uncompressed code. They've got browser events, ajax and a crapload of selectors. Compatible with most browsers. Oh and performance is nice as well. Kudos to the jQuery developers!
    - tonyedgecombe 10y ago
      I think it's 250 Kb rather than Mb.
      - smegel 10y ago
        I did a double take at that as well. Imagine trying to maintain 250mb of JavaScript spaghetti!
        deleted 10y ago
        [deleted]
livingston 10y ago
it's jQuery not JQuery
- azazqadir 10y ago
  The j was auto-capitalized.
- xentronium 10y ago
  I think HN auto-capitalizes the title.
deleted 10y ago
[deleted]
EugeneOZ 10y ago
Good reason to make jquery.com design mobile friendly.
mozumder 10y ago
I'm finding I don't need jQuery anymore. What are the reasons people still use it?
- mindcrime 10y ago
  I use it for a couple of (related) reasons. 1. A few other libraries still depend on jQuery in turn, so I find that I still usually have it available in every app I work on anyway, so I might as well use it. 2. It "just works" and I already know it, and since it's already there, anyway (see (1) above) it just makes sense to use it. IOW, I don't feel enough pain from using jQuery to justify going off and learning what combination of new ecmascript (es6? es7? es9037253223252??? ???) features and/or libraries du jour that I would need to do everything jQuery does for me now. That said, I mostly just use it for the selectors - which I understand can be easily replaced with native features now - and the ajax method. So in reality, yeah, I probably could ditch jQuery without too much pain, excepting for (1) above, but... why bother? I don't care too much about the size, since I don't typically link in tons of javascript libraries, ad networks, etc. to kill page load times, and page bloat seems to be the biggest argument I hear against using jQuery.
  - mozumder 10y ago
    And, why should a new developer on fresh projects use it? It seems ES6 and latest CSS specs should cover everything JQuery used to be used for. Plus, wouldn't actually using Vanilla JS be faster? Right now it looks like people use JQuery for legacy code. But, they give no reason to use it for new projects, except if they need it for other libraries they're going to use. (based on legacy code anyways...) JQuery looks redundant in the modern Javascript era on evergreen browsers.
    - jackmoore 10y ago
      jQuery is still much more pleasant to use than native methods when working with collections of DOM elements. If you do much DOM manipulation, you'll end up writing helpers that replicate aspects of jQuery to grease your workflow. The real issue is that trying to manage state by directly manipulating the DOM becomes a nightmare as the project grows, and newer frameworks can mostly take care of that for you. So jQuery is still wonderful at what it does, but there isn't much reason to be directly manipulating the DOM now that there are alternatives.
paradite 10y ago
Since I used d3.js for one project a few years ago, I have not touched jQuery ever since. d3 offers key jQuery features, but goes much more beyond that.
- tangue 10y ago
  I've often head this and it would probably be in my next-side project. Do you have an AJAX API bundled with D3 or are you using some custom functions ?
  - djKianoosh 10y ago
    you can use whatwg-fetch instead of jquery ajax
    - GroSacASacs 10y ago
      native fetch is not available in IE<11
      - djKianoosh 10y ago
        whatwg-fetch polyfill works well
  - paradite 10y ago
    d3.json, d3.csv, d3.xhr etc You can check the documentations here: https://github.com/d3/d3/wiki/Requests https://github.com/d3/d3/wiki/Requests Those methods are quite powerful.
- KurtMueller 10y ago
  What do you typically use it for?
  - paradite 10y ago
    It basically replaces jQuery, so there's that. And it's the default choice for any complex web data visualization project.
mkoryak 10y ago
This looks intersting: https://github.com/jquery/jquery/issues/2653 https://github.com/jquery/jquery/issues/2653 we use jquery in an angular code base and have long wanted a build without Ajax which is huge and that is useless in angular
arenaninja 10y ago
Exciting news for jQuery. Last night, I was working on a side project. For the front-end, I'm using React, React-Route, and I'm working on figuring out Fluxible. superagent to wrap XmlHttpRequest. browserify to compile what I serve to the front-end. I don't run a reverse-proxy with a node backend since the API is in PHP, I just served the minified JS files. Honestly, it's a huge pain. And every module I toss in there seems to limit compatibility with the next one. The barrier of entry to doing things right is HUGE. Also, if you disable JS the site would be useless, 100%. If I were to go with angular it would be even worse. I honestly may go back to jQuery on this project yet. I don't expect it to be huge, and since most Foundation plugins use jQuery anyway it should work. I honestly loathe how much crap I'm loading for two pages: sign-up / register.
- therealmarv 10y ago
  If you know the site is small why do you do the pain and go react, router and fluxible etc. etc. ? The investment in this (huge) toolchain will be beneficial when you start making things more complicated... then you may hit a wall with normal jQuery/JS. But not every project needs a big React based toolchain. This is definitely a JS platform problem. I'm currently looking at Elm because it makes life easier in comparison... but there you have other gaps like not good jQuery plugin interaction.
- cityzen 10y ago
  "doing things right"... by whose standards? It blows my mind how convoluted everything has become due to "doing things right" and "best practices". It's a side project, keep it in perspective. The faster it gets done, the sooner you can refactor IF you need to refactor.
- sotojuan 10y ago
  > I honestly loathe how much crap I'm loading for two pages: sign-up / register. Sorry, but this is entirely your fault. You don't need any of what you mentioned to do this. You can just use jQuery if that works for you. No one except really bad junior devs on here or Reddit will say you are doing things "wrong". PS: Use fetch instead of superagent.
combatentropy 10y ago
Since the oldest supported version of IE is now 11: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ "jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application. "If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with."
- roryokane 10y ago
  According to the upgrade guide (https://jquery.com/upgrade-guide/3.0/#browser-support https://jquery.com/upgrade-guide/3.0/#browser-support), jQuery 3 still supports IE 9+, not 11+.
GroSacASacs 10y ago
If you look for simplicity have a look at DOM99 https://github.com/GrosSacASac/DOM99 https://github.com/GrosSacASac/DOM99

238 points by azazqadir 10y ago

Major Changes: .load, .unload, and .error, deprecated since jQuery 1.8, are no more. Use .on() to register listeners. jQuery.Deferred is now Promises/A+ compatible Error cases don’t silently fail Animations now use requestAnimationFrame Massive speedups for some jQuery custom selectors

yread 10y ago
Is anyone using custom selectors? quick googling only returns 5+ years old results
- balac 10y ago
  I use :input (https://api.jquery.com/input-selector/ https://api.jquery.com/input-selector/) occasionally
- klean92 10y ago
  I use :visible. The notes say it can increase speed 17x in certain cases.
  - vonklaus 10y ago
    The notes say it is computationally expensive and bad for performance. Using this selector heavily can have performance implications, as it may force the browser to re-render the page before it can determine visibility. Tracking the visibility of elements via other methods, using a class for example, can provide better performance. To be clear, it is 17x faster than it was.
- ashmud 10y ago
  I did at one point in time for flagging links to show a "leaving site" prompt. Now the JS simply checks any link when you click it (no more custom selector for flagging).
arcatek 10y ago
> jQuery.Deferred is now Promises/A+ compatible Finally. Our old codebase is using quite a lot of jQuery deferreds and, well, Promises/A+ clearly improved a lot of things API-wise.
- crescentfresh 10y ago
  jQuery.Deferred was such a convoluted api for me. I polyfilled a Promises lib and felt bad having multiple libraries that on the cover said they did the same things.

Olscore 10y ago

jQuery sizes by version and compression: https://mathiasbynens.be/demo/jquery-size https://mathiasbynens.be/demo/jquery-size

tajen 10y ago
This is the first time I can justify a move from a version 1.8.0 to 2.0 or 3.0 of a product with "it has fewer code".
rtpg 10y ago
Wow compression ends up working really well for JQuery. Almost all the post-2.0 code size increases get totally absorbed.
- jmcomets 10y ago
  I'm not surprised, JavaScript is compression-friendly. Usually minification brings the file size down by about a x3 ratio, and gzipping does the same. What always impresses me with jQuery is the amount of features they're able to pack in 250 Mb of uncompressed code. They've got browser events, ajax and a crapload of selectors. Compatible with most browsers. Oh and performance is nice as well. Kudos to the jQuery developers!
  - tonyedgecombe 10y ago
    I think it's 250 Kb rather than Mb.
    - smegel 10y ago
      I did a double take at that as well. Imagine trying to maintain 250mb of JavaScript spaghetti!
      - deleted 10y ago
        [deleted]

livingston 10y ago

it's jQuery not JQuery

azazqadir 10y ago
The j was auto-capitalized.
xentronium 10y ago
I think HN auto-capitalizes the title.

deleted 10y ago

[deleted]

EugeneOZ 10y ago

Good reason to make jquery.com design mobile friendly.

mozumder 10y ago

I'm finding I don't need jQuery anymore. What are the reasons people still use it?

mindcrime 10y ago
I use it for a couple of (related) reasons. 1. A few other libraries still depend on jQuery in turn, so I find that I still usually have it available in every app I work on anyway, so I might as well use it. 2. It "just works" and I already know it, and since it's already there, anyway (see (1) above) it just makes sense to use it. IOW, I don't feel enough pain from using jQuery to justify going off and learning what combination of new ecmascript (es6? es7? es9037253223252??? ???) features and/or libraries du jour that I would need to do everything jQuery does for me now. That said, I mostly just use it for the selectors - which I understand can be easily replaced with native features now - and the ajax method. So in reality, yeah, I probably could ditch jQuery without too much pain, excepting for (1) above, but... why bother? I don't care too much about the size, since I don't typically link in tons of javascript libraries, ad networks, etc. to kill page load times, and page bloat seems to be the biggest argument I hear against using jQuery.
- mozumder 10y ago
  And, why should a new developer on fresh projects use it? It seems ES6 and latest CSS specs should cover everything JQuery used to be used for. Plus, wouldn't actually using Vanilla JS be faster? Right now it looks like people use JQuery for legacy code. But, they give no reason to use it for new projects, except if they need it for other libraries they're going to use. (based on legacy code anyways...) JQuery looks redundant in the modern Javascript era on evergreen browsers.
  - jackmoore 10y ago
    jQuery is still much more pleasant to use than native methods when working with collections of DOM elements. If you do much DOM manipulation, you'll end up writing helpers that replicate aspects of jQuery to grease your workflow. The real issue is that trying to manage state by directly manipulating the DOM becomes a nightmare as the project grows, and newer frameworks can mostly take care of that for you. So jQuery is still wonderful at what it does, but there isn't much reason to be directly manipulating the DOM now that there are alternatives.

paradite 10y ago

Since I used d3.js for one project a few years ago, I have not touched jQuery ever since. d3 offers key jQuery features, but goes much more beyond that.

tangue 10y ago
I've often head this and it would probably be in my next-side project. Do you have an AJAX API bundled with D3 or are you using some custom functions ?
- djKianoosh 10y ago
  you can use whatwg-fetch instead of jquery ajax
  - GroSacASacs 10y ago
    native fetch is not available in IE<11
    - djKianoosh 10y ago
      whatwg-fetch polyfill works well
- paradite 10y ago
  d3.json, d3.csv, d3.xhr etc You can check the documentations here: https://github.com/d3/d3/wiki/Requests https://github.com/d3/d3/wiki/Requests Those methods are quite powerful.
KurtMueller 10y ago
What do you typically use it for?
- paradite 10y ago
  It basically replaces jQuery, so there's that. And it's the default choice for any complex web data visualization project.

mkoryak 10y ago

This looks intersting: https://github.com/jquery/jquery/issues/2653 https://github.com/jquery/jquery/issues/2653 we use jquery in an angular code base and have long wanted a build without Ajax which is huge and that is useless in angular

arenaninja 10y ago

Exciting news for jQuery. Last night, I was working on a side project. For the front-end, I'm using React, React-Route, and I'm working on figuring out Fluxible. superagent to wrap XmlHttpRequest. browserify to compile what I serve to the front-end. I don't run a reverse-proxy with a node backend since the API is in PHP, I just served the minified JS files. Honestly, it's a huge pain. And every module I toss in there seems to limit compatibility with the next one. The barrier of entry to doing things right is HUGE. Also, if you disable JS the site would be useless, 100%. If I were to go with angular it would be even worse. I honestly may go back to jQuery on this project yet. I don't expect it to be huge, and since most Foundation plugins use jQuery anyway it should work. I honestly loathe how much crap I'm loading for two pages: sign-up / register.

therealmarv 10y ago
If you know the site is small why do you do the pain and go react, router and fluxible etc. etc. ? The investment in this (huge) toolchain will be beneficial when you start making things more complicated... then you may hit a wall with normal jQuery/JS. But not every project needs a big React based toolchain. This is definitely a JS platform problem. I'm currently looking at Elm because it makes life easier in comparison... but there you have other gaps like not good jQuery plugin interaction.
cityzen 10y ago
"doing things right"... by whose standards? It blows my mind how convoluted everything has become due to "doing things right" and "best practices". It's a side project, keep it in perspective. The faster it gets done, the sooner you can refactor IF you need to refactor.
sotojuan 10y ago
> I honestly loathe how much crap I'm loading for two pages: sign-up / register. Sorry, but this is entirely your fault. You don't need any of what you mentioned to do this. You can just use jQuery if that works for you. No one except really bad junior devs on here or Reddit will say you are doing things "wrong". PS: Use fetch instead of superagent.

combatentropy 10y ago

Since the oldest supported version of IE is now 11: http://youmightnotneedjquery.com/ http://youmightnotneedjquery.com/ "jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application. "If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with."

roryokane 10y ago
According to the upgrade guide (https://jquery.com/upgrade-guide/3.0/#browser-support https://jquery.com/upgrade-guide/3.0/#browser-support), jQuery 3 still supports IE 9+, not 11+.

GroSacASacs 10y ago

If you look for simplicity have a look at DOM99 https://github.com/GrosSacASac/DOM99 https://github.com/GrosSacASac/DOM99