Still unfortunate.
JsPerf was one thing (and still is, as it seems to be on a rework) and this, although similar, is another. It sounds like hijacking the success of the former to grant success to the latter.
"JsPerformance", "JSBenchmark", "PerfJs"... there are a lot of names to choose from, copying an used one only because it's not protected by a trade mark doesn't sound nice to me.
Well... It depends on what you mean with "plenty", I guess.
Because while I have no doubt that you and your peers managed to keep up with new technologies, many old-school developers actually struggled a lot with the ways of JavaScript, in terms of async code, functional programming and single-thread techniques.
JavaScript gave birth to some of the most exotic frameworks and introduced revolutionary development stacks. From React to Angular, from jQuery to Elm, from Browserify to Webpack, from Grunt to Gulp... an unprecented flexibility.
Also add isomorphic code, JWTs, WebSockets, PWAs, the end of the boundaries between JS, HTML and CSS... It's no surprise if someone gets dizzy.
But really, it's not a series of hacks. Personally, I can work with it just fine.
Developing for Wordpress feels like a series of hacks and monkey patches. But if you're saying that for modern web development, chances are you're not getting the hang of it!
And that's fine! It's normal, really. Just take your time and stick with one technology for as long as you need to be comfortable with it.
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.
`class` brings a lot of problem, but they're mostly "philosophical" and go over the mere word.
Moreover, if you want to deal with certain kind of things (custom elements, for example) you have to use classes, period. And you definitely need `class`, which both solves some problems and it's a base for future language development.