Core difference between object oriented and object based language

Just using objects does not mean you are doing OOP, even in a fully OO language if you are not implementing OO techniques it is simply object-based programming.

Object-based languages include basically any language that offers the built-in ability to easily create and use objects. There is one major criterion:

• Encapsulation. Objects have an API attached to them, typically in such a way that you work with the object more by telling it what to do than by running some function on it.

  Most object-based languages define objects in terms of "classes", which are basically blueprints for an object. The class lays out the internal structure of the object and defines the API.

  This is not the only way, though. In JavaScript, for example, objects don't really have "classes". Any object can have any properties it wants. And since functions are first-class values in JavaScript, they can be set as properties on the object, and serve as the object's API.

As far as object-based-but-not-object-oriented languages go, a good example would be Visual Basic (not the .net stuff; i'm talking about VB6 and VBA). Classes exist, but can't inherit from each other.

Object-oriented languages are object-based languages that take things a step further. They have built-in support for the two other pillars of OOP:

• Inheritance. Objects must have the ability to be (and be viewed as) specializations of some other object. This means, for example, being able to define "Dog" as "Animal that can bark and fetch sticks".

  In modern languages, it typically takes the form of one object's class inheriting from another object's class. This is not a requirement, though; contrary to what some people will try to tell you, the definition of OOP does not require classes at all.

• Polymorphism.  Code must be able to use an object without knowing or caring exactly what type it is.

  Most languages (especially statically typed ones) define polymorphism in terms of classes and inheritance. If you have a class B that inherits from A, code that requires a reference to an A can typically take a B instead, but not some class C that isn't related to A. Java also has the interface keyword, which lets you define a set of behaviors a class must implement. Any object whose class explicitly implements X, and thus implements the functions defined on interface X, qualifies as an instance of type X.

   Other languages, like JavaScript, let you pass any object you like. As long as the object presents the right interface, it doesn't matter exactly what kind of object it is. This is called "duck typing", and it is very nearly the purest form of polymorphism there is.

JavaScript is a prototype-oriented language.

It can build actual objects from a constructor function and it has almost any feature that any object could have:

• Constructor.
• Methods (i.e. functions in JavaScript).
• Properties (since ECMA-Script 5, "getters/setters").
• Instances.

In JavaScript, any object has a prototype, including functions. The prototype itself is a rudimentary way of adding object members to any newly created instance of the whole object.

var constructor = function() { };
constructor.prototype.text = "hello world";

alert(new constructor().text); // This alerts hello world

Why JavaScript isn't an object-oriented programming (scripting) language? Because it has no feature that fits the requirements of the definition of object-oriented programming:

• Polymorphism: No. You can change the behavior of a prototype member, but this is just reusing the identifier. You aren't able to access the previous implementation of the member in a pseudo-derived object.
• Inheritance: Not at all. Maybe prototype chain might be comparable to inheritance but JavaScript (ECMA-Script 5.x or earlier versions) has no syntax-based inheritance like other OOP-based languages (i.e. Java, C#, Ruby, Python, VisualBasic.NET, ...).
• Encapsulation. Yes, of course, but there's no way to create actual private or internal object members.

Perhaps I forgot to mention some other detail, but I honestly believe that this is a good summary.

Update and summary

The core difference is an object-oriented programming language has the features that an object-oriented paradigm must have in order to be considered an object-oriented programming language. Thus, JavaScript, for now, isn't an actual object-oriented programming language because it lacks actual polymorphism and inheritance.

Update: Does ES2015 and above changed the situation?

Esthetically speaking yes, ES2015 and above has a major improvement that let consider a not fully but more closer to an object-oriented programming: syntactic sugar to call to the super class.

For example:

class A {
     doStuff() {
         console.log("hello world");
     }
}

class B extends A {
     doStuff() {
         super.doStuff();
         console.log("...and goodbye!");
     }
}

This is polymorphism. A more specialized class can override its base class to both completely change a function behavior or do what the base was already doing, adding new code to the function.

BTW, ES2015 and above still lacks true encapsulation: where are access modifiers like private or public here? Nowhere.

And, at the end of the day, ES2015 and above implement class-based OOP but it's still a syntactic sugar layer on top of ECMAScript 5.x... The above code still works with prototypes under the hoods and it works the same way as if you would code it in ECMAScript 5.x:

function A() {
}

A.prototype.doStuff = function() {
    console.log("hello world");
};

function B() {
}

B.prototype = Object.create(A.prototype);
B.prototype.doStuff = function() {
    A.prototype.doStuff.call(this);
    console.log("...and goodbye!");
};

Let's hope I'll need to update this answer again because ES2020 has already proposed access modifiers and we'll be able to consider JavaScript another language which fully-supports object-oriented programming!