Introduction to Object-Oriented JavaScript
developer.mozilla.org
developer.mozilla.org
https://medium.com/javascript-scene/the-two-pillars-of-javas...
However, JavaScript does have the "new" keyword, and I would argue that constructors are quite central to JavaScript and good idiomatic JavaScript uses them. And it exposes YourConstructor.prototype, which I would argue is also useful.
So I guess maybe you're saying something about the term OOP that I don't understand. Maybe OOP means "everything is an object" to you? Or it means multiple inheritance?
I guess I don't understand the distinction you're trying to draw when you say "not OOP".
1) Using object literals for values.
2) Using object literals with functions.
3) Using object literals with functions and calling them in contexts (`this`, `bind`, `apply`).
4) Using the `new` keyword.
5) Designing objects with inheritance hierarchies or prototype chains.
6) Designing mutable and stateful objects with indefinite life spans.
Personally, I go through 1-4 liberally and 5 and 6 conservatively. IMHO, complaints about inheritance mechanisms seem to have something in common with the people who talk about the special needs of "large-scale applications". Why not just make smaller apps, or make smaller things that compose with less knowledge of where they are?
NB: It's entirely possible that I haven't run into the kind of complex requirements where liberal inheritance is a good fit. I'd be interested in hearing stories about when that worked out well.
The easy answer to this is that successful apps have a tendency to grow larger than expected and splitting them up requires care and lots of work. Class based inheritance provides a familiar way to split up the state space via encapsulation. It provides some boundaries instead of none and theoretically allows you to separate out your concerns and not have to think about the system-wide implications when writing code in your class.
I'm in the functional camp and think classes aren't a great way to build software but I support the addition of `class` to ES6 since it shifts the ecosystem from a hundred slightly-incompatible versions to a single one. The mystery to me is why the people who advocate for JS classes are still writing JS rather than writing Typescript or Dart to further constrain their state space with a type system.
Either way, my point was that there are many other paradigms that have been equally successful; that suggests that we should be looking at its other objective downsides in determining whether or not to add it to a programming language, rather than simply assume that it should be there.
(edit... y'all, please let me have a little joke)
What a game needs is a database view of the world - not a strict formalized model like SQL, but a customized, mixed-paradigm mode of keeping a ton of global state organized. Game actors are not truly independent, they're a view on various fragments of data allocated semi-independently and late bound into some association. They're all part of one world.
Anyone who claims lambdas are somehow new to or incompatible with OOP clearly doesn't understand OOP, since lambdas have been an integral part of the most influential pure OO language (Smalltalk) for 40 years.
var savings = account(200);
savings('deposit')(200);
console.log(savings('amount')); // should print 400
savings('withdraw')(200);
console.log(savings('amount')); // should print 200
Eg there's the 'parasitic instantiation' and then there's the 'Constructor pattern' and then there's the 'Parasitic Constructor', and there's like 3 other patterns that have their own permutations. Coming from Python and then Java, where classes just work...it's kind of annoying.
[edit] I was being a bit hyperbolic, the book discussed 6 ways of inheritance in JS, those being (1) Prototype Chaining (2) Constructor Stealing (3) Combination Inheritance <- most popular one according to the book (4) Prototypal Inheritance (5) Parasitic Inheritance (6) Parasitic Combination Inheritance <- pattern that is generally the best according to the book
`class Foo extends Bar {}`
(edit: app I was using chopped my comment...)
Or we can define a variable self in the class, set self = this in the constructor, and refer or that hereon.
just for note: I have never used "extends" in ES6.
Secondly, you should be able to auto-complete pretty much everything.
Requires tooling.
Well, yes, because programming languages don't exist in a vacuum. The currently available libraries, tools, and documentation are very important if you decide to actually do something with that language.
> I have never missed autocompletion in Javascript
A moment ago, you complained about having to press a few more keys for the type annotations.
> I wanted to make the point that I don't automatically consider that "IDEs can autocomplete" is a positive feature
That there are IDEs which let you auto-complete everything is a positive feature.
Being toolable doesn't mean that those tools exist. If those tools exist, you can make use of them if you decide to use this language. This is a good thing.
By the way, JavaScript doesn't lack good tooling because it doesn't need good tooling. It's the way it is, because offering good tooling for JavaScript is really difficult. ES6's modules and classes will help with that though. The tools will make good use of this statically available information.
>A moment ago, you complained about having to press a few more keys for the type annotations."
For Typescript, I dislike the extra typing. I have never missed autocompletion in Javascript. Where is the contradiction?
Compared to JavaScript, I have to press fewer keys when I write Dart. (This would be also true without shorthands like method cascades.)
I didn't even bring up environment flexibility, or terminals!
Since you asked, though, it is fairly nice to be able to ssh in to a box and make a code change, and recompile, for those languages that require that. Continuing with Scala as an example, I, myself, could not edit a Scala program extensively without benefit of an IDE. So say I have a Scala program sitting on a dev server where I'm building a batch image processing program. If Scala were as simple as Jacascript, I could easily use vi or emacs to iterate the development remotely. As it is, I edit and test locally on my laptop using an IDE, then push this big jar over to the server. So, there are plenty of cases where remote edit, compile, test cycle using a terminal is convenient.
The fact is we are being constrained by the past. We still program in plain text files, using languages and environments that are as basic as possible presumably to maximize flexibility of development. I don't see the point. There are those that eschew the mouse, or GUIs because the terminal is cool (or something). The fact is that this field is moving towards more and more tooling, hopefully improved visualization, and soon to be automation (imagine APIs automatically wiring themselves up, or the gruntwork drudgery of programming happening automatically). This is the future we should all be looking forward to, not placing arbitrary constraints on the languages and environments we use for the purpose of compatibility with outdated tools. The more constraints we place on ourselves, the longer this future will take to become reality.
My experience is that the complicated part web app is the part that does the state coordination, which can be either end.
When people say this as a knock against a language I can't help but wonder how they got so far in their careers using only two fingers.
Now, if you want to say that verbosity obscures intent and expressivity, then that's a fine argument to make (you'll have an steep hill to climb to show that types are an instance of this however). But if your development is bottlenecked by your typing speed, there's something seriously wrong.
JavaScript always has been an object-oriented language - arguably just not a partcularly well-designed one, and not a pure one (as not all computation happens through message passing).