Except they will actually deal with all of it. First question I get is usually "what is var" followed by "when do I use arrow functions and when do I use normal functions" shortly followed by "why does this code work with a normal function but not with an arrow function" or "why does my code using classes and arrow functions not work on [ancient browser some family member has for some reason]?". I'll also get numerous questions about whether it is a good practice to do things like `x++` where `x` is a string because they noticed that it happens to work and legitimately want to know if this is good practice / by design (oof). Don't even get me started on the "equality in js" discussion.

The key problem with js is the relationship between objects and functions is extremely confusing. You end up having to explain associative arrays, and spend 30+ minutes doing some hand-waving to even begin to describe what an object actually is in JavaScript. Then they get it. Contrast that with something like Java or even Rust where, despite the other complexities, it's pretty clear what the data is and how it is stored.

That sounds like a pedagogy problem, not a language problem. From my experience [1], students learn JS just fine as a first language, as long as the learning process is structured well. Every practical language has its quirks, and no one learns a programming language by learning all the quirks at one time. You can be productive in JS without understanding all of the quirks, and then build up to that later.

When you're teaching, you should be enabling the student to do one more thing that they couldn't do before. If you're spending 30+ minutes trying to explain what an object is, you're trying to do way too much. You don't need to have a 100% complete and correct understanding of Javascript's object model to use objects.

> Contrast that with something like Java or even Rust where, despite the other complexities, it's pretty clear what the data is and how it is stored.

That's nonsense. Particularly with Rust, now you're deep in the weeds of pointers, stack vs heap vs other segments, and borrow checking rules.

[1] helped design a JS class at Stanford for first-time programmers. Also designed an intro Rust class.

Right but this is my point. The bootcamp does a terrible job explaining this stuff, so I have to re-teach it in my mentoring sessions.

You have to deal with every idiosyncrasy as soon as you begin using external dependencies (and even many standard browser features), because there is no standard convention at any one time, much less over time. There is no fixed paradigm, no common way of doing things, and so the student must first understand how each library frames the world differently, and then work out how to composite those worlds into anything approaching coherence.

Learning an additional, "learning language", be it a real language like Pascal or an entirely conceptual/theoretical language like pseudocode or flowchart is the only way to become a programmer.

Programming is a very particular and abstract way to look at performing a task and most people need to be eased into it, trained to think like a computer.

This ideea that you can take a shoe salesman, make them "proficient" at JavaScript, and let them loose in the job market is a bit strange. It might work for a very limited number of people with an knack for it, but most people I've seen will approach the task as some sort of incantation of magic formulas that make the computer work. When the complexity of the task exceeds what can be achieved with magic formulas, they give up in frustration.