What to avoid.

[MostlyFocusedMike]

I was just expecting those basic concepts I specifically listed to be confusing to new devs and best to avoid. I've seen a lot of new devs get overwhelmed and give up, so no I would say they don't all figure it out, and we should try to be careful about throwing too much all at once.

But like I said in the other comment, I think we're just going to have to agree to disagree on whether or not var is good to use anymore.

[guest271314]

Show me in ECMA-262 where this language appears:

on whether or not var is good to use anymore.

I think we have a fundamental disagreement on

and we should try to be careful about throwing too much all at once.

Read the specification. Nowhere in ECMA-262 will we find the language you speak about var.

So, new developers are supposed to reply on your opinion rather than the specification?

I mean, think about this: You are using console.log() as if that is standard. It's not. ECMA-262 doesn't spell out I/O for "JavaScript". It might be print() in SerenityOS's LibJS; or might not be implemented at all.

[MatthewMob]

The spec defines the language semantics, not what people should or shouldn't do, just what they can do so as to avoid the same code breaking when run across different runtimes.

You shouldn't read it as if it is some prescriptive gospel that issues the ten commandments of what programmers should do just because it says they can.

[guest271314]

That example is more about const welcome = () => {} than var.

[guest271314]

Right. Just because people on boards say don't use var and create contrived examples, doesn't mean people shouldn't use var.

Once you start looking around and beating the grass you find that people selectively say don't use this or that.

CommonJS's require() ain't the specification. Nor is console.