
jQuery 3.0 Released - stop1234
https://jquery.com/download/
======
MichalBures
Here's the actual release blog post
[https://blog.jquery.com/2016/06/09/jquery-3-0-final-
released...](https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/)

------
jerf
I would suggest the release notes are a better link target:
[http://blog.jquery.com/2016/06/09/jquery-3-0-final-
released/](http://blog.jquery.com/2016/06/09/jquery-3-0-final-released/)

Developers can figure out how to download it if they are interested.

~~~
lucb1e
> "We set out to create a slimmer, faster version of jQuery (with backwards
> compatibility in mind)."

Wait, isn't the whole point of a major version bump that it breaks backwards
compatibility?

Later on it says there are a few breaking changes, but not many apparently.
Which in general is a good thing, but focusing on keeping compatibility
through a major version bump seems silly.

~~~
bradly
Backwards compatibility is still quite important in major version releases.
Just look at Angular 1 to 2, Rails 2.3 to 3, and Python 2 to 3 to see examples
of this.

~~~
dceddia
I'd say (and probably this is what you meant) that those are examples of what
happens when backwards compatibility is broken - the community gets
fragmented, finding answers on StackOverflow gets more difficult, lots of
helpful blogs/articles/videos are now useless, etc.

------
rcarmo
Whenever a new version of jQuery (or Zepto) comes along, I wonder what would
have happened if web development borrowed a page from other ecosystems and
browser runtimes had subsumed the jQuery API, shipping it natively.

It's a controversial notion, I'll grant, but what if the DOM APIs had been
replaced by "native" jQuery support? Would we have been better off? Worse?

Considering the intricacies of standards bodies and industry lobbies,
pondering the pros and cons makes for a fascinating exercise.

~~~
nailer
Well it's 2016 and we still don't have nodeList.forEach() so it can't be much
worse.

~~~
jacobr
Actually, we do, since Chromium 51. See
[https://dev.opera.com/blog/opera-38/](https://dev.opera.com/blog/opera-38/)

~~~
nailer
Yeah you're right. Just updated stable Chrome and:

    
    
      NodeList.prototype.forEach
      forEach() { [native code] }
    

Thank. God. Finally.

Edit:

    
    
      HTMLCollection.prototype.forEach
    

(which is what you'll get from other vanilla JS methods) is still missing.

------
sebslomski
Apparently there is no migration guide to migrate from React to jQuery :(

~~~
turowicz
I laughed :)

~~~
turowicz
you can still use redux with jquery!

------
awestroke
Is anybody in the HN crowd still using jQuery for new projects?

If yes, why not use "vanilla" js?

~~~
porker
Yup.

> If yes, why not use "vanilla" js?

I can't answer that, but I can answer "Why not use $Framework?"

My current project (a large admin system) is crying out for the more complex
parts of the admin UI to be built in React, Angular etc. The problem is it's
an all-or-nothing situation.

When picking up a new technology I want to add a little bit to the current
project, a bit more to the next, and so on. Progressive Enhancement for the
developer. jQuery lets me do that; the frameworks don't.

I have used KnockoutJS in 2 locations in this project; both for a single
component on a page which needed to be very dynamic. I have been impressed
that it doesn't try and take over, and lets me think of enhancing the
experience (and my skills) one component at a time.

~~~
wmonk
Why is it all or nothing?

We've been replacing certain parts of our vanilla js application with small
React apps and it's worked brilliantly. There is a really good talk by Ryan
Florence where he replaces backbone components (i think) with React
components.

~~~
porker
> Why is it all or nothing?

Erm, because that's the impression I've got from the tutorials and demos. I
guess a "Add $Framework to a bit of your app" isnt' sexy: the ones I've seen
add their own routing and focus on SPAs. Rather than "Here's some incredibly
complicated information to display, and we need to be fairly interactive over
it (and how other data on the page affects it)".

Would it work if you didn't have a vanilla JS application but a traditional
web app?

~~~
kej
You're right that most tutorials dive in with both feet, but this is literally
the very first text on
[https://facebook.github.io/react/](https://facebook.github.io/react/)

>Lots of people use React as the V in MVC. Since React makes no assumptions
about the rest of your technology stack, it's easy to try it out on a small
feature in an existing project.

------
forgotpwtomain
I've complained a few times about what seems to me, to be a less-friendly way
of handling Promise rejections in es6.

Consider the relatively common use-case - there is a service object which
proxies requests, format's the call to the backend (or fetches from cache) and
format's the returned response for the caller of the object. So the pattern
looks something like: ServiceObject.fetchData(query).then((data) => { / *
display data * / }, (err)=> { / * catch error - display no results * /})

At some-point you want to chain the promise to update another part of the ui:
promise.then((data) => { /* display something else _/ }, (err) => { /_ catch
error - display failed to load */ }).

The problem is you can't squash the error in the 'reject' of the previous
promise now, because otherwise the error isn't propagated to the last promise
in the link and instead you will hit the 'success' function. This 'reject'
behavior is alright if there is something your 'success' function can do when
the original request failed, but in a great majority of cases if the request
failed there is nothing you can do - you put a 'reject' in the first chain of
the promise resolution (potentially in the serviceObject itself) with some
generic flash-message like 'request failed please try again' and call it good.
As it stands you end up with a call chain where what a function higher up in
the chain should return should be based on what a resolving function further
down the chain is doing -- not having to do this was for me was almost
entirely the plus-side of the promise-style over callbacks-style concurrency
model.

I bring this up now because curiously the jQuery model of Deferred() precisely
did not do this before -(see section#2 of Major Changes):

> Example: returns from rejection callbacks

if an error wasn't re-thrown in a catch, the promise-handling would stay in
the 'reject' chain as long as an error had been thrown. I am quite curious as
to why the current-model won, I understand some of the potential benefits but
in practice I find that this behavior is worse in 90% of use-cases that I have
encountered. If someone has a link to a mailing-thread / issue where this was
discussed I would be quite interested.

~~~
nubs
The way I handle situations like this is to only put the catches where I need
them to serve some purpose. Generally, I don't catch errors at the start of
the chain because I can't know what to do with them at that point. If I do
catch them, it's only for logging or similar purposes and I still let the
error propagate further.

One pattern I use is to rethrow the error:

return service.fetchData().then((data) => {}).catch((err) =>
{console.log(err); throw err;});

Another pattern I use is to split the promise chain so that I let my main
results flow be the result that gets passed on, but I can do other things in a
parallel manner internally:

let results = service.fetchData().then((data) => {}); results.catch((err) =>
{console.log(err);}); return results;

~~~
forgotpwtomain
> return service.fetchData().then((data) => {}).catch((err) =>
> {console.log(err); throw err;});

Yes - but this kind of code requires that you know that something else chains
the promise and handles 'err' \- which is my entire complaint, a higher level
function shouldn't need to know whether it has children or if they do error
handling. Otherwise it's back to the same kind of callback style where you
have to go into another file and modify a top-level function to accommodate
adding a child.

Edit:

I would rather you and the other commentators here re-read my parent post, as
well as the relevant resources[0][1][2] - I seriously think I'm repeating the
same thing for the 4th time here, _no_ \- I don't need an explanation of how
promises work; I only was pointing out that the previous (2.0) dferred.promise
model actually fits most better in most of use cases that I've experienced
than the es6 one and I found that quite curious; but it seems impossible to
have that discussion without being on the same page first.

[0] [https://blog.jquery.com/2016/06/09/jquery-3-0-final-
released...](https://blog.jquery.com/2016/06/09/jquery-3-0-final-released/)

[1]
[https://api.jquery.com/deferred.promise/](https://api.jquery.com/deferred.promise/)

[2]
[https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise)

~~~
nubs
It doesn't need to care whether someone else is handling it. It should just do
what it needs to do according to its contract. The caller that receives the
promise as a result has its own contract that may or may not involve handling
the error as well (and so on up the chain).

You generally have to have an end-of-the-chain catch as a safety precaution.
If you don't have one and the promise fails you may get no feedback that an
error happened at all. All methods that return promises should be able to
expect the caller to handle them appropriately whether they pass or fail -
it's not their responsibility to try and figure out how to handle an error in
the context of the wider application.

~~~
WorldMaker
«You generally have to have an end-of-the-chain catch as a safety precaution.
If you don't have one and the promise fails you may get no feedback that an
error happened at all.»

This will be increasingly less of a need as browser native promises catch up
(and more reason to make sure that the promise library you are using is built
on top of native promises rather than rolled from scratch). Several browser
dev consoles will already show unhandled promise rejections today, and there's
a growing convergence to also providing browser/system-wide event handlers for
unhandled rejections as well.

[http://www.2ality.com/2016/04/unhandled-
rejections.html](http://www.2ality.com/2016/04/unhandled-rejections.html)

------
emirb
[http://youmightnotneedjquery.com/](http://youmightnotneedjquery.com/)

~~~
andybak
That page does an excellent job of convincing me to carry on using jQuery.

    
    
      if (el.classList)
        el.classList.contains(className);
      else
        new RegExp('(^| )' + className + '( |$)', 'gi').test(el.className);
    

vs

    
    
      $(el).hasClass(className);
    

<shivers>

~~~
oneeyedpigeon
I don't think anyone would suggest you write all of the first codeblock every
time you want to check a class. You'd put it in a function and call that, much
like jquery does.

The point is that this site explains how you do it because a) that's probably
easier than trawling through the jquery source b) including this polyfill when
you know you need it might save you from requiring all the rest of jquery.

~~~
andybak
In that case I'd be much more likely to use a minimal jQuery replacement such
as umbrella.js mentioned elsewhere here. That's 3k (vs about 28k for jQuery)
so counters most of the 'bloat' objections with jQuery. I'm sure it will still
irk some some purists on other grounds however.

------
yedpodtrzitko
from changelog: "Golf away 21 byte"

I like how (code)golf has become a term.

------
formula1
Theres a few things that I want from the next x.0 release. Until these get
done, jQuery will look like a library that doesnt know what it wants to be but
used to serve a purpose.

\- removal of animation from core

\- removal of styling from core

\- Create a jQuery 'fx' library seperate from jQuery

\- have a standardized serialized / deserialize for forms

\- Ability to handle multipart forms in ajax post requests

