My confusions about TypeScript

That definitely clears up your point quite a lot, and there's a lot less distance between our positions than it seemed at first, so I really appreciate the clarification and your example.

I definitely agree in general with composition-over-inheritance approaches like the one you've demonstrated, especially if you have a wide variety of features that need to be combined depending on circumstance. But to be honest, I haven't really run into many circumstances IRL where it's been an issue.

To return to my specific example, I think there's a lot of value to be found in subclassing a common Model class to represent each table in my database, especially given the use fo static getters to represent metadata like which columns are the primary keys and how different tables are related. Additionally, while your example demonstrates how to simulate private instance vars using closures with the _name, _energy, and _breed vars, if you were to modify your example above to add these vars to the returned object and to add static properties to the factory functions, it just feels more and more to me like you're writing a polyfill for the class keyword. And at that point, I honestly feel that class declarations are far more readable than these sorts of factory functions, especially when you have several long-time Java devs on your team who are now coming up to speed on JavaScript (as I do) and you want to give them a graceful transition.

And that actually brings me to something else that I'd love to hear your feedback on. You said:

The complexity comes from Javascript's expression of classes being misleading and the headaches of trying to apply OOP on top of it.

This is something I've heard expressed many, many times by other devs, that JavaScript's classes are fundamentally different from classes in other languages in important ways that make them misleading to devs who transition from these other languages. But in my experience, having written classes in Java, Python, Ruby, and JavaScript (and, in case there's any doubt, as someone who has a very deep understanding of JavaScript's prototype system and how extends works under the hood), I just really haven't found that to be true, aside from the lack of certain functionality like private and protected members, which seem to be coming down the pipe anyhow.

So as someone who clearly has both a strong opinion on the subject and a better understanding of by-the-book OOP and classic design patterns than I do (admittedly, my theory suffers there), what do you see as the most important differences between classes in JavaScript and other languages, and most importantly, what do you see as misleading about them? I'm genuinely anxious to know, because I've recently entered a role where, as I mentioned, I'm training up a few long-time Java devs in the ways of the web, and I'm anxious to avoid any misconceptions.

Do you mean at the program layer? Is this really different than a class construct where as you pointed out the syntax doesn't require the function keyword?

I do mean at the program layer, yes. As far as whether it's really different than a class, I mean... yeah, it is. How would you restructure that program to use a class? Unless you want to go the Java route and use a Main class:

class Main {
  constructor() {
    const {sslInfo, outputFile} = this.processCmdLineArgs()

    const client = this.initClient(sslInfo)
    const rawMetrics = this.getRawMetrics(client)
    const metrics = this.processMetrics(rawMetrics)

    fs.writeFileSync(outputFile, JSON.stringify(metrics, null, 2))
  }

  processCmdLineArgs() {
    // ...
  }

  initClient(sslInfo) {
    // ...
  }

  getRawMetrics(client) {
    // ...
  }

  processMetrics(rawMetrics) {
    // ...
  }
}

// run Main
new Main()

If that's what you mean by using a class construct, then we just have very different preferences, because that's a nightmare to me.

But even if that's your personal preference, the point is that I still see plenty of code written this way by other developers, and it doesn't make sense unless you understand that function declarations are hoisted. My comment was mostly in response to when you said:

Lots of old school JavaScript interviewers will still ask you about "hoisting" which is non-existent by default with the Class. Why do anything but use the Class? If it's not an issue any longer, why do interviewers want to test your knowledge of "hoisting" even today?

My point is that hoisting is still a fundamental aspect of JavaScript and it's pretty important to understand, or at least be aware of, even if you have to look it up from time to time. Not understanding hoisting can lead to some subtle, hard-to-find bugs; I've been there a few times.

"ctrl+click my way into whichever part I need to read or mess with at the moment"

From the command line of an IDE? Or in browser console/debug mode?

Either, I suppose, though I was mostly thinking of an IDE context. My point is that anyone reading my code (including myself) can open the file and see the overview of the file, then quickly jump to the relevant function using standard IDE tools. And IIRC, ctrl+click works in browser dev tools' "Sources"/"Debug" tabs as well.

I hated AngularJs for the inability to get Service's to expose their properties and functions using Intellisense/Autocomplete. I think you are showing something that worked for AngularJs?

Totally agree, my biggest frustration with AngularJS is the total lack of intellisense. And no, unfortunately, this doesn't help with intellisense; in fact, it's more important in cases where intellisense doesn't work. The point is that when you see some code saying, dataService.getVendor(id), you can jump over to data-service.js, easily see the available methods, and ctrl+click stright to getVendor() without needing ctrl+f or other mechanisms. It's even more useful in a service that uses its own methods internally, since ctrl+f is less useful in that case.

How would you define Hoisting and when to use it over other constructs?

Hoisting is a step in the interpretation of a JavScript scope wherein all declarations are basically plucked out of their place in the script and moved to the top of the scope. It's not really something you use or don't use, it's just the way JavaScript works.

It's important to note, however, that declarations are hoisted, but initializations are not. So for example, in this code:

(function do() {
  console.log(x)
  var x = 10
})()
// Output:
// => undefined

You'll get undefined as your output. However, function declarations are special because they don't have separate declaration and initialization steps, it's all-in-one, so they get hoisted completely to the top:

(function do() {
  console.log(x)
  function x() { console.log('hey!') }
})()
// Output:
// => function x() { console.log('hey!') }

And const and let are a bit weirder. They do get hoisted, but there's this weird thing called the Temporal Dead Zone where they're defined but not initialized and you'll still get errors if you try to reference them... so a lot of people say they "aren't hoisted", which is technically not true, but it might as well be.

Hopefully that all made sense... it's a weird bit of rather esoteric JavaScript knowledge that you can basically look up when you need it.