[abecedarius]

Do any of you just avoid 'this' and write your Javascript like infix Scheme? You can define objects via JSON literals with function values, and the result seems both simpler to think about and more pleasant to read. (JS engines are tuned for thissy code instead, I think unfortunately, but you can fall back to using prototypes where it makes a difference.)

[gruseom]

Yes indeed. I don't bother with 'this' at all, except when forced to by some interface. I don't even bother to define objects most of the time, just top level functions that can easily be called from a REPL. That simple subset of JS is powerful enough to go a long way — long enough that I'm unconvinced one needs anything else, unless one believes one does — and programming this way feels liberating, like riding a bicycle instead of pushing a car.

[lopatin]

Are you able to write large applications like this without things getting too messy? I'm interested because I usually write JavaScript in the complete opposite way than you just described (strictly OOP, almost like I'm writing Java). This also means that I use 'this' quite a lot. Do you come from a functional programming background? What do you think about languages like clojurescript?

[gruseom]

My main work is on a complex application, but we write it in Parenscript, a Lisp that compiles to Javascript (so yes, I do like languages like Clojurescript). That gives us escape hatches for controlling complexity that raw Javascript doesn't have. On the other hand, I do still write some raw Javascript and I prefer the same style in both. As far as I can tell from various measurements, the Lisp I write is about half the size of what I would write in JS. That's a win, but not so big that it can be the only strategy for limiting complexity.

Do I come from a functional programming background? Not really. I use closures and lambdas a lot, but my code is rather imperative. My obsession when building systems is to keep the code as simple and small as I reasonably can. Mutable state and even global state don't scare me as long as they help with that. What scares me are architectural assumptions about how one "should" structure complex software.

This sort of thing is a bazillion times more fun to discuss in person, whilst drinking beer, than it is in the contactless format in which we find ourselves. I'd try to convince you that you might do well to drop your OO assumptions, but I'm afraid of coming across as shrill. There isn't enough context here to make one's claims nuancedly enough, and then also "nuancedly" is not a word.

[javajosh]

So far, my code tends to not use this at all. However, I've not written any applications that go beyond a few hundred lines of JS (interestingly, most of these programs would have been a few thousand lines of Java, if I even bothered to try at all. For UI, the libraries for JavaScript far outstrip anything available for Java!)

I do seem to be gravitating toward an organization scheme that centralizes my applications data into a single place such that all moving pieces of the application get a shot at dealing with inbound messages in an orderly fashion. This allows me to decompose the application into a very small number of function types, each of which has an explicit kind of responsibility.

The only time I've been tempted to go back to OOP has been to write (pure!) functions that seem to just beg for it - complex validation routines in particular. But using OOP for the app as a whole seems to not only be unnecessary, but positively undesirable.

[aufreak3]

This is why I avoid using "this". Placing this comment next to any of the 9 points causes the comment to mean something different. However, "this" could be useful in circumstances where that is the exact effect desired. Even in such cases, the relevant object can be made explicit as an argument.

Some time back, I had to explain to some people how to think about "traditional OO" in JS, which I tried to make systematic in a post [1]. (Not trying to self promote here, but most other presentations I've seen start with the prototype mechanism. "this" is not brought in until much later in the post.)

[1] http://sriku.org/blog/2012/04/12/classes-and-javascript/

[edit: fixed typo]