[debaserab2]

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?

[marcusarmstrong]

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]

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]

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]

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.

[Silhouette]

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.

[matt4077]

Let's dispense with the "amateurs" first: the complete stack is build almost exclusively by people employed by Google, Facebook, Apple, Mozilla, and a handful of smaller, but at least as professional, companies.

Then, I don't understand the rest of the argument. Open Source software has simply won in the marketplace, mostly because of it's openness, rarely because of it's price.

Example: Operating Systems, which is the rare beast where an actual closed-source competitor still exists. Yet the Windows marketshare on the server is around 10%, and I doubt that it's the price that encourages all those Unicorns to chose Linux. Databases are a similar story.

> Neither of these necessarily implies writing or maintaining ideal tools to support web development more widely

It doesn't necessarily do that, but in the case of Google specifically, it does: they need the open web as a platform to compete against the "walled gardens" of Apple and Facebook. Their interests happen to be aligned with those of web developers, which is why Chrome has revitalised browser competition, easily beating the laser-focused team at Mozilla.

> Unfortunately, because so much of the influence is now concentrated with so few organisations or even individual people

The influence is spread out far wider today than it was at the time where Microsoft and Flash were able write APIs without asking anybody.

But, more importantly, I'm unsure what you want? A version of React that supports IE 6 and lynx? They have that, it's called XHTML 1.0 Transitional.

[Silhouette]

Let's dispense with the "amateurs" first: the complete stack is build almost exclusively by people employed by Google, Facebook, Apple, Mozilla, and a handful of smaller, but at least as professional, companies.

You might like to take a look at the history of Babel (formerly 6to5) as one prominent counter-example. For several years, much of the web development community has been relying on a great tool that was originally written by one talented young amateur.

Open Source software has simply won in the marketplace, mostly because of it's openness, rarely because of it's price.

Chrome being prominently advertised every time anyone visited a Google site using another browser probably didn't hurt. Being installed by default on the most popular mobile OS also didn't hurt. If openness were all it took, Firefox would surely still be a more prominent player.

It doesn't necessarily do that, but in the case of Google specifically, it does: they need the open web as a platform to compete against the "walled gardens" of Apple and Facebook.

Google wants people to use the Web because it makes its money primarily from advertising on web sites. It is in Google's direct financial interest to support the part of the Web ecosystem that in turn supports advertising. That typically doesn't include, for example, corporate intranets, or embedded UIs in network-connected devices, or academic sites, which are three big areas where web technologies are widely used but stability and long-lasting content are more highly valued.

Their interests happen to be aligned with those of web developers, which is why Chrome has revitalised browser competition

Writing as a professional web developer who often works in those other areas I mentioned, Chrome hasn't revitalised browser competition. On the contrary, it's become the new IE from the old browser wars. A lot of the new functionality only works properly in Chrome, and often it's not reliable even there because of the frequent updates that change behaviour and/or introduce regressions. There's no real concern about proper standardisation or compatibility or longevity any more.

But, more importantly, I'm unsure what you want?

I want the fundamental tools on which much of the ecosystem now relies not to break everything that predates a standard that is less than two years old and still not fully supported across many active browsers. In this case, that means being able to install packages from NPM with a reasonable expectation that they will not require a substantial extra build process to be used.

Obviously no-one contributing NPM packages has any obligation to respect that. It's not as if we're all paying for their openly licensed work. I just think the community as a whole will otherwise suffer yet more overheads getting infrastructure set up instead of actually getting useful work done.

[marcus_holmes]

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]

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]

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.

[tracker1]

As someone who's been building against browser/web tech for over two decades now... that React is emphatically no less than "Good"... The diagnostic messages alone are leaps and bounds ahead of anything else I've used. Angular just breaks in weird ways with no warnings, sometimes non-sense error messages, other platforms likewise... React regularly warns on usage that might break something in the next release, and more than a clue how to fix it. Nothing else I've used comes close to that. Not that it was your implication.

Now, I'll admit, I've dev'd against React and deployed with preact-compat as a build sub for size... but a couple times back to React for broader support, and it really didn't save on speed anyway.

React is hands down the first web tech I've used (out of dozens of platforms and toolkits over the years) that just made sense. Not everything I agree with, and would love some adjustments. All the same, more often than not, it does what I expect, and I definitely can't say that of most of the rest.

As to jQuery, I think it's a great idea, was and still is in a lot of ways. I do wish they'd just drop their XHR, and Promise implementation at this point... but the selection library + eventing is cool and easier to grasp to this day, despite going without it for about 2 years now. There are cases where it was just nice, and still is.

I'm actually fine with JSX, imho it's better having some XML in my JS than it ever was having weird DSL in templates in JS.

[sjellis]

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.

[tracker1]

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]

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]

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]

Yes, actually, if that's who you are selling your product to it is exactly your job to be doing that.

[spankalee]

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.