Earlier quoted context omitted.
There are ways to do it for sure, but imagine if there was just One Obvious Way To Do It.
document.querySelectorAll(..).forEach?!?!?!?!
Yep, that just rolls of the tongue...
jQuery 3.0 Released
81–90 of 164 posts
Re: jQuery 3.0 Released
#82Is anybody in the HN crowd still using jQuery for new projects? If yes, why not use "vanilla" js?
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 E…
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.
Re: jQuery 3.0 Released
#83Earlier quoted context omitted.
I'm surprised that there's no youmightnotneedprintf.com
I'm surprised you are comparing jQuery (a non-trivial additional dependency with reasonable dependency-less alternatives) to printf (a small piece of a dependency you most likely pull in already with).
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.
Re: jQuery 3.0 Released
#84Whenever 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.
Re: jQuery 3.0 Released
#85Whenever 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…
What I wonder is why not have a heavily cached, canonical version of each jQuery library, and every other library as long as it is used on a lot of sites? These days the browsers cache the bytecode, which is almost as fast as shipping native code with the browser.
I think google used to host those things. It automatically becomes more cached the more it is used.
https://developers.google.com/speed/libraries/
The downside is that with a referer header, you then let some centralized DNS know your site is being visited by a new visitor.
What we really need is my httpc:// proposal. The c stands for constant. Download once from a seed and cache the file. Guarantee it's always the same. Or web browsers should support magnet links.
Re: jQuery 3.0 Released
#86Earlier quoted context omitted.
I'm surprised you are comparing jQuery (a non-trivial additional dependency with reasonable dependency-less alternatives) to printf (a small piece of a dependency you most likely pull in already with).
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 the ratio is in libc's favor, but no one would have written "I'm surprised that there's no youmightnotneedlibc.com".
Re: jQuery 3.0 Released
#87Re: jQuery 3.0 Released
#88Earlier quoted context omitted.
They are just recreating jQuery, no?
You aren't recreating jQuery by using basic JavaScript syntax.
Not sure if you read the page, but many of the examples are not "basic JavaScript syntax", the fadeIn approach is a function that attempts to replicate jQuery's, probably poorly.
Re: jQuery 3.0 Released
#89Apparently there is no migration guide to migrate from React to jQuery :(
lol