Closed boneskull closed 8 years ago
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.
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 ofextends
andnew
, respectively.Its
constructor
cannot be executed viaFunction.prototype.call
orFunction.prototype.apply
. Effectively, a consumer cannot supply a pre-existing object, as would have been possible with an ES5 pseudoclass:Above,
MyClass.prototype
can be accessed and leveraged via other means, but theconstructor
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 thuslynew
. This culiminates in it being exceedingly difficult--if not impossible, depending on the behavior ofconstructor
--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!