3 ms·
In practice, we've seen its prototype-based OO functionality be a burden, rather than a benefit. In any sizable JavaScript code base, there is usually a lot of
by PommeDeTerre 14y ago
In practice, we've seen its prototype-based OO functionality be a burden, rather than a benefit. In any sizable JavaScript code base, there is usually a lot of code and effort put into faking a far more sensible and practical class-based approach to OO. This often obfuscates the code significantly.
This is part of the reason why languages like CoffeeScript and TypeScript have become popular. They offer the tools that developers actually need, rather than just telling them, "you should be using prototype-based OO because it's good".
- dasil003 14y agoArguably that's just because people aren't used to prototype-based OO, but in any case, it supports these custom pseudo-class-based OO constructs just fine doesn't it?
- cygx 14y agoNo, it's because JS doesn't expose (or at least didn't used to before ES5) it's prototype system, but instead provides a pseudo class-based overlay. The proper way to do inheritance in JS is // Foo extends Bar Foo.prototype = Object.create(Bar.prototype); function Foo() { Bar.call(this); } Before the introduction of Object.create, you either had to roll your own version, assigned a dummy instance of Bar to Foo.prototype (which is horribly wrong) or transferred methods manually from Bar.prototype to Foo.prototype, which is arguably more 'in the spirit' of JS1.0. That's not how it's done in 'real' prototypal languages like Self or Io.
- PommeDeTerre 14y agoNo, it does an absolutely horrible job supporting anything that resembles class-based OO. That's why so much JavaScript code is utterly unmaintainable. It doesn't offer the functionality that developers want and need, so they have to fake it, and this can only be done very poorly.