Hate JavaScript?

Do you hate JavaScript? Well, I have bad news. There are still no alternatives in the web browsers.

I develop ASP.NET (MVC) –based web applications, and I must use JavaScript. What’s the big difference between the modern web applications and websites from a few years ago? Well, the server-side/client-side ratio. A few years ago I was happy coding on server-side. I did as much as I could do in C#, in ASP.NET. I did learn JavaScript but I avoided it as much as I could (so I never knew it well enough).

Now you can’t avoid JavaScript anymore. More and more code is on client-side. More and more business logic and architectural challenges are on client-side, right in the browser. I’ve written database-like features and even messaging systems in JavaScript. That challenge reminds me the early days of other languages. Missing features, missing language support, missing best practices, missing design patterns. Pure greenfield tasks.

How well do you speak JavaScript? A few years ago it was enough to understand how to define a function and some variables. Learn how DOM works. How different DOMs work. That’s not a small thing if you did it well. But did we write good, quality code with low bug ratio and good manageability? I’d say no.

A few years later there came the object-oriented world to JavaScript. We, I personally, had to learn the idea behind prototype-based languages. That’s a hard step with a ‘real’ object-oriented (Java, C#, C++) mindset. How can I implement inheritance? How can I hide data? How can I achieve polymorphism? Tough questions. Luckily along came design patterns. There are even a few books on the topic in JavaScript. Still, it’s not easy. I personally can recite 4-5 inheritance patterns. There are at least 2 data hiding patterns I can recall right now.

Well, many options, with their own drawbacks. It’s not easy to choose, e.g. at the beginning of a new project. There is no universal solution. There is no good solution. You have to consider the tasks you have to do with your object model and the knowledge level of the colleagues. Usually the later is harder. How much knowledge people have about JavaScript in e.g. Java/C# world? As much as they get along the projects. They teach each other.  To good and bed. What I saw in the last years, mostly obsolete and sometimes bad. Not easy to show them the current trends and solutions. Or may I say, contemporary engineering practices. People can, and usually are, be very proud of their coding style, quality, cleverness, etc. How can they be so neglect on these in an other language, e.g. JavaScript?

Now there are frameworks for DOM manipulation (jQuery, dojo, YUI), for common tasks (Underscore, YUI, Closure), and there are architectural frameworks (Knockout, Backbone) as well. As you can see, they are fractured and you must use different frameworks for different tasks. You should choose well because it’s very very hard to change frameworks, and you have to watch out for compatibility. Framework version changes represent huge risk in the lifetime of a project. Even a minor version change can render your web application totally useless. So test heavily.

No we have two ways. Full manual testing with a lot of humans. Or follow the ‘new’ trend and use some kind of automated test frameworks (Selenium, Watir). If they work the way you think. If it’s not more time to maintain your tests than execute them manually.

The same applies to unit tests. There are various frameworks in different flavors (xUnit, BDD, etc.) with different capabilities and APIs. Some live long, some live short. Choose well. Update regularly. Follow the news, trends.

Well, I chose a unit testing framework. Now I should test my code. How? It produces HTML into the DOM and calculates things according to different business rules – in the same function. Well, good luck. Try separating your business logic from visual stuff. Rings the bell? MVC? MVVM? Well, I’d say Knockout and Backbone. I’d say use (revealing) module pattern for your view model and your rendering as well. Separate them. Use a framework, e.g. Require.js. If you do it good, you can even get rid of the inheritance and other OO problems. Now you can test your business logic separated from the UI.

Next problem: I have a dynamic AJAX (AJAJ - Asynchronous Javascript and JSON) application calling back to the server. That’s not good. Let’s spy. Let’s stub.  Let’s mock. Find a framework, I chose Sinon.

So, let’s summarize. I do my job well if I know functions, variables, OO patterns, DOM frameworks, task frameworks, architectural frameworks, testing frameworks, module patterns, JavaScript mocking frameworks. Is that enough?

I have bed news. We in the web world develop applications like C++ coders develop applications for Windows, Linux, BSD… at the same time with the same code base. Instead of OSs, we have browsers and JavaScript standard versions. Now we have mobile devices as well, with different kind of browsers. So keep up, learn and write code in JavaScript. It’s better to learn and understand it than hope for surviving it. The next few years are about JavaScript and the Web. Get used to it, accept it. Do it as good as you do your job on server-side.