JavaScript is a difficult language to love. It sometimes feels like one of those “What’s this wedding ring doing on my finger?” romantic comedies.

You know the scene: a trashed hotel suite, the Vegas strip visible through the windows, bottles strewn about, art askew, and the appearance of an unfamiliar leg sticking out from under the covers. “What?” You cry, in horror, “But I’m engaged to the elegant and impeccably bred Haskell (played by Nicole Kidman)! Or, at least I thought I’d end up with the pragmatic and quietly intelligent Ruby (played by Ellen Page).

Not you, you blowzy slattern JavaScript! Everyone knows that all you’re about is getting embedded with every browser in town!” (The casting of JavaScript is left as an exercise for the reader.)

It might not be fair to criticize a language based on its name—or lack thereof—but the language’s name is fittingly arcane. Code-named “Mocha,” it first shipped as the eminently sensible “LiveScript,” then to be rechristened in a blatant attempt to jump on the bandwagon of the then-new Java language, only to end up officially named “ECMAScript” because everyone figured that it’d get a real name before the standard was ratified. So now “JavaScript” is a trademark of Oracle, and it’s probably proper to say something like “Mozilla’s JavaScript implementation of the ECMAScript programming lang—oh, I’m sorry, I seem to have dozed off.” Of course, no one calls it ECMAScript, and I’m not going to either.

More substantive criticism might center on such JavaScript language quirks as the “implicit semicolon” that is inserted at the end of a line, meaning that there is a behavioral difference between programs coding a return with an opening curly-bracket on the same line (sometimes called “K&R-style”) and curly-brackets lined up (“Allman style,” as is standard in C#). Criticism might also touch on the regrettable coercion rules, which specify that ‘3’ + 2 becomes the string “32,” but ‘3’ – 2 becomes the number 1.

The prototype inheritance model, while arguably quite natural for a dynamic language, is confusing to map into the commonly taught class-based model of inheritance.

What am I forgetting? Oh yeah, implicit global variables. Just. Not. Good.

It’s no wonder that the best book on JavaScript programming is called “JavaScript: The Good Parts,” and seems a mere pamphlet alongside the rhinoceros-covered “JavaScript: The Definitive Guide.”

Further, the JavaScript containers that are by far the most common, which is to say browsers, generally make it absurdly easy for JavaScript exceptions to quietly disappear. Add in the timing problems associated with page loading and it’s a wonder that any programs got executed at all before the release of jQuery. (More on jQuery in a moment.)

Yet, for all its warts, JavaScript is the language that you must master. It used to be that every programmer had to know C; it was such a part of so many different types of work that you simply had to be competent in it. That’s how JavaScript is today. Even if your main task is not Web programming, you will have to do some pages, sometimes.

And pleasing your clients with your Web programming, now and into the foreseeable future, is going to involve JavaScript. You might prefer a REST-ful series of pages filled with static text and hyperlinks (I know I prefer that), but your clients want in-page refreshes and widgets and text completion in their search boxes.

As far as that type of JavaScript programming goes, thank heavens for jQuery. jQuery is like C++’s Standard Template Library: It’s so powerful and idiomatic that it’s almost like a redefinition of the language itself.

jQuery makes manipulating the DOM and AJAX programming clean and structured; I’m less fond of its UI library, and its myriad extensions are a mixed bag, but the upside is so valuable that jQuery should be a focus of your JavaScript study. I like the books “jQuery in Action” by Bear Bibeault and Yehuda Katz, and the “jQuery Cookbook,” edited by Cody Lindley.

Regular readers know that I am a big fan of Erik Meijer’s work developing libraries for “reactive programming.” The Reactive Extensions for JavaScript bring these concepts into the browser (including Firefox and Chrome) in a way that I very much like, although the library’s use is hardly widespread yet.

It’s also difficult to love JavaScript during the Web development cycle. Although IDEs like JetBrains WebStorm add some niceties, it’s difficult to establish a development rhythm that doesn’t primarily involve working in the browser. Although all of the modern browsers have improved their development consoles, it’s still a clunky experience compared to method-by-method test-driven development. Tools like JsUnit help, and browser-based testing with Selenium are certainly vastly faster than driving things by hand, but still it’s discouragingly hard to set up an efficient development cycle.

The actual spur for this column, though, was not the use of JavaScript in Web programming, but the increasing interest in using JavaScript for general programming. Node.js (nodejs.org) makes it possible to write Web applications in JavaScript and, at least for simple servers, it’s dead simple. Sadly, most Web frameworks start elegantly and slowly accrete layers and libraries and become more and more unwieldy, but for now, Node.js is very approachable and promising. I’ve yet to find a good book on Node.js, but you can see some of my recommended links at pinboard.in/u:lobrien/t:nodejs.

Once cleaned up with a decent IDE, accessorized with some decent libraries, and treated with some respect, JavaScript can turn into a tolerable, if not thrilling, language. As with all romantic comedies, though, the “happily ever after” is left for the sequel.

Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.