I'm not a professional programmer, but having a PhD in an engineering field, I've taught myself many programming languages over the years. The past few years I've been using primarily Ruby, and now I'm trying to learn JavaScript so I can do a bit of web programming.

I guess like a lot of people, I had a mostly negative impression of JavaScript going in, but as I'm studying the language (through the book JavaScript: The Good Parts by Crockford), I find that the functional part of the language is really neat. I dabbled in Haskell a few years ago, so I had some idea about functional programming.

I'm wondering how professional programmers tend to use the language. Do you stick to one paradigm when writing in JavaScript, or do you use it like a swiss army knife, and used different paradigms for different problems? Is there a "most popular" way to use it these days, or does it simply depend on the programmer, problem, company, etc.?

  • 3
    Try CoffeeScript. It takes the good stuff from JavaScript and leaves the bad parts behind (although it "compiles" to JavaScript). – Nick May 23 '12 at 1:02
  • @Nick I took a look at CoffeeScript a few days ago, and it reminded me a lot of Ruby actually. I think I want to make sure I have a good handle on "pure" JS, and then maybe I'll take a longer look at it. – Evan Zamir May 23 '12 at 3:29
  • 1
    Getting a good handle first is the right move. And take Crockford with a grain of salt. JS definitely wasn't his first programming language and I get the sense he's had a long-standing love/hate thing with it. Some of the 'bad parts' are actually really powerful when used responsibly. – Erik Reppen May 23 '12 at 4:50

The only paradigm JavaScript doesn't readily lend itself to is an overly locked one. One of the things I find most offensive about Java, for instance is this idea that everything must originate with classes, that each class is in one file, that there is an impregnable barrier of encapsulation between your code and the enem... I mean the other developers on your team or your dev customers.

When everything is forced OOP, IMO, what you end up with is a whole lot of devs (I didn't say all or most of them) who don't actually know what problems OOP is supposed to solve in the first place. So yes, the tradeoff is that sometimes it can be a touch arcane but we get everything. We get objects that can have factories built to emulate classical OOP if that's what desperately floats your boat (Crockford admits he never really used the one he wrote). We get closures. We get first class functions we can toss around all over the place. Hell we can even reapply methods from objects as if they were methods of other objects at whim. Awful if abused. Stunningly powerful when used wisely. You get the flexibility and the rope to hang yourself rather than having the options snatched away for fear that the lowest common denominator will hang themselves.

The problem on the flip-side where JavaScript stands of course, is code soup. You have to establish some kind of a paradigm or what you end up with is something that is not so nice for the next guy to read or use or modify. The good news is that you can pretty much pick any paradigm you want. I find what works for me at my current job is larger app object structures that act as factories, warehouses, and event routers for event-driven interfaces that enable either total decoupling or something that looks and works more like traditional objects but logs an event name, origin, and params passed every time you fire a method for debug purposes. I continue to use JQuery for bringing cross-browser sanity and insane speed-of-development to the nitty-gritty DOM stuff but then I bury the JQ soup inside my own app architecture so a back end dev never has to make sense out of $('#someId > .someClass :first').click(function(e){.... to figure out what the heck is happening on the front end. But even if your first attempt at structure looks like a bunch of cookie-cutter JavaBeans, it's better to perhaps start with something than nothing. Just don't go nuts with inheritance schemes. I mention this. Everywhere. Because it's the most awful thing you can do in any language and the reason having something less than native classical OOP is not such a big deal.

The real trick to JS is finding the right balance of structure and consistently implemented interface and giving people enough flexibility to use your stuff in a variety of ways without turning your code into an ungainly, unreadable, mess. Fortunately, ugly things are easily wrapped, adapted, and decorated in JS. So how do you use it? You learn it. Really well. Then you write code to explore, invent, assert, or assimilate other development paradigms into your own as needed. What I really love about JS is that I generally find if I put a little thought into design, I can have my cake and eat it too. Stick with DRY, loose-coupling and the elimination of boiler-plate as priorities and any paradigm you adopt in JS is likely to not stink when you know your way around the language well enough. But there's a lot to learn. Partially because the spec is constantly having new features added and occasionally dropping old nasty ones and every new browser is an adventure waiting to happen.

On the matter of functional vs. OOP, I personally use both extensively. I think most experienced JS devs do, without even really realizing they're doing something atypical. My objects and constructors inform architecture and the blocks that tend to interact with one another. The functional nature of JS makes it possible to have the nature of how those objects interact be anything I want.

  • Wow. If you wrote a book, I'd definitely want to read it. Thanks. – Evan Zamir May 23 '12 at 11:44

I use a good JavaScript framework, such as jQuery or Prototype. It should change your negative impression of JavaScript in general. It has come a long way over the years and it's definitely worth another look.


I would say years ago, JavaScript was for making things flash on the screen, and for making cool mouse trailers (to the general developers of the time), and for teaching patience to developers..

Then Ajax gained popularity, which allowed for Javascript to deal with Data. Javascript was a real pain because it was so rudimentary back then and when we had tools like Visual Studio which provides great intellisense for the .NET languages, when compared to Javascript which had little to none, it was a pretty awful experience honestly.. most of my peers hated javascript back then..

Then came jQuery... I told my boss a couple years ago we better learn JavaScript (me C#, him VB), because jQuery took all the work out of JavaScript and gave us some really cool functionality.

Now we have things like Node.js, which is all JavaScript, both client and server.. I'm not going to get into that.. and i'm not sure how i feel about that.. but it's definately a full materialization of JavaScript on the Web anyways..

I remember hearing about Enyo and WebOS, which was pretty much JavaScript, and Windows 8 is pretty JavaScript friendly as mentioned..

And I almost forgot to mention JSON.. JSON is a cool way for passing data around.. again, nice to work with on the client side, and DB's like Mongo seem to like the technology a lot as well

So for Usage you ask?? I would say it is like a swiss army knife.. some can say HTML with JavaScript is all you need when paired with a good webservice layer(s).. I think there's definately still room for a strong platform base (asp.net, and others..) but to each his own

IMO, I think it has it's place on the client end of things.. it's great for making UI updates.. great for making "Partial" post backs, and accessing a local data store (on the client).. and now with HTML 5, I really do see it being the "Flash Killer".. we'll probably start seeing intro's again with a skip button.. lol.. those were the cool days..

For single page applications and applications like that.. it should definitely be considered with one of the frameworks out there like backbone or one of the others (there's a tone).. Security is something to keep in mind, as well as latency.. but that will all vary in importance based on the project at hand..

So really i would say it's a mix of preference and the application at hand.

  • That's a great answer, but maybe I wasn't clear enough about my question. What I really am wondering is whether you use JS more as a functional or object-oriented language, or both, and it just depends on the project. Another way to ask this is whether it's up to the individual programmer preference, or is there now a "preferred" style or paradigm (i.e. functional or OO) among JS programmers, or maybe there are different camps that argue one way or the other is better. – Evan Zamir May 23 '12 at 3:30
  • woops.. then JSON would somewhat touch on the subject.. but i would say a solid mix of both depending on the application.. it's such loose language that it's really not about what it can do for you, it's more about what do you need to do with it. – hanzolo May 23 '12 at 17:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.