[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.

[mangeletti]

That would pretty cool, but one of the biggest reasons jQuery exists is because browsers don't standardize on anything, which makes the idea of native jQuery a bit of a paradox.

Another big reason jQuery exists is because standards change. You can use jQuery.ajax without worrying about a change in the XMLHTTPRequest API, because jQuery will support the old and new version until some point where the old version is considered "too old".

That second reason is the necessary evil that would exist, even if jQuery became the built-in standard.

[mikegerwitz]

> 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 idea back in the day to avoid compatibility headaches, but with modern DOM APIs and CSS3, the only time I personally use jQuery is if my coworkers decide to use it.

https://developer.mozilla.org/en-US/docs/Web/API/Document_Ob...

http://youmightnotneedjquery.com/

[d0lph]

Moreso at the time JQuery was created than now.

[coroutines]

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

[DougWebb]

You must have a short memory; a lot of the really useful bits of the standard DOM API we have now was originally only found in jQuery.

[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/

[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.

[kolodny]

https://gist.github.com/paulirish/12fb951a8b893a454b32

[Klathmon]

well we do have for..of that will iterate over a nodeList natively (and now that i'm using let/const i've found myself using for..of a lot more)

[dmethvin]

jQuery 3.0 lets you do for..of for a jQuery collection even.

[eyko]

Array.from(document.getElementBy...).forEach ?

[Jgrubb]

There are ways to do it for sure, but imagine if there was just One Obvious Way To Do It.

[rcarmo]

Don't get me going on Python in the browser... :)

[andybak]

I can't find a reference but I remember hearing a tale that Guido was contacted by Netscape just before Brendan Eich but wasn't interested. What an interesting parallel reality that conjours up.

Hmmmm. On second thoughts maybe we're be living in a world where Python was as maligned as Javascript.

[smt88]

1) There's certainly not "one way" to iterate in Python[1], and they're not even consistently named (xrange is the iterator version of range, but izip is the iterator version of zip).

2) You can use Python in the browser[2][3][4 sort of].

1. https://youtu.be/OSGv2VnC0go?t=3m20s

2. http://transcrypt.org

3. http://pyjs.org

4. http://www.rapydscript.com

[djsumdog]

From "import this"

> There should be one-- and preferably only one --obvious way to do it.

Key words are preferably and obviously. Of course there are going to be multiple ways to do everything, but it'd be nice if the best practice is pretty obvious.

> Although that way may not be obvious at first unless you're Dutch.

[nathggns]

document.querySelectorAll(..).forEach?!?!?!?!

[calebegg]

In Firefox, Safari, IE, and Chrome < 51:

    TypeError: document.querySelectorAll(...).forEach is not a function

That's exactly what this sub-thread is about! NodeList doesn't have .forEach.

[robodale]

Yep, that just rolls of the tongue...

[mratzloff]

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

[MrPatan]

querySelector and querySelectorAll exist in browsers only because of jQuery

[fxbois]

Please do not forget Prototype that inspired jQuery

[terda12]

Not a bad idea. Personally I'm fine with using pure javascript. I haven't used jquery in a long long time. But I'm sure many people would benefit from having jquery features natively.

[Touche]

What version of jQuery exactly? They've made backwards incompatible changes; browsers can't do that.

[drdaeman]

In theory, supporting backwards-incompatible changes should be well possible with versioning (with, e.g. the <script>'s type attribute or a <meta> tag, or "use jquery14"; magic string or whatever) - everything should work as long as one can specify "I want libfoo API v2 here".

[dmethvin]

Right, that is the advantage of having an API layer that the developer (not the web platform) controls. The more we dump into the web platform the bigger it gets because it's nearly impossible to remove anything. The idea of the Extensible Web Manifesto is to provide primitives in the web platform and let people build more powerful abstractions over them in JavaScript.

You could view jQuery as that type of abstraction. If you decide to use some other abstraction (e.g. React) you can switch your web page/app and you aren't paying the cost of having jQuery embedded into the web platform.

[jjp]

Would probably mean that we have multiple libraries or frameworks developed (to various levels of completeness) that sit above the different browser runtime implementations of the jQuery API in order to handle the challenges of having the browser runtime not supporting, only partial supporting or incorrectly supporting the jQUery API specification.

[EGreg]

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.

[Klathmon]

Actually those CDNs for libraries like jquery don't have as high of a cache hit rate as you'd think.

The problem is that there is a pretty wide number of versions of each library that are used. Combine that with the fact that mobile caches are still laughably small (like 5-50mb on some phones), means that it's not really helping all that many people.

As for the caching stuff, there was a push for that with html imports (basically treating all imports with the same name as the same, so if you and another library needed jquery, they could both use the one in your cache without needing to re-import it), but I haven't heard anything on it for a while, and i'm not sure if that's even a goal any more.

[cwmma]

they have in many ways you can use fetch instead of $.ajax and document.querySelectAll instead of $,