Adventures in Javascript

As I detailed in the last article about my little side-project, for creating a web-based mindmap/task management application, I have gone through several architecture design stages. What that article doesn’t mention, is the amount of refactoring it took in the modules themselves, to reach a working prototype.

Javascript is a language that stepped out from the the shadow of the basic browser event handling, to become a widely adopted language blazing fast. The speed of transformation is like Dr Doolittle on steroids, trying to get a bum to deliver a speech in the literary society in just a few hours.

In the beginning, I started up with a few core Javascript based modules, using core NodeJS. I was using simple tutorial examples to boot the service modules, as I didn’t want to waste time on the first few attempts. I literally looked up everything I knew I could solve using core language constructs, to see if there are any already existing solutions to go with. I did so, even when I knew it would be faster to write my own solution for that particular problem. The number of module dependencies started to increase pretty fast.

Why would I do that? First of all, you don’t want to reinvent the wheel. Secondly, if there is a module solving your particular problem, there is a chance, it would later be useful to solve similar tasks as well. The third reason was to get an idea about the NodeJS world.

It soon transpired, that the framework is quite in the developing stages, you can find several modules doing the same, with unlimited amount of time spent on parallel development. There are tons of abandoned modules, some branched of in several directions. The level of fragmentation is astonishing.

I had to tread lightly with the modules I used, but it was well worth the effort. Development started rolling, and the research I invested turned out to be enough to avoid the pitfalls of replacing non-working modules.

The better part of me decided to start creating unit tests for my code. You should never test your own code, but as I am working on this alone, I went with this schizophrenic approach. It took just a few hours, to understand and include the mocha unit test framework in the application. Soon it turned out to be a good idea.

A friend told me, that no self respective adult would work in a loosely typed language.

The tests quickly brought out several issues with type conversions. So I decided to give Typescript a run for it.

Typescript is basically a precompiled, that allows Javascript be extended with a few extras, such as type declarations and visibility of class members and methods. In runtime it gives you no advantage whatsoever, but at development time it helps you to avoid simple mistakes.

In practice adding the type declaration is too easily overlooked, and it doesn’t enforce it. On the other hand, for the modules that are not written in Typescript (ie most of them) you have to get a declaration file from somewhere. These are outdated or simply don’t exist for most of the major modules, that I use. Since the Javascript module mechanisms are as fragmented as the modules themselves, writing such a definition is not as easy as seems. I literally wasted days on migration of a single module.

Once I got fed up with Typescript, I learned, that the newly released node.js version supports ECMA script version 6 (ES6) This standard supposed to bring a much better oop support for the language. I have therefore took a single module, and converted it to ES6, only to learn, that ES6 is only available, if I use a transpired, to convert my code, either in runtime, or using the precompiler to create ES5 compatible code.

Babel is the transpiler of my choice, and it soon turned out, I can’t debug the transpiled code, as the line numbers are changed in runtime when you use it.

Soon I got back to using typescript, and as a final step in this long experiment, I’ve collapsed the microservices in a classic 3 tier web architecture, reintroduced Typescript and decided to go with that from now on.

With the stabilized environment, I’ve created as much new, tested code, in two days, than in the previous two months. So I guess I will just stick with it.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.