Coupling, API surface area and change change change

Recently I started a new job focusing much more heavily on JavaScript than before and having been in this new role for a little while and having got the release of JSquared 1.1 out of the way, I have had some time to think about what I have learnt so far.

Firstly it must be said that I am thoroughly enjoying working more heavily with JavaScript and I have already learnt some wonderful and interesting things about the way that JavaScript operates and how to make it go a bit faster. No, a LOT faster! I will be talking about some of these things in the future and applying that knowledge to JSquared!

Also, I have recently read the excellent book from Douglas Crockford espousing about the good parts of JavaScript. However, what I saw in my new role did not conform too closely if at all to the Crockford way of thinking (which I happen to largely share).

First off, the code that exists here is of a very high quality and is well organised, but I have started to realise that there are a number of things I would look to do differently if we could re-write all the code from scratch.

The code has become fairly tightly coupled over time with one object requiring and expecting another object to exist and the second object creating a back reference to the first. There are a number of circular references if one looks through the various objects closely enough.

References to objects are being passed around freely and there is little control being exercised over how values should be accessed and a distinct lack of singletons being used when I believe they should be.

This leads to a very large API surface area. By this I mean that there are a large number of methods that each object needs to expose and a large number of object references being passed around when a smaller API with singletons where appropriate would be simpler.

The combination of the above two things leads to a problem. If you want to rebuild all or part of an object, it becomes more difficult as the objects have very little private code. If an object exposes just a few methods and properties as its API, and retains the rest of its working as private internals, it becomes much easier and simpler to re-write or add to it.

This is a JavaScript application which undergoes constant change by multiple people. Whilst this is good, it does mean that there are more and more objects with wider and wider surface areas. I personally believe that this will lead to the need for a complete re-write of large parts of the application sooner.

This brings me on to my final point, a positive and a negative point. The application is harder to learn and takes longer to become confident with because of this large API surface area. I enjoy that though as I want the challenge!