How old are we targetting?
Check these stats out:
http://www.w3schools.com/browsers/browsers_stats.asp
http://www.w3schools.com/browsers/browsers_explorer.asp
I think we should target no earlier than IE 11. If people want to target earlier browsers, they can use another library other than ours. That’s how it was when Three.js was started. People knew they could target only browsers that had WebGL. Now they all do (starting from IE11). I think IE11 is a good target (Firefox and Chrome are ahead, no need to worry there). IE11’s DOM transforms are nothing but jank, but at least users can use (with some exceptions) WebGL things smoothly in there.
That might be true for IE users, but less so for Firefox users, and much less so for Chromium users:
http://www.w3schools.com/browsers/browsers_firefox.asp
http://www.w3schools.com/browsers/browsers_chrome.asp
And Chrome has the largest market share, so most of those users are always up to date. You all know how good Chrome is at keeping itself updated. I think it’s safe to assume that if we’re making the library that we are, there will be some users that simply won’t be able to experience the awesomeness. I personally can live with that. Those users aren’t the types of people who’d be interested in using the products we’re going to make anyways. “You gotta pay to play”. They want awesome? They’ll upgrade. The laggers aren’t the target audience, because our products won’t be lagging products. Who knows, by the time the library is rock solid, there may be many more Edge users (hopefully).
But besides that, I don’t think ES6 classes will be much a performance hit for our target audience (people who do, because they’re not gonna experience awesome without some self initiative to update to IE11+ or install a new browser until Edge becomes normal for Windows users). We can work within our means, and using ES6 classes will let us write cleaner, better code.
Which people are going to say that? The laggers?.. So?.. Those people aren’t going to care to even look at our demos. If they are people who would care to look at our demos, they’d be 99.99999% likely to care about using a better browser as well (or would at least be 99.99999% persuadable to switch over if we include a simple message on the site that tells them their experience will be better if they switch). And even if they didn’t, when they eventually make the switch, they’ll realize what they were missing out on, and they’ll eventually hear word about our library again and check it out again, and realize what awesomeness is.
1 Like
Excerpt from one of my other posts in the previous thread:
We’d need to do some proper research into browser usage (including native webviews on mobile) to make a final call, but my main point was just that, if some optimization will solve some problem for us and is expected to land in “the next chrome-beta”, we should not assume that this fix is acceptable for all our users (i.e. our users’ users) most of whom probably won’t be keeping their browsers constantly up-to-date.
e.g. according to https://kangax.github.io/compat-table/es6/, no current browser (including google chrome beta and canary) has native ES6 class support… some do if you enable flags for experimental javascript (which is unrealistic to expect all users to do), and some implementations aren’t final. So I think we’ll still be relying on transpiled code for some time to come (there’s also the issue of intelligently detecting the browser environemt and serving raw ES6 if it’s fully supported).
I think it’s important to realize that what’s important to our users are their own users, who aren’t developers. My main drive for this project is to be able to easily make a product that works and feels great on all devices. If Gadi the business owner is getting negative feedback about his app from his non-technical users who are the main source of his income, he’ll stop using a library that doesn’t deliver. I don’t want this to be a library that’s only relevant for a minority of early-adopter end-users.
The problem with the w3schools stats is that it’s from their own log files… i.e. it’s showing the browser/version share used by web developers, which relates back to my point above.
I usually use http://gs.statcounter.com/#all-browser_version-ww-monthly-201509-201509-bar, although to be honest, I never really looked into it more than the fact that it’s the source wikipedia uses. Anyway, according to that (for September until today, and rouding off):
- 22% Other!
- 20% Chrome 45
- 14% Chrome for Android
- 10% Safari iPhone + iPad
- 7% Firefox 40
- 6% Chrome 44
- 6% IE 11
- 6% Android
- 5% Opera
So yes, Chrome does a friggin’ awesome job at keeping itself up to date. But it’s not all inclusive. For the reasons I mentioned above, I think it’s important to, at the least, support the last 3 browser versions (that increment quickly, e.g. 4.5 months back), and yeah, I at least am fine with IE11+. Just remember that e.g. for ES6 it’s still not properly/fully implemented in the dev releases, so, even if 4.5 months from now, it won’t be ready.
Also critical is to verify what happens with Cordova! This won’t be in browser stats since it’s “local browsing”. We need to know what engine is used for Android/iPhone and how it’s kept to date. I think for Android since 4.4.4 they use Chrome which is kept up to date, which again, is friggin’ awesome. For < 4.4.4, if it’s really important, we can just build with crosswalk which includes the chrome engine inside the app container (but makes for a +100mb app). For iOS I’m not sure how it works, anyone?
This is the same discussion over and over across the web. Just decide, publish it and go.
The issue with which ones to support has to also be dependent on if the browser is keeping up as @gadicc has stated. As an example, are you going to let the library be held up, because you have one browser not complying with ES6 standards when the rest are on board? Not sure what the answer is going to be in this case, but it is the same old discussion.
This is going to be a decision based on dependencies in the library also (i.e. WebGL, 3D Transforms including preserve-3D).
Our users (developers) will need to know their target audience, and if it includes anything less than IE11 (I’m on the fence like a cat ready to fall onto the Edge about even supporting IE 11), then they should not make the bad decision of using our lib for IE 8 or IE 9 users, etc. It’s not the user’s fault, it’s the developer’s fault for making that choice. We can expect to make awesome things in those older browsers the way we invision our library working.
Our market is essentially for the latest Chrome/Safari, Firefox (DOM 3D is still kind of jank), and Edge (hopefully DOM 3D is better). For DOM 3D (most of developers will use this as @Steveblue predicts) then, the target market is just Chome/Safari, and that’s it (literally!) If Edge has seriously improved their DOM 3D, then we can add Edge too. But as far as WebGL, all of Chrome/Safari, Firefox, and IE11, and Edge will be fine. Users of older browsers won’t be able to experience our awesomeness.