Something that may not be obvious: JavaScript absolutely, can not under any circumstances, break backwards compatibility. If JavaScript breaks backwards compati

Something that may not be obvious: JavaScript absolutely, can not under any circumstances, break backwards compatibility. If JavaScript breaks backwards compatibility, it literally breaks the web. Most of the complexity we're seeing in projects is around that constraint applied to 'modern' JavaScript - we have to translate all of our modern code into older code that older browsers can still understand. JavaScript can't just forget the past right now - there might be a point in the future where it's given the IE6 treatment: "if you're using a browser that can't support a standard that is 10+ years old, tough, you need to upgrade." But we have to all move there, together, as an industry. It took a long time for us to dump IE6 in that way, it'll take a while before we can dump ES5. This is exacerbated by the fact that there is no standard library in JavaScript. Check out some of webpack's dependencies: https://github.com/webpack/webpack/blob/master/package.json#L14-L23 https://github.com/webpack/webpack/blob/master/package.json#.... A lot of these are replicating basic functionality a standard library should provide. But we can't just blame this on environmental factors - a lot of this feels very much self inflicted. For example: node provides a file system utility for but wepack is using a different one. Maybe the fs utility can't solve all of their problems and they need an extended one. Instead of just using the standard file system and dealing with the quirks of it, we have to write a new, slightly better one and use that instead. Locally, it might make sense for webpack to do that, but when you do it in aggregate across the industry, you end up with the death by a thousand cuts situation we find ourselves in.