I\'m not a professional programmer, but having a PhD in an engineering field, I\

Question

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.?

Explanation / Answer

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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.