JavaScript is Good, Actually

Yeah, arguing that language features that have caused untold pain, constant confusion, and an shameful level of strictness aren't an issue because third-party linters and typed DSLs give you warnings is... weak. Any language can address any issue in that manner. The very fact 3rd party tooling is required to address language design issues is a pretty harsh criticism of that languages design in and of itself.

Javascript the language is getting much better, and is quite nice in many dimensions. Javascript the ecosystem has a lot of strengths, while also having embarrassingly poor base libraries that require stupid levels of duplicated effort and a platform that is still painfully inconsistent. The fragmentation around Coffescript/Typescript and linters hints at a much stronger need for a language that does more than JS does at its core... As traditional languages encroach into the browser space I see a lot of the "SPA" and cutting edge fat-client-in-html moving away from JS because of those warts.

I think javascript shines only depending on which languages you compare it to, and what you're doing with it.

Also JS + Typescript is a force to be reckoned with (the added safety is great), and once a multi-threaded runtime like Chakra[0] takes shape, it'll be even better. JS's early introduction of concurrency primitives (callbacks, futures/deferreds, promises) will make javsacript developers much productive much faster than the equivalent ruby/python 2 developer with not as much early exposure to managing concurrency.

> Switching back to Java (...)

I miss the "and a project which doesn't use modern standards"-part in your post. It's not as if JSON or other modern things are not used in many Java projects. Your project seems to be stuck in the past, as are many JS projects. Legacy code is no fun most of the time.

> the only thing you have to do to turn it into JS is remove the `as ConsignmentSetup`

Removing the cast means removing static typing. It might be a small change for this snippet, but at the project level, you'd need considerably more changes, and you'd lose type safety.

I think it's useful to differentiate between JavaScript the classic language for adding limited interactive behaviours to otherwise static Web pages and JavaScript the language for full-blown MVw web apps and JavaScript the ubiquitous portable script language.

For the first and third use case, really not much has changed since ES3/ES5: if you want portable JavaScript and appreciate simple "press reload button" workflows without babel or other complex transpilation steps, then ES6+ features don't add any essential capability, and I tend to avoid them.

If OTOH you really need to develop SPAs with massive code bases and third-party libs, then ES6 and in particular ES7 with async/await is a big win.

But I can't help wondering if the tension between these language profiles is going to work well for JavaScript in the long run. IMHO for full-blown apps there are much better alternative back-end languages available, and in any massive ES6 code base I've come across the desire to introduce types and type metadata is very much noticable (Angular and Typescript come to mind).