I lead a somewhat large (~10000 sloc) project which uses the module pattern everywhere. I think the best argument against the module pattern is the difficulty of debugging. I can no longer just pop open a console and inspect objects.
Responses to your individual points:
>> * you cannot use previous OOP experience
While unfortunate I believe this is largely unavoidable. Javascript's object system is not 'classical' inheritance. The module pattern, however, is also not 'classical' inheritance. Regardless of OOP technique, the New Javascript Programmer must learn about the object system.
>> * there are MANY ways to do OOP using prototypes
There are also many forms of the module pattern. You just showed me another one I hadn't seen before. Then there's immediately invoking function expressions, which some people like to do like this
(function () { var exports = {}; return exports; })());
and others like to do like this
!function() { var private = 4; return { getPrivate: function () { return private; }; }();
>> * 'this' has different meanings depending on context
Can't argue against this one.
>> * prototypes make existing objects unreliable -> requires prior knowledge about libraries and APIs (leaky abstraction)
I'm not sure I see the argument here.
>> * building an object with prototypes requires far more mental steps: ..
I'm not sure you really need to know about all of these things.. but sure, prototypal inheritance is confusing to those with a 'classical' background.
As for the advantages:
>> * conforms to established industry and business standards in OOP
I don't see why prototypal inheritance does not. If you look at CoffeeScript, it even appears classical.
>> * requires less knowledge about language details
I have to disagree here. Explaining object literals and immediately invoking functions and closure isn't all that easy.
>> * very transparent, no sugar code or libs required
That's true.
>> * neat code
There's no reason why new/this/prototypal code can't be neat!
>> * design patterns blah blah
There's no reason why new/this/prototypal code can't do design patterns!
>> * protection against corruption
I've never seen this as an issue in practice, but my code isn't running in the browser. Unless you're talking about protection from other programmers, in which case, I would quote Guido van Rossum.
>> * no this, that or self variables
Could be a good thing or a bad thing. This means that you have to know what's public and what isn't, rather than it being explicit. I rather like it when things are explicit.
Sometimes we sacrifice a little simplicity for a little flexibility or a little efficiency. Sometimes it's worth it, sometimes it isn't.
It all boils down to maintainability.
In my experience the minimalist approach solves much of the complexity of JS by eliminating some features that are not required (performance might be an issue but never had any problems with it in practice).
So why am I not allowed to share something that works just because it may not fully comply with the 'preferred javascript style culture'?
Nobody said you aren't allowed to share it, I simply disagree with you. As I said, I use a very similar pattern in a large project; I've used new/this/prototypal style OOP in other projects; and I prefer the traditional new/this/prototypal style.
Okay fine. Then tell me how do you write javascript OOP; what's your favourite way. Can you give me an example of your code? I am willing to admit mistakes but I have to be convinced.
I just use Object.create[1]. Constructor functions give the illusion of classical inheritance but JavaScript doesn't have classical inheritance and I think it's best to simply break the notion off from your brain by not using stuff that makes JS appear to be something it is not. JavaScript uses prototypes. Prototypes or just objects from which you derive other objects. Object.create makes this very obvious. Under the hood you are still using prototypes in the same way as you would by using constructor functions you just don't have to worry about the Constructor.prototype object as it is abstracted from view.
The second biggest problem with the method you are using (after performance/memory consumption) is not having access to either instanceof or isPrototypeOf. If you are doing anything complicated having access to one of those two can by crucial.
You shouldn't be defensive, I'm just another programmer like you. I (and hopefully others in this thread) just want to share my own experiences and let you know what options are out there. Feel free not to use them, find your own preferences.
The article I linked to gives a shim for Object.create if you need to target IE7/IE8. All other browsers already support it, including all mobile browsers.
Yeah, the descriptor object is, in my opinion, a design mistake when they did Object.create. Modifying property descriptors is an exceptional need, and there are other ways to do it when you have that need (Object.defineProperty and Object.defineProperties).
However, that's an optional parameter. You don't need to use it. You can just define properties like you normally would to an object. For example:
var one = Object.create(null);
one.foo = 'bar';
var two = Object.create(one);
two.fee = 'fi fo fum';
If you want extra sugar to make the definition of own properties more eloquent (by having them in a single object literal) there are libraries/snippets that will do that for you. Here is one I wrote (which is just a very small snippet around Object.create): http://code.matthewphillips.info/thingjs/
You're right, there is no need to be defensive. For some reason though I felt like being attacked here. Maybe words like 'piece of shit' (not from you) have something to do with this.
I am not used to participate in technical debates like this. All I know is that the I like the minimalistic way of OOP in JS and that it works for me. All I tried to do is share my experience. I no longer feel the need to prolong this discussion as I am no longer capable of providing arguments. I am left wondering why a perfectly reasonable way of coding JS is dismissed here so aggressively. For me hackernews has been a big dissappointment (first thread/comments here). I had hoped to either learn something new or find support for my method. Instead I have felt attacked for my opinion. As a natural response I try to defend myself; however this rhetoric gets in the way of reason and rational argumentation.
I understand how you feel, as you know programmers tend to be overly frank about their opinions on software, and it sucks to be on the receiving end of that. But if you ever want to talk about JavaScript or coding or whatever, my emails in my profile.
That's because "override the 'general' toString() function" doesn't make sense. This is a method. It must be overriden for a particular class of objects.
The first part of your example is due to the conversion between primitives and objects for method calls. It has little to do with prototypal inheritance.
Then, you override the method on an instance of String. When you set toString to null, of course, the call to toString fails.
Lastly, you override it on the prototype of String, which will apply to all String objects. Why is this an unexpected error? toString is on the prototype, because it's defined on the class, not the instance. I'm not sure what the confusion is here.
yeah, but the people who write blog entries 'threatening' to switch all tend to be using unity or gnome-shell, or else threatening to switch to one of those two.
Well, it'll toss all of your templates into a convenient object, rather then having to do _.template($('#thing')). Still, doing the templating fully on the client seems a little wasteful, when it's easy to at least precompile the templates to functions. Brunch is useful to automate this, and has mustache support: http://brunch.io
Your .vimrc is essentially just going to be a collection of snippets that you've found that seem to do some good. Many of mine have been taken from other people's dotfiles, from dotfile projects such as
