A modern JavaScript engineer would point out that:
- The community is very accepting of new engineers.
- The ecosystem is huge and there are great solutions
available to many problems.
- It's easy to write consistent code while avoiding
many problems with the language if you use `eslint`,
`prettier` and `flowtype`. Tooling on the web is
excellent and rapidly improving.
- You can use one language on the back-end and front-end.
You can even use the same language to write desktop,
embedded, command-line and curses applications.
- `babel` drives the adoption of new features into the
language with greater vigor than many other languages.
- The VM is very fast due to lots of work by Google,
Mozilla, etc. There's also methods of interacting with
modules written in WebAssembly or if you're on the
back-end native modules written in Rust/C++.
- JavaScript is driving a lot of momentum for
new programming languages (Reason, Elm, PureScript, etc)
since as a transpilation target it gives you access
to many environments and libraries at the get-go.
In my opinion JavaScript in 2017 is a much better language than JavaScript in 2012. I wouldn't call it objectively good but I certainly wouldn't call it 'objectively bad'. There are many reasons to choose it beyond the syntax and semantics of the language itself, and there are effective treatments available for most of the warts it was once known for.
It's dominating because of the sheer drive within the community, and if there were award ceremonies it'd be winning 'Most Improved' year-upon-year.
How much of that is just solving a problem created by Javascript?
A community accepting of new engineers isn't. But it isn't something to brag about either, because it never means its literal sense. Instead, people say a community accepts new engineers when it has low enough standards that newbies feel empowered without learning anything new. The one language to rule them all mentality is also about low standards.
The ecosystem is just compensating the lack of native features and bad overall design; so is the tooling. Babel is a great tool, but it's just compensating for the lack of a good VM at the browsers; ditto for all the transpiled languages.
Besides, no JS VMs aren't very fast. They are faster than the slowest popular languages (Python, Ruby), but can't get anywhere near the moderately fast ones like Java and .Net.
Almost none of the things I mentioned are solutions to 'a problem created by JavaScript' therefore your question seems deliberately misleading.
An accepting community can be a large funnel: it doesn't need to mean that nobody improves or that there are no selection effects. More candidates means more chaff, but also more wheat.
Babel isn't merely contributing to a 'lack of a good VM'. It's more valuable to see it as a playground and streamlined process for large-scale testing of language-level features. (It solved this problem later on. It was originally meant only to solve the problem of running modern code on older VMs.)
I guess you could argue that the VM should have been complete in 1995 but what programming language has managed this?
Also, I don't think that comparing JavaScript's VM to the VMs of statically typed languages is fair. You mentioned yourself that in comparison to similar dynamically typed languages it's faster. Compare apples to apples.
I don't think I'm bending the truth here. There's been a lot of investment into JavaScript, and not all of the problems that have been solved are obvious or easy.
At this point it is ascendant because it has effectively solved lots of problems that relate to speed of change and it has done this seamlessly on a large number of platforms. I think people look at this and pattern-match to 'first-mover advantage' or 'JavaScript has a monopoly on browsers' but neither of these things were what got us to this place: it was innovation in maneuverability.
(It won't necessarily stay ascendant now that it is so easy to circumvent writing JavaScript but yet still plug into its ecosystem.)
> More candidates means more chaff, but also more wheat.
That needs substantiation. It's not immediately obvious in any way.
About Babel, notice how we never had a problem playing with language-level features that target the PC? That's the difference a good VM makes (although on the PC case, it's not virtual). Besides, you are conflating VMs and languages somehow - they have only a tenuous relation.
About the speed, Javascript misses most of the expressiveness of Python and Ruby. It's more on line with Java but if you want dynamically typed languages, with PHP and Perl too. Yet, it's not any faster than PHP and Perl. It has reasonably fast runtimes - those are not an issue for the language, but are not a big selling point either.
Overall, the reason Javascript still exists and is viewed as a serious language is all because it has a monopoly on the browsers. It was worked on enough that if that monopoly goes away it will still be a good choice for some stuff, but it is not an stellar language, and can't be coerced into becoming one unless it can pass through a Perl5 - Perl6 level transition.
>Overall, the reason Javascript still exists and is viewed as a serious language is all because it has a monopoly on the browsers.
Basically, this. ClojureScript and others are simply the efforts of sane, experienced developers that don't want to cope anymore with Javascript and its warts.
I don't think that comment requires more substantiation than yours that there are "low enough standards that newbies feel empowered without learning anything new". The more people that learn your language, the more likely it is that you will find some that can contribute to its state-of-the-art. A low bar doesn't effect people that would surpass a higher bar with ease: they still wish to learn and sate their natural curiosities.
In fact, the normal stereotype of JavaScript developers as people constantly chasing new technologies and libraries is actually true, but what you are claiming is the exact opposite: "people feeling empowered without learning anything new". People are empowered and learning new things because there is a low barrier to doing so and this is exciting.
> misses most of the expressiveness of Python and Ruby.
> It's more on line with Java
Have you actually written modern JavaScript code? I personally think it's more expressive than both Python and Ruby, and certainly much more so than Java.
> Overall, the reason Javascript still exists and is
> viewed as a serious language is all because it has a
> monopoly on the browsers.
As it stands JavaScript doesn't have a monopoly on the browser. You can transpile ClojureScript, Elm, Reason, PureScript and many other languages to it. Yet -- surprise! It is still in use. Do you honestly think this is just inertia? I'd argue that it's investment in the platform itself and particularly 'innovation in maneuverability' (number of environments, speed of prototyping, backward compatible code, ease of hiring) which keeps developers using the platform.
In my opinion, the existence of NPM and a broad range of environments that you can run your code on will likely mean that JavaScript would still be a productive environment even if the web was to die.
>You can transpile ClojureScript, Elm, Reason, PureScript and many other languages to it. Yet -- surprise! It is still in use. Do you honestly think this is just inertia?
No, it isn't inertia -- one important reason is that creating a transpiler to JS invariably ends up with a crippled (feature-restricted), slower version of the original language (Clojure, etc.)
My point is that those transpiled languages aren't that stymied. You can use them without a lot of problems, and they're being left on the bench for reasons other than their feature set.
Companies generally choose JavaScript because there are lots of developers to choose from, it runs everywhere and the ecosystem is huge.
Engineers choose something like PureScript as it's not a 'blub' language and people think that by choosing it they will be able to hire (or be seen as) "math geniuses". I'm sure the feature set is important, but it's not enough to unseat a language with the previously described properties.
You can't change the rules interpreting your source code so that the parser will expand a small command into an entire program, or that it will read a more fitting DSL that does not resemble your original language.
You can not inspect an object and change its type or the set of available properties based on some calculation.
You can not run some code in a controlled environment separated from your main code.
> Even the most ardent JS fans I work with call it objectively bad.
Counterargument: Read
Douglas Crockford - JavaScript: The Good Parts
Even though this book is somewhat "aged" (it is from 2008), I know no better book where it is presented so well what is so interesting about JavaScript and how this language is so often misunderstood.
If after reading this book you still consider JavaScript as "objectively bad", so be it. But first read the arguments that are presented in this book.
It is very telling that you don't see the irony of the fact that a language needs a book titled "Language X: the good parts".
Good tech mostly speaks for itself. When you need entire books to convince you that a language has good parts, then you know the language has a problem.
I can think of one: the fraction of design decisions that the language's creator, standardizers, and serious developers wish they could change but can't.
Even the most ardent JS fans I work with call it objectively bad.