a) Don't use anonymous functions ... You want your program to be easy to understand, so come up with a name for the function and put it as a sub-function at the bottom of the current function.

b) I love the Nodejs implementation of modules and I would say it's the main reason behind Nodejs success. But it doesn't make sense in the HTTP world. Imagine having to download 100 dependency files each time you visit a webpage.

c) I have a keyboard macro for " + + ". So if you don't save an extra keystroke, what's the deal? It might be useful if you have nasty habits like building HTML or SQL by concatenating strings though. (don't do that).

d) Just declare your variables at the top of the function and stop worrying about scope, (while listening to Bobby McFerrin.)

e) I can somewhat agree here. But where it's really needed you should make a copy or clone function. And if it's not really needed you shouldn't. Makes you write less complicated code because of laziness.

f) Give it a name!

  function Car() {var car = this;} 

  var that = this;

h) It's possible to make async code intuitive. Stop using anonymous functions will help a lot! But it's not That easy. Promises is just another (ineffective; it just threats the symptoms) paradigm to reason with async code.

i) We don't need classes. The prototype already work great. It might be hard to learn but once you understand it's brilliant! (I don't blame you if you never will, it's hard to learn an old dog to sit).

I encourage you to use the paradigms you believe in, and also to try different solutions, and think outside the box. But don't force certain paradigms by changing the language itself. One exception being Node.js where you are forced into making modules. (but some people are stubborn and use Browserify to circumvent it).

Many of your suggestions are just optimizing for the current state of JS instead of thinking about how to best leverage the many brilliant syntactic advances from throughout the industry. I guess there's no point in arguing. Change is coming, and people can keep writing super verbose JS if they like; I'll be writing code that more directly reflects the actual important logic.

  var odds = evens.map(v => v + 1);

  var odds = increment(evens, n);

The only thing => does is to make the syntax more complex (and ugly) by saving a few keystrokes. And even worse, it's a treatment for a symptom from anonymous functions, that you shouldn't even use in the first place. And will be used everywhere, because we are lazy. But the time saved, will have to be used for mind juggling, to figure out what goes where in the syntax.

That said, I don't think all new stuff is useless. For example Object.defineProperty (ES5) that actually Adds to the language, and makes it possible to do things you couldn't do before. Like defining a set function.

  const vals = ['#hp','#mp','#gp'].map(x => $(x).val());

  var elems = ['#hp','#mp','#gp'];
  var getVal = function (x) { return $(x).val() };
  var mtVals = [];
  
  for (var x = 0; x < elems.length; x++) {
    mtVals.push(getVal(elems[x]));
  }

(basically just juggling data, you should make a real world example.)

I have seen Jquery before so I know $ returns a document element. And if you pass # into it, it will return getElementById(). And .val() returns .value

So my guess is that you want to get the values of hp, mp, gp, whatever that is. I don't understand why you want them in an array though!? Wouldn't it be better to store them in an associative array? So that you don't have to remember what position in the array points to what value.

Try this instead:

  var signupForm = getFormData("signupForm");
  alert( "Your name is " + signupForm["name"] );

  var name = document.getElementById("name").value;

Yes, I can see my preceding correspondent was correct in discontinuing this engagement. Sorry to have wasted our collective time.

If it's too long to type, and you use it often, make a macro for it. When naming stuff, keep it short and simple though.

Also, you shouldn't hide logic behind names. I was actually wrong about evens.map(v => v + 1); If that's what you want to do, then write that. It's a thin line though, it might be hard to know what "v" is in that context.