"Let" feels utterly pointless and worse, introduces unnecessary memory thrashing. If you "need" that fine a granularity of scope you are doing something horrifyingly wrong in your codebase such as re-using variable names in a confusing manner. Worse, because they don't lift you increase stack allocations and de-allocations since lifting was added to the language to address the fact it's not forward declarative. (Something C gets away with because it's designed for multi-pass compilation so all those inner scopes can be allocated at function entry)
When I said I wanted constants, "const" is not what I was asking for. I guess I should have said DEFINE. Though it would be nice if we could have unmutable object properties with something a bit less convoluted than defineProperty. See, the problem for me is that they are scoped, the one place I don't need constants! (unless it were a property on an object's "this") Then that whole "Symbol" thing almost sounds like what I want, except it's so poorly documented and explained you'd almost think it was a W3C specification.
The old joke, W3C specifications read like they were written in Finnish, translated to Japanese by a Russian, then Google translated to Engrish moist goodry me love you long time. There's a reason we all pretty much go straight to third party tutorials instead of the specification to learn the... uhm... "specification". I swear there are sections of the ECMAScript, CSS, and HTML specifications that you need to hire a gaggle of lawyers to explain.
Arrow functions are another thing that just takes the already agonizingly painfully cryptic BS the language inherited from C (I'm a Wirth guy) and makes it all the more complex and difficult to follow. And for what, one minor distinction in how "this" is handled and "wah wah, eyes bee two layzee too tiep teh wurd function"?!?
Though what's really annoying about arrow functions is how everyone is throwing them into code for nothing, often where callbacks and some newer methods -- like foreach -- are less efficient -- often painfully so -- than a simple old-fashined for loop.
But then when people don't even seem to realize that ANY expression can go in the middle of "for" what can you expect. There's a lot of new stuff people are just using without thinking about "is this an improvement over the old way or not" -- and the answer is quite often not!
"For" example rimshot I keep seeing stuff like this:
let allSpans = document.querySelectorAll('span');
allSpans.foreach((span) => {
// process span here
});
Thing is if you're using an immediate function on foreach, why are you even using a function? Much less, see the flub using querySelectorAll that has to go through every selector instead of getElemetnsByTagName which only searches tagName typically from a pre-built lookup table?
This:
for (var span of document.getElementsByTagName('span')) {
// process span here
}
.. and of course the pointer for 'span' would be allocated on function entry, which is why I wrap all my scripts in IIFE meaning scope bleed is a non-issue anyways. But if it really bugs you, fine, use let there. Don't even need the extra variable.
... and because we have removed the overhead of the function callback, it executes many, many, MANY times faster.
But then it often seems so many people are unaware of the highly powerful for/of. Not surprising when most people operating on nodeLists continued to brute force things in their legacy support instead of just:
var allSpans = document.querySelectorAll('span');
for (var i = 0, span = allSpans[i]; i++) {
// process span here
}
Basically if you need for/of in browsers that don't support it on a nodeList or other array iterable where you know none of your values are loose false, that's the fastest way to go through them. It's funny because that technique seemed to be gaining traction back in '03, but by '08 it had all but disappeared -- never could figure out why.
Even the examples given in various tutorials are -- IMHO garbage. For example I've seen this dozens of places:
this.nums.forEach((v) => {
if (v % 5 === 0) this.fives.push(v)
});
Why would you EVER do that -- especially if you like 'let' -- instead of:
for (let v of this.nums) {
if (v % 5 === 0) this.fives.push(v);
}
I don't get it. MAYBE for event handlers, but is it really THAT hard to do "function(e) {" instead of "(e) => {"... I know which one I'd rather look at if I'm trying to write comprehensible code, and it's not the flipping arrow functions!
Generally though this whole let, const, arrow function, and endless callback methods thing is introducing excess overhead and reducing code clarity, two things that always raise the hackles on my hackles.
That said, things like classList were riduculously overdue, shame that because browser implementations seem to work off the Array instead of the className string methods like classList.add, classList.remove and so forth end up slower than any decent regex polyfill for them. Which is sad when a regex or even multiple regex brute-forced by your own functions are faster than the native methods, but that's JavaScript arrays for you! Probably because they aren't actually Arrays, they're pointered lists!
That's not so much a problem with the specification though as it is the implementation. Honestly I don't think the 'array' part of classList should have even been a 'thing'.
I do think that proper Class declarations were a good idea, but to be frank the implementation feels as ugly and shoe-horned in as C++'s nasty slopped in any-old-way object implementation. (again, my prejudice is showing. I learned objects in smalltalk, object pascal, modula, and ADA) To the point that honestly, declaring conventional object as the constructor and using object.prototype as a object literal actually feels like a more reasonable approach -- even if extending the object in a new instance can be a bit of a wonk since you have to spin your own clone method.
A lot of things strike me as just encouraging bad practices; see "block scoped functions" where if you want another function, give it a new name. I've already hit up against namespace hell from people reusing variable and function names all over the place inside the same parent function. It's a confusing inconsistent mess that after some four decades of writing code, I really question what greenhorn came up with the idea.
"template strings" is another of the C mentality garbage I never wanted to see make its way over to JavaScript. I have always found C's printf to be confusing hard to follow garbage; I want to see that string closed, the variable there, and that string opened again for code clarity, not some goofy hard to follow handlebars type bull that for me often triggers false positives. This is only made worse by the allowance of operations inside it, which strikes me as the same type of foolhardiness as using "eval"!
It's all part of why I've come to the conclusion that when people say "syntactic sugar" what they mean is "cryptic to the point of intentionally trying to make programming harder than it has to be".
All that said, I love all the destructuring on assignment stuff, computed properties, the WAY past due proper unicode support, the new parameter handling that's way less of a headache than the "arguments" array, typed arrays (or as I call them, actual huffing arrays!)...
... and a lot of it I'm just indifferent to as it's not anything I would use when writing JavaScript; such as the moving of certain functions out of the global space and onto their associated objects. All this has done (for me) is result in having to type String(myVar) or Number(myVar) around a bunch of things to use the old method, resulting in zero real-world improvement. Oh noes, library functions in the global space!!! AAAAAAAAH!!! I swear it had to be some die-hard Java fanboy who thought JavaScript needed that.
Which makes sense given the mass exodus we've seen from Java to node.js by "people who follow the hot and trendy" if you think about it.
I can see that for consistency sake, but it's not really anything I think they should have wasted time on.
... and there are things that I understand, but would prefer to just avoid. Promises for example to me are a pointless addition for a language that's pretty much inherently single-threaded. It's at best a crutch for people who can't handle async coding, at worst a way to make a convoluted mess out of the simplest of things.
Shame for 99%+ of what I'm writing these days I can't even deploy a single bit of ES6, since I mostly work client-side where you can't even guarantee it exists yet. (though I have a side project I'm building in Electron that will definitely leverage a lot of it!) I'm sure if I did more with node.js other than ripping out large chunks of code and garbage frameworks that are screwing over clients, taking hundreds of K of code and reducing it to dozens, I'd have a better understanding of why some of this exists.
Although arrow functions do have a nice side-effect in that regard. Because IE has no clue what to make of them, their mere presence will make your entire script fail to even execute. I actually used that instead of browser sniffing or capabilities detection on a recent project so that the site could gracefully fall back to the non-scripted functionality, ignoring the attempt at scripting enhancement altogether.
But then client-side I write all my pages so that the page's base functionality and the most important thing a website can do -- delivering content -- works before I even think about adding JavaScript to the page. My scripting is there to enhance the user experience, not be the only means of providing it. As my buddy Dan used to say:
If you can't make a fully functioning useful page without client-side JavaScript first, you likely have zero business adding scripting to it!