MarxistJS - The Classless Javascript Manifesto

at marxist.js.org

4 up and 5 down, posted by ohmfox 2999 days ago 4 comments

sylvainpv 2999 days ago. link parent 2 points ▲ ▼

I don't understand why ES2015 classes suddenly become mandatory. They have been described as syntactical sugar over the prototype-based OO pattern and are already massively transpiled to ES5. If classes are absolutely mandatory for custom elements v1, how does Polymer manage to polyfill this specification while supporting IE11 ?

Replies

tracker1 2999 days ago. link 2 points ▲ ▼

Classes in JS(ES6) are definitely sugar over the prototype chain... beyond this, you'll still need to have that inheritance chain for certain contexts.  If you choose prototype syntax over class syntax is entirely subjective.  I happen to think the class syntax is cleaner to look at and follow.

I don't think classical inheritance is a good use case for many types of workflows, for others, they are.  In general, where you want to persist state in conjunction with workflows, classes tend to work better.  Not that you can't work around them, but it really depends on your needs.

I tend to use classes very sparingly in JS.

MaxArt 2999 days ago. link 1 point ▲ ▼

Polymer is a fully-fledged library that falls back to polyfills when certain features aren't available.
ES2015 classes are not "mandatory", but sugar is... well, sweet. Actually, most of ES6's features could be transpiled to ES5: arrow functions, the spread operator, default arguments, even `let` and `const`. Are those superfluous just for that? No, we're going to use them because achieving the same result with ES5 is just annoying/boring/cumbersome.

Incidentally, `class` is one of those features that can *not* be completely transpiled to ES5. Native elements were just an example, but we also cannot correctly extend `Error` or `Array` with ES5.
Therefore, `class` isn't going away any time soon, and while JavaScript will keep evolving as a functional programming language, for those uncommon cases where classes are needed `class` could and will be used every time they're more convenient than the good old `function` pattern, as long as  we're aware that ES2015's classes aren't anything like "classic" classes.
But then again, every language has its own perks, so as mindful developers we're going to learn the differents like the pros we are.

So far, I had very little use for classes in JavaScript in general (lately I've been using them mainly for React), but things may change.
The next step for classes in JavaScript is defining a way to deal with composition nicely. Nothing is really ready, but the word "trait" is resonating among the community. Let's wait and see.