91–100 of 164 posts
I would suggest the release notes are a better link target: http://blog.jquery.com/2016/06/09/jquery-3-0-final-released/ Developers can figure out how to download it if they are interested.
Is anybody in the HN crowd still using jQuery for new projects? If yes, why not use "vanilla" js?
Is anybody in the HN crowd still using jQuery for new projects? If yes, why not use "vanilla" js?
I started using "vanilla" js, then created a method as a name for the huge `[].prototype.slice.call(document.querySelectorAll(selector))` Then as I continued adding useful methods such as ajax() (no, in vanilla js it's not "solved") and turning events off (also non-trivial) I ended up with a jquery alternative: > http://umbrellajs.com/ It's not exactly the same, but most methods are the same or highly compatible. For…
Right - I use jQuery because I've greater confidence that `.ajax()` will behave correctly across a wide range of browser versions, though I don't have any good evidence about using that vs vanilla `XMLHttpRequest` these days. I'd be interested to know which bits of "not solved" - which aspects in particular are not yet well supported?
Is anybody in the HN crowd still using jQuery for new projects? If yes, why not use "vanilla" js?
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) => { / *…
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;
http://youmightnotneedjquery.com/
A good example of why I will continue using jQuery for the time being.
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 an…
Well it's 2016 and we still don't have nodeList.forEach() so it can't be much worse.
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) => { / *…
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) => {}).cat…
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...
[1] https://api.jquery.com/deferred.promise/
[2] https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
http://youmightnotneedjquery.com/
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);
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.
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) => { / *…