Skip to main content


Topic: Thoughts on ES6 Classes (Read 1804 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
Thoughts on ES6 Classes
Someday, perhaps I will feel a different way. I'm also speaking a bit of hyperbole here to make my point. But this is what I think about ES6 classes.

They are not necessary, and generally a poor fit for JavaScript.

The way to do inheritance in JS, using prototypes has been called a hack, but it's actually inspired by how SmallTalk works. And SmallTalk is one of the older and more pure object-oriented languages. When prototypical inheritance is called a hack, it implies to me that writer is simply not aware of non-class-based object paradigms. Modifying and assigning to a prototype is simply another way to do it.

So why do I think that prototypical objects are a better fit for JavaScript? Because in JavaScript a function and an object are largely interchangeable, and because JavaScript is duck-typed.

I believe the functional aspect of JavaScript better suited to prototypical objects because with prototypical objects there is no need for a class definition. The constructor, a function, is the definition. You can add methods to it by adding to its prototype. This is better suited to functional programming, or a mix of functional and object-oriented programming, because now the object's definition is a function, and an object is (in a way similar to SmallTalk) a function that has a captured and maintained scope.

Duck-typing is quite useful here because it makes arbitrary extension of the prototype more natural. Since there is no formal class definition, you can attach anything to it and not be violating some definition. All that matters, the actual requirements of the 'class', is how it is used. Does it have a 'quack' method? The requirements are the usage.

Perhaps this is just a rationalization to have duck-typing. But it seems to work well here.

Maybe I'm just set in my ways. But I feel that in many ways, ES6 Classes are an extension that is solely to make programmers from class-based languages more comfortable. They don't add much value to JavaScript, except to make it look more like another language.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Thoughts on ES6 Classes
Reply #1
I much prefer JavaScript's duck typing over classical inheritance myself, so you're not alone there.    It makes it very easy to prototype stuff (no pun intended) because you can just hack together an object with the proper members for the task--you don't even need to write a constructor.  Only later, when you've determined that your prototype works, do you refactor, which is itself painless because of the duck typing.  Honestly I think people get insecure when a language gives them too much freedom.  For whatever reason, people seem to actually like it when their compiler yells at them constantly.  It's like how everyone gets into an tizzy over `==` vs `===` - sure, there can be issues if you're not careful, but it's not nearly as big a deal as everyone thinks it is.

If I had to guess why this is happening, I'd say it was due to pressure from CoffeeScript.  Everyone seems to believe CoffeeScript is "what JavaScript should have been" to the point that internal style guides even dictate its use (GitHub, for instance).  Personally, I can't stand CoffeeScript and avoid it like the plague.

In the end though, I'm not too worried.  ES6 has a lot of awesome things in it too.  The Proxy constructor, for instance, which is a cleaner, more well-thought-out version of Lua metatables, block scoping via let, etc.  And backwards compatibility has to be maintained because otherwise you break 90% of the web. :)
  • Last Edit: April 28, 2015, 09:47:41 pm by Lord English
Sphere 5.6.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub