6 ms·

The State of jQuery 2013

155 points by dmethvin 14y ago

eranation 14y ago
> "The most exciting news of all? The Plugin site returns!" Indeed!
- portmanteaufu 14y ago
  This bit was lost on me. What plugin site? Could you provide a link?
  - xentronium 14y ago
    http://plugins.jquery.com/ http://plugins.jquery.com/
  - numbnuts 14y ago
    http://plugins.jquery.com/ http://plugins.jquery.com/ They wiped out all the plugins (with no recent backups) in the process of removing spam.
- wyuenho 14y ago
  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.
  - numbnuts 14y ago
    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 https://github.com/jquery/plugins.jquery.com#how-it-works
    - wyuenho 14y ago
      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.
      - CognitiveLens 14y ago
        > 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.
  - fourstar 14y ago
    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.
numbnuts 14y ago
I understand why they'd drop IE8 support in 2.0 but it's still a bitter pill to swallow.
- halvsjur 14y ago
  > 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.
- pdwetz 14y ago
  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.
  - zalambar 14y ago
    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-and-beyond/ 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:"
alxndr 14y ago
"jQuery 2.0 now has more patches and shims for Chrome, Safari, and Firefox than for Internet Explorer!" Interesting.
- fourstar 14y ago
  Well if you consider that the support for IE6-IE8 is dropped, it's pretty realistic.
  - alxndr 14y ago
    I suppose it's three browsers vs one...
- davej 14y ago
  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.
tambourine_man 14y ago
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.
- currysausage 14y ago
  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.
  - cmircea 14y ago
    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 http://www.speedtest.net/result/2436462597.png (local server) & http://www.speedtest.net/result/2436466252.png http://www.speedtest.net/result/2436466252.png (across the pond.
  - tambourine_man 14y ago
    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.
ajanuary 14y ago
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.
bloggersway 14y ago
Thanks bro for sharing.

155 points by dmethvin 14y ago

eranation 14y ago

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

portmanteaufu 14y ago
This bit was lost on me. What plugin site? Could you provide a link?
- xentronium 14y ago
  http://plugins.jquery.com/ http://plugins.jquery.com/
- numbnuts 14y ago
  http://plugins.jquery.com/ http://plugins.jquery.com/ They wiped out all the plugins (with no recent backups) in the process of removing spam.
wyuenho 14y ago
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.
- numbnuts 14y ago
  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 https://github.com/jquery/plugins.jquery.com#how-it-works
  - wyuenho 14y ago
    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.
    - CognitiveLens 14y ago
      > 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.
- fourstar 14y ago
  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.

numbnuts 14y ago

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

halvsjur 14y ago
> 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.
pdwetz 14y ago
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.
- zalambar 14y ago
  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-and-beyond/ 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:"

alxndr 14y ago

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

fourstar 14y ago
Well if you consider that the support for IE6-IE8 is dropped, it's pretty realistic.
- alxndr 14y ago
  I suppose it's three browsers vs one...
davej 14y ago
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.

tambourine_man 14y ago

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.

currysausage 14y ago
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.
- cmircea 14y ago
  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 http://www.speedtest.net/result/2436462597.png (local server) & http://www.speedtest.net/result/2436466252.png http://www.speedtest.net/result/2436466252.png (across the pond.
- tambourine_man 14y ago
  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.

ajanuary 14y ago

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.

bloggersway 14y ago

Thanks bro for sharing.