You hate it, you love it
You start hating it but you might end up having so much fun with Javascript. It takes time to acquire the taste and enjoy the powerful capabilities that annoy you at the beginning. This is my experience learning this popular language.
Take into account that my opinion is based on just a few months of experience with Javascript as a language, not just a tool to manipulate the DOM (html and css). It will probably change along the journey.
The white box
Being used to languages like Python, I’d say Javascript is a white-box language while Python is a black-box one. That is, you don’t really need to read books to start coding in Python, you just see some example code, try some lines and usually its execution behaves as you expected. It feels so natural. That is not the case of Javascript, its rules are not natural at a first glance. In fact, you have to know very well how the interpreter makes decisions. If you make a mistake writing some code that wouldn’t compile or would raise an exception on other programming languages, Javascript will instead try to execute the code. And will probably traverse all the execution path. Because it doesn’t fail, this behavior can be very confusing and hard to detect. You wish the interpreter to tell you that, you made a mistake and you probably didn’t want to write what you did, you don’t want the execution to continue. That is the feeling at the beginning. On the other hand, as time goes by, these capabilities turn out to be so powerful in terms of implementation choices and performance tuning.
Unfortunately coding for performance tuning leads to code that is hard to understand and maintain.
TDD is a must
We’ve been pairing and test driving our Javascript code these months using Jasmine. I feel that the impact of BDD on Javascript is bigger than on any other language. It’s mandatory. I don’t want to write a single line of production code if there is no failing test asking for it. Because Javascript forces me to be smarter than I am sometimes and ocuppies part of my mind with subtle implementation details that moves me away from writing code that expresses the business domain, the semantic of the actual business problem to solve.
If I don’t write a test, a specification that clearly states what I expect the code to do and see it pass, I can’t bet that it will work just by looking at the production code. It would feel like gambling.
There is a tone of patterns to avoid tipical Javascript mistakes. There are many books on the subject. Experts advise you techniques like, “check the type of the arguments the function receives, to make sure you get what you expect”. But then they tell you that “instanceof” operator might not work if the inheritance wasn’t implemented properly. It is overwhelming. I tell you a secret… you don’t need to master all those patterns if you test drive your code! You don’t have to worry about all possible usages of your code if it’s you or your team who are going to consume it, because the specifications are already thought, written and are executable.
I always prefer “duck typing” than asking for the type of the arguments. I usually prefer to let Javascript evaluate conditions using its coercion rather than using strict operators like “===” or “!==”. Because if you write code for humans, it is better to say:
“if (userExists)”
than
“if (userExists === true)”.
So the approach and the concerns are totally different when you test drive the code. The productivity gain is brutal. Javascript is too expensive to work with if you can’t guarantee all the time, that your code functions as you inteded it to be.
If for some reason I would not be able to develop with BDD, I would code with Coffescript rather than Javascript 🙂
The approach is totally different if you are writing a framework. Frameworks are too general, they are horizontal, not vertical so there is no business semantic on them. So yes, for frameworks you should be a Javascript power ranger.
OOP or Funtional?
Javascript is not a classical objet oriented language. There are no classes. However is a great language for object oriented programming! Don’t be confused with this. If you know the object oriented paradigm, you just need to know how to implement polymorphism, composition and so on. The discussion on “there are no classes, there are prototypes”, is superfluous. It is an implementation detail I don’t care about. I don’t think that is really important because I can express behavior with objects and model the domain the same way I would do it in Java. Rather than using “class” and “extends” I would use “constructor stealing along with prototype chainning”. But it’s the same tool 🙂
On the other hand, javascript is a great language for functional programming too 🙂 It is actually more used as a functional language than as an OOP one. It is very common to pass functions as parameters and things like that.
You can approach different paradigms with Javascript. My advise is to not mix them together though.
Programming the UI is fun again!
I used to write desktop applications using Delphi, pyGTK and Windows Forms at the beginning of the past decade. When the web started getting mainstream, it was sad to say goodbye to all the best practices learned all those years. Used to the power of event oriented programming, rich components, data binding, and design patterns in general, developing for the web felt a step back. During the past decade there have been many attemps to mimic the old desktop in the web; portlets, asp webforms, and so on. None of them made developers happy, so the Model-View-Controller (MVC) pattern came to the rescue. However, dealing with the UI is still something developer don’t really use to enjoy. DOM manipulation has been a pain in the ass with every browser having different behavior and API. I’ve been trying to avoid it until now and, to be honest, I am happy to not have invested my time fighting with problems that jQuery handles for me nowdays.
Now, ECMAScript 5 is supported in all major browsers. jQuery and other frameworks make life easier. And there is something that we didn’t have in the old desktop programming: the chance to programmatically interact with widgets (UI controls or components). Well there are some frameworks for that in the native desktop, by they came late. This means that we can write automated tests for UI behavior!
So now, we have the chance again to use event driven programming, to really implement patterns like the “observer” and many others. And we can test drive all of them!
We can develop semantic components that add domain knowledge inside UI widgets and make the user experience way better. There is no need for intrusive frameworks that tell us exactly all the layers to be used and how. Everything is ready to craft the code to make it express as much human knowledge as possible.
So we are taking the chance.
No need for MVC frameworks
In the first two weeks of the project we started using Backbone. In the first spike, we used the whole framework. A bit later, just the models and collections. Nowdays, we have completely got rid of it. It is a great framework, but we don’t need MVC frameworks anymore on the client side because they are more restrictive than we need. We don’t develop “screens”, we try to create “smart components” that can be reused and provide a different level of abstraction. The screen is just a place holder for components that can be injected. With the rich UI programming that Javascript give us today, the paradigm has changed. It is time to retrieve practices from 15 years ago mixed with best practices learned in the latest years. I wouldn’t port or copy exactly what we have been doing recently.