We're not getting much of a quorum in the weekly meetings, so I thought I'd try to get some discussion started here instead. Sorry it's a bit rushed and not as well thought out as I'd like but it seems like Addy's tweet gave the wrong impression and I wanted to try and clear things up.
More than 60% of jQuery users are currently on version 1.4.x or older:
Last year we blazed through three major-point releases that each incorporated different subsystem rewrites with dozens of changes and feature additions. As is inevitable when you have a large installed base of users with code that you couldn't imagine in your worst nightmares, each introduced breaking changes.
It's possible the concern about things breaking is one of the things that has slowed adoption of later versions, but in any case it does seem like we're moving very fast compared to their pace. Think about it, more than half the people using jQuery aren't using the new $.ajax, Deferreds, or attribute rewrite.
In addition we're talking about making more changes, some of which are likely to break existing code (either intentionally or accidentally) and prevent people on previous versions from upgrading. That includes deprecating and deleting functionality like $.browser.
Instead of making these breaking changes a little bit at a time, I am wondering if we should create a stable branch (say 1.x) and go for more changes and refactoring in a new branch (say 2.0). This isn't a license to rewrite jQuery in a really incompatible way, I think it should stay as compatible as possible although might get that compatibility in the form of plugins. Also, I'd prefer that if an API is there it retain its semantics. I'd rather remove an API totally or make it a plugin because that is a lot easier to debug or document than some subtle change.
*So as far as old IE support is concerned, the jQuery *project* obviously needs to support IE6-8 for several more years. *
At some point we will be free of it, however. Remember that Microsoft's Extended XP support (e.g., security bugfixes) totally disappears as of mid-2014 for example, and that is the source of most IE6-8 users. Companies will need to transition off XP by then, unless Microsoft blinks and says they'll provide patches for a longer time.
If we are going to make big moves in APIs and browser support, it seems like the 2.0 version might be the natural place to make it. At the very least, start with the assumption that oldIE is not there and make a plugin to support it -- or just use 1.x for that case. And now might be the time to start planning that, since if we slow the pace for point-releases it's likely 2.0 won't arrive until 2013 at the earliest.
*But again, the oldIE support issue is just one of many here.*
I'm making my own set of assumptions:
- Are we moving too fast in versions? - Is the fact we're so far ahead of the installed base a problem? - Is it too early to plan for jQuery 2.0? - Should we just continue to make incremental breaking changes on point versions?
We're not getting much of a quorum in the weekly meetings, so I thought I'd try to get some discussion started here instead. Sorry it's a bit rushed and not as well thought out as I'd like but it seems like Addy's tweet gave the wrong impression and I wanted to try and clear things up.
More than 60% of jQuery users are currently on version 1.4.x or older:
Last year we blazed through three major-point releases that each incorporated different subsystem rewrites with dozens of changes and feature additions. As is inevitable when you have a large installed base of users with code that you couldn't imagine in your worst nightmares, each introduced breaking changes.
It's possible the concern about things breaking is one of the things that has slowed adoption of later versions, but in any case it does seem like we're moving very fast compared to their pace. Think about it, more than half the people using jQuery aren't using the new $.ajax, Deferreds, or attribute rewrite.
In addition we're talking about making more changes, some of which are likely to break existing code (either intentionally or accidentally) and prevent people on previous versions from upgrading. That includes deprecating and deleting functionality like $.browser.
Instead of making these breaking changes a little bit at a time, I am wondering if we should create a stable branch (say 1.x) and go for more changes and refactoring in a new branch (say 2.0). This isn't a license to rewrite jQuery in a really incompatible way, I think it should stay as compatible as possible although might get that compatibility in the form of plugins. Also, I'd prefer that if an API is there it retain its semantics. I'd rather remove an API totally or make it a plugin because that is a lot easier to debug or document than some subtle change.
*So as far as old IE support is concerned, the jQuery *project* obviously needs to support IE6-8 for several more years. *
At some point we will be free of it, however. Remember that Microsoft's Extended XP support (e.g., security bugfixes) totally disappears as of mid-2014 for example, and that is the source of most IE6-8 users. Companies will need to transition off XP by then, unless Microsoft blinks and says they'll provide patches for a longer time.
If we are going to make big moves in APIs and browser support, it seems like the 2.0 version might be the natural place to make it. At the very least, start with the assumption that oldIE is not there and make a plugin to support it -- or just use 1.x for that case. And now might be the time to start planning that, since if we slow the pace for point-releases it's likely 2.0 won't arrive until 2013 at the earliest.
*But again, the oldIE support issue is just one of many here.*
I'm making my own set of assumptions:
- Are we moving too fast in versions? - Is the fact we're so far ahead of the installed base a problem? - Is it too early to plan for jQuery 2.0? - Should we just continue to make incremental breaking changes on point versions?
"Is the fact we're so far ahead of the installed base a problem?" - have you compared that to any download numbers? How many people download each jQuery version, compared to release cycles and previous releases. That should be much more representive for adoption than what sites are actually using, as that includes all sites that are built once and then just maintained, where there is usually no incentive to update the jQuery version in use.
As for jQuery UI, the download numbers for various releases are somewhat even: http://code.google.com/p/jquery-ui/downloads/list - without crunching those numbers in detail, it looks like the number of downloads over time is some linear, so the longer one release is the major one, the more downloads it gets. I suspect the same is the case for jQuery.
Does Microsoft like that the XP base is still so huge? Does it stop anyone from buying Windows 7 with a new machine?
On Mon, Jan 23, 2012 at 23:17, Dave Methvin <dave.meth...@gmail.com> wrote: > We're not getting much of a quorum in the weekly meetings, so I thought > I'd try to get some discussion started here instead. Sorry it's a bit > rushed and not as well thought out as I'd like but it seems like Addy's > tweet gave the wrong impression and I wanted to try and clear things up.
> More than 60% of jQuery users are currently on version 1.4.x or older:
> Last year we blazed through three major-point releases that each > incorporated different subsystem rewrites with dozens of changes and > feature additions. As is inevitable when you have a large installed base of > users with code that you couldn't imagine in your worst nightmares, each > introduced breaking changes.
> It's possible the concern about things breaking is one of the things that > has slowed adoption of later versions, but in any case it does seem like > we're moving very fast compared to their pace. Think about it, more than > half the people using jQuery aren't using the new $.ajax, Deferreds, or > attribute rewrite.
> In addition we're talking about making more changes, some of which are > likely to break existing code (either intentionally or accidentally) and > prevent people on previous versions from upgrading. That includes > deprecating and deleting functionality like $.browser.
> Instead of making these breaking changes a little bit at a time, I am > wondering if we should create a stable branch (say 1.x) and go for more > changes and refactoring in a new branch (say 2.0). This isn't a license to > rewrite jQuery in a really incompatible way, I think it should stay as > compatible as possible although might get that compatibility in the form of > plugins. Also, I'd prefer that if an API is there it retain its semantics. > I'd rather remove an API totally or make it a plugin because that is a lot > easier to debug or document than some subtle change.
> *So as far as old IE support is concerned, the jQuery *project* obviously > needs to support IE6-8 for several more years. *
> At some point we will be free of it, however. Remember that Microsoft's > Extended XP support (e.g., security bugfixes) totally disappears as of > mid-2014 for example, and that is the source of most IE6-8 users. Companies > will need to transition off XP by then, unless Microsoft blinks and says > they'll provide patches for a longer time.
> If we are going to make big moves in APIs and browser support, it seems > like the 2.0 version might be the natural place to make it. At the very > least, start with the assumption that oldIE is not there and make a plugin > to support it -- or just use 1.x for that case. And now might be the time > to start planning that, since if we slow the pace for point-releases it's > likely 2.0 won't arrive until 2013 at the earliest.
> *But again, the oldIE support issue is just one of many here.*
> I'm making my own set of assumptions:
> - Are we moving too fast in versions? > - Is the fact we're so far ahead of the installed base a problem? > - Is it too early to plan for jQuery 2.0? > - Should we just continue to make incremental breaking changes on > point versions?
I'd like to reiterate my apology for the tweets early. I was hoping more people would have read it was only an idea and moving oldIE support to plugins was a possibility, but not definite by any means : /
That said, I'd like to distill some of the feedback that came through (in case it does help with discussions for 2.0):
- On the whole, developers that contacted me seemed okay (many, very positive) about the prospect of oldIE support being moved to a plugin for 2.0. Granted that the baseline at enterprise is currently IE8 in many places now (Drupal dropped support for IE7 today, at AOL we're working against 8 as of this year) this is quite welcome to hear. As I mentioned in the meeting, I think we need to be careful about how/if this plugin idea becomes a reality. - There were questions about whether (if this idea was implemented) it would be done so a version basis (e.g plugin for IE6, plugin for IE7 support etc.). I conveyed this is something that might be more feasible with the GCC work being experimented with, but imo a single oldIE plugin may be more feasible than maintaining multiple versions. - About 20% of those that got in touch suggested it would be 2013/2014 before jQuery would probably consider adopting oldIE support as a plugin (note: I didn't make any mention of years today, this is from developers themselves).
In terms of us being far ahead of the install base, the last time I checked, many of the top 50 sites are still using older versions of jQuery. On reaching out to them, some are using pre 1.5 due to worries about instability whilst others have either a) been unaware they were using older versions or b) required a poke to get their dev team to work on updating. An example of a site where this was successful is the Guardian<http://www.guardian.co.uk/>, who were on 1.4.2 but shifted to 1.6.x. I'm not sure what we can do to improve adoption of newer versions other than increasing awareness.
People have mentioned they'd like more advance notice of breaking changes, but I thought the blog posts Dave (and others) have been doing over the past few releases were ample for this.
On Mon, Jan 23, 2012 at 10:17 PM, Dave Methvin <dave.meth...@gmail.com>wrote:
> We're not getting much of a quorum in the weekly meetings, so I thought > I'd try to get some discussion started here instead. Sorry it's a bit > rushed and not as well thought out as I'd like but it seems like Addy's > tweet gave the wrong impression and I wanted to try and clear things up.
> More than 60% of jQuery users are currently on version 1.4.x or older:
> Last year we blazed through three major-point releases that each > incorporated different subsystem rewrites with dozens of changes and > feature additions. As is inevitable when you have a large installed base of > users with code that you couldn't imagine in your worst nightmares, each > introduced breaking changes.
> It's possible the concern about things breaking is one of the things that > has slowed adoption of later versions, but in any case it does seem like > we're moving very fast compared to their pace. Think about it, more than > half the people using jQuery aren't using the new $.ajax, Deferreds, or > attribute rewrite.
> In addition we're talking about making more changes, some of which are > likely to break existing code (either intentionally or accidentally) and > prevent people on previous versions from upgrading. That includes > deprecating and deleting functionality like $.browser.
> Instead of making these breaking changes a little bit at a time, I am > wondering if we should create a stable branch (say 1.x) and go for more > changes and refactoring in a new branch (say 2.0). This isn't a license to > rewrite jQuery in a really incompatible way, I think it should stay as > compatible as possible although might get that compatibility in the form of > plugins. Also, I'd prefer that if an API is there it retain its semantics. > I'd rather remove an API totally or make it a plugin because that is a lot > easier to debug or document than some subtle change.
> *So as far as old IE support is concerned, the jQuery *project* obviously > needs to support IE6-8 for several more years. *
> At some point we will be free of it, however. Remember that Microsoft's > Extended XP support (e.g., security bugfixes) totally disappears as of > mid-2014 for example, and that is the source of most IE6-8 users. Companies > will need to transition off XP by then, unless Microsoft blinks and says > they'll provide patches for a longer time.
> If we are going to make big moves in APIs and browser support, it seems > like the 2.0 version might be the natural place to make it. At the very > least, start with the assumption that oldIE is not there and make a plugin > to support it -- or just use 1.x for that case. And now might be the time > to start planning that, since if we slow the pace for point-releases it's > likely 2.0 won't arrive until 2013 at the earliest.
> *But again, the oldIE support issue is just one of many here.*
> I'm making my own set of assumptions:
> - Are we moving too fast in versions? > - Is the fact we're so far ahead of the installed base a problem? > - Is it too early to plan for jQuery 2.0? > - Should we just continue to make incremental breaking changes on > point versions?
--
*Addy Osmani*
Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams member Blogger at: http://addyosmani.com
At one of our meetings, just after 1.7 was released, I brought up all of the same points about release schedule. I believe 1.4 has so much adoption because it was the I only major release for just short of a year. I also think that 1.7 should simmer for a bit...
All of that aside, I'm in full support of this plan. I'm mobile right now, but when I have a moment I will write up any additional thoughts, but on the whole I think this is something we should start seriously discussing.
Rick
On Jan 23, 2012, at 5:17 PM, Dave Methvin <dave.meth...@gmail.com> wrote:
> We're not getting much of a quorum in the weekly meetings, so I thought I'd try to get some discussion started here instead. Sorry it's a bit rushed and not as well thought out as I'd like but it seems like Addy's tweet gave the wrong impression and I wanted to try and clear things up.
> More than 60% of jQuery users are currently on version 1.4.x or older:
> Last year we blazed through three major-point releases that each incorporated different subsystem rewrites with dozens of changes and feature additions. As is inevitable when you have a large installed base of users with code that you couldn't imagine in your worst nightmares, each introduced breaking changes.
> It's possible the concern about things breaking is one of the things that has slowed adoption of later versions, but in any case it does seem like we're moving very fast compared to their pace. Think about it, more than half the people using jQuery aren't using the new $.ajax, Deferreds, or attribute rewrite.
> In addition we're talking about making more changes, some of which are likely to break existing code (either intentionally or accidentally) and prevent people on previous versions from upgrading. That includes deprecating and deleting functionality like $.browser.
> Instead of making these breaking changes a little bit at a time, I am wondering if we should create a stable branch (say 1.x) and go for more changes and refactoring in a new branch (say 2.0). This isn't a license to rewrite jQuery in a really incompatible way, I think it should stay as compatible as possible although might get that compatibility in the form of plugins. Also, I'd prefer that if an API is there it retain its semantics. I'd rather remove an API totally or make it a plugin because that is a lot easier to debug or document than some subtle change.
> So as far as old IE support is concerned, the jQuery *project* obviously needs to support IE6-8 for several more years.
> At some point we will be free of it, however. Remember that Microsoft's Extended XP support (e.g., security bugfixes) totally disappears as of mid-2014 for example, and that is the source of most IE6-8 users. Companies will need to transition off XP by then, unless Microsoft blinks and says they'll provide patches for a longer time.
> If we are going to make big moves in APIs and browser support, it seems like the 2.0 version might be the natural place to make it. At the very least, start with the assumption that oldIE is not there and make a plugin to support it -- or just use 1.x for that case. And now might be the time to start planning that, since if we slow the pace for point-releases it's likely 2.0 won't arrive until 2013 at the earliest.
> But again, the oldIE support issue is just one of many here.
> I'm making my own set of assumptions: > Are we moving too fast in versions? > Is the fact we're so far ahead of the installed base a problem? > Is it too early to plan for jQuery 2.0? > Should we just continue to make incremental breaking changes on point versions?
> "Is the fact we're so far ahead of the installed base a problem?" - have > you compared that to any download numbers? How many people download each > jQuery version, compared to release cycles and previous releases. That > should be much more representive for adoption than what sites are actually > using, as that includes all sites that are built once and then just > maintained, where there is usually no incentive to update the jQuery > version in use.
> Since the CDN versions are the same as the ones used by the sites (we
don't have a download builder), I don't know a way to split out that number. It's definitely possible that many of those are "build and forget" sites, but I know that many are just behind for other reasons. Designers using jQuery are sometimes stymied by the smallest things, like a small incompatibility in a plugin. Our own jquery.com site is on 1.4.2 still, so it's hard to complain too much about this...
> Does Microsoft like that the XP base is still so huge? Does it stop anyone > from buying Windows 7 with a new machine?
Microsoft HATES that there are so many XP (and IE6/7/8) systems out there, it makes their life harder just like it makes ours. I think that a lot of the XP use at this point is corporate. Corporate IT has totally different rules about how they get new systems and upgrade them. The impact isn't just on corporations though, one of the companies I've worked with does high-fashion shopping and says that IE6-8 users are more than half of their traffic. It's because people are shopping at their company PCs during lunch hours.
> I'd like to reiterate my apology for the tweets early. I was hoping more > people would have read it was only an idea and moving oldIE support to > plugins was a possibility, but not definite by any means : /
It's hard to get nuances across in Twitter, unfortunately. I wasn't mad, just frustrated. We have to be able to brainstorm about future directions somewhere, but if we do it in the open it can't be instantly considered a roadmap.
My goal was to get us thinking more than one release ahead to make sure we aren't surprised when we get there. That will be even more important if we're stretching out the release schedule. At this point I don't think we are keen on adding new features, so it *should* be possible to have these 1.x versions plateau for longer periods of time.
I'm not concerned in the slightest about adoption. I think devs build till they finish a project, and usually don't upgrade until there's a need. That's understandable and a sane practice most of the time.
What's important to me is the rate of adoption of jQuery as a whole compared to other frameworks and the Internet as a whole. Last I checked, our builtwith numbers continue to climb.
My opinion: 1.X should not stop introducing breaking changes. Iterative continued development makes sense. We should continue to fix bugs and standardize popular cross browser features (vendor prefixes being the most obvious), deprecate unpopular ones (with plugins), and continue to focus on speed and size. You know, more of the same of what got us here.
If we really want to know if our pace of dev is prohibiting adoption, we should be tracking trends over time. Saying 60% today use 1.4 is meaningless unless I know what that number was yesterday. Is the rate of adoption slower?
I do believe however that there is room for a 2.0, but it's not what you think. The people that are clamoring for a targeted, leaner jQuery core are mostly the ones asking about mobile. 30K? That mainly matters in mobile. jQm is currently built on top of 1.X core, when it clearly should be built on top of a core that doesn't have IE6-IE8 support in it. So, yeah, let's built 2.0, but let's actually cut IE<9 support from it with the intent of a "mobile first" core.
With all this said, I have the least experience here about what a sane direction for jQuery might be, and this is mostly a rambling email written standing up on a train on my cell, so please please please poke holes in what I just said. I need to be brought back to reality ;)
Mike Sherov Lead Programmer SNAP Interactive, Inc. Ticker: STVI.OB
Sent Via Mobile: Please excuse my grammar, tone, and punctuation. My thumbs can't create flowery prose.
On Jan 23, 2012, at 6:50 PM, Dave Methvin <dave.meth...@gmail.com> wrote:
I'd like to reiterate my apology for the tweets early. I was hoping more
> people would have read it was only an idea and moving oldIE support to > plugins was a possibility, but not definite by any means : /
It's hard to get nuances across in Twitter, unfortunately. I wasn't mad, just frustrated. We have to be able to brainstorm about future directions somewhere, but if we do it in the open it can't be instantly considered a roadmap.
My goal was to get us thinking more than one release ahead to make sure we aren't surprised when we get there. That will be even more important if we're stretching out the release schedule. At this point I don't think we are keen on adding new features, so it *should* be possible to have these 1.x versions plateau for longer periods of time.
On Mon, Jan 23, 2012 at 2:17 PM, Dave Methvin <dave.meth...@gmail.com>wrote:
> We're not getting much of a quorum in the weekly meetings, so I thought > I'd try to get some discussion started here instead. Sorry it's a bit > rushed and not as well thought out as I'd like but it seems like Addy's > tweet gave the wrong impression and I wanted to try and clear things up.
> More than 60% of jQuery users are currently on version 1.4.x or older:
> Last year we blazed through three major-point releases that each > incorporated different subsystem rewrites with dozens of changes and > feature additions. As is inevitable when you have a large installed base of > users with code that you couldn't imagine in your worst nightmares, each > introduced breaking changes.
I think it's natural to feel that this is a good thing, especially as Internet projects have been moving towards more frequent releases. However, I think we need to seriously consider the tradeoffs:
More rapid releases means that features land and are pushed out very quickly, which means we often get stuck with features that aren't fully baked. Several of the last few releases introduced a new mechanism for doing event binding (live: 1.3, delegate: 1.4, on: 1.6), which is slowly coalescing towards a sane API. Maybe slowing things down a bit and thinking about the features we were adding would have resulted in less fragmentation.
We have trended towards exposing new features designed for internal refactoring as public APIs (Deferreds, Callbacks, *Hooks), which has solidified them while we were still learning about them for our own use. The result is that we are stuck with APIs with a large surface-areas that aren't particularly related to the core mission of the project, but which we can't easily revisit. It also required deprecating several initial features. Longer release cycles and a more conservative approach to new features would have given us the opportunity to do a release using the features internally, and then wait a good amount of time before adopting it whole-hog as a public API.
Rapid release cycles make it harder to consider significant project changes that will take more than a few months to accomplish. Moving to a 1-x-stable/2-0-unstable branch structure will work, but it will essentially cut the 2.0 branch loose from master, which is probably necessary in order to consider a project change of this magnitude. Longer release cycles might allow us to make changes of the magnitude we're discussing here without splitting the project into 1-x and 2-0 branches.
- I personally attribute a lot of the success of jQuery long-term to the fact that we have avoided this kind of divergence. Having participated in similar types of refactorings in other projects, I am unsure that splitting jQuery would be good for our long-term success. Among other things, if jQuery 2.0 is sufficiently different from jQuery 1.x, it will make it easier for the Zeptos and JQ.Mobis of the world to argue that if the upgrade cost to jQuery 2.0 is very difficult, and many plugins don't work, why not try an alternative?
Rapid release cycles have given a lot of developers the impression that jQuery is unstable, partially because of API fragmentation (like .bind, .live, .delegate, .on), and partially for unfair reasons. Upgrading your browser is transparent -- upgrading jQuery is a potentially expensive process. The longer people hold off on upgrading jQuery, the harder it gets (if a 1.4 user didn't upgrade to 1.5 and 1.6 due to fears of instability, what would make them upgrade to 1.7).
Rails has been somewhat successful by sticking to a 2ish-year release cycle for major breaking versions, and 6 months to 1 year for minor version changes. That is my other major point of reference for a project of this size, and I feel that shorter release cycles (1-3 months) are mostly appropriate for bug-fixes and minor improvements, while longer release cycles (6 months to a year) are appropriate for major new features. This is mostly due to the time it takes to vet a major new feature and back out of mistakes.
> It's possible the concern about things breaking is one of the things that > has slowed adoption of later versions, but in any case it does seem like > we're moving very fast compared to their pace. Think about it, more than > half the people using jQuery aren't using the new $.ajax, Deferreds, or > attribute rewrite.
Honestly, I suspect that the vast majority of 1.7 users are using jQuery 1.7 in a 1.4-compatible way. This is a good thing.
> In addition we're talking about making more changes, some of which are > likely to break existing code (either intentionally or accidentally) and > prevent people on previous versions from upgrading. That includes > deprecating and deleting functionality like $.browser.
I have said this before, but I strongly recommend creating a compatibility plugin for these features that we maintain for the forseeable future and release with each new version of jQuery. We should run the tests for these features that shipped with jQuery 1.6 to confirm compatibility.
> Instead of making these breaking changes a little bit at a time, I am > wondering if we should create a stable branch (say 1.x) and go for more > changes and refactoring in a new branch (say 2.0). This isn't a license to > rewrite jQuery in a really incompatible way,
I have never seen a statement like this hold true in practice. Once the branch is forked off, people usually agitate for larger changes than would have been considered acceptable beforehand. It can be kept under control, but I would expect that a 2.0 branch would diverge rather rapidly from the 1.x branch, at least in terms of the internal code.
> I think it should stay as compatible as possible although might get that > compatibility in the form of plugins. Also, I'd prefer that if an API is > there it retain its semantics. I'd rather remove an API totally or make it > a plugin because that is a lot easier to debug or document than some subtle > change.
> *So as far as old IE support is concerned, the jQuery *project* obviously > needs to support IE6-8 for several more years.*
It remains to be seen whether IE8 ends up as an albatross around the web's neck, but I tend to agree that we will eventually be free of this monster.
> At some point we will be free of it, however. Remember that Microsoft's > Extended XP support (e.g., security bugfixes) totally disappears as of > mid-2014 for example, and that is the source of most IE6-8 users. Companies > will need to transition off XP by then, unless Microsoft blinks and says > they'll provide patches for a longer time.
> If we are going to make big moves in APIs and browser support, it seems > like the 2.0 version might be the natural place to make it. At the very > least, start with the assumption that oldIE is not there and make a plugin > to support it -- or just use 1.x for that case. And now might be the time > to start planning that, since if we slow the pace for point-releases it's > likely 2.0 won't arrive until 2013 at the earliest.
It probably makes sense to move oldIE support into a separate file if that doesn't balloon the file size, just to see what it would look like. I suspect that a large chunk of the problem areas will be in the area of manipulation and `clean` et al.
> *But again, the oldIE support issue is just one of many here.*
> I'm making my own set of assumptions:
> - Are we moving too fast in versions? > - Is the fact we're so far ahead of the installed base a problem? > - Is it too early to plan for jQuery 2.0? > - Should we just continue to make incremental breaking changes on > point versions?
> I think a polar choice between a 2.0 branch and keeping oldIE support
integrated with the rest of the code is a mistake. As I said above, I propose that we take a look at what it would take to move oldIE support into a separate file, and then regroup from there.
It's really late, and this thought is obviously only half-baked, but do we have an opportunity to help the web go forward at all?
If we chose to make a hard stop going forward, perhaps a project as visible as jQuery stopping ie8 support would encourage more and more people to stop caring about ie8 support as much. The 'alternatives' that are within the grasp of most of the users of jQuery already don't support IE8. It could potentially just cause people to never update again, as well.
All I can relate this to is IE6 support being dropped from major websites. I could explain how terrible it was, and no one cared, but as soon as google and facebook dropped support for it, I suddenly had ground to stand on.
All I'm saying is that we do have some weight here and clear messaging that people should focus on the future could be beneficial for the web.
On Tue, Jan 24, 2012 at 2:11 AM, Yehuda Katz <wyc...@gmail.com> wrote:
> Yehuda Katz > (ph) 718.877.1325
> On Mon, Jan 23, 2012 at 2:17 PM, Dave Methvin <dave.meth...@gmail.com>wrote:
>> We're not getting much of a quorum in the weekly meetings, so I thought >> I'd try to get some discussion started here instead. Sorry it's a bit >> rushed and not as well thought out as I'd like but it seems like Addy's >> tweet gave the wrong impression and I wanted to try and clear things up.
>> More than 60% of jQuery users are currently on version 1.4.x or older:
>> Last year we blazed through three major-point releases that each >> incorporated different subsystem rewrites with dozens of changes and >> feature additions. As is inevitable when you have a large installed base of >> users with code that you couldn't imagine in your worst nightmares, each >> introduced breaking changes.
> I think it's natural to feel that this is a good thing, especially as > Internet projects have been moving towards more frequent releases. However, > I think we need to seriously consider the tradeoffs:
> More rapid releases means that features land and are pushed out very > quickly, which means we often get stuck with features that aren't fully > baked. Several of the last few releases introduced a new mechanism for > doing event binding (live: 1.3, delegate: 1.4, on: 1.6), which is slowly > coalescing towards a sane API. Maybe slowing things down a bit and thinking > about the features we were adding would have resulted in less fragmentation.
> We have trended towards exposing new features designed for internal > refactoring as public APIs (Deferreds, Callbacks, *Hooks), which has > solidified them while we were still learning about them for our own use. > The result is that we are stuck with APIs with a large surface-areas that > aren't particularly related to the core mission of the project, but which > we can't easily revisit. It also required deprecating several initial > features. Longer release cycles and a more conservative approach to new > features would have given us the opportunity to do a release using the > features internally, and then wait a good amount of time before adopting it > whole-hog as a public API.
> Rapid release cycles make it harder to consider significant project > changes that will take more than a few months to accomplish. Moving to a > 1-x-stable/2-0-unstable branch structure will work, but it will essentially > cut the 2.0 branch loose from master, which is probably necessary in order > to consider a project change of this magnitude. Longer release cycles might > allow us to make changes of the magnitude we're discussing here without > splitting the project into 1-x and 2-0 branches.
> - I personally attribute a lot of the success of jQuery long-term to > the fact that we have avoided this kind of divergence. Having participated > in similar types of refactorings in other projects, I am unsure that > splitting jQuery would be good for our long-term success. Among other > things, if jQuery 2.0 is sufficiently different from jQuery 1.x, it will > make it easier for the Zeptos and JQ.Mobis of the world to argue that if > the upgrade cost to jQuery 2.0 is very difficult, and many plugins don't > work, why not try an alternative?
> Rapid release cycles have given a lot of developers the impression that > jQuery is unstable, partially because of API fragmentation (like .bind, > .live, .delegate, .on), and partially for unfair reasons. Upgrading your > browser is transparent -- upgrading jQuery is a potentially expensive > process. The longer people hold off on upgrading jQuery, the harder it gets > (if a 1.4 user didn't upgrade to 1.5 and 1.6 due to fears of instability, > what would make them upgrade to 1.7).
> Rails has been somewhat successful by sticking to a 2ish-year release > cycle for major breaking versions, and 6 months to 1 year for minor version > changes. That is my other major point of reference for a project of this > size, and I feel that shorter release cycles (1-3 months) are mostly > appropriate for bug-fixes and minor improvements, while longer release > cycles (6 months to a year) are appropriate for major new features. This is > mostly due to the time it takes to vet a major new feature and back out of > mistakes.
>> It's possible the concern about things breaking is one of the things that >> has slowed adoption of later versions, but in any case it does seem like >> we're moving very fast compared to their pace. Think about it, more than >> half the people using jQuery aren't using the new $.ajax, Deferreds, or >> attribute rewrite.
> Honestly, I suspect that the vast majority of 1.7 users are using jQuery > 1.7 in a 1.4-compatible way. This is a good thing.
>> In addition we're talking about making more changes, some of which are >> likely to break existing code (either intentionally or accidentally) and >> prevent people on previous versions from upgrading. That includes >> deprecating and deleting functionality like $.browser.
> I have said this before, but I strongly recommend creating a compatibility > plugin for these features that we maintain for the forseeable future and > release with each new version of jQuery. We should run the tests for these > features that shipped with jQuery 1.6 to confirm compatibility.
>> Instead of making these breaking changes a little bit at a time, I am >> wondering if we should create a stable branch (say 1.x) and go for more >> changes and refactoring in a new branch (say 2.0). This isn't a license to >> rewrite jQuery in a really incompatible way,
> I have never seen a statement like this hold true in practice. Once the > branch is forked off, people usually agitate for larger changes than would > have been considered acceptable beforehand. It can be kept under control, > but I would expect that a 2.0 branch would diverge rather rapidly from the > 1.x branch, at least in terms of the internal code.
>> I think it should stay as compatible as possible although might get that >> compatibility in the form of plugins. Also, I'd prefer that if an API is >> there it retain its semantics. I'd rather remove an API totally or make it >> a plugin because that is a lot easier to debug or document than some subtle >> change.
>> *So as far as old IE support is concerned, the jQuery *project* >> obviously needs to support IE6-8 for several more years.*
> It remains to be seen whether IE8 ends up as an albatross around the web's > neck, but I tend to agree that we will eventually be free of this monster.
>> At some point we will be free of it, however. Remember that Microsoft's >> Extended XP support (e.g., security bugfixes) totally disappears as of >> mid-2014 for example, and that is the source of most IE6-8 users. Companies >> will need to transition off XP by then, unless Microsoft blinks and says >> they'll provide patches for a longer time.
>> If we are going to make big moves in APIs and browser support, it seems >> like the 2.0 version might be the natural place to make it. At the very >> least, start with the assumption that oldIE is not there and make a plugin >> to support it -- or just use 1.x for that case. And now might be the time >> to start planning that, since if we slow the pace for point-releases it's >> likely 2.0 won't arrive until 2013 at the earliest.
> It probably makes sense to move oldIE support into a separate file if that > doesn't balloon the file size, just to see what it would look like. I > suspect that a large chunk of the problem areas will be in the area of > manipulation and `clean` et al.
>> *But again, the oldIE support issue is just one of many here.*
>> I'm making my own set of assumptions:
>> - Are we moving too fast in versions? >> - Is the fact we're so far ahead of the installed base a problem? >> - Is it too early to plan for jQuery 2.0? >> - Should we just continue to make incremental breaking changes on >> point versions?
>> I think a polar choice between a 2.0 branch and keeping oldIE support > integrated with the rest of the code is a mistake. As I said above, I > propose that we take a look at what it would take to move oldIE support > into a separate file, and then regroup from there.
I would like to see us explore what a separate oldie.js would look like, but I think we need to be more careful going forward than we have been.
Sent from my Windows Phone ------------------------------ From: Alex Sexton Sent: 1/24/2012 12:20 AM To: jquery-bugs-team@googlegroups.com Subject: Re: [jquery-bugs-team] Thoughts on jQuery past and future
It's really late, and this thought is obviously only half-baked, but do we have an opportunity to help the web go forward at all?
If we chose to make a hard stop going forward, perhaps a project as visible as jQuery stopping ie8 support would encourage more and more people to stop caring about ie8 support as much. The 'alternatives' that are within the grasp of most of the users of jQuery already don't support IE8. It could potentially just cause people to never update again, as well.
All I can relate this to is IE6 support being dropped from major websites. I could explain how terrible it was, and no one cared, but as soon as google and facebook dropped support for it, I suddenly had ground to stand on.
All I'm saying is that we do have some weight here and clear messaging that people should focus on the future could be beneficial for the web.
On Tue, Jan 24, 2012 at 2:11 AM, Yehuda Katz <wyc...@gmail.com> wrote:
> Yehuda Katz > (ph) 718.877.1325
> On Mon, Jan 23, 2012 at 2:17 PM, Dave Methvin <dave.meth...@gmail.com>wrote:
>> We're not getting much of a quorum in the weekly meetings, so I thought >> I'd try to get some discussion started here instead. Sorry it's a bit >> rushed and not as well thought out as I'd like but it seems like Addy's >> tweet gave the wrong impression and I wanted to try and clear things up.
>> More than 60% of jQuery users are currently on version 1.4.x or older:
>> Last year we blazed through three major-point releases that each >> incorporated different subsystem rewrites with dozens of changes and >> feature additions. As is inevitable when you have a large installed base of >> users with code that you couldn't imagine in your worst nightmares, each >> introduced breaking changes.
> I think it's natural to feel that this is a good thing, especially as > Internet projects have been moving towards more frequent releases. However, > I think we need to seriously consider the tradeoffs:
> More rapid releases means that features land and are pushed out very > quickly, which means we often get stuck with features that aren't fully > baked. Several of the last few releases introduced a new mechanism for > doing event binding (live: 1.3, delegate: 1.4, on: 1.6), which is slowly > coalescing towards a sane API. Maybe slowing things down a bit and thinking > about the features we were adding would have resulted in less fragmentation.
> We have trended towards exposing new features designed for internal > refactoring as public APIs (Deferreds, Callbacks, *Hooks), which has > solidified them while we were still learning about them for our own use. > The result is that we are stuck with APIs with a large surface-areas that > aren't particularly related to the core mission of the project, but which > we can't easily revisit. It also required deprecating several initial > features. Longer release cycles and a more conservative approach to new > features would have given us the opportunity to do a release using the > features internally, and then wait a good amount of time before adopting it > whole-hog as a public API.
> Rapid release cycles make it harder to consider significant project > changes that will take more than a few months to accomplish. Moving to a > 1-x-stable/2-0-unstable branch structure will work, but it will essentially > cut the 2.0 branch loose from master, which is probably necessary in order > to consider a project change of this magnitude. Longer release cycles might > allow us to make changes of the magnitude we're discussing here without > splitting the project into 1-x and 2-0 branches.
> - I personally attribute a lot of the success of jQuery long-term to > the fact that we have avoided this kind of divergence. Having participated > in similar types of refactorings in other projects, I am unsure that > splitting jQuery would be good for our long-term success. Among other > things, if jQuery 2.0 is sufficiently different from jQuery 1.x, it will > make it easier for the Zeptos and JQ.Mobis of the world to argue that if > the upgrade cost to jQuery 2.0 is very difficult, and many plugins don't > work, why not try an alternative?
> Rapid release cycles have given a lot of developers the impression that > jQuery is unstable, partially because of API fragmentation (like .bind, > .live, .delegate, .on), and partially for unfair reasons. Upgrading your > browser is transparent -- upgrading jQuery is a potentially expensive > process. The longer people hold off on upgrading jQuery, the harder it gets > (if a 1.4 user didn't upgrade to 1.5 and 1.6 due to fears of instability, > what would make them upgrade to 1.7).
> Rails has been somewhat successful by sticking to a 2ish-year release > cycle for major breaking versions, and 6 months to 1 year for minor version > changes. That is my other major point of reference for a project of this > size, and I feel that shorter release cycles (1-3 months) are mostly > appropriate for bug-fixes and minor improvements, while longer release > cycles (6 months to a year) are appropriate for major new features. This is > mostly due to the time it takes to vet a major new feature and back out of > mistakes.
>> It's possible the concern about things breaking is one of the things that >> has slowed adoption of later versions, but in any case it does seem like >> we're moving very fast compared to their pace. Think about it, more than >> half the people using jQuery aren't using the new $.ajax, Deferreds, or >> attribute rewrite.
> Honestly, I suspect that the vast majority of 1.7 users are using jQuery > 1.7 in a 1.4-compatible way. This is a good thing.
>> In addition we're talking about making more changes, some of which are >> likely to break existing code (either intentionally or accidentally) and >> prevent people on previous versions from upgrading. That includes >> deprecating and deleting functionality like $.browser.
> I have said this before, but I strongly recommend creating a compatibility > plugin for these features that we maintain for the forseeable future and > release with each new version of jQuery. We should run the tests for these > features that shipped with jQuery 1.6 to confirm compatibility.
>> Instead of making these breaking changes a little bit at a time, I am >> wondering if we should create a stable branch (say 1.x) and go for more >> changes and refactoring in a new branch (say 2.0). This isn't a license to >> rewrite jQuery in a really incompatible way,
> I have never seen a statement like this hold true in practice. Once the > branch is forked off, people usually agitate for larger changes than would > have been considered acceptable beforehand. It can be kept under control, > but I would expect that a 2.0 branch would diverge rather rapidly from the > 1.x branch, at least in terms of the internal code.
>> I think it should stay as compatible as possible although might get that >> compatibility in the form of plugins. Also, I'd prefer that if an API is >> there it retain its semantics. I'd rather remove an API totally or make it >> a plugin because that is a lot easier to debug or document than some subtle >> change.
>> *So as far as old IE support is concerned, the jQuery *project* >> obviously needs to support IE6-8 for several more years.*
> It remains to be seen whether IE8 ends up as an albatross around the web's > neck, but I tend to agree that we will eventually be free of this monster.
>> At some point we will be free of it, however. Remember that Microsoft's >> Extended XP support (e.g., security bugfixes) totally disappears as of >> mid-2014 for example, and that is the source of most IE6-8 users. Companies >> will need to transition off XP by then, unless Microsoft blinks and says >> they'll provide patches for a longer time.
>> If we are going to make big moves in APIs and browser support, it seems >> like the 2.0 version might be the natural place to make it. At the very >> least, start with the assumption that oldIE is not there and make a plugin >> to support it -- or just use 1.x for that case. And now might be the time >> to start planning that, since if we slow the pace for point-releases it's >> likely 2.0 won't arrive until 2013 at the earliest.
> It probably makes sense to move oldIE support into a separate file if that > doesn't balloon the file size, just to see what it would look like. I > suspect that a large chunk of the problem areas will be in the area of > manipulation and `clean` et al.
>> *But again, the oldIE support issue is just one of many here.*
>> I'm making my own set of assumptions:
>> - Are we moving too fast in versions? >> - Is the fact we're so far ahead of the installed base a problem? >> - Is it too early to plan for jQuery 2.0? >> - Should we just continue to make incremental breaking changes on >> point versions?
>> I think a polar choice between a 2.0 branch and keeping oldIE support > integrated with the rest of the code is a mistake. As I said above, I > propose that we take a look at what it would take to move oldIE support > into a separate file, and then regroup from there.
Dave, based on those statistics, I'm sure that more than 60% of *publicly accessible sites* using jQuery are currently on version 1.4.x or older, but that doesn't mean that *jQuery users* are currently on version 1.4.x or older.
Once work on a site has been completed, there seldom exists a compelling reason to upgrade the version of jQuery on that site, unless either a) a specific issue has been fixed or b) new functionality needs to be added.
So, the vast majority of sites that were created two or more years ago (which is a huge chunk of the web) are using jQuery 1.4.x or older. Because they aren't going to be updated. Ever. Which means that their existence and contribution the the statistics we're looking at doesn't matter, because no matter how you change jQuery in future versions, these old sites will still use the old version.
Unless either "a" or "b" above condition is met. In which case it also doesn't matter, because then the user will upgrade to the latest jQuery. And then they'll fix their code to work with the latest jQuery, because that's what they *have to* do. It's their job. It doesn't matter if the latest version of jQuery has some major breaking changes, their *job* is to fix the site, and they'll find a way to do it. And if they complain about jQuery, tell them to use something else. jQuery doesn't owe them anything.
I've been giving a lot of thought lately to how open source works and how it should work, and am starting to form an opinion that innovation, forward momentum and fun are a pretty important part of open source projects, and while there should be some general feeling of responsibility when releasing code, it shouldn't be at the expense of innovation. Or fun. I think jQuery 2.0.0, with whatever breaking changes happen as a result of that work, *should be* developed. Because it'll be innovative, it'll more the project ahead, and it'll be a lot of fun to work on.
On Mon, Jan 23, 2012 at 5:45 PM, Addy Osmani <addyosm...@gmail.com> wrote: > I'd like to reiterate my apology for the tweets early. I was hoping more > people would have read it was only an idea and moving oldIE support to > plugins was a possibility, but not definite by any means : /
> That said, I'd like to distill some of the feedback that came through (in > case it does help with discussions for 2.0):
> - On the whole, developers that contacted me seemed okay (many, very > positive) about the prospect of oldIE support being moved to a plugin for > 2.0. Granted that the baseline at enterprise is currently IE8 in many > places now (Drupal dropped support for IE7 today, at AOL we're working > against 8 as of this year) this is quite welcome to hear. As I mentioned in > the meeting, I think we need to be careful about how/if this plugin idea > becomes a reality. > - There were questions about whether (if this idea was implemented) it > would be done so a version basis (e.g plugin for IE6, plugin for IE7 > support etc.). I conveyed this is something that might be more feasible > with the GCC work being experimented with, but imo a single oldIE plugin > may be more feasible than maintaining multiple versions. > - About 20% of those that got in touch suggested it would be 2013/2014 > before jQuery would probably consider adopting oldIE support as a plugin > (note: I didn't make any mention of years today, this is from developers > themselves).
> In terms of us being far ahead of the install base, the last time I > checked, many of the top 50 sites are still using older versions of jQuery. > On reaching out to them, some are using pre 1.5 due to worries about > instability whilst others have either a) been unaware they were using older > versions or b) required a poke to get their dev team to work on updating. > An example of a site where this was successful is the Guardian<http://www.guardian.co.uk/>, > who were on 1.4.2 but shifted to 1.6.x. I'm not sure what we can do to > improve adoption of newer versions other than increasing awareness.
> People have mentioned they'd like more advance notice of breaking changes, > but I thought the blog posts Dave (and others) have been doing over the > past few releases were ample for this.
> On Mon, Jan 23, 2012 at 10:17 PM, Dave Methvin <dave.meth...@gmail.com>wrote:
>> We're not getting much of a quorum in the weekly meetings, so I thought >> I'd try to get some discussion started here instead. Sorry it's a bit >> rushed and not as well thought out as I'd like but it seems like Addy's >> tweet gave the wrong impression and I wanted to try and clear things up.
>> More than 60% of jQuery users are currently on version 1.4.x or older:
>> Last year we blazed through three major-point releases that each >> incorporated different subsystem rewrites with dozens of changes and >> feature additions. As is inevitable when you have a large installed base of >> users with code that you couldn't imagine in your worst nightmares, each >> introduced breaking changes.
>> It's possible the concern about things breaking is one of the things that >> has slowed adoption of later versions, but in any case it does seem like >> we're moving very fast compared to their pace. Think about it, more than >> half the people using jQuery aren't using the new $.ajax, Deferreds, or >> attribute rewrite.
>> In addition we're talking about making more changes, some of which are >> likely to break existing code (either intentionally or accidentally) and >> prevent people on previous versions from upgrading. That includes >> deprecating and deleting functionality like $.browser.
>> Instead of making these breaking changes a little bit at a time, I am >> wondering if we should create a stable branch (say 1.x) and go for more >> changes and refactoring in a new branch (say 2.0). This isn't a license to >> rewrite jQuery in a really incompatible way, I think it should stay as >> compatible as possible although might get that compatibility in the form of >> plugins. Also, I'd prefer that if an API is there it retain its semantics. >> I'd rather remove an API totally or make it a plugin because that is a lot >> easier to debug or document than some subtle change.
>> *So as far as old IE support is concerned, the jQuery *project* >> obviously needs to support IE6-8 for several more years. *
>> At some point we will be free of it, however. Remember that Microsoft's >> Extended XP support (e.g., security bugfixes) totally disappears as of >> mid-2014 for example, and that is the source of most IE6-8 users. Companies >> will need to transition off XP by then, unless Microsoft blinks and says >> they'll provide patches for a longer time.
>> If we are going to make big moves in APIs and browser support, it seems >> like the 2.0 version might be the natural place to make it. At the very >> least, start with the assumption that oldIE is not there and make a plugin >> to support it -- or just use 1.x for that case. And now might be the time >> to start planning that, since if we slow the pace for point-releases it's >> likely 2.0 won't arrive until 2013 at the earliest.
>> *But again, the oldIE support issue is just one of many here.*
>> I'm making my own set of assumptions:
>> - Are we moving too fast in versions? >> - Is the fact we're so far ahead of the installed base a problem? >> - Is it too early to plan for jQuery 2.0? >> - Should we just continue to make incremental breaking changes on >> point versions?
> --
> *Addy Osmani*
> Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams > member > Blogger at: http://addyosmani.com
3 cheers for Ben. This is exactly how I feel. jQuery has to continue to blazing a trail and moving the web forward, because it's fun and lets developers have fun doing their jobs.
Not by abandoning IE (unless it was targeted for a world where oldIE doesn't exist: mobile). Not by being afraid to make incremental API changes and deprecations ( what's the cost? when we thought about cutting features to remove bloat, it was like 1K out of 33K).
We (you, really, cause i just got here) succeeded by fixing browser bugs, smoothing out APIs, exposing new design patterns, and introducing small breaking changes to facilitate the first 3.
Dave is not wrong in pondering the question. Its a good one, and I'll go in whatever direction the team decides, because jQuery development is fun.
However, I'd prefer rapid dev because I just like making pull requests. I hate bugs, and breaking changes are a part of that. Maybe that's naive.
Mike Sherov Lead Programmer SNAP Interactive, Inc. Ticker: STVI.OB
Sent Via Mobile: Please excuse my grammar, tone, and punctuation. My thumbs can't create flowery prose.
On Jan 24, 2012, at 6:52 AM, Ben Alman <cow...@rj3.net> wrote:
Dave, based on those statistics, I'm sure that more than 60% of *publicly accessible sites* using jQuery are currently on version 1.4.x or older, but that doesn't mean that *jQuery users* are currently on version 1.4.x or older.
Once work on a site has been completed, there seldom exists a compelling reason to upgrade the version of jQuery on that site, unless either a) a specific issue has been fixed or b) new functionality needs to be added.
So, the vast majority of sites that were created two or more years ago (which is a huge chunk of the web) are using jQuery 1.4.x or older. Because they aren't going to be updated. Ever. Which means that their existence and contribution the the statistics we're looking at doesn't matter, because no matter how you change jQuery in future versions, these old sites will still use the old version.
Unless either "a" or "b" above condition is met. In which case it also doesn't matter, because then the user will upgrade to the latest jQuery. And then they'll fix their code to work with the latest jQuery, because that's what they *have to* do. It's their job. It doesn't matter if the latest version of jQuery has some major breaking changes, their *job* is to fix the site, and they'll find a way to do it. And if they complain about jQuery, tell them to use something else. jQuery doesn't owe them anything.
I've been giving a lot of thought lately to how open source works and how it should work, and am starting to form an opinion that innovation, forward momentum and fun are a pretty important part of open source projects, and while there should be some general feeling of responsibility when releasing code, it shouldn't be at the expense of innovation. Or fun. I think jQuery 2.0.0, with whatever breaking changes happen as a result of that work, *should be* developed. Because it'll be innovative, it'll more the project ahead, and it'll be a lot of fun to work on.
On Mon, Jan 23, 2012 at 5:45 PM, Addy Osmani <addyosm...@gmail.com> wrote: > I'd like to reiterate my apology for the tweets early. I was hoping more > people would have read it was only an idea and moving oldIE support to > plugins was a possibility, but not definite by any means : /
> That said, I'd like to distill some of the feedback that came through (in > case it does help with discussions for 2.0):
> - On the whole, developers that contacted me seemed okay (many, very > positive) about the prospect of oldIE support being moved to a plugin for > 2.0. Granted that the baseline at enterprise is currently IE8 in many > places now (Drupal dropped support for IE7 today, at AOL we're working > against 8 as of this year) this is quite welcome to hear. As I mentioned in > the meeting, I think we need to be careful about how/if this plugin idea > becomes a reality. > - There were questions about whether (if this idea was implemented) it > would be done so a version basis (e.g plugin for IE6, plugin for IE7 > support etc.). I conveyed this is something that might be more feasible > with the GCC work being experimented with, but imo a single oldIE plugin > may be more feasible than maintaining multiple versions. > - About 20% of those that got in touch suggested it would be 2013/2014 > before jQuery would probably consider adopting oldIE support as a plugin > (note: I didn't make any mention of years today, this is from developers > themselves).
> In terms of us being far ahead of the install base, the last time I > checked, many of the top 50 sites are still using older versions of jQuery. > On reaching out to them, some are using pre 1.5 due to worries about > instability whilst others have either a) been unaware they were using older > versions or b) required a poke to get their dev team to work on updating. > An example of a site where this was successful is the Guardian<http://www.guardian.co.uk/>, > who were on 1.4.2 but shifted to 1.6.x. I'm not sure what we can do to > improve adoption of newer versions other than increasing awareness.
> People have mentioned they'd like more advance notice of breaking changes, > but I thought the blog posts Dave (and others) have been doing over the > past few releases were ample for this.
> On Mon, Jan 23, 2012 at 10:17 PM, Dave Methvin <dave.meth...@gmail.com>wrote:
>> We're not getting much of a quorum in the weekly meetings, so I thought >> I'd try to get some discussion started here instead. Sorry it's a bit >> rushed and not as well thought out as I'd like but it seems like Addy's >> tweet gave the wrong impression and I wanted to try and clear things up.
>> More than 60% of jQuery users are currently on version 1.4.x or older:
>> Last year we blazed through three major-point releases that each >> incorporated different subsystem rewrites with dozens of changes and >> feature additions. As is inevitable when you have a large installed base of >> users with code that you couldn't imagine in your worst nightmares, each >> introduced breaking changes.
>> It's possible the concern about things breaking is one of the things that >> has slowed adoption of later versions, but in any case it does seem like >> we're moving very fast compared to their pace. Think about it, more than >> half the people using jQuery aren't using the new $.ajax, Deferreds, or >> attribute rewrite.
>> In addition we're talking about making more changes, some of which are >> likely to break existing code (either intentionally or accidentally) and >> prevent people on previous versions from upgrading. That includes >> deprecating and deleting functionality like $.browser.
>> Instead of making these breaking changes a little bit at a time, I am >> wondering if we should create a stable branch (say 1.x) and go for more >> changes and refactoring in a new branch (say 2.0). This isn't a license to >> rewrite jQuery in a really incompatible way, I think it should stay as >> compatible as possible although might get that compatibility in the form of >> plugins. Also, I'd prefer that if an API is there it retain its semantics. >> I'd rather remove an API totally or make it a plugin because that is a lot >> easier to debug or document than some subtle change.
>> *So as far as old IE support is concerned, the jQuery *project* >> obviously needs to support IE6-8 for several more years. *
>> At some point we will be free of it, however. Remember that Microsoft's >> Extended XP support (e.g., security bugfixes) totally disappears as of >> mid-2014 for example, and that is the source of most IE6-8 users. Companies >> will need to transition off XP by then, unless Microsoft blinks and says >> they'll provide patches for a longer time.
>> If we are going to make big moves in APIs and browser support, it seems >> like the 2.0 version might be the natural place to make it. At the very >> least, start with the assumption that oldIE is not there and make a plugin >> to support it -- or just use 1.x for that case. And now might be the time >> to start planning that, since if we slow the pace for point-releases it's >> likely 2.0 won't arrive until 2013 at the earliest.
>> *But again, the oldIE support issue is just one of many here.*
>> I'm making my own set of assumptions:
>> - Are we moving too fast in versions? >> - Is the fact we're so far ahead of the installed base a problem? >> - Is it too early to plan for jQuery 2.0? >> - Should we just continue to make incremental breaking changes on >> point versions?
> --
> *Addy Osmani*
> Developer at Aol | jQuery Core [Bug Triage/Docs/Learning site] teams > member > Blogger at: http://addyosmani.com
I'm not sure if it's entirely germane to this discussion, but I wanted to just take issue with this assertion:
"More rapid releases means that features land and are pushed out very quickly, which means we often get stuck with features that aren't fully baked. Several of the last few releases introduced a new mechanism for doing event binding (live: 1.3, delegate: 1.4, on: 1.6), which is slowly coalescing towards a sane API. Maybe slowing things down a bit and thinking about the features we were adding would have resulted in less fragmentation."
The fragmentation of the event delegation helpers is *not* a consequence of the rapid release cycle. jQuery 1.3 introduced .live in early 2009. jQuery 1.4.2 introduced .delegate in February of 2010, over a year later. It was only in very *late* 2010, in response to the landing of multiple features (especially the autoconversion of data- to data()) in point releases like 1.4.3 and 1.4.4, that we shifted to the quote-unquote rapid release cycle. Thus, in 2011, we did 3 major releases, and it was only in November 2011, nearly 2 years after .delegate was added, that .on was added to *1.7*.
.delegate was added at the behest of the community, which wanted an event delegation helper that wasn't quite so "magic" as .live. And there was a major sea-change in the development cycle in late 2010, as there was shift to development being driven by the bugs team and with more transparency about how new features were to be decided and added. The reason for having the "major" releases more frequently was so that we could land "new features" without putting them into "maintenance" releases.
All that said, I think that everyone's already on the same page about slowing down the pace of the release pipe, for a variety of reasons, and that 1.8 is probably still at least several months away. I just want to make it clear that the fact that we had a year of rapid releases is not why there's fragmentation in the event delegation helpers - but I do agree that the frequency did somewhat frustrate users anyway. And I also agree with Ben that "upgrading" isn't only concern here; the question isn't how smooth of a path it is to go from 1.3.2 to 1.7.2 in one fell swoop, it's whether the person who never upgraded his site from 1.3.2, when starting a new project, starts with 1.7.2, or because of FUD, sticks with an outdated version.
On Tue, Jan 24, 2012 at 3:11 AM, Yehuda Katz <wyc...@gmail.com> wrote:
> Yehuda Katz > (ph) 718.877.1325
> On Mon, Jan 23, 2012 at 2:17 PM, Dave Methvin <dave.meth...@gmail.com>wrote:
>> We're not getting much of a quorum in the weekly meetings, so I thought >> I'd try to get some discussion started here instead. Sorry it's a bit >> rushed and not as well thought out as I'd like but it seems like Addy's >> tweet gave the wrong impression and I wanted to try and clear things up.
>> More than 60% of jQuery users are currently on version 1.4.x or older:
>> Last year we blazed through three major-point releases that each >> incorporated different subsystem rewrites with dozens of changes and >> feature additions. As is inevitable when you have a large installed base of >> users with code that you couldn't imagine in your worst nightmares, each >> introduced breaking changes.
> I think it's natural to feel that this is a good thing, especially as > Internet projects have been moving towards more frequent releases. However, > I think we need to seriously consider the tradeoffs:
> More rapid releases means that features land and are pushed out very > quickly, which means we often get stuck with features that aren't fully > baked. Several of the last few releases introduced a new mechanism for > doing event binding (live: 1.3, delegate: 1.4, on: 1.6), which is slowly > coalescing towards a sane API. Maybe slowing things down a bit and thinking > about the features we were adding would have resulted in less fragmentation.
> We have trended towards exposing new features designed for internal > refactoring as public APIs (Deferreds, Callbacks, *Hooks), which has > solidified them while we were still learning about them for our own use. > The result is that we are stuck with APIs with a large surface-areas that > aren't particularly related to the core mission of the project, but which > we can't easily revisit. It also required deprecating several initial > features. Longer release cycles and a more conservative approach to new > features would have given us the opportunity to do a release using the > features internally, and then wait a good amount of time before adopting it > whole-hog as a public API.
> Rapid release cycles make it harder to consider significant project > changes that will take more than a few months to accomplish. Moving to a > 1-x-stable/2-0-unstable branch structure will work, but it will essentially > cut the 2.0 branch loose from master, which is probably necessary in order > to consider a project change of this magnitude. Longer release cycles might > allow us to make changes of the magnitude we're discussing here without > splitting the project into 1-x and 2-0 branches.
> - I personally attribute a lot of the success of jQuery long-term to > the fact that we have avoided this kind of divergence. Having participated > in similar types of refactorings in other projects, I am unsure that > splitting jQuery would be good for our long-term success. Among other > things, if jQuery 2.0 is sufficiently different from jQuery 1.x, it will > make it easier for the Zeptos and JQ.Mobis of the world to argue that if > the upgrade cost to jQuery 2.0 is very difficult, and many plugins don't > work, why not try an alternative?
> Rapid release cycles have given a lot of developers the impression that > jQuery is unstable, partially because of API fragmentation (like .bind, > .live, .delegate, .on), and partially for unfair reasons. Upgrading your > browser is transparent -- upgrading jQuery is a potentially expensive > process. The longer people hold off on upgrading jQuery, the harder it gets > (if a 1.4 user didn't upgrade to 1.5 and 1.6 due to fears of instability, > what would make them upgrade to 1.7).
> Rails has been somewhat successful by sticking to a 2ish-year release > cycle for major breaking versions, and 6 months to 1 year for minor version > changes. That is my other major point of reference for a project of this > size, and I feel that shorter release cycles (1-3 months) are mostly > appropriate for bug-fixes and minor improvements, while longer release > cycles (6 months to a year) are appropriate for major new features. This is > mostly due to the time it takes to vet a major new feature and back out of > mistakes.
>> It's possible the concern about things breaking is one of the things that >> has slowed adoption of later versions, but in any case it does seem like >> we're moving very fast compared to their pace. Think about it, more than >> half the people using jQuery aren't using the new $.ajax, Deferreds, or >> attribute rewrite.
> Honestly, I suspect that the vast majority of 1.7 users are using jQuery > 1.7 in a 1.4-compatible way. This is a good thing.
>> In addition we're talking about making more changes, some of which are >> likely to break existing code (either intentionally or accidentally) and >> prevent people on previous versions from upgrading. That includes >> deprecating and deleting functionality like $.browser.
> I have said this before, but I strongly recommend creating a compatibility > plugin for these features that we maintain for the forseeable future and > release with each new version of jQuery. We should run the tests for these > features that shipped with jQuery 1.6 to confirm compatibility.
>> Instead of making these breaking changes a little bit at a time, I am >> wondering if we should create a stable branch (say 1.x) and go for more >> changes and refactoring in a new branch (say 2.0). This isn't a license to >> rewrite jQuery in a really incompatible way,
> I have never seen a statement like this hold true in practice. Once the > branch is forked off, people usually agitate for larger changes than would > have been considered acceptable beforehand. It can be kept under control, > but I would expect that a 2.0 branch would diverge rather rapidly from the > 1.x branch, at least in terms of the internal code.
>> I think it should stay as compatible as possible although might get that >> compatibility in the form of plugins. Also, I'd prefer that if an API is >> there it retain its semantics. I'd rather remove an API totally or make it >> a plugin because that is a lot easier to debug or document than some subtle >> change.
>> *So as far as old IE support is concerned, the jQuery *project* >> obviously needs to support IE6-8 for several more years.*
> It remains to be seen whether IE8 ends up as an albatross around the web's > neck, but I tend to agree that we will eventually be free of this monster.
>> At some point we will be free of it, however. Remember that Microsoft's >> Extended XP support (e.g., security bugfixes) totally disappears as of >> mid-2014 for example, and that is the source of most IE6-8 users. Companies >> will need to transition off XP by then, unless Microsoft blinks and says >> they'll provide patches for a longer time.
>> If we are going to make big moves in APIs and browser support, it seems >> like the 2.0 version might be the natural place to make it. At the very >> least, start with the assumption that oldIE is not there and make a plugin >> to support it -- or just use 1.x for that case. And now might be the time >> to start planning that, since if we slow the pace for point-releases it's >> likely 2.0 won't arrive until 2013 at the earliest.
> It probably makes sense to move oldIE support into a separate file
1. I am okay with a 2.0, but would like to hear what John has to say about it. 2. If we're saying 2.0 could be sometime in 2013, I don't think IE7/8 will have low enough market shares by then. Keep in mind that IE8 is still the #1 browser. 3. Mobile. If I am not mistaken, many of the fixes we provide for IE also apply to mobile browsers. We should keep mobile support in mind. 4. Plugins have never worked well. We may come out with something that is sufficient in providing support for IE, but let's face it, we ain't gonna support it like we support core and if we don't continue to provide 1 working file for everyone, we will probably lose users due to the loss of simplicity. 5. Almost every one of us has said we don't want to maintain 2 jQueries. If we make 2.0 whatever we want, it probably means that the 1.x.x will have to continue to be maintained along with 2.0. It may be worth it, but I'm just throwing that out there as devil's advocate. 6. We are removing a few things in 1.8 and working on reducing its size. We have plans to try modules and closure compiler. Perhaps we should wait until we see how small we can get it with minimal affect on back-compat before considering a 2.0. 7. I have heard several times that we are going too fast for people. They may be upgrading in new projects, but we were going so quickly, I'm sure people were upgrading 2 or 3 or 4 times before they completed one particular project. That can get annoying.
Overall, I am for freezing features for a while and making 1.8 as stable as possible and then reevaluating from there.
A fun challenge: let's build a Fake jQuery 2.0 from nil, but use the current unit tests to implement it - while only concerning ourselves with modern and mobile browsers, but with the exception of IE8. We can do this casually, as a sort of academic exercise, if you will.
On Tue, Jan 24, 2012 at 10:31 AM, Timmy <timmywill...@gmail.com> wrote: > A few points:
> 1. I am okay with a 2.0, but would like to hear what John has to say about > it. > 2. If we're saying 2.0 could be sometime in 2013, I don't think IE7/8 will > have low enough market shares by then. Keep in mind that IE8 is still the > #1 browser. > 3. Mobile. If I am not mistaken, many of the fixes we provide for IE also > apply to mobile browsers. We should keep mobile support in mind. > 4. Plugins have never worked well. We may come out with something that is > sufficient in providing support for IE, but let's face it, we ain't gonna > support it like we support core and if we don't continue to provide 1 > working file for everyone, we will probably lose users due to the loss of > simplicity. > 5. Almost every one of us has said we don't want to maintain 2 jQueries. > If we make 2.0 whatever we want, it probably means that the 1.x.x will have > to continue to be maintained along with 2.0. It may be worth it, but I'm > just throwing that out there as devil's advocate. > 6. We are removing a few things in 1.8 and working on reducing its size. > We have plans to try modules and closure compiler. Perhaps we should wait > until we see how small we can get it with minimal affect on back-compat > before considering a 2.0. > 7. I have heard several times that we are going too fast for people. They > may be upgrading in new projects, but we were going so quickly, I'm sure > people were upgrading 2 or 3 or 4 times before they completed one > particular project. That can get annoying.
> Overall, I am for freezing features for a while and making 1.8 as stable > as possible and then reevaluating from there.
Mike Sherov Lead Programmer SNAP Interactive, Inc. Ticker: STVI.OB
Sent Via Mobile: Please excuse my grammar, tone, and punctuation. My thumbs can't create flowery prose.
On Jan 24, 2012, at 12:46 PM, Rick Waldron <waldron.r...@gmail.com> wrote:
A fun challenge: let's build a Fake jQuery 2.0 from nil, but use the current unit tests to implement it - while only concerning ourselves with modern and mobile browsers, but with the exception of IE8. We can do this casually, as a sort of academic exercise, if you will.
On Tue, Jan 24, 2012 at 10:31 AM, Timmy <timmywill...@gmail.com> wrote: > A few points:
> 1. I am okay with a 2.0, but would like to hear what John has to say about > it. > 2. If we're saying 2.0 could be sometime in 2013, I don't think IE7/8 will > have low enough market shares by then. Keep in mind that IE8 is still the > #1 browser. > 3. Mobile. If I am not mistaken, many of the fixes we provide for IE also > apply to mobile browsers. We should keep mobile support in mind. > 4. Plugins have never worked well. We may come out with something that is > sufficient in providing support for IE, but let's face it, we ain't gonna > support it like we support core and if we don't continue to provide 1 > working file for everyone, we will probably lose users due to the loss of > simplicity. > 5. Almost every one of us has said we don't want to maintain 2 jQueries. > If we make 2.0 whatever we want, it probably means that the 1.x.x will have > to continue to be maintained along with 2.0. It may be worth it, but I'm > just throwing that out there as devil's advocate. > 6. We are removing a few things in 1.8 and working on reducing its size. > We have plans to try modules and closure compiler. Perhaps we should wait > until we see how small we can get it with minimal affect on back-compat > before considering a 2.0. > 7. I have heard several times that we are going too fast for people. They > may be upgrading in new projects, but we were going so quickly, I'm sure > people were upgrading 2 or 3 or 4 times before they completed one > particular project. That can get annoying.
> Overall, I am for freezing features for a while and making 1.8 as stable > as possible and then reevaluating from there.
On Tue, Jan 24, 2012 at 9:52 AM, Mike Sherov <mike.she...@gmail.com> wrote: > I'm in, Rick.
> Mike Sherov > Lead Programmer > SNAP Interactive, Inc. > Ticker: STVI.OB
> Sent Via Mobile: Please excuse my grammar, tone, and punctuation. My > thumbs can't create flowery prose.
> On Jan 24, 2012, at 12:46 PM, Rick Waldron <waldron.r...@gmail.com> wrote:
> A fun challenge: let's build a Fake jQuery 2.0 from nil, but use the > current unit tests to implement it - while only concerning ourselves with > modern and mobile browsers, but with the exception of IE8. We can do this > casually, as a sort of academic exercise, if you will.
> Rick
> On Tue, Jan 24, 2012 at 10:31 AM, Timmy <timmywill...@gmail.com> wrote:
>> A few points:
>> 1. I am okay with a 2.0, but would like to hear what John has to say >> about it. >> 2. If we're saying 2.0 could be sometime in 2013, I don't think IE7/8 >> will have low enough market shares by then. Keep in mind that IE8 is still >> the #1 browser. >> 3. Mobile. If I am not mistaken, many of the fixes we provide for IE also >> apply to mobile browsers. We should keep mobile support in mind. >> 4. Plugins have never worked well. We may come out with something that is >> sufficient in providing support for IE, but let's face it, we ain't gonna >> support it like we support core and if we don't continue to provide 1 >> working file for everyone, we will probably lose users due to the loss of >> simplicity. >> 5. Almost every one of us has said we don't want to maintain 2 jQueries. >> If we make 2.0 whatever we want, it probably means that the 1.x.x will have >> to continue to be maintained along with 2.0. It may be worth it, but I'm >> just throwing that out there as devil's advocate. >> 6. We are removing a few things in 1.8 and working on reducing its size. >> We have plans to try modules and closure compiler. Perhaps we should wait >> until we see how small we can get it with minimal affect on back-compat >> before considering a 2.0. >> 7. I have heard several times that we are going too fast for people. >> They may be upgrading in new projects, but we were going so quickly, I'm >> sure people were upgrading 2 or 3 or 4 times before they completed one >> particular project. That can get annoying.
>> Overall, I am for freezing features for a while and making 1.8 as stable >> as possible and then reevaluating from there.
This is fair. I think my other assertion, that our release cycle has pushed internal APIs into the public API too rapidly, still stands.
Sent from my Windows Phone ------------------------------ From: adam j. sontag Sent: 1/24/2012 7:02 AM To: jquery-bugs-team@googlegroups.com Subject: Re: [jquery-bugs-team] Thoughts on jQuery past and future
I'm not sure if it's entirely germane to this discussion, but I wanted to just take issue with this assertion:
"More rapid releases means that features land and are pushed out very quickly, which means we often get stuck with features that aren't fully baked. Several of the last few releases introduced a new mechanism for doing event binding (live: 1.3, delegate: 1.4, on: 1.6), which is slowly coalescing towards a sane API. Maybe slowing things down a bit and thinking about the features we were adding would have resulted in less fragmentation."
The fragmentation of the event delegation helpers is *not* a consequence of the rapid release cycle. jQuery 1.3 introduced .live in early 2009. jQuery 1.4.2 introduced .delegate in February of 2010, over a year later. It was only in very *late* 2010, in response to the landing of multiple features (especially the autoconversion of data- to data()) in point releases like 1.4.3 and 1.4.4, that we shifted to the quote-unquote rapid release cycle. Thus, in 2011, we did 3 major releases, and it was only in November 2011, nearly 2 years after .delegate was added, that .on was added to *1.7*.
.delegate was added at the behest of the community, which wanted an event delegation helper that wasn't quite so "magic" as .live. And there was a major sea-change in the development cycle in late 2010, as there was shift to development being driven by the bugs team and with more transparency about how new features were to be decided and added. The reason for having the "major" releases more frequently was so that we could land "new features" without putting them into "maintenance" releases.
All that said, I think that everyone's already on the same page about slowing down the pace of the release pipe, for a variety of reasons, and that 1.8 is probably still at least several months away. I just want to make it clear that the fact that we had a year of rapid releases is not why there's fragmentation in the event delegation helpers - but I do agree that the frequency did somewhat frustrate users anyway. And I also agree with Ben that "upgrading" isn't only concern here; the question isn't how smooth of a path it is to go from 1.3.2 to 1.7.2 in one fell swoop, it's whether the person who never upgraded his site from 1.3.2, when starting a new project, starts with 1.7.2, or because of FUD, sticks with an outdated version.
On Tue, Jan 24, 2012 at 3:11 AM, Yehuda Katz <wyc...@gmail.com> wrote:
> Yehuda Katz > (ph) 718.877.1325
> On Mon, Jan 23, 2012 at 2:17 PM, Dave Methvin <dave.meth...@gmail.com>wrote:
>> We're not getting much of a quorum in the weekly meetings, so I thought >> I'd try to get some discussion started here instead. Sorry it's a bit >> rushed and not as well thought out as I'd like but it seems like Addy's >> tweet gave the wrong impression and I wanted to try and clear things up.
>> More than 60% of jQuery users are currently on version 1.4.x or older:
>> Last year we blazed through three major-point releases that each >> incorporated different subsystem rewrites with dozens of changes and >> feature additions. As is inevitable when you have a large installed base of >> users with code that you couldn't imagine in your worst nightmares, each >> introduced breaking changes.
> I think it's natural to feel that this is a good thing, especially as > Internet projects have been moving towards more frequent releases. However, > I think we need to seriously consider the tradeoffs:
> More rapid releases means that features land and are pushed out very > quickly, which means we often get stuck with features that aren't fully > baked. Several of the last few releases introduced a new mechanism for > doing event binding (live: 1.3, delegate: 1.4, on: 1.6), which is slowly > coalescing towards a sane API. Maybe slowing things down a bit and thinking > about the features we were adding would have resulted in less fragmentation.
> We have trended towards exposing new features designed for internal > refactoring as public APIs (Deferreds, Callbacks, *Hooks), which has > solidified them while we were still learning about them for our own use. > The result is that we are stuck with APIs with a large surface-areas that > aren't particularly related to the core mission of the project, but which > we can't easily revisit. It also required deprecating several initial > features. Longer release cycles and a more conservative approach to new > features would have given us the opportunity to do a release using the > features internally, and then wait a good amount of time before adopting it > whole-hog as a public API.
> Rapid release cycles make it harder to consider significant project > changes that will take more than a few months to accomplish. Moving to a > 1-x-stable/2-0-unstable branch structure will work, but it will essentially > cut the 2.0 branch loose from master, which is probably necessary in order > to consider a project change of this magnitude. Longer release cycles might > allow us to make changes of the magnitude we're discussing here without > splitting the project into 1-x and 2-0 branches.
> - I personally attribute a lot of the success of jQuery long-term to > the fact that we have avoided this kind of divergence. Having participated > in similar types of refactorings in other projects, I am unsure that > splitting jQuery would be good for our long-term success. Among other > things, if jQuery 2.0 is sufficiently different from jQuery 1.x, it will > make it easier for the Zeptos and JQ.Mobis of the world to argue that if > the upgrade cost to jQuery 2.0 is very difficult, and many plugins don't > work, why not try an alternative?
> Rapid release cycles have given a lot of developers the impression that > jQuery is unstable, partially because of API fragmentation (like .bind, > .live, .delegate, .on), and partially for unfair reasons. Upgrading your > browser is transparent -- upgrading jQuery is a potentially expensive > process. The longer people hold off on upgrading jQuery, the harder it gets > (if a 1.4 user didn't upgrade to 1.5 and 1.6 due to fears of instability, > what would make them upgrade to 1.7).
> Rails has been somewhat successful by sticking to a 2ish-year release > cycle for major breaking versions, and 6 months to 1 year for minor version > changes. That is my other major point of reference for a project of this > size, and I feel that shorter release cycles (1-3 months) are mostly > appropriate for bug-fixes and minor improvements, while longer release > cycles (6 months to a year) are appropriate for major new features. This is > mostly due to the time it takes to vet a major new feature and back out of > mistakes.
>> It's possible the concern about things breaking is one of the things that >> has slowed adoption of later versions, but in any case it does seem like >> we're moving very fast compared to their pace. Think about it, more than >> half the people using jQuery aren't using the new $.ajax, Deferreds, or >> attribute rewrite.
> Honestly, I suspect that the vast majority of 1.7 users are using jQuery > 1.7 in a 1.4-compatible way. This is a good thing.
>> In addition we're talking about making more changes, some of which are >> likely to break existing code (either intentionally or accidentally) and >> prevent people on previous versions from upgrading. That includes >> deprecating and deleting functionality like $.browser.
> I have said this before, but I strongly recommend creating a compatibility > plugin for these features that we maintain for the forseeable future and > release with each new version of jQuery. We should run the tests for these > features that shipped with jQuery 1.6 to confirm compatibility.
>> Instead of making these breaking changes a little bit at a time, I am >> wondering if we should create a stable branch (say 1.x) and go for more >> changes and refactoring in a new branch (say 2.0). This isn't a license to >> rewrite jQuery in a really incompatible way,
> I have never seen a statement like this hold true in practice. Once the > branch is forked off, people usually agitate for larger changes than would > have been considered acceptable beforehand. It can be kept under control, > but I would expect that a 2.0 branch would diverge rather rapidly from the > 1.x branch, at least in terms of the internal code.
>> I think it should stay as compatible as possible although might get that >> compatibility in the form of plugins. Also, I'd prefer that if an API is >> there it retain its semantics. I'd rather remove an API totally or make it >> a plugin because that is a lot easier to debug or document than some subtle >> change.
>> *So as far as old IE support is concerned, the jQuery *project* >> obviously needs to support IE6-8 for several more years.*
> It remains to be seen whether IE8 ends up as an albatross around the web's > neck, but I tend to agree that we will eventually be free of this monster.
>> At some point we will be free of it, however. Remember that Microsoft's >> Extended XP support (e.g., security bugfixes) totally disappears as of >> mid-2014 for example, and that is the source of most IE6-8 users. Companies >> will need to transition off XP by then, unless Microsoft blinks and says >> they'll provide patches for a longer time.
>> If we are going to make big moves in APIs and browser support, it seems >> like the 2.0 version might be the natural place to make it. At the very >> least, start
Btw, to clarify... I'm not married to the IE8 support. I only included it to preemptively satisfy any notions from others that jQuery will need to support IE8. Take it or leave it.
The point was that we have nearly 6000 unit tests to guide us to in makng a completely semantics compatible API design.
On Tue, Jan 24, 2012 at 1:05 PM, Dan Heberden <danheber...@gmail.com> wrote: > FUNQUERY2012
> On Tue, Jan 24, 2012 at 9:52 AM, Mike Sherov <mike.she...@gmail.com>wrote:
>> I'm in, Rick.
>> Mike Sherov >> Lead Programmer >> SNAP Interactive, Inc. >> Ticker: STVI.OB
>> Sent Via Mobile: Please excuse my grammar, tone, and punctuation. My >> thumbs can't create flowery prose.
>> On Jan 24, 2012, at 12:46 PM, Rick Waldron <waldron.r...@gmail.com> >> wrote:
>> A fun challenge: let's build a Fake jQuery 2.0 from nil, but use the >> current unit tests to implement it - while only concerning ourselves with >> modern and mobile browsers, but with the exception of IE8. We can do this >> casually, as a sort of academic exercise, if you will.
>> Rick
>> On Tue, Jan 24, 2012 at 10:31 AM, Timmy <timmywill...@gmail.com> wrote:
>>> A few points:
>>> 1. I am okay with a 2.0, but would like to hear what John has to say >>> about it. >>> 2. If we're saying 2.0 could be sometime in 2013, I don't think IE7/8 >>> will have low enough market shares by then. Keep in mind that IE8 is still >>> the #1 browser. >>> 3. Mobile. If I am not mistaken, many of the fixes we provide for IE >>> also apply to mobile browsers. We should keep mobile support in mind. >>> 4. Plugins have never worked well. We may come out with something that >>> is sufficient in providing support for IE, but let's face it, we ain't >>> gonna support it like we support core and if we don't continue to provide 1 >>> working file for everyone, we will probably lose users due to the loss of >>> simplicity. >>> 5. Almost every one of us has said we don't want to maintain 2 jQueries. >>> If we make 2.0 whatever we want, it probably means that the 1.x.x will have >>> to continue to be maintained along with 2.0. It may be worth it, but I'm >>> just throwing that out there as devil's advocate. >>> 6. We are removing a few things in 1.8 and working on reducing its size. >>> We have plans to try modules and closure compiler. Perhaps we should wait >>> until we see how small we can get it with minimal affect on back-compat >>> before considering a 2.0. >>> 7. I have heard several times that we are going too fast for people. >>> They may be upgrading in new projects, but we were going so quickly, I'm >>> sure people were upgrading 2 or 3 or 4 times before they completed one >>> particular project. That can get annoying.
>>> Overall, I am for freezing features for a while and making 1.8 as stable >>> as possible and then reevaluating from there.
Rick, just keep in mind that many of those unit tests were written after-the-fact to provide API coverage, and aren't necessarily indicative of what a "jQuery 2.0" API should be.
- Ben
On Tue, Jan 24, 2012 at 1:08 PM, Rick Waldron <waldron.r...@gmail.com>wrote:
> Btw, to clarify... I'm not married to the IE8 support. I only included it > to preemptively satisfy any notions from others that jQuery will need to > support IE8. Take it or leave it.
> The point was that we have nearly 6000 unit tests to guide us to in makng > a completely semantics compatible API design.
> Rick
> On Tue, Jan 24, 2012 at 1:05 PM, Dan Heberden <danheber...@gmail.com>wrote:
>> FUNQUERY2012
>> On Tue, Jan 24, 2012 at 9:52 AM, Mike Sherov <mike.she...@gmail.com>wrote:
>>> I'm in, Rick.
>>> Mike Sherov >>> Lead Programmer >>> SNAP Interactive, Inc. >>> Ticker: STVI.OB
>>> Sent Via Mobile: Please excuse my grammar, tone, and punctuation. My >>> thumbs can't create flowery prose.
>>> On Jan 24, 2012, at 12:46 PM, Rick Waldron <waldron.r...@gmail.com> >>> wrote:
>>> A fun challenge: let's build a Fake jQuery 2.0 from nil, but use the >>> current unit tests to implement it - while only concerning ourselves with >>> modern and mobile browsers, but with the exception of IE8. We can do this >>> casually, as a sort of academic exercise, if you will.
>>> Rick
>>> On Tue, Jan 24, 2012 at 10:31 AM, Timmy <timmywill...@gmail.com> wrote:
>>>> A few points:
>>>> 1. I am okay with a 2.0, but would like to hear what John has to say >>>> about it. >>>> 2. If we're saying 2.0 could be sometime in 2013, I don't think IE7/8 >>>> will have low enough market shares by then. Keep in mind that IE8 is still >>>> the #1 browser. >>>> 3. Mobile. If I am not mistaken, many of the fixes we provide for IE >>>> also apply to mobile browsers. We should keep mobile support in mind. >>>> 4. Plugins have never worked well. We may come out with something that >>>> is sufficient in providing support for IE, but let's face it, we ain't >>>> gonna support it like we support core and if we don't continue to provide 1 >>>> working file for everyone, we will probably lose users due to the loss of >>>> simplicity. >>>> 5. Almost every one of us has said we don't want to maintain 2 >>>> jQueries. If we make 2.0 whatever we want, it probably means that the 1.x.x >>>> will have to continue to be maintained along with 2.0. It may be worth it, >>>> but I'm just throwing that out there as devil's advocate. >>>> 6. We are removing a few things in 1.8 and working on reducing its >>>> size. We have plans to try modules and closure compiler. Perhaps we should >>>> wait until we see how small we can get it with minimal affect on >>>> back-compat before considering a 2.0. >>>> 7. I have heard several times that we are going too fast for people. >>>> They may be upgrading in new projects, but we were going so quickly, I'm >>>> sure people were upgrading 2 or 3 or 4 times before they completed one >>>> particular project. That can get annoying.
>>>> Overall, I am for freezing features for a while and making 1.8 as >>>> stable as possible and then reevaluating from there.
While it's true that most of the tests were written after the fact, I'm trying to establish them as the tests that will test drive the development of an API that has semantic design compatibility
On Tue, Jan 24, 2012 at 1:44 PM, Ben Alman <cow...@rj3.net> wrote: > Rick, just keep in mind that many of those unit tests were written > after-the-fact to provide API coverage, and aren't necessarily indicative > of what a "jQuery 2.0" API should be.
> - Ben
> On Tue, Jan 24, 2012 at 1:08 PM, Rick Waldron <waldron.r...@gmail.com>wrote:
>> Btw, to clarify... I'm not married to the IE8 support. I only included it >> to preemptively satisfy any notions from others that jQuery will need to >> support IE8. Take it or leave it.
>> The point was that we have nearly 6000 unit tests to guide us to in makng >> a completely semantics compatible API design.
>> Rick
>> On Tue, Jan 24, 2012 at 1:05 PM, Dan Heberden <danheber...@gmail.com>wrote:
>>> FUNQUERY2012
>>> On Tue, Jan 24, 2012 at 9:52 AM, Mike Sherov <mike.she...@gmail.com>wrote:
>>>> I'm in, Rick.
>>>> Mike Sherov >>>> Lead Programmer >>>> SNAP Interactive, Inc. >>>> Ticker: STVI.OB
>>>> Sent Via Mobile: Please excuse my grammar, tone, and punctuation. My >>>> thumbs can't create flowery prose.
>>>> On Jan 24, 2012, at 12:46 PM, Rick Waldron <waldron.r...@gmail.com> >>>> wrote:
>>>> A fun challenge: let's build a Fake jQuery 2.0 from nil, but use the >>>> current unit tests to implement it - while only concerning ourselves with >>>> modern and mobile browsers, but with the exception of IE8. We can do this >>>> casually, as a sort of academic exercise, if you will.
>>>> Rick
>>>> On Tue, Jan 24, 2012 at 10:31 AM, Timmy <timmywill...@gmail.com> wrote:
>>>>> A few points:
>>>>> 1. I am okay with a 2.0, but would like to hear what John has to say >>>>> about it. >>>>> 2. If we're saying 2.0 could be sometime in 2013, I don't think IE7/8 >>>>> will have low enough market shares by then. Keep in mind that IE8 is still >>>>> the #1 browser. >>>>> 3. Mobile. If I am not mistaken, many of the fixes we provide for IE >>>>> also apply to mobile browsers. We should keep mobile support in mind. >>>>> 4. Plugins have never worked well. We may come out with something that >>>>> is sufficient in providing support for IE, but let's face it, we ain't >>>>> gonna support it like we support core and if we don't continue to provide 1 >>>>> working file for everyone, we will probably lose users due to the loss of >>>>> simplicity. >>>>> 5. Almost every one of us has said we don't want to maintain 2 >>>>> jQueries. If we make 2.0 whatever we want, it probably means that the 1.x.x >>>>> will have to continue to be maintained along with 2.0. It may be worth it, >>>>> but I'm just throwing that out there as devil's advocate. >>>>> 6. We are removing a few things in 1.8 and working on reducing its >>>>> size. We have plans to try modules and closure compiler. Perhaps we should >>>>> wait until we see how small we can get it with minimal affect on >>>>> back-compat before considering a 2.0. >>>>> 7. I have heard several times that we are going too fast for people. >>>>> They may be upgrading in new projects, but we were going so quickly, I'm >>>>> sure people were upgrading 2 or 3 or 4 times before they completed one >>>>> particular project. That can get annoying.
>>>>> Overall, I am for freezing features for a while and making 1.8 as >>>>> stable as possible and then reevaluating from there.
> While it's true that most of the tests were written after the fact, I'm > trying to establish them as the tests that will test drive the development > of an API that has semantic design compatibility
> Rick
> On Tue, Jan 24, 2012 at 1:44 PM, Ben Alman <cow...@rj3.net> wrote:
>> Rick, just keep in mind that many of those unit tests were written >> after-the-fact to provide API coverage, and aren't necessarily indicative >> of what a "jQuery 2.0" API should be.
>> - Ben
>> On Tue, Jan 24, 2012 at 1:08 PM, Rick Waldron <waldron.r...@gmail.com>wrote:
>>> Btw, to clarify... I'm not married to the IE8 support. I only included >>> it to preemptively satisfy any notions from others that jQuery will need to >>> support IE8. Take it or leave it.
>>> The point was that we have nearly 6000 unit tests to guide us to in >>> makng a completely semantics compatible API design.
>>> Rick
>>> On Tue, Jan 24, 2012 at 1:05 PM, Dan Heberden <danheber...@gmail.com>wrote:
>>>> FUNQUERY2012
>>>> On Tue, Jan 24, 2012 at 9:52 AM, Mike Sherov <mike.she...@gmail.com>wrote:
>>>>> I'm in, Rick.
>>>>> Mike Sherov >>>>> Lead Programmer >>>>> SNAP Interactive, Inc. >>>>> Ticker: STVI.OB
>>>>> Sent Via Mobile: Please excuse my grammar, tone, and punctuation. My >>>>> thumbs can't create flowery prose.
>>>>> On Jan 24, 2012, at 12:46 PM, Rick Waldron <waldron.r...@gmail.com> >>>>> wrote:
>>>>> A fun challenge: let's build a Fake jQuery 2.0 from nil, but use the >>>>> current unit tests to implement it - while only concerning ourselves with >>>>> modern and mobile browsers, but with the exception of IE8. We can do this >>>>> casually, as a sort of academic exercise, if you will.
>>>>> Rick
>>>>> On Tue, Jan 24, 2012 at 10:31 AM, Timmy <timmywill...@gmail.com>wrote:
>>>>>> A few points:
>>>>>> 1. I am okay with a 2.0, but would like to hear what John has to say >>>>>> about it. >>>>>> 2. If we're saying 2.0 could be sometime in 2013, I don't think IE7/8 >>>>>> will have low enough market shares by then. Keep in mind that IE8 is still >>>>>> the #1 browser. >>>>>> 3. Mobile. If I am not mistaken, many of the fixes we provide for IE >>>>>> also apply to mobile browsers. We should keep mobile support in mind. >>>>>> 4. Plugins have never worked well. We may come out with something >>>>>> that is sufficient in providing support for IE, but let's face it, we ain't >>>>>> gonna support it like we support core and if we don't continue to provide 1 >>>>>> working file for everyone, we will probably lose users due to the loss of >>>>>> simplicity. >>>>>> 5. Almost every one of us has said we don't want to maintain 2 >>>>>> jQueries. If we make 2.0 whatever we want, it probably means that the 1.x.x >>>>>> will have to continue to be maintained along with 2.0. It may be worth it, >>>>>> but I'm just throwing that out there as devil's advocate. >>>>>> 6. We are removing a few things in 1.8 and working on reducing its >>>>>> size. We have plans to try modules and closure compiler. Perhaps we should >>>>>> wait until we see how small we can get it with minimal affect on >>>>>> back-compat before considering a 2.0. >>>>>> 7. I have heard several times that we are going too fast for people. >>>>>> They may be upgrading in new projects, but we were going so quickly, I'm >>>>>> sure people were upgrading 2 or 3 or 4 times before they completed one >>>>>> particular project. That can get annoying.
>>>>>> Overall, I am for freezing features for a while and making 1.8 as >>>>>> stable as possible and then reevaluating from there.
>>>>>> - Timmy
-- Mike Sherov Lead Developer SNAP Interactive, Inc. Ticker: STVI.OB
Sorry but once again I'm pressed for time so I can't compose a complete reply. I do have a few thoughts to add for now.
Here's the version issue from another perspective: If you believe those stats from above, more than 90% of jQuery sites are currently running an unsupported version of jQuery. More than half are running jQuery 1.4.x or older. This includes top-50 sites as well; amazon.com is using jQuery 1.2.6, craigslist.org, msn.com and imdb.com are using 1.4.2.
Sites could be holding back for many reasons -- incompatible plugins, waiting for their next big redesign, irrational fear, or most likely just lack of a good excuse to switch -- but they CAN hold back and not be suffering. If you were amazon.com, would you switch out a 55KB minified jQuery 1.2.6 for a 92KB 1.7.1? From what I can tell they've added their own code to deal with some mobile Safari position() issues, so it seems they'd *actively* rather patch than switch.
With that in mind, what are the pain points for users? What problems are they having that aren't fixed by the current code? Are they performance issues, size issues, stupidities in our API semantics, missing features, or what?
> With that in mind, what are the pain points for users? What problems are > they having that aren't fixed by the current code? Are they performance > issues, size issues, stupidities in our API semantics, missing features, or > what?
Although somewhat succinct answers to these questions should be appearing in the call for proposals done before each major version, perhaps what's needed is a survey done across our user-base over a prolonged period of time. Some may deem it unnecessary or over-simplistic, however I think there's a great deal to learn from questions like:
- What company do you work for? - What version of jQuery are you/your team using? - If not the latest version, why haven't you upgraded? [incompatible plugins] [instability] [unneeded] - How would you like to see jQuery change? [smaller size] [modularity/optimized builds] [etc etc] [other] - Have you been looking at other solutions and if so, why? [size] [optimized for mobile] [etc etc]
We can derive hypothesis about why amazon may be using jQuery 1.2.6 in production but not reach out and start asking them instead? That is of course unless we're happy to assume those content with a stable, existing solution are not our target audience for future releases and should instead be focusing on active users who are more regularly interested in considering upgrades.
