3 ms·

Wow. Axe grind much? > The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing compelling produ

Wow. Axe grind much? > The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing compelling produced in that time. Nothing compelling produced in JavaScript? A reader could be forgiven at this point for thinking that you're not only unfamiliar with the language, but also largely unfamiliar with what people have done on the web in JS. > Whenever it comes to getting real work done, we see JavaScript developers resorting to some imitation of the proper class-based OO functionality made available by so many other languages. Who's "we"? Look, I don't know what your real criticisms of JavaScript's approach are, since you've chosen to spend your writing energy on making a few comments filled with vague pejoratives rather than any specifics. So I'm going to go on a guess: from your perspective, "proper" OO programming is modeling out the problem domain of the program in a class/type hierarchy, with inheritance relationships as the primary mechanism for code reuse. That can be a helpful way of organizing a program. It works well enough for some problem domains where you've got a lot of related objects that are mostly like some other object, and where the relationships between them are pretty clear. It works particularly well where there's a set of well-established conventions ("patterns") for definitions... or where you're actually writing software where someone's already formally modeled a problem domain in exactly this manner (though not all formally modeled domains are easily amenable to this approach, as anyone who's ever tried to write or use an ORM for non-trivial domain can tell you). But it's not the only way to write software. Heck, it's not the only way to write object oriented software. And a class hierarchy is sometimes not the simplest or the most robust way of approaching a program. The JS devs I know who are best at getting "real work" done recognize this. And they don't spend a lot of time stressing over modeling their programs as a class hierarchy. In some cases where that turns out to be the best model for a problem, it turns out JavaScript will support it (you used words like "imitate" and "fake" but the word "implement" would probably do just as well for a non-polemicist). But much of the time, composition and a bit of shallow prototype delegation or method grafting will do. And that's for the space where objects are helpful... that's to say nothing of the domain where sometimes, functions and a spot of imperative code alone will do the job.

coldtea 14y ago
>>The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing compelling produced in that time. > Nothing compelling produced in JavaScript? No, he means nothing compelling produced with prototypes, without resorting to some tricks to make it class-like. (Did you even notice the context he replied to?) Now, here and there you'll find some prototype usage for what it is. But the overwhelming majority of frameworks, developers, and projects uses a class-like approach.
- tracker1 14y ago
  And that has led us where. Class-based OO approaches became popular in the mid-90's as a panacea of maintainability and code reuse... This has taken us to "enterprise" frameworks and layers of abstraction that offer very little actual value, and huge amounts of maintenance overhead. In VS/Eclipse, I can't tell you how many times I go through the inheritance chain only to be brick walled into an Interface, and then have to look for the specific/abstracted implementation of said interface. 99/100 times there is only one implementation, and no test coverage to justify said abstraction. So, why do it at all? Because of how strict and constrained said programming environment is. JS doesn't have those levels of restriction, and doesn't need those levels of abstraction and inheritance. You can utilize other patterns and practices... there's more out there than Class based approaches. For example MVC is really seamless in JS... you can have models that are dumb JS objects (they don't need to be inherited from, or to).. and modules that manipulate/use/store said objects. It doesn't need to be so complicated. It isn't that some problems aren't complicated, and don't need some serious use of patterns/factories/IoC... It's simply that in many cases they are done because they "can be" or some overzealous architect thinks they "should" be. I've only ever seen a couple instances where most of these abstraction patterns actually make sense.. and I've been writing software for close to two decades now. As for "but the overwhelming majority of frameworks... use class-like approach" .. arguably the single most used framework/library in use today is jQuery.. and that definitely does NOT use a class-like approach.
  - coldtea 14y ago
    >And that has led us where. Here. A thriving web, mobile and native application ecosystem. >Class-based OO approaches became popular in the mid-90's as a panacea of maintainability and code reuse. This has taken us to "enterprise" frameworks and layers of abstraction that offer very little actual value, and huge amounts of maintenance overhead. Yes, only that has nothing to do with the classes. You could do the same bloated mess of enterprise layer upon layer, XML configuration, boilerplate etc, even with prototypes, if anybody cared about them. And you can do perfectly clean designs, also with classes. Not even need to use Smalltalk, CLOS etc, you can even do them in Java if you take the necessary care. And lots of people do them in Python, Ruby, etc too. >JS doesn't have those levels of restriction, and doesn't need those levels of abstraction and inheritance. You can utilize other patterns and practices... there's more out there than Class based approaches. Nothing in using class based approaches necessitates those "levels of restriction, abstraction and inheritance". People use Coffescript (which has "classes") and do perfectly lean work, without it looking like Apache Struts or something similar. >As for "but the overwhelming majority of frameworks... use class-like approach" .. arguably the single most used framework/library in use today is jQuery.. and that definitely does NOT use a class-like approach. That's because it is a DOM manipulation library, not a code structuring library itself. And people writing plugins with fuller functionality on top of jQuery (as jQuery/jQuery UI plugins) have been using OO styles on top of jQuery since for ever.

coldtea 14y ago

>>The JavaScript community has had well over 15 years to show that prototype-based OO is feasible. Yet we've seen nothing compelling produced in that time. > Nothing compelling produced in JavaScript? No, he means nothing compelling produced with prototypes, without resorting to some tricks to make it class-like. (Did you even notice the context he replied to?) Now, here and there you'll find some prototype usage for what it is. But the overwhelming majority of frameworks, developers, and projects uses a class-like approach.

tracker1 14y ago
And that has led us where. Class-based OO approaches became popular in the mid-90's as a panacea of maintainability and code reuse... This has taken us to "enterprise" frameworks and layers of abstraction that offer very little actual value, and huge amounts of maintenance overhead. In VS/Eclipse, I can't tell you how many times I go through the inheritance chain only to be brick walled into an Interface, and then have to look for the specific/abstracted implementation of said interface. 99/100 times there is only one implementation, and no test coverage to justify said abstraction. So, why do it at all? Because of how strict and constrained said programming environment is. JS doesn't have those levels of restriction, and doesn't need those levels of abstraction and inheritance. You can utilize other patterns and practices... there's more out there than Class based approaches. For example MVC is really seamless in JS... you can have models that are dumb JS objects (they don't need to be inherited from, or to).. and modules that manipulate/use/store said objects. It doesn't need to be so complicated. It isn't that some problems aren't complicated, and don't need some serious use of patterns/factories/IoC... It's simply that in many cases they are done because they "can be" or some overzealous architect thinks they "should" be. I've only ever seen a couple instances where most of these abstraction patterns actually make sense.. and I've been writing software for close to two decades now. As for "but the overwhelming majority of frameworks... use class-like approach" .. arguably the single most used framework/library in use today is jQuery.. and that definitely does NOT use a class-like approach.
- coldtea 14y ago
  >And that has led us where. Here. A thriving web, mobile and native application ecosystem. >Class-based OO approaches became popular in the mid-90's as a panacea of maintainability and code reuse. This has taken us to "enterprise" frameworks and layers of abstraction that offer very little actual value, and huge amounts of maintenance overhead. Yes, only that has nothing to do with the classes. You could do the same bloated mess of enterprise layer upon layer, XML configuration, boilerplate etc, even with prototypes, if anybody cared about them. And you can do perfectly clean designs, also with classes. Not even need to use Smalltalk, CLOS etc, you can even do them in Java if you take the necessary care. And lots of people do them in Python, Ruby, etc too. >JS doesn't have those levels of restriction, and doesn't need those levels of abstraction and inheritance. You can utilize other patterns and practices... there's more out there than Class based approaches. Nothing in using class based approaches necessitates those "levels of restriction, abstraction and inheritance". People use Coffescript (which has "classes") and do perfectly lean work, without it looking like Apache Struts or something similar. >As for "but the overwhelming majority of frameworks... use class-like approach" .. arguably the single most used framework/library in use today is jQuery.. and that definitely does NOT use a class-like approach. That's because it is a DOM manipulation library, not a code structuring library itself. And people writing plugins with fuller functionality on top of jQuery (as jQuery/jQuery UI plugins) have been using OO styles on top of jQuery since for ever.