Agile is responsible for a lot of it. When you have interchangeable developers instead of people that focus on what suits them best, all of a sudden you need tools to that even the weakest database guy can get his database tasks done. Agile never fixed the mistrust between stakeholder and developer, it just tied the developer's hands. Terms like "polish the cannonball" are used to beat down and suppress the desire to do things beautifully and just turn software development into a machine in and of itself.

You would like this site http://programming-motherfucker.com/

It really blows but you can make money doing it.

J2E you mean? Not all of the JVM ecosystem blows, IMO. Scala is decent. Clojure is decent. Hell, on a somewhat related note Clojurescript even seems kinda neat.

nodeJS is getting better and more performant, particularly after 5.5.0 so plenty of opportunity to leverage JS on the middleware, service or resource layer as well if you wanted to

Developers have forgotten how to develop great programs. All we see now is crappy programs with a shiny graphical interface that has these cool effects.

Consider this alternative interpretation: sales/product have realized that you can make mad bank selling cheaply and crappily made programs as long as they have slick UIs with flashy effects. That style over substance ('Murica, Fuck yeah) is a thing in this product space.

Because as it turns out, most end users generally don't give a flying fuck about how elegant or well factored the underlying 3/4GL codebase is.

And before people start whining about the prioritization of running the business over craftsmanship or technical excellence... Where the hell do you think your project funding/budgets come from?

IIRC they released teh sauce after the recent announcement to retire the SaaS portion of their business model. So you could always set up your own VPS?

Hell yeah functional js. TLA+ semantics ftw.

This is hilarious as Backbone predates Angular.

And what you're discovering are some of the tradeoffs/pitfalls of Convention-over-Configuration frameworks.

Both are convention-over-config frameworks, but Angular more heavily than Backbone, and it appears you've begun to feel the pinch/restrictiveness of the former along with its domain-specific lexical bloat.

In in the end it boils down to what you are trying to accomplish and picking the right tool/framework for the job.

Sigh... part of the problem involves industry washouts/burnouts trying to sell you shit (90%+ of coding "bootcamps", I'm looking@u) while their skillset is still somewhat relevant, and part of the problem involves just how much bad learning material is out there. The well has been poisoned long ago, and there's too much money to be made keeping things that way.

If you mean JS classes, you don't as they are syntactic sugar.

In JS, you generally "initialize" objects with a constructor call:

function Class(){
   this.privateProperty = 'foo';
}
var object = new Class();
console.log(object.privateProperty); // 'foo'

You generally define "methods" by augmenting the constructor prototype, as each instance of the returned object inherits from aforementioned prototype:

function Class(){
   this.privateProperty = 'foo';
}
Class.prototype = {
   fooMethod: function(append) {
      return this.privateProperty + append;
   }
}
var object = new Class();
console.log(object.fooMethod('Bar')); // 'fooBar'

You can also emulate some semblance of private/public by how you make use of arguments and function calls:

function Class(options){
   this.privateProperty = 'foo';
   this.publicProperty = options ? options.publicProperty : 'derp';
}
Class.prototype = {
   fooMethod: function(append) {
      return this.privateProperty + append;
   },
   barMethod: function(append) {
      return this.publicProperty + append;
   }
}
var foo = new Class();
var bar = new Class({publicProperty: 'Bizz'});
console.log(foo.barMethod('Buzz')); // 'derpBuzz'
console.log(bar.barMethod('Buzz')); // 'BizzBuzz';

The aforementioned examples are specific to JS though.

While they show that you essentially already have everything you need in Ecmascript-land without introducing classical inheritance or introducing syntax to encourage thinking in OOP paradigms (I'm looking at you, ES6/7 sugar), that doesn't mean that classical inheritance/OOP aren't necessary/useful/helpful in other languages.

And now you just confirmed that you didn't even read through the linked post.

OP posts a link specific to a JS library workaround for managing client-side browser-quirk-related DOM interactions as part of facilitating data transport and you derail by posting server-side C# which makes the assumption that browser quirks are automagically already handled for you.

Bravo.

Yes but you're de-scoping the DOM interaction aspect from the original problem