
jQuery 3.0 Release Candidate - azazqadir
https://blog.jquery.com/2016/05/20/jquery-3-0-release-candidate-released/
======
arenaninja
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.

~~~
sotojuan
> 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.

~~~
criswell
Fetch support is awful. Rachel McAdams knew the future.

~~~
therealmarv
+1 for fetch. Use the good github fetch polyfill for old browsers
[https://github.com/github/fetch](https://github.com/github/fetch)

~~~
nilliams
I tried fetch, the polymorphic-fetch module that builds on this github one and
found it doesn't support .finally(), or work with the promise.finally polyfill
(yes I know it's not in the spec, but seriously).

Also sinon.js couldn't mock it, and dealing with error cases is inelegant (it
doesn't look like much extra code, but is hard to justify if you're just
writing a small component that hits one endpoint, in terms of weird new code
to explain to your teammates that is).

I have gone back to $.ajax for now, though I do mean to try out qwest [1] when
I get the chance. Seems to be both tiny and also have a sane promise-y API.

[1] [https://github.com/pyrsmk/qwest](https://github.com/pyrsmk/qwest)

~~~
therealmarv
Why you want stuff which is not in the spec? It's not in the spec it's not in
the polyfill :/ Why the fetch from Github is not good enough for you?

~~~
nilliams
Because needing to do something regardless of success or failure is incredibly
common (e.g. stop a progress bar, re-enable form inputs & buttons).

The (promises) spec is lacking w.r.t. this use-case, and most ajax libraries
(and a lot or promise libraries) recognise this by implementing a 'finally'
equivalent.

------
vonklaus
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
Is anyone using custom selectors? quick googling only returns 5+ years old
results

~~~
klean92
I use :visible. The notes say it can increase speed 17x in certain cases.

~~~
vonklaus
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_.

------
Olscore
jQuery sizes by version and compression:
[https://mathiasbynens.be/demo/jquery-
size](https://mathiasbynens.be/demo/jquery-size)

~~~
rtpg
Wow compression ends up working really well for JQuery. Almost all the
post-2.0 code size increases get totally absorbed.

~~~
jmcomets
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
I think it's 250 Kb rather than Mb.

~~~
smegel
I did a double take at that as well.

Imagine trying to maintain 250mb of JavaScript spaghetti!

------
mkoryak
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

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

~~~
georgestephanis
jQuery also tends to handle a lot of assorted browser quirks, giving you a
consistent api to call.

~~~
unclebucknasty
Yeah, initially they was one of its biggest selling points.

~~~
snaky
And now it isn't?

~~~
unclebucknasty
Read the ancestor comments.

------
paradite
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
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
you can use whatwg-fetch instead of jquery ajax

~~~
GroSacASacs
native fetch is not available in IE<11

~~~
djKianoosh
whatwg-fetch polyfill works well

------
EugeneOZ
Good reason to make jquery.com design mobile friendly.

------
GroSacASacs
If you look for simplicity have a look at DOM99

[https://github.com/GrosSacASac/DOM99](https://github.com/GrosSacASac/DOM99)

------
combatentropy
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
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+.

------
livingston
it's jQuery not JQuery

~~~
xentronium
I think HN auto-capitalizes the title.

