Aggressive reduction in browser compatibility

[fortes]

Note: Just an idea at this point, but something to consider.

We can vastly simplify code and improve performance with a few minimum browser requirements. Here are some ideas in additive order (also roughly in order of contention):

1. document.querySelectorAll: Cuts IE7-, Firefox 3-, Opera 10-
2. window.localStorage: Cuts Safari 3.2-, Opera 10.5
3. window.JSON: Cuts iOS 3.2-
4. HashChange event: Cuts Safari 4-, Opera Mobile 10-, Opera Mini
5. W3C Event Model: Cuts IE8
6. CSS3 Transforms: No new cuts!
7. <audio> element: Android 2.2-
8. element.matchesSelector: Cuts Opera 11.1-, Opera Mobile 11-
9. CSS3 Transitions: Cuts IE9
10. window.pushState: Cuts Firefox 3.6-, iOS 4.2-

At this point, with IE7 two versions behind, I don't think there's much contention in numbers 1 and 2 -- all other browsers cut at that level are also at least two versions behind as well. Not sure about iOS upgrade rates, but the first few generations of iPhones and iPods are stuck on 3.2 for perpetuity it seems. Not sure how big the market is, but this may not be something worth worrying about too much.

Moving to level 3 gives us the following native browser features:

• querySelectorAll: Having a fast, native implementation of this is incredibly useful
• localStorage: Incredibly useful for mobile and offline scenarios -- but does come with performance cost
• Native JSON support: Key for storing info in localStorage
• Data URLs: For baking in loading assets/animations
• Native Array helper functions
• A few features useful for designers:
  • CSS inline-block
  • CSS generated content
  • CSS box-sizing
  • CSS table display

The riskiest move would be cutting support for IE8, the most popular desktop browser. However, as of right now Treesaver is mostly used in mobile devices, as well as recent browsers. IE8 numbers will only go down, although it will be the final IE that is supported in XP (those users can of course still get Chrome). Cutting Android below 2.3 may be risky as well, since carriers don't do a great job of upgrading sometimes.

Moving to level 7 gives us the following guaranteed features:

• Single event model, with reliable firing of custom events and event propagation
• CSS3 transform support
• <video> and <audio> elements
• No need for HTML5 shiv
• matchesSelector: Could help with event delegation
• DOMContentLoaded event
• Features for designers/devs:
  • Geolocation
  • CSS3 colors (rgb, hsla, etc)
  • CSS3 border-radius
  • CSS3 box-shadow
  • CSS3 background-image

I think cutting IE9 in order to get CSS3 Transitions is a step too far. Eliminating the most recent version of IE is unnecessary.

[scottkellum]

I think adopting what Google has is the right idea: http://googleenterprise.blogspot.com/2011/06/our-plans-to-support-modern-browsers.html

It's so nice as devs to force people to upgrade so without a clear rule its easy to get carried away.

[fortes]

Following Google's lead would be equivalent of level 1, maybe 3 depending on how you want to define Safari/Mobile Safari versions.

[scottkellum]

iOS 5 is coming out soon enough to support 4 +. Hopefully by the time the code is launched we will be within our rules.

Android and FF are tricky. Android due to fragmentation, every .x release comes with major changes. Firefox because they just changed to a fast versioning cycle.

[bramstein]

I've dusted off my noie7 branch just for this occasion:

https://github.com/bramstein/treesaver/compare/master...noie7

I'm all for dropping 1-3.

[bramstein]

Just to clarify, that branch only removes IE7/legacy support. It does not rewrite things to use faster paths.

[fortes]

Yes, I think some targeted refactoring is where we stand to gain the most. Will help with code size as well.

[fortes]

Took an initial stab at this: https://github.com/fortes/treesaver/tree/no-legacy

It's still shallow, but as of now we've dropped 10% off of the compiled file size (~65K down to 59K, minified not gzipped).

These are the quick and easy optimizations, there are still some other areas to think about.

[bramstein]

Awesome, that really cleans things up. Any idea about when you'll merge it into master?

[fortes]

Need to do some testing, but will try to do it soon so the merge isn't painful.

Try not to keep too many commits local on your machine, otherwise you're stuck doing some merging :)

[fortes]

The no-legacy branch in my fork cuts up to number 6. Things aren't completely optimized yet, but it does simplify a lot of things and the file size reduction is nice. Haven't profiled yet though.

I think this is the way forward for Treesaver, it'll free us from a bunch of browser compatibility bugs and work, and let us do some more interesting features, instead of trying to support browsers whose market share is only dropping.

I'd like to merge this into master soon, any objections?

[bramstein]

Which level are we at now? I was just looking into a bug report for IE8, but then found out we don't support it any longer. Do we plan some sort of compatibility plugin for IE8, or is it just plain out? IE8's market share is still fairly sizable...

[gilbert]

I was under the impression that Treesaver's greatest strength was looking great on any device, which would include cross-browser compatibility.

Right now I'm evaluating Treesaver as potentially being the primary method of publishing our online magazine content. If IE8 is going to be cut, I can't consider Treesaver a viable candidate.

[scottkellum]

@mindeavor We are weighing the browser support vs speed and functionality. I agree IE8 may be too agressive but IE8 users will still be able to view your content as a traditional scrolling site. Users can still view content on ANY device with a web browser, it is just a question of who gets the best experience and IE8 is holding other browsers back.

You may notice that you can still compile Treesaver with legacy support, it is just removed from the standard package.

[scottkellum]

We need to brink IE8 back. Other than that lets discuss closing this issue.

[andreacampi]

Looks like we are at level 6 now.

Beyond that:

• I'm not sure we should cut Android 2.2 just yet, there are quite a few out there. OTOH there are known issues with it;
• element.matchesSelector would be nice, but we don't use it yet so there's no point requiring it;
• we absolutely can't cut IE9;
• there are some edge cases around window.pushState that we are investigating on Android.

All this considered, I'm leaning towards letting things stand as they are and closing this issue soon.