A junior developer who is just learning how to code will not deal with all of JS historical baggage; they will deal with historical JS when joining a large historical codebase. A junior developer will also not be dealing with the different quirks arising from different browser runtimes. These are concerns for businesses who already have products.
But a Student does not encounter these things while learning and writing greenfield apps. Otherwise we are advocating for a student to learn an additional "learning" language. That sounds ideal for a 4 year university program.
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.
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.
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.
Also, most languages have quirks. What are you going to teach them? Python, which also has almost 30 years of baggage? Java, which requires you to spend significantly more time to produce basic functionality? Haskell, so they can gloat about the power of purity and monads on Hacker News?
I understand that javascript might not be the ideal intro language in theory. But I think it probably is the best one in the bootcamp specific use case.
Ruby's also got a much better web dev story, which is good for junior devs (without ML and/or infrastructure backgrounds) who are looking to enter the market. After learning Ruby, either JS or Java could be a great 2nd language.
> It's much more beginner friendly and is a thoroughly consistent OO language—i.e., everything is an object, including numbers and strings.
This sort of thing occurs to you and me and makes sense because we have a broader understanding of software engineering. In practice, I just don't think "everything is an object" means much to someone who's a month into a bootcamp.
IMO learning very beginner-friendly language like Ruby to a low-intermediate level first actually speeds up the process of getting to an employable level with a more difficult language like JS.
Elm would probably work too.
With Java you will spend a huge amount of time on pointless ceremony that can seem important to a beginner but is really pedantic enforcement of programming preferences from the Java designers (everything is a class for example).
With Python you have a pretty easy language but the dependency management situation is a disaster. Python in a Google Colab notebook where everything is pre-installed could be good.
Dependency management with either Java or Python is PITA IMO, but my idea would be to avoid dependencies during this initial phase of learning the basics.
On one hand, it seems like an antiquated curriculum. On the other hand, a surprising number of mid-sized companies still run on Rails or Django.
(I don't comment on the usefulness of Rails and Django to small companies and individuals, because they're not the ones hiring bootcamp grads.)
The other thing about Python is that, because it's already so popular for teaching, it has an ecosystem of tools around that. E.g. it has turtle graphics in the standard library (!), which is a very good way to explain loops, recursion etc for visual learners. There's also IDEs like https://thonny.org/ that visualize program execution step-by-step.
Also, the language has clear defects, but they irritate much more the experienced folks than the rookies (that are not so surprised when encountering inconsistencies).
Oh, and I have also trained many people using Java, and I initiated my dev career with Java 0.99 (or 0.98?). Most of my courses started with the sentence "let me tell you a joke: public static void main(String[] args)" :)
Eg just disallow for...in to be used at all (but allow for...of)
No iterating over objects except via eg Object.entries
No inheriting objects from other objects (ie no prototypal inheritance)
No var
No anonymous functions (ie only named function declarations or lambda/fat-arrow expressions, to avoid `this` binding gotchas)
Etc
I think the only real big blocker to a thing like this is that it'd need tooling (eg a transpiler that injects error throws at appropriate places), and tooling is another big hairy thing that makes JS less approachable for beginners.
It's almost like we could use a better frontend language. Too bad there isn't some magical universal assembly language supported by all major browsers we could use as a launchpad for such a thing ;)
Anyway, my point is, it's very important to make sure students understand that their confusion surrounding how things are structured in JavaScript is natural, and that they can (and should, on their own preferably) look forward to learning more stable/sensical languages in the near future. It's a shame I have to do this for my students instead of the course just doing it for me, however.