reconsider exposing ES2015 classes

[Christopher Hiller]

Hi,

I've noticed Nodal exposes ES2015 classes in its public API. I understand the desire to use ES2015 classes, as they are standardized, and certainly more simple than equivalent ES5 code. ES2015 classes have taken a lot of heat, and I'm not here to trash them, but I wanted to bring the following to your attention.

Many library & framework authors (but not all!) will avoid exposing classes or pseudoclasses altogether. For those libraries which expose ES5 pseudoclasses, but do not expose ES2015 classes, this is mainly an inconvenience for the consumer--it's not necessary to use new to leverage the pseudoclass' functionality.

However, ES2015 classes require the use of new. ES2015 classes are viral. Once an ES2015 class has been defined, it cannot be extended--nor can it be instantiated--via any means other than the prescribed methods of extends and new, respectively.

Its constructor cannot be executed via Function.prototype.call or Function.prototype.apply. Effectively, a consumer cannot supply a pre-existing object, as would have been possible with an ES5 pseudoclass:

class MyClass {
  constructor () {
    // does something important
  }
}

const myObj = {};

MyClass.call(myObj); // TypeError

Above, MyClass.prototype can be accessed and leveraged via other means, but the constructor is off-limits.

At best, a consumer who wishes to avoid ES2015 classes in their own application can only provide "wrappers". Contributors wishing to extend Nodal's classes must also leverage the class keyword, and thusly new. This culiminates in it being exceedingly difficult--if not impossible, depending on the behavior of constructor--to use an alternative inheritance strategy, or factory functions, in a Nodal app or extension.

Now, I realize Nodal is an opinionated framework, and it's free to have a different opinion. I'm also not saying that Nodal mustn't use ES2015 classes across the board. I am saying it'd benefit the framework's flexibility (and potentially acceptance) if ES2015 classes were not exposed in the public API.

That said, I'm excited about the future of this framework and stdlib. I'm hoping to get a chance to build something with these soon. Great job all around!

[Christopher Hiller]

Re-reading your original post on Nodal, I'm going to infer this was chosen for reasons of "dialect" or "design patterns". That makes sense--and class is certainly welcoming to newcomers--but there's a significant tradeoff. As such, I don't expect this is on the table.