Is JavaScript getting worse?

I happen to know all this; what I wanted to stress is not the nature of closures, which is exactly as you say, but that they were used since long ago in a "purely object oriented" languages, which - AFAIK - are not meant to implement lambda calculus in any shape or form.

GP wrote that - in short "everything in OOP is bad, let's use FP only". I responded with an argument that, in fact, certain OOP languages used FP features long before Haskell (because that's the example GP provided). I don't think the fact that closures are just one interpretation of an abstract concept of "lambda" is very relevant to this argument.

And about "shaming" people: I meant to gently point out that advocates for some cause should at the very least get their facts straight. Bashing some concept without knowing it well is the thing I objected to, a "not knowing it well" part by itself wouldn't be anything one should feel ashamed of.

Classes are just functions for constructing certain kinds of objects using open recursion. There's nothing wrong with them per se, but their elevated status is confusing. It also might lead to trying to solve all complexity concerns using open recursion. I'm interested in clear analysis about how good or bad that idea is honestly. At this point I just find it (a) not personally necessary and (b) interesting.

As to the author's problem? I imagine it might have some deep seated cause related to the above, but that keeps getting translated to abstract disdain for the concept. Which is tragic.

So classes in ES6 are something I have very mixed feelings about, on one hand all that is being added is syntactic sugar for what is already being done, I'd like to repeat that ES6 classes add NOTHING that isn't already being done and all it really does is pave the cowpath that is being used in places like node

Currently:

    JSONParseStream.prototype = Object.create(Transform.prototype);
    function JSONParseStream(options) {

    Transform.call(this, options);
        ...
    }
   
    JSONParseStream.prototype = Object.create(Transform.prototype);

    Object.defineProperty(JSONParseStream.prototype, 'constructor', {
        value: JSONParseStream,
        enumerable: false,
        writable: true,
        configurable: true
    }

    JSONParseStream.prototype._transform = function(chunk, encoding, cb) {
        ...
    }

With ES6:

    class JSONParseStream extends Transform {
        constructor(options) {
            super(options);
            ...
        },
        _transform(chunk, encoding, cb) {
            ...
        }
    }

That being said, the fact that previously you could not simply use the word class meant that despite efforts of people unused to the language (let me tell you how many half assed class libraries i've seen in code written by people who mainly code in python or java but have some web code as well), unnecessary inheritance tends to be avoided. The lack of a class keyword tends to get javascript writers to avoid inheritance for things best served by mix-ins or object literals, or whatever. I predict that adding the class keyword, while saving me some time will also cause an uptick to unnecessarily convoluted inheritance patterns as new users find they can implement all of their design patterns verbatim without thinking if they really need the ajax method, the json parser, and the url builder to all be in objects that inherit from each other.

> Now, sometimes it will throw.

No, typeof /isn't/ throwing.

    let x = 1;
	function some_random_function(y) { }
	(function() {
		some_random_function(x);
		let x = 2;
	})();

This will throw the same exception for exactly the same reason. You're using a variable defined using "let" before the variable definition. Sod all to do with typeof.

I don't see it as massively confusing that a variable declared one way behaves differently to a variable declared another way. That's the whole point of having a new way of declaring a variable.

Why isn't everyone up in arms about how confusing it is that it behaves differently here?

    (function() {
		var x = 1;
	    if (true) {
		    var x = 10;
		}
		console.log(x); // Will print 10
	})();
	
	(function() {
		let x = 1;
		if (true) {
			let x = 10;
		}
		console.log(x); // Will print 1
	})();
	

Oh no, if I use "let" it behaves differently to "var"!

Its not like its throwing on unexpected data, its throwing because the program isn't constructed properly. This is the same as just about every other language.

Are you really saying we shouldn't make improvements to the language because then it would behave differently to the old, poorly designed features we're trying to deprecate?

[edit] You still can use typeof to check if something is defined without throwing on spurious inputs. The only time the code will throw is if you make changes to further down in the lexical scope. And guess what - whether you do that with var or with let you've changed the argument of typeof to refer to a different variable. Except with var it will likely silently fail in a hard to track down way, while with let it will error in an obvious place.

    let data;
    function sanitizeData() {
        if (typeof data === 'undefined') {
            // data not yet set
            return;
        }
        // sanitize data in place
    }

No matter what you put in data, "typeof data" is never going to throw an exception.

The only way to get it to throw an exception is to change sanitizeData to add a variable shadowing "data" from the parent scope.

    let data;
    function sanitizeData() {
        if (typeof data === 'undefined') {
            // data not yet set
            return;
        }
        // sanitize data in place
        var data = ...;
        // sanitize data in place
    }

If I use var, sanitizeData doesn't do anything and I spent a while hunting the issue down.

    let data;
    function sanitizeData() {
        if (typeof data === 'undefined') {
            // data not yet set
            return;
        }
        // sanitize data in place
        let data = ...;
        // sanitize data in place
    }

If I use let, sanitizeData throws as soon as it's called and I can track down the issue much quicker.

The only time "typeof throws an exception" is if you add a let statement later in the lexical scope in a place where if you added a var statement, it would completely change the behaviour of your code in a way you almost certainly didn't want it to.

I think the concern is simple, really.

People are going to be told (rightly so) to use `let` instead of `var`. If they do so too mechanically, and their code is structured in certain ways, an expression which could never before throw an exception in Javascript, `typeof x`, now will do so.

This is not the end of the world, by any means. And it doesn't add an exception into unchanged code, but it still is a legitimate concern.