Yes it makes the toolchain more complicated and it makes debugging slightly harder. On top of that having it as a standard means you can go anywhere and just use it without worrying about which transpiler they are using.
> Yes it makes the toolchain more complicated and it makes debugging slightly harder.
Are there ways we can help with this? Improvements we could be making to sourcemaps? Maybe we should be looking into adding new descriptors that are designed specifically to help generated code get read by debuggers? Maybe some kind of support for marking regions of code so you can run multiple transpilers on the same codebase?
I dislike transpilation in its current form, but I can think of things off the top of my head that would make it easier.
> On top of that having as a standard means you can go anywhere and just use it without worrying about which transpiler they are using.
Fair enough, there are definitely advantages to having a large set of core features. But if you look at languages like modern C++, it seems that there are also disadvantages that come along with that.
Given that the web is far more permanent than most other languages (we can never remove a JS feature), are the advantages of having one code style worth the disadvantages of not being able to test new syntax in the wild before we standardize?
There's a balance here -- I like lodash, a lot. But I don't want lodash to be part of the core language. Maybe some syntax fits into that category as well?
But why not have a larger standard library for Node for instance so you don’t have so many dependencies and have separate optional libraries for the browser?
Note that Node is actually in a much better position than Javascript as a whole, because Node apps can be shipped with a specific version of Node. This means that the Node team actually has more power than web browsers to deprecate old features and remove parts of the library, as long as they do so carefully. It is much harder to make breaking changes in a browser than it is to make them in Node.
One middle ground I've seen people suggest is to have officially "blessed" external libraries that still need to be imported, but that are cached locally or have special privileges. For example, JQuery was at one point so common that the Firefox dev tools actually ship with a subset of the JQuery API enabled -- just so devs that are used to working with it can use it in the debugger on any site.
I look at JQuery as a massive success story for how 3rd-party extensions should work. It was extremely ubiquitous, it did influence the core language, but now we've grown and because it was kept separate, we're still free to abandon it and move on.
On the Node side maybe that means that Node ships with dependencies that still need to be added to your package.json, but that are always bundled in your installation so that you have them locally and don't need to hit a network request when you type `npm install X`.
Also on the Node side we have modules that are built by the core team, but just not distributed in the core library. This helps out a bit with security, because you can still have a large organization like Google maintaining a feature and validating it, they just ship it separately from their browser.
