Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

jQuery 3.0 Released

jquery.com

Post reply on HN
Print view View original

111–120 of 164 posts

Re: jQuery 3.0 Released

#111

Post by fxbois »

MrPatan wrote: post #80
rcarmo wrote: post #30

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…

querySelector and querySelectorAll exist in browsers only because of jQuery

Please do not forget Prototype that inspired jQuery

Re: jQuery 3.0 Released

#112

Post by md224 »

forgotpwtomain wrote: post #110
eyko wrote: post #100

Earlier quoted context omitted.

If you're not handling the error in the first promise, then throw it again.

> If you're not handling the error in the first promise, then throw it again. You are handling the error (e.g. providing the user with a flash message telling them their was an error) - but if you don't re-throw it you will end up in the 'success' callback-chain - without a result obviously. Therefore whether you re-throw the error or squash it depends on whether another 'reject' function will be there to squash it f…

> Therefore whether you re-throw the error or squash it depends on whether another 'reject' function will be there to squash it further down the chain etc.

Does it matter if another 'reject' function is there to squash it? I was under the impression that unhandled rejections would just vanish into the ether... no need to worry about another promise handling them. Just re-throw the error and forget about it.

Edit: To be clear, the browser may display an error in the console as a diagnostic tool, but my impression is that unhandled rejections will not result in an actual exception that halts execution.

Edit 2: Here's a fun example for the Chrome console:

    var p = Promise.reject();
    setTimeout(() => p.catch(e => {}), 1000);
It displays an error... and then a second later the error transforms into a non-error!

Re: jQuery 3.0 Released

#113

Post by [deleted] »

forgotpwtomain wrote: post #110
eyko wrote: post #100

Earlier quoted context omitted.

If you're not handling the error in the first promise, then throw it again.

> If you're not handling the error in the first promise, then throw it again. You are handling the error (e.g. providing the user with a flash message telling them their was an error) - but if you don't re-throw it you will end up in the 'success' callback-chain - without a result obviously. Therefore whether you re-throw the error or squash it depends on whether another 'reject' function will be there to squash it f…

[deleted]

Re: jQuery 3.0 Released

#114

Post by coroutines »

d0lph wrote: post #67
mikegerwitz wrote: post #61

Earlier quoted context omitted.

> browsers don't standardize on anything, which makes the idea of native jQuery a bit of a paradox. Eh? Browsers will sometimes implement their own extensions to various standards (which are sometimes incorporated into those standards), but there is certainly a standard DOM API. If you're referring to older versions of IE, they're the ugly ducking, and the situation has since improved dramatically. jQuery was a great…

Moreso at the time JQuery was created than now.

Kids have it so easy these days, amirite? :D

Re: jQuery 3.0 Released

#115

Post by Guillaume86 »

mrweasel wrote: post #37
awestroke wrote: post #2

Is anybody in the HN crowd still using jQuery for new projects? If yes, why not use "vanilla" js?

>If yes, why not use "vanilla" js? Isn't that like asking why jQuery exists? Personally I still believe that JavaScript and HTML should be separate, like HTML and CSS. I know that might make sound old, but I really dislike having a template language embedded in my JavaScript library, and as a result I end up disliking most of the newer frameworks. I know jQuery, the documentation is good, it's easy to get help, and i…

I can relate to this idea, but I gave a try to react and I changed my position:

Here's why IMO react is not actually mixing the two: HTML is just the serialized form of the DOM, your browser reads it, transforms it the a DOM tree before rendering it.

With react, you interact with the DOM (indirectly via a virtual DOM API), so you manipulate javascript objects, you only do javascript. JSX is just syntaxic sugar over that API, because deep nesting is easier to read with XMLish syntax. JSX is not a templating language (that outputs a string).

Re: jQuery 3.0 Released

#116

Post by nubs »

forgotpwtomain wrote: post #98
nubs wrote: post #95

Earlier quoted context omitted.

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…

> 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 an…

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.

Re: jQuery 3.0 Released

#117

Post by abritinthebay »

MrPatan wrote: post #90
mratzloff wrote: post #87

Earlier quoted context omitted.

Alias `document.querySelectorAll` to `$$`?

var $ = selector => [].slice.call(document.querySelectorAll(selector)); Fo' sizzle

If you're using ES6 you may as well use spread and defaults to make it more useful:

const $ = (selector, context=document) => [...context.querySelectorAll(selector)]

Re: jQuery 3.0 Released

#119

Post by mhd »

jjnoakes wrote: post #86
mhd wrote: post #83

Earlier quoted context omitted.

One man's trivial is another man's bother. I consider 30k (less than some images or the rather popular fonts) to be quite trivial for most purposes, and if it gives me a nicer syntax for common operations, it's probably worth it. On the other hand, I've seen actual backlash against printf implementations in libs and the bloat they're causing, never mind potential bugs [1]. So there you go. [1]: https://www.fefe.de/di…

I'm not advocating for or against jQuery or printf. I'm just pointing out that equating the two (in size, utility, or potential gains by avoiding them) doesn't make a lot of sense. jQuery's ratio of size-versus-additional-utility is much larger than printf's, even more so if you consider typical use cases of each. But it isn't even a fair comparison to begin with. How about comparing jQuery to libc. I'd still argue t…

libc seems much more substantial, maybe we can split the difference and call it "youmightnodneedstdio.com", although that sounds much less pithy.

I still wouldn't be so sure about that ratio. The people decrying the printf family of functions are often targeting small statically linked binaries. Where a few kb shaved off might be a bigger chunk than 30kb are for your usual multi-megabyte front page of today's web.

Re: jQuery 3.0 Released

#120

Post by andybak »

oneeyedpigeon wrote: post #99
andybak wrote: post #76

Earlier quoted context omitted.

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);

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.

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.
Post reply on HN