The State of jQuery 2013 | Hacker News Reader

The State of jQuery 2013

blog.jquery.com

155 pointsdmethvin25 comments

"jQuery 2.0 now has more patches and shims for Chrome, Safari, and Firefox than for Internet Explorer!"

Interesting.

That's awesome and since Firefox and Chrome (and Opera?) are evergreen browsers they will presumably be able to phase those browser patches out quite rapidly on the 2.x branch.

Well if you consider that the support for IE6-IE8 is dropped, it's pretty realistic.

I suppose it's three browsers vs one...

> "The most exciting news of all? The Plugin site returns!"

Indeed!

I for one would love to see the plugin site stay down. There are just way too many terribly written and inflexible plugins around that are mostly reinventions of other terribly written and inflexible plugins. The people in the jQuery ecosystem really need to learn some proper OOP. At the very least, you should be able to do what the Bootstrap's jQuery plugins do - write your own UI class, wrap it around with the jQuery plugin namespace, and send a custom event for every action the class takes. No more stupid callbacks.

Having the plugin site down the past year had been a breath of fresh air. I've discovered a dozen or so truly great plugins purely by world of mouth. I can't tell you how much better this filter is than the searching and rating and commenting stuff on the old plugin site.

If you are so against the plugins that are there (when they come back), consider contributing some better ones. It doesn't make any sense for an open-source project to not exist simply because you personally don't like the way the code is being written.

Oh you have over-estimated my power to make terrible jQuery plugins disappear. Terrible they may be, they certainly have a right to exist, they just should crowd out the really good ones on an official plugin site.

I have given up on writing jQuery plugins. Something about calling "methods" on the plugin by using a string isn't resonating with me. But since you've asked, I recently have open sourced 2 backbone projects on Github. One has reached 1.0 tho I just discovered a few bugs, another one is coming along with a first release soon.

https://github.com/wyuenho/backbone-pageable

https://github.com/wyuenho/backgrid

Maybe the GitHub requirement[0] will raise the barrier to entry? I never used the old plugin site but I'll give the new one a chance. GitHub will make reviewing plugins so much easier.

[0]: https://github.com/jquery/plugins.jquery.com#how-it-works

That sounds like a terrible idea that only the jQuery and npm people think is Ok. What if someone wants to host on their own domain and servers and review code with reviewboard? What about people using Bitbucket or other free source code repo hosts?

Reading web mags like DailyJS and Smashing magazines are probably a vastly superior way to know about high quality jQuery plugins. These mags are like the academics journals, if your plugin gets published, there's a shallower limit to how terrible it can be.

I think it's more important for jQuery to provide a more flexible module/plugin system that jQuery itself is built on. Many people are actually asking for easier ways to have their own customized jQuery builds. There are ways you can do it now, but they are pretty involved. This is one area I'd definitely like to see jQuery improve on.

> What if someone wants to host on their own domain and servers and review code with reviewboard? What about people using Bitbucket or other free source code repo hosts?

Any time developers want to be involved in a collaborative project, they generally have to conform to an agreed set of best practices. For jQuery plugins available through the plugins site, this now means using their GitHub-based system. If a developer's code is so tied to a particular set of tools that they can't make adapt to a new system, that's something they need to deal with, not the jQuery Foundation.

This bit was lost on me. What plugin site? Could you provide a link?

http://plugins.jquery.com/

They wiped out all the plugins (with no recent backups) in the process of removing spam.

http://plugins.jquery.com/

Much has been said that 2.0 dropping IE8 was about code size. I really hope it was a focusing effort rather than size reduction decision.

jQuery minified is ~90K. Even if 2.0 weights half as much, 45K isn't that big a deal, even on mobile. Besides, it's so widely used that if you link to Google's CDN, it's probably cached already.

First, I believe that "every millisecond counts" is a good principle in web design. There is enough latency that we can't avoid, which is why we should avoid latency wherever it is possible. Considering this, 45K is a big deal indeed.

Second, just some hours ago, I read that the mere execution (not the download!) of jQuery takes about a second on an iPhone 3G. These devices and similarly weak ones are still out there, which is easy to forget if you test only on the latest hardware.

Lastly, keep in mind that bandwidth isn't always ideal. Consider mobile: In rural areas, 3G isn't always available. When I'm on the train, loading the slim HN itself often is not an issue, while many other pages simply time out. In developing countries, bandwidths are often very low, too. 56kbps still is a realistic bandwidth. And downloading 45K on a 56kbps connection takes almost 7s.

Every millisecond does count. But design is about compromise. By that logic we shouldn't use CSS at all, but we choose to pay the price of a few KBs for the returned value.

I'm all for efficiency, I'll use Zepto or a focused custom made solutions whenever I can, I'll squeeze every byte out of the images, serve resolution specific versions, gzip, etc.

But there are some compromises that I'm not willing to make. Take images for example. If I can see image quality degradation on something that I find important, I won't compress it further, even if it's huge. Add a few iPad retina display PNGs and suddenly 45KB seems like small change. Sometimes I'd rather have the user wait for a great result than deliver a poor one fast.

In the case of jQuery 2.0, dropping IE8 support seems a poor and premature kind of optimization. If your target is a memory starved 128MB iPhone 3G on Edge, than 45K for a single JS library is still way too much. Not only it would take forever to load and run, but unresponsiveness and eventual crashing would still be a problem.

I think the effort would be better spent on improving jQuery mobile. People on 56kbps connections could be running even older versions of IE.

There's also a difference when you're developing your own site compared to when you're developing a framework or library. If your library is used on more than half of the top 100,000 websites (as jQuery is) then a 45KB saving or a 100ms speed boost, 50,000 times over is a big deal.

Depending on the definition of developing countries, I think you would find "developing" countries can have much better connections than many western developed countries. This is $10/mo: http://www.speedtest.net/result/2436462597.png (local server) & http://www.speedtest.net/result/2436466252.png (across the pond.

I understand why they'd drop IE8 support in 2.0 but it's still a bitter pill to swallow.

If you're primarily focused on older IE's, I think it's assumed you're dealing with a forced intranet environment (typically government/military/large corp) and/or need to focus on stability, not the latest and greatest. Part of me says "good riddance" as I never got the lock in to XP, but I get why devs might be annoyed with being stuck at 1.9 for the foreseeable future.

We're not going to be "stuck" with 1.9. Use 2.0 for a smaller and faster library on modern browsers and 1.9 to continue to support old IE versions.

http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-an... "Our goal is for 1.9 and 2.0 to be interchangeable as far as the API set they support. When 2.0 comes out, your decision on which version to choose should be as simple as this: If you need IE 6/7/8 support, choose 1.9; otherwise you can use either 1.9 or 2.0. ... If your web site needs oldIE support, and we expect most sites will need it for at least another year or two, you can use IE conditional comments to include version 1.9 only when visitors are using oldIE:"

> Some glorious day in the future, jQuery 2.0 will be the only version you’ll need; until then we’ll continue to maintain jQuery 1.9

The benefit is that if you're targeting mobile only, you can use the optimized 2.0. For other use case there's still going to be 1.9.

I'm wondering if they should have give. jQuery 2.0 a separate name to make it clear development on jQuery 1.9 will continue in parallel.

Thanks bro for sharing.

Reply on news.ycombinator.com