5 ms·

All current browsers support ES6. That's debatable, particularly when you factor in bugs. However, even if they did, it seems unwise to assume that all relevan

All current browsers support ES6. That's debatable, particularly when you factor in bugs. However, even if they did, it seems unwise to assume that all relevant users for all or even most projects will be on the latest evergreen browsers. Several large groups, including business users on IE and mobile users on slightly older devices, probably won't be. I know there's a certain type of web developer who would love for everyone to have updated their browser within the last five minutes so all the new toys are available universally, but that has never been the nature of web development. Deliberately breaking major infrastructure is just going to make JS development even more screwed up than it already is.

debaserab2 10y ago
This is a common theme I'm noticing a lot lately. Meanwhile, I check my product's browser breakdown and IE9/10 is still too significant to ignore. There's just no way our customers would be okay with this. Many are still locked on older IE versions due to (bad) corporate policies. I can't strongarm them into upgrading. Which leads me to wonder: are developers that are so willing to advocate breaking compatibility with older browsers actually deploying real sites that have normal representative user audiences? Or is this an insular group of developers mostly making things for each other?
- Silhouette 10y ago
  I'm afraid this culture is now endemic in web development. Everyone expects everything to be free, so the people building most of the tools, from the libraries to the browsers themselves, are mostly either doing it for fun as an amateur or doing it professionally in order to support something that does bring in revenues. Neither of these necessarily implies writing or maintaining ideal tools to support web development more widely; any wider benefit is largely coincidental. Unfortunately, because so much of the influence is now concentrated with so few organisations or even individual people, and most of them are aligned on this, it's going to be difficult to return to a more widely supportive ecosystem now.
  - marcus_holmes 10y ago
    Agree. This is Maker's Triangle stuff (Good, Cheap or Fast, pick two). Everyone is picking Cheap and Fast, and not only Cheap, but Free, so the amount of Good left in this stuff is non-existent. If there's no Good chosen, then it all gets crufty and full of tech debt. So someone else thinks they can do better, and starts developing a replacement. In order to get traction, though, they need to make it Free and develop it Fast, so after a while they start taking a few short-cuts, and round we go again. I have faith that it'll settle down eventually, but until then...
    - matt4077 10y ago
      I'm unsure if this Maker's Triangle thing applies to OSS. But if it does, it's my impression that it's usually the "Fast" that is abandoned, not the "Good". But how does that apply to Chrome, or React? Is there any indication that Chrome carries more technical debt than, say IE7? Similarly, in what way does Facebook need people to adopt React, and would that matter enough to accept such compromises? Is there any indication that their code quality is inferior to <pick whatever commercial js library you want>? And if this is the complaint about churn, that, at this time would be older than our js stack if it were true: React came out in 2013, it's four years old. Before that, most people probably used JQuery, which came out in 2006, i. e. 11 years ago. Is learning a new library every five years too much, considering this is one of the most dynamically evolving ecosystems of technology?
      - Silhouette 10y ago
        To continue the analogy, the JavaScript community doesn't believe in technical debt. It just declares itself bankrupt every few weeks and moves on, leaving anyone who was relying on earlier arrangements to cover the costs. To extend it further, this is why you should be very careful who you give credit to in the JavaScript ecosystem. If you're trying to build anything robust and potentially long-lived, relying on anything but the largest and most established dependencies is usually unwise, and even then relying on any any aspect that isn't in mainstream use is a risk.
      - 10y ago
- marcusarmstrong 10y ago
  For whatever my anec-data is worth, I run a sports stats website as a hobby (which has a decidedly non-developer user base), and when looking at my own user breakdown I found that less than .1% of my traffic was IE10 or below. So while there's still likely an insular group at play, it's not limited to just developers.
  - Silhouette 10y ago
    Stats for older IE versions are similar for most sites/apps I'm involved with, though I know in some niches they are still important. IE11 is a different case entirely, though. Almost everything still gets significant traffic on that platform, and in the business world supporting it is pretty much essential. Not much ES6 support there, though.
    - debaserab2 10y ago
      Yeah that's interesting. I might be biased since I'm in an exclusive B2B market. Still though, it's hard to adopt a policy that axes even just 1% of your customer base just for the sake of easier development cycles when alternate options exist.
      - Silhouette 10y ago
        Oh, I completely agree. If in your circumstances older IE builds are still significant then of course you might want to continue supporting them. I'm just suggesting that that issue is somewhat separate to the original point, because in the case of ES6 support, even the latest version of IE doesn't have it.
- sjellis 10y ago
  I think that there is a real split between consumer and corporate at this point (certainly in the West). Some managed corporate setups are definitely still on old versions of IE, but for everyone else, the path of least resistance has been auto-updated platforms for a while now (Windows 10 + Edge, iOS, Chrome, Firefox). Recently, I updated the browser support docs for my employer, and was surprised to note that IE11 is now the oldest browser with standard vendor support, so everybody on older versions of IE is either working for a company with specific extended support contracts with Microsoft, or they are running with no support at all.
- spankalee 10y ago
  If your users need ES5, then compile to ES5. The packages you use can't know that though. I'm not advocating for breaking anything.
- tracker1 10y ago
  I propose a warning... "For security reasons, all versions of Internet Explorer are no longer supported. Please upgrade to a modern/current browser such as Chrome, Firefox or Edge." Make sure to state "For security reasons" policies always have that even when it's not true, or bad security, because most people don't question it.
  - debaserab2 10y ago
    That would scare the hell out of my users and immediately increase support volume by a not insignificant amount. There's not a lot of sense in doing that anyways since many/most of the users stuck on old browser versions are stuck due to corporate policy.
    - tracker1 10y ago
      Then their corporations are running old/insecure browsers... the end. It's not my job to coddle corporations that are endangering their own users.
      - debaserab2 10y ago
        Yes, actually, if that's who you are selling your product to it is exactly your job to be doing that.
frik 10y ago
Many user are still on ES5/JS5 capable browser. IE11, older FF and Chrome, and especially older mobile devices with older Webkit based browser (Android and iOS)
- tracker1 10y ago
  There's still a handful of features (though far fewer than 2 years ago) that I need babel for anyway, so just sticking with that, and may adjust my babel-preset-env config as things change. I may even do dual builds, one for bleeding edge (a bit more than half the users) and a catch-all ES5 build. YMMV.
matt4077 10y ago
The situation has really improved, mostly due to auto-updating, increased competition between browsers, the iPhone's power to compel modernisation, and the resulting fading of proprietary technology like flash or ActiveX. Sure, google.com probably needs to support IE 6. For my own business, I'm not willing to make compromises for browsers below 2%. That currently means Safari 10, Chrome 56, and IE 11. And IE 11 is really stretching it by now–next time it gets in my way, I'll give people a reason to upgrade. Now I don't have "enterprise" customers, and it's a rather small business. For anything medium-size up, the calculus changes, and probably makes it worthwhile. But at some point, these mystical "enterprises" really have to get their act together and stop dragging technology back to 2006.
- debaserab2 10y ago
  That's crazy to me: you'd give up 2% of your customer size (and potential revenue?) just to make your dev workflow more convenient?
  - growtofill 10y ago
    This can be justified. Multiple times I'd been in the spot when shipping of a feature by a certain date will get your contract signed. And this is dependant of how convenient your workflow is.
  - CognitiveLens 10y ago
    particularly for a young or fast-growing product, this makes a ton of sense - shipping features that multiply your target market can be a _much_ better strategy than keeping 2% of your current user base.
spankalee 10y ago
Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers. But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.
- Silhouette 10y ago
  Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers. No, it isn't. For a lot of web developers, two of those aren't major browsers at all and you've missed the 800lb gorilla. You're also ignoring older versions of mobile browsers, the current Firefox ESR, and at least one other browser that has a larger market share than several of the above in parts of Asia, among other things. But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation. And consequently, the entire community has to start incorporating a heavyweight build process that relies on third party tools just to use modules from the de facto standard package repository, and everyone also has to take extra time checking the exact requirements for every module they directly or indirectly depend on to make sure their build process supports it. In an ecosystem with absurd levels of microdependencies, which is certainly what we have today in JS world, the last thing we need is moving goalposts on the basic assumptions that everyone makes. This sort of thing is exactly why proper, long-lived standards are important as the foundation of a productive development ecosystem.
  - spankalee 10y ago
    Yes, "current version" specifically doesn't include "older versions", that should be uncontroversial. Not sure the 800lb gorilla you're referring to, but maybe UC Browser? That thing is so odd it's difficult to know what it supports, and it's not supported in nearly any popular CI service. I'm sure all kinds of things are broken on it, but you can still compile your app to ES5. And ES6 _is_ a proper long lived standard. I'm not sure what would be more standard. Compiling dependencies is not that heavyweight, especially when there is no configuration. Babel and TypeScript are fast. The results can be cached, it can be done on the fly for dev servers. Requirements shouldn't need to be checked - I'm not advocating for distributing code using decorators or class properties, nor modules (which without the HTML spec on module specifiers isn't a fully functional spec anyway) just plain ES6. ES5 and ES6 classes cannot coexist on the same proto chain. Compiling to ES5 prevents things like mixins being usable against ES6 superclasses, so you force all dependents to be ES6. If you're going to force one way or the other, force in the future direction where there's still the option to compile the whole app to the older version of JS. ES5 classes can't extend subclassable built-ins like Array, Promise, Set, Map, HTMLElement, Error, etc. ES5 is now mostly slower than the equivalent ES6, it also doesn't minify as well as ES6.

debaserab2 10y ago

This is a common theme I'm noticing a lot lately. Meanwhile, I check my product's browser breakdown and IE9/10 is still too significant to ignore. There's just no way our customers would be okay with this. Many are still locked on older IE versions due to (bad) corporate policies. I can't strongarm them into upgrading. Which leads me to wonder: are developers that are so willing to advocate breaking compatibility with older browsers actually deploying real sites that have normal representative user audiences? Or is this an insular group of developers mostly making things for each other?

Silhouette 10y ago
I'm afraid this culture is now endemic in web development. Everyone expects everything to be free, so the people building most of the tools, from the libraries to the browsers themselves, are mostly either doing it for fun as an amateur or doing it professionally in order to support something that does bring in revenues. Neither of these necessarily implies writing or maintaining ideal tools to support web development more widely; any wider benefit is largely coincidental. Unfortunately, because so much of the influence is now concentrated with so few organisations or even individual people, and most of them are aligned on this, it's going to be difficult to return to a more widely supportive ecosystem now.
- marcus_holmes 10y ago
  Agree. This is Maker's Triangle stuff (Good, Cheap or Fast, pick two). Everyone is picking Cheap and Fast, and not only Cheap, but Free, so the amount of Good left in this stuff is non-existent. If there's no Good chosen, then it all gets crufty and full of tech debt. So someone else thinks they can do better, and starts developing a replacement. In order to get traction, though, they need to make it Free and develop it Fast, so after a while they start taking a few short-cuts, and round we go again. I have faith that it'll settle down eventually, but until then...
  - matt4077 10y ago
    I'm unsure if this Maker's Triangle thing applies to OSS. But if it does, it's my impression that it's usually the "Fast" that is abandoned, not the "Good". But how does that apply to Chrome, or React? Is there any indication that Chrome carries more technical debt than, say IE7? Similarly, in what way does Facebook need people to adopt React, and would that matter enough to accept such compromises? Is there any indication that their code quality is inferior to <pick whatever commercial js library you want>? And if this is the complaint about churn, that, at this time would be older than our js stack if it were true: React came out in 2013, it's four years old. Before that, most people probably used JQuery, which came out in 2006, i. e. 11 years ago. Is learning a new library every five years too much, considering this is one of the most dynamically evolving ecosystems of technology?
    - Silhouette 10y ago
      To continue the analogy, the JavaScript community doesn't believe in technical debt. It just declares itself bankrupt every few weeks and moves on, leaving anyone who was relying on earlier arrangements to cover the costs. To extend it further, this is why you should be very careful who you give credit to in the JavaScript ecosystem. If you're trying to build anything robust and potentially long-lived, relying on anything but the largest and most established dependencies is usually unwise, and even then relying on any any aspect that isn't in mainstream use is a risk.
    - 10y ago
marcusarmstrong 10y ago
For whatever my anec-data is worth, I run a sports stats website as a hobby (which has a decidedly non-developer user base), and when looking at my own user breakdown I found that less than .1% of my traffic was IE10 or below. So while there's still likely an insular group at play, it's not limited to just developers.
- Silhouette 10y ago
  Stats for older IE versions are similar for most sites/apps I'm involved with, though I know in some niches they are still important. IE11 is a different case entirely, though. Almost everything still gets significant traffic on that platform, and in the business world supporting it is pretty much essential. Not much ES6 support there, though.
  - debaserab2 10y ago
    Yeah that's interesting. I might be biased since I'm in an exclusive B2B market. Still though, it's hard to adopt a policy that axes even just 1% of your customer base just for the sake of easier development cycles when alternate options exist.
    - Silhouette 10y ago
      Oh, I completely agree. If in your circumstances older IE builds are still significant then of course you might want to continue supporting them. I'm just suggesting that that issue is somewhat separate to the original point, because in the case of ES6 support, even the latest version of IE doesn't have it.
sjellis 10y ago
I think that there is a real split between consumer and corporate at this point (certainly in the West). Some managed corporate setups are definitely still on old versions of IE, but for everyone else, the path of least resistance has been auto-updated platforms for a while now (Windows 10 + Edge, iOS, Chrome, Firefox). Recently, I updated the browser support docs for my employer, and was surprised to note that IE11 is now the oldest browser with standard vendor support, so everybody on older versions of IE is either working for a company with specific extended support contracts with Microsoft, or they are running with no support at all.
spankalee 10y ago
If your users need ES5, then compile to ES5. The packages you use can't know that though. I'm not advocating for breaking anything.
tracker1 10y ago
I propose a warning... "For security reasons, all versions of Internet Explorer are no longer supported. Please upgrade to a modern/current browser such as Chrome, Firefox or Edge." Make sure to state "For security reasons" policies always have that even when it's not true, or bad security, because most people don't question it.
- debaserab2 10y ago
  That would scare the hell out of my users and immediately increase support volume by a not insignificant amount. There's not a lot of sense in doing that anyways since many/most of the users stuck on old browser versions are stuck due to corporate policy.
  - tracker1 10y ago
    Then their corporations are running old/insecure browsers... the end. It's not my job to coddle corporations that are endangering their own users.
    - debaserab2 10y ago
      Yes, actually, if that's who you are selling your product to it is exactly your job to be doing that.

frik 10y ago

Many user are still on ES5/JS5 capable browser. IE11, older FF and Chrome, and especially older mobile devices with older Webkit based browser (Android and iOS)

tracker1 10y ago
There's still a handful of features (though far fewer than 2 years ago) that I need babel for anyway, so just sticking with that, and may adjust my babel-preset-env config as things change. I may even do dual builds, one for bleeding edge (a bit more than half the users) and a catch-all ES5 build. YMMV.

matt4077 10y ago

The situation has really improved, mostly due to auto-updating, increased competition between browsers, the iPhone's power to compel modernisation, and the resulting fading of proprietary technology like flash or ActiveX. Sure, google.com probably needs to support IE 6. For my own business, I'm not willing to make compromises for browsers below 2%. That currently means Safari 10, Chrome 56, and IE 11. And IE 11 is really stretching it by now–next time it gets in my way, I'll give people a reason to upgrade. Now I don't have "enterprise" customers, and it's a rather small business. For anything medium-size up, the calculus changes, and probably makes it worthwhile. But at some point, these mystical "enterprises" really have to get their act together and stop dragging technology back to 2006.

debaserab2 10y ago
That's crazy to me: you'd give up 2% of your customer size (and potential revenue?) just to make your dev workflow more convenient?
- growtofill 10y ago
  This can be justified. Multiple times I'd been in the spot when shipping of a feature by a certain date will get your contract signed. And this is dependant of how convenient your workflow is.
- CognitiveLens 10y ago
  particularly for a young or fast-growing product, this makes a ton of sense - shipping features that multiply your target market can be a _much_ better strategy than keeping 2% of your current user base.

spankalee 10y ago

Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers. But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation.

Silhouette 10y ago
Chrome, Firefox, Edge, Safari and Opera all support ES6. That's the current version of all major browsers. No, it isn't. For a lot of web developers, two of those aren't major browsers at all and you've missed the 800lb gorilla. You're also ignoring older versions of mobile browsers, the current Firefox ESR, and at least one other browser that has a larger market share than several of the above in parts of Asia, among other things. But, I'm not arguing that web sites should only serve ES6 to browsers, only that packages should be distributed as ES6 and the app should be responsible for compilation. And consequently, the entire community has to start incorporating a heavyweight build process that relies on third party tools just to use modules from the de facto standard package repository, and everyone also has to take extra time checking the exact requirements for every module they directly or indirectly depend on to make sure their build process supports it. In an ecosystem with absurd levels of microdependencies, which is certainly what we have today in JS world, the last thing we need is moving goalposts on the basic assumptions that everyone makes. This sort of thing is exactly why proper, long-lived standards are important as the foundation of a productive development ecosystem.
- spankalee 10y ago
  Yes, "current version" specifically doesn't include "older versions", that should be uncontroversial. Not sure the 800lb gorilla you're referring to, but maybe UC Browser? That thing is so odd it's difficult to know what it supports, and it's not supported in nearly any popular CI service. I'm sure all kinds of things are broken on it, but you can still compile your app to ES5. And ES6 _is_ a proper long lived standard. I'm not sure what would be more standard. Compiling dependencies is not that heavyweight, especially when there is no configuration. Babel and TypeScript are fast. The results can be cached, it can be done on the fly for dev servers. Requirements shouldn't need to be checked - I'm not advocating for distributing code using decorators or class properties, nor modules (which without the HTML spec on module specifiers isn't a fully functional spec anyway) just plain ES6. ES5 and ES6 classes cannot coexist on the same proto chain. Compiling to ES5 prevents things like mixins being usable against ES6 superclasses, so you force all dependents to be ES6. If you're going to force one way or the other, force in the future direction where there's still the option to compile the whole app to the older version of JS. ES5 classes can't extend subclassable built-ins like Array, Promise, Set, Map, HTMLElement, Error, etc. ES5 is now mostly slower than the equivalent ES6, it also doesn't minify as well as ES6.