I come from a background of strongly typed languages -- Pascal, Modula 2, Ada -- and to me most of this is pedantic nonsense that fails to leverage the entire reason JavaScript is dynamically typed.

The "getPrice" is a stunning example of this. Testing for if it's numeric or string gives a powerful and easy to use trigger... though I'd use null... and I'd not use else after a return... nor would I even have two separate returns since this looks like the job for a ternary.

That's a hot wet mess for what I'd write as:

return (count < 0) ? null : count * 100;

Using the fact it's a type mismatch ON PURPOSE!

Kind of like the abuse of the word "closure" that's so hot and trendy right now, the derpitude of declaring a fixed height in pixels, the nesting in said "closure" section that could be avoided by not using a "function for nothing' inside getResult, the LACK of code clarity the dumbass arrow function garbage brings to the table, the card-statcked BAD prototype example (that would likely be better served by using defineProperties to make getters)...

Which is just part of why the shoe-horning of "class" from other languages into JavaScript is just more derp derp derp...

That said class doesn't even have the defining parameters correct, is missing a this, and is using a ternary on a boolean…

This would be a better approach:

function Person(firstName, lastName, age) {
  this.firstName = firstName;
  this.lastNAme = lastName;
  this.age = age.
}
Object.defineProperties(Person.prototype, {
  fullName : {
    get : function() {
      return this.firstName + ' ' + this.lastName;
    }
  },
  isAdult : {
    get : function() {
      return this.age >= 18;
    }
  }
});

Since this way the functions can behave as properties. You just “if (myPerson.isAdult) {“ instead of “if (myPerson.isAdault())”. Hell, I’d be tempted to set the various “this” properties using the same methodology, just to make them immutable.

Much less the template string crap being used to make HTML, the LAST thing you should be doing in JavaScript (well, at least client-side. Server-side it makes sense).

Don’t even get me started on the whole “timeout for nothing” rubbish since they’re all the same timeout set at the same time, meaning there’s no reason for them to be separate. Much less if you wanted them to timeout 100ms apart, your best bet would be to scope and daisy chain. I THINK you meant to do this:

{
  let count = 0;
  function countCallback() {
    console.log(count);
    if (++count <= 10) setTimeout(countCallback, 100);
  }
  setTimeout(countCallback, 100);
}

I usually dislike LET, but in this case it gives us scoping without a IIFE. In this version there’s actually a REASON for the timeout and they won’t all blindly try to run near simultaneously.

And again, another instance of a ternary where it is pointless, since comparisons already inherently return boolean.

To be frank that you goof even the simplest of things — like the use of “else after return” and ternary on boolean to return boolean — seems proof you don’t know enough JavaScript to be making authoritative claims of what good script writing is.

Of course it's all ES6 stuff which for many of us is NOT real world deployable yet.