I think one of the things that's led to the mess with javascript is that it's kind of crazy to have settled on using a language to write such large applications that:
- Has no standard library.
- Is used to automate host platforms that have either no standard framework or very little (e.g. Node on v8 doesn't have nothing but it's quite small).
- Has no module/namespace system.
The effect of this is that immediately, anyone building anything in non-trivial has to make a decision about how to fill in things that would be covered in a standard library. I'm not even talking about fancy stuff, just the stuff supplied by underscore, lodash, etc. The choices are basically:
1) Write all the code yourself. This is an extremely low ROI option
2) Adopt a series of libraries and hope you can get them to work together
3) Adopt a framework, that by its nature, will be designed to use some sort of new pattern and this pattern will be expressed on top of whatever libraries the framework uses, so just draft behind that.
There aren't really many other mainstream systems where a language is used to specialize applications on a platform where this situation obtains. Windows, OS X, iOS, Android, even Java, come with enormous, enormous amounts of library code. Generally, this library code also pushes one fairly firmly towards certain design patterns.
Imagine if we all decided to use...hmmm...Scheme, I guess, to develop Windows applications, and you took away everything but the lowest-level Windows APIs. I'm using Scheme because the Scheme standard outlines a remarkably small language that has nothing approaching a standard library.
We'd probably be in a similar situation. How do you do this? How much does adopting this or that library force you to do this or that? It's just not very common to have a situation where to do anything non-trivial, you need to either:
- adopt an enormous amount of third party code (because the situation works at every level, each third-party solution will also not be built on a standard library ecosystem)
- write an enormous amount of boilerplate code.
And further, the issue is exacerbated by the fact that js doesn't really have a standard module system, so even the approaches taken to fill these gaps are frequently non-compatible, or just choosing which system to use to manage modules often means replacing huge chunks of your application.
There are other reasons why JS the language is moving, all of the sudden: JS has had a lot of rough edges and all of the sudden a confluence of interest, capability, and technology has made it possible to sand down some of those edges.
But I think even if the ES process slows down, and we all agree that language-wise the features in the language are pretty good or something happens that freezes, we'll keep seeing lots of churn because of the interaction between every project being built on towers of third party code with far-reaching effects.
When Java, for instance, was released, the standard library it shipped with included:
- a set of standard container classes: hashes, vectors, arrays, etc.
- a rich set of real types (e.g. numbers that weren't insane, Objects for compatibility with the object system, primitive types in the language for performance)
- a whole tree of calendar/date manipulation code
- a standard way of connecting to SQL databases and all the code for that
- a standard GUI-drawing and event-handling system
- a big, rich set of APIs for handling IO of various kinds with different performance/complexity tradeoffs.
- a concurrency api, threadpools, etc.
That's just a sample. And all of the bits worked together, and sort of implied patterns in how things should be built and used.
You could certainly replace anything, should you choose to, in your project (e.g. the calendar stuff really sucked), but the point is, there was a default, and there was a standard pattern for where and how to bring in new library code, and that new library code would in turn be built on as little third-party code as possible.
Look at an average iOS project's Podfile or Carthage file, Android project's Gradle file, and then look at a Node or browser js project's package.json. Then actually look in Pods and node_modules. The average amount of third party libs in a JS project is many orders of magnitude higher than in the others.
There are like, what, five or so competing implementations of Promises in javascript land? And they aren't mutually compatible always, so this means if you want to use non-ES6 babel-compiled Promises in your code, you have to:
- choose a library
- hope that other libraries and frameworks you use use the same style
- add shims or something where they don't, or else switch out the library and framework.
This is just like...no one writing an Android app is like "which Runnables library are you using?". No one writing an iOS app is like "soo...the new GCD spec looks interesting, which GCD lib are you using for your project? Oh yeah how spec-complete is it? Does it work with AFNetworking?"
"Lodash makes JavaScript easier by taking the hassle out of working with arrays, numbers, objects, strings, etc.
Lodash’s modular methods are great for:
Iterating arrays, objects, & strings"
Iterating arrays, objects, & strings is something that most other languages have decent std lib support for, and so even your third-party libs will use the host language's affordances. In Javascript you have to ask these questions all the time.
- Has no standard library. - Is used to automate host platforms that have either no standard framework or very little (e.g. Node on v8 doesn't have nothing but it's quite small). - Has no module/namespace system.
The effect of this is that immediately, anyone building anything in non-trivial has to make a decision about how to fill in things that would be covered in a standard library. I'm not even talking about fancy stuff, just the stuff supplied by underscore, lodash, etc. The choices are basically:
1) Write all the code yourself. This is an extremely low ROI option 2) Adopt a series of libraries and hope you can get them to work together 3) Adopt a framework, that by its nature, will be designed to use some sort of new pattern and this pattern will be expressed on top of whatever libraries the framework uses, so just draft behind that.
There aren't really many other mainstream systems where a language is used to specialize applications on a platform where this situation obtains. Windows, OS X, iOS, Android, even Java, come with enormous, enormous amounts of library code. Generally, this library code also pushes one fairly firmly towards certain design patterns.
Imagine if we all decided to use...hmmm...Scheme, I guess, to develop Windows applications, and you took away everything but the lowest-level Windows APIs. I'm using Scheme because the Scheme standard outlines a remarkably small language that has nothing approaching a standard library.
We'd probably be in a similar situation. How do you do this? How much does adopting this or that library force you to do this or that? It's just not very common to have a situation where to do anything non-trivial, you need to either: - adopt an enormous amount of third party code (because the situation works at every level, each third-party solution will also not be built on a standard library ecosystem) - write an enormous amount of boilerplate code.
And further, the issue is exacerbated by the fact that js doesn't really have a standard module system, so even the approaches taken to fill these gaps are frequently non-compatible, or just choosing which system to use to manage modules often means replacing huge chunks of your application.
There are other reasons why JS the language is moving, all of the sudden: JS has had a lot of rough edges and all of the sudden a confluence of interest, capability, and technology has made it possible to sand down some of those edges.
But I think even if the ES process slows down, and we all agree that language-wise the features in the language are pretty good or something happens that freezes, we'll keep seeing lots of churn because of the interaction between every project being built on towers of third party code with far-reaching effects.
When Java, for instance, was released, the standard library it shipped with included: - a set of standard container classes: hashes, vectors, arrays, etc. - a rich set of real types (e.g. numbers that weren't insane, Objects for compatibility with the object system, primitive types in the language for performance) - a whole tree of calendar/date manipulation code - a standard way of connecting to SQL databases and all the code for that - a standard GUI-drawing and event-handling system - a big, rich set of APIs for handling IO of various kinds with different performance/complexity tradeoffs. - a concurrency api, threadpools, etc.
That's just a sample. And all of the bits worked together, and sort of implied patterns in how things should be built and used.
You could certainly replace anything, should you choose to, in your project (e.g. the calendar stuff really sucked), but the point is, there was a default, and there was a standard pattern for where and how to bring in new library code, and that new library code would in turn be built on as little third-party code as possible.
Look at an average iOS project's Podfile or Carthage file, Android project's Gradle file, and then look at a Node or browser js project's package.json. Then actually look in Pods and node_modules. The average amount of third party libs in a JS project is many orders of magnitude higher than in the others.
There are like, what, five or so competing implementations of Promises in javascript land? And they aren't mutually compatible always, so this means if you want to use non-ES6 babel-compiled Promises in your code, you have to: - choose a library - hope that other libraries and frameworks you use use the same style - add shims or something where they don't, or else switch out the library and framework.
This is just like...no one writing an Android app is like "which Runnables library are you using?". No one writing an iOS app is like "soo...the new GCD spec looks interesting, which GCD lib are you using for your project? Oh yeah how spec-complete is it? Does it work with AFNetworking?"
"Lodash makes JavaScript easier by taking the hassle out of working with arrays, numbers, objects, strings, etc. Lodash’s modular methods are great for:
Iterating arrays, objects, & strings"
Iterating arrays, objects, & strings is something that most other languages have decent std lib support for, and so even your third-party libs will use the host language's affordances. In Javascript you have to ask these questions all the time.