I don't think that the belief that feature X was created at the expense of feature Y is a reasonable assumption. Who knows how this feature came about? It could have been a Githubber's 20% project, or weekend hack project, or largely down to a 3rd party library.
Well for one 'class Foo extends Bar' will work without any further code to make inheritance work in the way you'd expect, including use of super() etc. Whereas your second example is using non-trivial framework code, that some framework author has to write. See Backbone's extend() for a clear example of what is required . That's work that every framework author is potentially going to implement differently, needlessly.
And the fact that almost every major framework has implemented something similar themselves is proof enough (for me at least) that the ES6 sugar is valuable. It has nothing to do with Java, it's simply a useful pattern that everybody was already using.
The question is whether that ~15 lines of code, written once, is worth the substantial increase in the surface area of the language, especially when overlapping so much with the existing prototypal inheritance mechanism. The choice to use Java/C++-style inheritance is a design pattern that doesn't necessarily reflect the only (or even the best) way to accomplish things.
Thanks for the response. If the choice is between manually specifying that (type of) code for every kind of object (and likely moving to a #create factory method) or using a native syntax for class declaration, I can see why people would choose the latter.
It's to a degree for people who are not primarily JS developers and often have no clue about prototypical inheritance. It also to a good degree reflects how V8 or some other engine actually treating your code under the hood.
To be fair, not everyone is suggesting you need a scripted build system, but you do need some sort of build step, because <script> tags just aren't sufficient for anything beyond a trivial app. (Also ultimately, you do need to minify your code for production).
This build step can just be 'browserify main.js -o bundle.js'. This is where I suggest people start or go back to if they are intimidated by all the various options.
Because it's a useful pattern, that people were using heavily. Not sure why you're trying to suggest some kind of ill-intent.
A nice thing about prototypal inhericance is that classical inheritance can be implemented in it. People were doing that commonly enough that it made sense to add sugar to do it more directly, and signal intent more clearly to the reader.
Yeah it's really bad. I feel for anyone that has stuck with these old-school 'cross-platform toolkits' over the last few years, they have really been missing out for a while now. On top of this, the whole scene is just stagnant and decades out-of-date from my experience (trying to get into Qt a couple of years ago). There are no devs there, you're basically on your own.
If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron  and NW.js . Then you can tap into the web ecosystem with its (enormous, company-backed) massively vibrant frameworks, libraries, tools and communities.
It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore (opinion - willing to be proved wrong).
I think you are wrong on pretty much everything you've stated here.
> There are no devs there, you're basically on your own
There is an extremely active mailing list and IRC channel (several official ones actually) where you can almost always get in touch with the actual Qt devs and others who use it for support without paying them anything. There are over 500 people in the IRC room right now.
> If you want to make cross-platform desktop apps (with opportunities for mobile too), I'd recommend hiring people who know web-dev and start looking at Electron  and NW.js .
Maybe when Web Assembly (or whatever its called) becomes a thing performance will be tolerable but I have yet to come across a web application that doesn't run incredibly slowly. I use Atom for a basic code viewer right now and it is pathetically slow compared to any native applications (GEdit, Kate, Geany, etc)... and this is on a desktop machine. I can't imagine anyone creating a remotely complex web application on mobile and expecting any sort of reasonable performance. Text editors should be some of the faster applications -- imagine creating something that's media rich like a music player, a video or photo editor; it would be a disaster.
Also regarding your "with opportunities for mobile too" comment, you know Qt is supported on iOS, Android, WinPho, BlackBerry, Sailfish right?
> massively vibrant frameworks, libraries, tools and communities
Yeah, its not like the native software community doesn't have that or anything. Unlike web tools, native tools have been developed for far longer and they are more robust and reliable.
>It really doesn't make sense to use things like Qt, wxWidgets, GTK anymore
Yes, if you don't care about performance and all the things web frameworks miss out on (how's that GL support looking? Native is getting ready to support Vulkan -- WebGL is still stuck on the ES2 equivalent) then jump on board the web app hype train.
You're also completely overlooking embedded where Qt specifically is used extensively. Kiosks, IVIs, small displays for smart appliances, etc.
I don't like the Qt model of using the GPL as a way to get people to go for their very expensive commercial offering and I think a model like Unreal Engine's (give us a share of your revenue) makes more sense as an additional option for smaller devs.
I don't agree with your characterisation. GP was complaining about downvotes to anti-MS comments, and that's nothing to do with 'attracting a readership'. More like the specific criticism of Microsoft demonstrated in this thread so far is the same tired old crap and not relevant to the actual topic.