One of the things I really want to see is both IE and Safari move to the six weekly update cycle that Firefox and Chrome are using.
Whereas I would really like IE not to do that, and ideally Firefox and Chrome to move to longer cycles (minimum 6 months, preferably annual) for their main public releases.
One good reason for this is that there is no point in having browsers support new features within moments of someone conceiving them unless developers are also keeping up with new developments at the same pace. Take three major browsers on a six-weekly cycle and you literally need to be updating your skill set every two weeks and have projects to work on where those new skills are actually useful. Unless all you do is write trendy web development blogs for a living, you are not likely to be in this category.
Another good reason is that both Firefox and Chrome have horrible records for quality since going to six-weekly release cycles, both in terms of bugs/regressions and because they frequently implement new features that tick boxes but have such poor quality of implementation that they aren't actually useful for production work anyway. For example, right now, both Firefox and Chrome have numerous glitches and performance problems in popular HTML/CSS features like animations, web fonts, multimedia elements, and SVG, to the extent that you can't reliably assume even relatively simple applications will work without extensive and ongoing testing.
Recent versions of IE stand in sharp contrast to that pattern, and as such I think IE now provides both a valuable brake on the industry and a demonstration that having a solid, fast implementation of some features is far more useful in practice than having unreliable and/or slow implementations of more features.
(Edit: It's disappointing to see multiple downvotes yet no responses. This happens all too often when I express the unpopular-but-based-on-hard-data view that Firefox and Chrome are often slow and/or buggy when it comes to new features, even though numerous articles and blog posts giving specific examples in the areas I mentioned are yours to read for the price of a Google search.)
Most Chrome and Firefox releases (in my experience) have been relatively minor, and focused on security and bugs. Lets take a look at the last 4 releases of Chrome:
What argument could be made that longer release cycles would mean less bugs? Is there going to be better QA? More stringent testing? Why would shorter release cycles mean less testing?
No, longer release cycles would mean similar number of bugs, and security holes would just sit out there longer. Chrome and Firefox is an example of doing it right.
Most Chrome and Firefox releases (in my experience) have been relatively minor, and focused on security and bugs.
Serious security issues should be fixed as soon as possible anyway. This has absolutely nothing to do with a regular schedule for planned releases, and all of the major browser developers will already issue an immediate out-of-band update for a sufficiently dangerous vulnerability.
What argument could be made that longer release cycles would mean less bugs?
Well, for one thing, you can't regress something if you don't change it. Both Firefox and Chrome typically introduce a bunch of breaking changes every update. Sometimes these are unintentional bugs. Sometimes they are deliberate policy decisions, and in this case newer features are at far greater risk of backward-incompatible changes, as with the CSS syntax and multimedia controls examples I mentioned in another post to this thread.
The thing is, if your site/app used to work and it doesn't work any more after your customer updated their browser, and now you're getting paged in the early hours to be second/third tier support, it is highly unlikely that you care about niceties like whether the browser developers consider the change to be desirable. So if nothing else, every time every browser pushes out a major update, a lot of people building sites or apps need to be testing that their own projects still work, which is clearly a much greater overhead if you do it eight or nine times per browser per year than if you only have to do it once or twice.
You can, but you still have to test against N different versions per year instead of 1, which is still an N-fold increase in testing overhead compared to annual releases.
You can automate some aspects of that testing to reduce the burden. However, in the nature of web sites, some things will always need manual examination. No unit test is going to tell you that Chrome has a layout bug where your element that is styled to have a 100px width is being calculated at width 50px anyway and your entire home page doesn't render properly as a result, nor that resizing a responsive page in Firefox so it satisfies different media queries and then changing it back to the original size might result in a different layout (both real examples I've personally seen in recent months, BTW).
I'll give you an upvote because I hear what you're saying; keeping up with new browser features is tough if you've got other things to do as well. But, you don't need to incorporate every new feature into your own web projects, and you don't need to follow the same rapid release cycle as the browsers.
If my project has an annual update cycle, I want to be certain that any new browser features I'd like to use are widely supported and have been tested in-the-wild for as long as possible before I commit to them. The rapid release cycles of the browsers gives me that, and also ensures that there will be blogs and StackOverflow questions providing useful documentation on the best ways to use the new features by the time I'm ready to learn about them.
But, you don't need to incorporate every new feature into your own web projects, and you don't need to follow the same rapid release cycle as the browsers.
Sure, but then if the features aren't going to be incorporated into new projects almost immediately, browsers don't need to push out new releases (and the attendant risk of regressions) every few weeks either. The biggest claimed advantage of the rapid release cycles doesn't stand up to scrutiny.
If my project has an annual update cycle, I want to be certain that any new browser features I'd like to use are widely supported and have been tested in-the-wild for as long as possible before I commit to them.
That seems perfectly reasonable to me. Unfortunately, I think it's also reasonable to assume that lots of other people who might be interested in that same feature will behave the same way. It's therefore not reasonable to assume that those new features have in fact been thoroughly tested in-the-wild before you rely on them.
A related concern is that with the very rapid release cycles, you never really know when an implementation is "final". We've seen fundamental changes over recent years in everything from the syntax for new CSS features to the layout of controls on multimedia elements, sometimes more than once in the same browser within a few months of each other. At least if you ship functionality updates several months apart you offer a degree of definitive behaviour and stability.
also ensures that there will be blogs and StackOverflow questions providing useful documentation on the best ways to use the new features by the time I'm ready to learn about them.
It seems you've had better luck than me. I frequently find that when we run into issues with relatively recent developments in browsers, there are a handful of other people writing blog posts or writing SO questions that show we're not alone, but no-one actually has the answer.
It's also worth considering that just because the main production release of a browser only updates, say, annually, that doesn't necessarily mean that the browser can't also have developer releases going out more regularly for those who want to experiment with new features.
Valid points. I think each new feature will likely interest a different set of developers, so the feature can still get pretty wide testing even if a lot of developers choose to wait for it to mature, or choose not to use it at all.
I do agree with your points about the rapid release of browser bugs alongside the new features. I've had multiple occasions where clients have told me "You changed something and broke the site" on a project I haven't been working on, only to find out it's only broken in Chrome. My response to them that it's a bug in Chrome that's been reported, affects lots of websites, and will probably be fixed in a few days/weeks, and there's little or nothing I can do about it, is never satisfying.
Chrome and Firefox don't support features within moments of someone conceiving them. I've seen discussions about what features will be coming to Chrome in the future - rarely does a feature take less than six months to go from idea to stable implementation in Chrome. Firefox is a little different because Mozilla is pumping APIs into Firefox OS and then moving them to the main Firefox browser.
IE has issues with implementations even with their slow release cycle, as does Safari. While in theory a quicker release cycle probably should result in less stability and more bugs, there doesn't really seem to be this correlation in practice. A good way to check this out is to have a look at caniuse.com and see which browsers have issues with feature implementations (although caniuse is lagging behind a bit of recent). IE, Firefox, Chrome and Safari will all have issues. To Apple's credit, Safari is the only browser which seems to be willing to regularly remove buggy features.
While in theory a quicker release cycle probably should result in less stability and more bugs, there doesn't really seem to be this correlation in practice.
Anecdotally, the bug tracker for every major project I currently work on would disagree. That's a fair range of projects, using very different sets of browser features but including quite a few relatively recent developments.
A good way to check this out is to have a look at caniuse.com and see which browsers have issues with feature implementations
Caniuse is great, but it's not even close to the level of detail I'm talking about here. For example, it currently lists no known issues with HTML5 video elements, where IIRC one project I work on that uses that feature extensively was tracking 17 related open issues as of a few days ago, including at least one for every major browser.
When I write about that kind of experience, I sometimes get asked why we don't do more to support the browser developers by filing detailed bug reports when we find these issues. Sadly, the answer is simple: the projects I work on all have relatively small teams and would literally have to hire another full time employee just to report browser bugs, because we find that many. And a heavy majority of them are in Firefox or Chrome.
Whereas I would really like IE not to do that, and ideally Firefox and Chrome to move to longer cycles (minimum 6 months, preferably annual) for their main public releases.
One good reason for this is that there is no point in having browsers support new features within moments of someone conceiving them unless developers are also keeping up with new developments at the same pace. Take three major browsers on a six-weekly cycle and you literally need to be updating your skill set every two weeks and have projects to work on where those new skills are actually useful. Unless all you do is write trendy web development blogs for a living, you are not likely to be in this category.
Another good reason is that both Firefox and Chrome have horrible records for quality since going to six-weekly release cycles, both in terms of bugs/regressions and because they frequently implement new features that tick boxes but have such poor quality of implementation that they aren't actually useful for production work anyway. For example, right now, both Firefox and Chrome have numerous glitches and performance problems in popular HTML/CSS features like animations, web fonts, multimedia elements, and SVG, to the extent that you can't reliably assume even relatively simple applications will work without extensive and ongoing testing.
Recent versions of IE stand in sharp contrast to that pattern, and as such I think IE now provides both a valuable brake on the industry and a demonstration that having a solid, fast implementation of some features is far more useful in practice than having unreliable and/or slow implementations of more features.
(Edit: It's disappointing to see multiple downvotes yet no responses. This happens all too often when I express the unpopular-but-based-on-hard-data view that Firefox and Chrome are often slow and/or buggy when it comes to new features, even though numerous articles and blog posts giving specific examples in the areas I mentioned are yours to read for the price of a Google search.)