I think ES6+ has done wonders for JavaScript and has made it a highly expressive language. It's true there are quirks and poorly designed aspects which can be confusing at first glance. But like with any language, once you understand how it works, you learn to work with it. Moreover, as the language continues to improve, many of those quirks become irrelevant.

It's important to understand that, by virtue of having been bestowed with a monopoly over the web, JavaScript holds a great deal of leverage as a language. If you want to develop for the web, you pretty much have to adopt JavaScript into your stack. It's no surprise, then, that Node became so popular. Being able to use that language you're forced to use for the client on the server and to run the same code has major benefits. The Node and npm developers got many things right to be sure. But Node and its ecosystem, by virtue of offering JavaScript, benefitted immensely from developers' desire to unify a previously disjoint part of their stack.

I find myself asking instead, how far will JavaScript's reach continue to stretch? Electron and React Native have become extremely popular. It's not just speculation, there is undeniable momentum.

I think ES6 is the worst thing that ever happened to JavaScript because it killed it's best feature: being a small language that runs everywhere.

Now when I want to use a JS library, I have to think: what is this author's philosophy about language extension? Are they going to start using some new feature that some other library I depend on is incompatible with?

You used to be able to run JavaScript anywhere on any device. Think about how powerful that is. We sacrificed that for supposed gains in "ergonomics".

People hate callbacks. People hate "this". But if you ask people who really learned how to use those things, they're not problems at all. They're only problems if you're coming from Ruby.

It's like someone took an Apple and said "this is gross, it's not juicy and tangy like an orange!" And then they soaked it in vinegar and wrapped in orange skins. Now it scores well on orange-ness but is that a virtue?

I really don't agree, as a developer writing predominantly js. It's still pretty standard to compile es6 down to at least es2015 using babel or typescript, meaning js still runs everywhere. I've also literally never met anyone who thinks that callback-structured code is "not a problem". And you can work around issues of "this" and lexical scoping to the point where it isn't as irritating, but it's completely unintuitive to a new js developer, and IMO at least never stops feeling "wrong". There are also a ton of features aside from arrow functions and promises that completely change the way code is written for the better- off the top of my head I use ` string formatting, classes, let/const declarations, and module loading every day.

> It's still pretty standard to compile es6 down to at least es2015

Yea, but that means if I want to use your library, I need a build chain. It used to be I could just do require("you") or <script src="you"> and be done with it. That's what we lost.

Actually I need n buildchains, one for each npm module I use. And they better all be compatible and target at least one common runtime. And that better be a runtime I am comfortable deploying for my app.

> I've also literally never met anyone who thinks that callback-structured code is "not a problem"

Well here I am. Pleased to meet you. Might I also point you at: http://callbackhell.com There are many of us.

I think what this really shows is how much professional ES6 programmers live in a filter bubble.

This also explains why you think "just transpile" is a reasonable substitute for a simple, run-anywhere language. Professional ES6 programmers think everyone has 40 hours a week of paid time to spend maintaining a build chain.

Javascript+Node used to be one of few languages that you could use without a build system. That's no longer the case. Maybe the loss was worth it to you. Fine. Makes sense. I wish more people would just acknowledge something has been lost, and that amateurs are struggling now at the expense of pros.

I agree with a lot of your sentiment. But there's still nothing stopping you from writing ES5 or even ES3 and just ignoring ES6. Thats what we do and it works great for us. And we build extremely high end interactive apps using virtual dom, webgl, etc.

that's really interesting - would love to know more about your JS stack and your project structure?

I think you missed that the parent meant that libraries are compiled _before_ publishing. So even if the library is written with ES6 you can simply require it with no build setup.

Many (most?) libraries are not built that way. There are plenty of libraries that use async in their exports.

i wish i could upvote you 100 times.

> It's still pretty standard to compile es6 down to at least es2015

...aren't ES6 and ES2015 the same thing?

Yeah, they are. People get confused because ES6 === ES2015, "ES7" === ES2016. I sometimes make the same mistake.

If you transpile down to an old version of js, does it matter what language you're transpiling from?

The minute you decide to transpile, you no longer really using javascript, and this discussion isn't really relevant any more.

Well, jQuery is the single most popular JavaScript library ever, with over a decade under its' belt, and going to be around for likely another. Its' style was not predefined by the JS language... It has a monadic style in nature... Likewise, JS didn't prevent coffee-script or transpilers...

That said, I still feel that not sending the event registration context (not just the target) in with the event is a mistake... escalated by the use of fat-arrow functions today. You never know where things will go.

As to callbacks, I think it provides a great base... allows for easy extension and progression. I do now prefer Promises where async/await is available or via babel.

Java 8 isn't the same as Java 3... it's changed... languages evolve, and JS has done so rather rapidly the past 6+ years... It looks to be settling in a bit now. Next will be the module support, and that shift will be more painful than everything that came before.

I don't mind the context class sugar... there are places where it makes sense, and far cleaner than the prototype syntax. I tend to only use it for UI components, and even then sparingly. Just the same, other parts of ES6+ have been incredibly great.

What are you talking about? ES6 transpiles down to ES5, and this is what people publish libraries as. The language version compatibility story is way better than it is for most languages.

Who's writing native ES6 code? Support for IE8 is just now starting to slip in the community (due too old, mundane things like Object.defineProperty). Almost every package on NPM targets ES3. Also, IE never ran everywhere. Targeting IE8 is hard, targeting IE6 was a nightmare.

I can't speak for you, but I've worked at a few companies and done some contracts overs the last 5 years and supporting ie8 easily stopped around 2012.

Microsoft ended support for IE8 early 2016. Until then most open-source libraries supported it. I wrote an IE8-compatible application this year and only had to downgrade a few random libraries.

I see this misconception a lot in this thread. "Yes, people say the language has problems, but there are people can work around the problems, so they aren't really problems!"

The very fact that you need to learn to work with X means that it's a problem. Otherwise, all languages are just fine.

everything is stupid if you dont understand it. JS is pretty good at not getting in your way.

There is no "stupid" and "clever". There's only "consistent" and "inconsistent". JS isn't very consistent.

>everything is stupid if you dont understand it.

Some things are stupid even after you understand them, and JS has plenty of those, as its creator and its greater evangelizer both admitted.

I don't think it's about missing features. JavaScript has a lot of footguns. You admit that, but dismiss the complaints. Sure, with experience you know what to ignore, but a well-designed language has fewer of those areas in the first place.

I've used JS enough to find that it's more like a nuclear powered .50 cal Gatling gun.

We hate JavaScript, because writing the code below is a perfect valid way of calling alert(1).

    [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+ [])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

That's a feature if most of the keys on your keyboard are broken. :)

Seriously, it is not a good reason. Just don't write code like this nor allow other people in your team to write code like this. Fortunately, this kind of code is unlikely to be written by mistake so it is easily avoidable.

That was just one example, there are lots of other WATs.

As for team, in enterprise consulting, the concept of team is very shallow.

I initially believed it was a sarcasm!

Are you familiar with Gary Bernhardt's talk "Wat"? (https://www.destroyallsoftware.com/talks/wat)

I don't think it's that productive to judge a language on the worst features and edge cases that most teams will be able to easily reach consensus on avoiding, as every language will have its bullshit.

>I don't think it's that productive to judge a language on the worst features and edge cases that most teams will be able to easily reach consensus on avoiding

Only those edge cases merely expose functionality that can burn programmers on an everyday basis, like coercion rules.

It's not something that you have to get out of your way to get.

These same obfuscations exist in many, many other languages.

I imagine they hate those other languages too.

You do know there are many, many languages where that sort of obfuscation lay between difficult to impossible, right?

Why would you ever write such a thing?

You wouldn't. The argument is so straw-man that it verges on trolling.

Actually you don't have to write such a thing to get the same BS behavior, and it's not a strawman at all.

It's just a side-product of JS god-broken coercion rules and types, and those affect every statement one writes, down to the suggestion to use === instead of == for the most fundamental thing any language does: equality comparison.

The example is just meant to showcase how far the brokeness can be taken...

Actually I like the ability to == all known ducks. There are a lot of cases that we run into like a DB that we have no control over where they use null, '' or 0 as some form of indicator of no value, it's nice to be able to ignore all of those cases when one does not have control over the quality of data coming in the pipe.

I tend to favor the mantra of be a liberal when consuming data and a conservative when exporting data and I find the == vs === does that very well. Sure it's a gotcha but no big surprise to most people that have been doing JS for any amount of time. I personally think it is a brilliant feature that save a lot of boilerplate when one understands the difference.

It's an effective way of obfuscating malware, for one thing.

Surely not. It would be easy to spot.

Obfuscation doesn't necessarily need to be hard to spot, just hard to understand. Like, could you spot this in a chunk of minified code? Probably. Would you be able to figure out what was going on? Probably not without some difficulty.

If it's hard to understand like that then I would be automatically suspicious of it.

>I think instead the real issue is that we're too bad at educating people in how to properly use the language.

I don't think this is true at all. I think over time it becomes very easy to apologize for the environment we're forced to use, because there is no comparison, we only have JS for the web.

In any decent project, you're going to have hundreds of 3rd party dependencies installed from tons of sources, some of which could freely introduce exploits into popular programs at any time. If any of these break, you're going on a long hunt to track it down, ultimately to be met with authors that aren't responsive or some bug caused by god knows what incompatability.

We're stuck between the ever flowing battle of new language constructs and languages ontop of JS that try to make it 'easier'. JS lacks very important things that devs have found to be necessary, like typings, and even trying to add typings is a huge battle in itself, that again, is ever changing. Just try and google for where you should put your .d.ts files, and you'l get 4 different answers, all from different stages of versions and recommendations.

You can't teach JS. You can only say that things never stay the same, so build things fast and break them quicker. What you consider 'properly' today, is tomorrows bad practice.

You can put //@flow at the top of your files and install a plugin for your editor and have typing in about 30 seconds.

See, thats the thing though. There's so many ways to do something, with multiple competing standards on how to do it, along with plenty of quirks and ways of working with it you only understand by experience. This is good, when you already know exactly what you need and what that provides, but its impossible to keep up unless you're spending a lot of time testing and researching, and even still, at the end of the day you've gotta make the application.

One of those 'it takes a village' to make a good JS app.

a village?! Come on healthcare.gov ...

I agree, JS is quite an elegant language, especially since ES6.

I'm kind of disappointed with the introduction of the 'class' keyword though (and the way it was implemented). The old prototype function declaration approach is really good once you understand it.

I do like how the prototype way makes it more clear that it's just a function. What about you?

I find that an implementation detail that most people don't care about in their use of prototypes.

I don't follow

Prototypes in js are almost always used in a way that approximates classical classes, but with confusing syntax. The 'class' keyword just makes things more readable.

> seasoned JavaScript developer you simply know to ignore those corners

I'm sorry, but how does a seasoned Javascript developer ignores the absence of compile-time type checks? Aside from switching to a language that compiles to Javascript.

You can't have a language that satisfies both camps. Some like statically typed languages, some don't. Stating that it's an inferior language because it's not statically typed is just plain wrong. I accept that you belong to the statically typed camp, and that's awesome. But don't be fooled into thinking that it's somehow better - it's just a different approach to programming. If you like it, then that's cool.

I guess I'm a seasoned JS developer.

If I needed compile time type checks for a snippet of code, I would use a language with compile time type checking that compiles to JavaScript.

If I needed compile time type checks for many snippets of code, I would take a few days off and rethink my architecture. Ask myself why my call sites are so brittle or confusing that I am making frequent type errors.

Well said, came to say this.

There are many popular dynamically typed languages.

Why is it suddenly a foregone conclusion that seasoned Javascript developers all want compiled statically typed languages?

I know that it's a very old argument that I'm not going to win. But I would like to provoke you to it because I'm really trying to change my mindset, coming from a static language to Javascript - and I still just don't see, where are the wins.

Please argue with me, because I _want_ to be convinced. I'm trying.

It may be because of the habits I developed, writing compiled code. I always would first concentrate on my concepts, things that I want the code to do, data and flow structure - while keeping all errors (even syntax) silent. And only when I got everything I wanted implemented and consistent, I would turn to a compiler to quickly fix all mismatches in API, all wrong method names and other trivial blunders.

Now I stumble, feeling that I'm a blind man going through a minefield. Every line I write, I have to think about the things that I want to express and the mechanics of language and API simultaneously - because nothing's got my back. (Yes, I know that I should write unit tests, but not all of us have the luxury of working on perfect projects, starting perfect projects from scratch, or having the resources of putting good practices into legacy code).

Every time I discover that I mistyped the name of the function or variable, forgot to use "this" when referring to an object property (C# habit), forgot that external API function returns a custom type and not a string - I do it too late. Instead of quickly fixing the thing that I've only typed right now, I have to go back, and spend time reading and understanding relevant code again.

All I'm trying to understand is, where are the trade-offs? Where are all the awesome dynamic things that make all that worth it?

The trade-offs are that the language implementer has an easier time of it (once), then every programmer has to expend extra effort writing the code (a lot of the time), the computer has to work harder running it (every time), and code browsing/refactoring/etc. tools are literally never, not even in theory, going to work 100% perfectly.

Now, if you're writing a programming language, this probably seems pretty awesome...

I wrote on my blog about some of the annoyances that come with type checking:

Type Checking vs. Metaprogramming: http://www.oilshell.org/blog/2016/12/05.html

http://www.oilshell.org/blog/2017/01/21.html (at the end, pretty printing requires metaprogramming, or escaping into another language)

Whenever you have a code generator like an ORM, or protobuf-like schema languages, you can use metaprogramming instead. Generally I think this helps the program so you don't have these impenetrable walls between layers, where one person understands one side and the other person understands the other.

I find that a lot of programmers coming from statically typed languages are writing Java in Python, or Java in JavaScript. In Java you don't really think in terms of metaprogramming.

If that's the case, then it is going to feel annoying. You're getting all the downsides without any of the upsides.

I would look at Go for other examples of the downsides -- namely the lack of generics. Go is attracting a lot of Python and Ruby programmers.

In Go, you can't write basic generic functions like max(), map(), filter(), and sort() -- in JavaScript and other dynamic languages this is not something you would think twice about.

I guess between metaprogramming and generics, dynamic languages let you write more abstract and concise programs. Programming in statically typed languages feels repetitive to me, and the architecture is quite clunky unless you are doing textual code generation.

Steve Yegge also has a bunch of good posts about dynamic languages.

Thanks for the honest question. I think it's important to remember that there are tradeoffs. I fully admit that type checking is useful in many circumstances. I would like the best of both worlds. I'm a little disappointed that recent hybrid languages like Dart and to some extent Racket have had problems with optional typing and gradual typing. It is something I'm interested in but it seems like an unsolved problem.

I can see benefits of metaprogramming in quite a few very specific tasks - but most of developers who are using Javascript day in and out aren't writing compilers. We're writing business logic. And because this logic comes from human, fuzzy rules, to accurately represent all the corner cases and not drive the code into a globe of insane parameters and checks, one have to get into a mindset of _not_ trying to generalize things.

Thanks for "When Polymorphism Fails" link, it was a wonderful read. I've actually run into such situations a couple of times - but in my experience, you want most of your methods to be statically checked, and only a minority of them to be added and checked dynamically in runtime. May be the solution is to have two different method tables, that look and behave in a different way?

Yes I totally believe that part of the static vs. dynamic debate is different use cases.

However I will point out that probably 80% of the world's top websites are written in dynamic languages -- Wikipedia, Facebook, Yahoo, YouTube, Reddit, etc. (that's not even counting the JavaScript.)

So there is something about that use case and dynamic languages... That's not to say a language is great because it's used widely. But it means that it must be getting something right, and not doing other things too badly.

So yeah all I'm saying is that there's a tradeoff. If there's was no tradeoff, then it would have never have swung toward dynamic languages in the 90's/2000's. It's not like we didn't have statically typed languages before the web. But things swung that way, and it sounds like they're swinging back, with PHP, Python, and JavaScript all getting optional types in one way or another.

I don't really think so. F# and Haskell are WAY more expressive and compact than JavaScript. And they have probably among the best statically typed systems out there. I guess you didn't use many languages in your career if you are in awe of JavaScript expressiveness..

There are linting tools that you can and should add to your text editor of choice. Whenever I reference a variable in JS, if that variable is not assigned it highlights it as a possible error. If I define a variable or function and don't use it, that gets highlighted too. If my syntax is wrong, that gets highlighted. If my team had decided that we only want to use single quotes around strings, that gets highlighted. Even our build will complain and our tests will fail because we have incorporated linting into them. With ES6 there is no reason to have global variables anymore, so it is possible to confidently identify all these errors before the code is even run.

The language is constantly being improved while maintaining backwards compatibility. Finally it's ability to handle whatever kind of data you throw at it until you choose to check the data is a strength in an environment (web pages) where nothing is certain. You aren't sure about the data you will get from an API, from the user, you don't even know what kind of environment your code will be run in! The same code might run on the latest version of Chrome, a headless test environment, or some old version of Internet Explorer. And that is totally possible. It's all up to how you code it. And you have to get used to coding in this type of language. You can and should test your code as you go along, no need to wait to compile, you can see the results right away. Build your code to handle errors, because even if the code is perfect, the data you are working with will not be. And have lots of tests. Not only do they identify current errors in the code, but they allow you to make large changes with confidence that everything else is still working like it should.

You're bolting on an optional, incomplete compiler to make up for the shortcomings in the environment.

I jist can't deal with the sloppy wild west way Javascript world works.

It's alright, I have no interest in an argument :-)

I like Javascript, and that's enough for me - and I (in _most_ situations) find dynamic typing more of a benefit than hindrance; but I don't mean to purport that my perspective is everyone's perspective :-) IMO it's very plausible that dynamic typing will never be better for you; because we're all different and we don't all like the same thing. If you've come to learn that dynamic typing doesn't suit you, act accordingly, don't just try to change yourself because something else works for others.

If you're interested in static typing, maybe try moving to Typescript? AFAIU it also integrates fairly well with normal Javascript, and hence maybe it's more to your taste? And if there are other people feeling the same way you are on your projects, it mightn't be too difficult to move new (or maybe a subset of new) development to something more your taste instead? (I've heard good things about Flow as well, and maybe it's simpler to "sneak in" to your projects, and offers big enough benefits for you?)

In my experience, legacy projects (or projects where there's pressure to cut corners (eg unit tests)) are often the bigger issue than the language. (eg I've been "in pain" working with code in languages I otherwise like that was obviously done in a big hurry, or evolved obviously from clumsy requirements and hence has big inconsistencies.

(As an actual example of a reason _that applies to me_, the last Javascript project I worked on ran the integration tests faster than the last compiled statically typed project compiled (and reloaded) - hence I ran the tests in a watching process, and felt more productive and less frustrated. And yeah, I haven't written `this` for a very long time :-p )

i rarely think of types when writing JS. where something is not obvious, like i forgot if it returned a string or object i write an error that will throw if my expectations are wrong. i call them sanity checks. also where something is not obvious you want to rename it so it becomes obvious. so you kinda replace type annotations with better easier to understand names.

Dude.

I've always thought that Javascript makes up for its lack of compile-time guarantees with compensating tooling.

For example, it's common to use Flow with Javascript to enable static type checking before actually running it.

The language itself doesn't guarantee type safety, but when used with peripheral tooling, the developer isn't missing too much.

We write tests.

Really, I find compile time checks to be moot when you have fast running and good unit tests.

Yeah, that whole suite of tests that you don't have to write yourself (or, more likely, you were never going to write, if you had to do it yourself...) that runs automatically every time called a compiler.

That's misleading. You don't write tests to check types. You write the same tests you would with a typed language. There is no extra work.

A by product of testing your logic is that it will fail if there is a type cast problem.

Having a monopoly could potentially be a great thing, no more tech-change anxiety, consolidation of effort etc

But there is so little structure, and so many roll-your-own efforts, the JS world is heavily fragmented...

> we're too bad at educating people in how to properly use the language

Does such a thing exist? How does a seasoned JS dev avoid DOM manipulation/interference nightmares, lack of typing, event hierarchy complexity? How do you really make a modular site without heavily committing to one framework?

> ideal of a perfect language is a pipe dream

Nothing's perfect, but still keep fighting for better.

I think we know how to teach it but we can't agree on how to use it. How many shops are more then happy to cut corners, pull in gigantic misunderstood 3rd party libs, green light advertisers code, allow unsupervised and under-trained juniors to contribute if it "looks right", etc. etc. Bottom line is the business and administrative aspects of language usage are loosely defined with javascript and it makes our lives as engineers slightly less pleasant (or potentially extremely unpleasant depending on what you have to work on).

And the world keeps spinning.

> I think it's a common misconception that JavaScript isn't an elegant language.

1 + 'a' = "1a", I've seen more ellegant solutions, I'd love JS to be strongly typed at least (without typescript).

I'm not nearly so concerned with elegance as I am with being able to manage memory simply. the GC and "needed" detection lend themselves, how shall I say, to complexity.

GC is often better at the job then humans. you can manage memory in JS yourself though by not crating new objects and using pre alloc buffers instead.