Logging From JavaScript

24. November, 2011

Logging is a recurring issue in JavaScript. There are a  couple of frameworks which support you. I’ve picked out two:

Some pros and cons:

log4javascript is very powerful. It contains lots of options, it has timers, several appenders (in page or using a popup window), the console supports tons of filters. If you know log4j, you’ll find almost everything replicated. If you need fewer options, there is even a lite version.

Despite the many options, log4javascript is still simple to set up and use (so it’s not like log4j in every respect). The default setup needs 3 lines of code (not counting the script element to load the framework).

There are two minor points: The console is pretty big and the in-page version can’t be moved.

Blackbird is a really small logging framework. No frills, just the basics. So no exception logging, for example. A profiling option is the most complex feature. In the world of the logging frameworks, it’s the iPhone: Nice look and only the useful features. The console is always in page, it sits in one of the four browser corners, it can be hidden and shown with F2.

My main complaint about Blackbird is that you can’t use the mouse to move the console. Also disabling the framework needs several lines of code. A single variable would have been more comfortable.

 


Jazoon 2011, Day 2 – How frameworks can kill your projects and patterns to prevent you from getting killed – Sander Hoogendoorn

26. June, 2011

How frameworks can kill your projects and patterns to prevent you from getting killed – Sander Hoogendoorn

Sander talked about frameworks and the usual problems with them:

  • How to choose the best framework from over 9’000?
  • Some frameworks integrate only specific things (like logging or building a UI), others include everything and the kitchen sink. Which is better?
  • How do you convince your management to buy a framework, train the developers, testers, support people for it?
  • How do you get the other developers to agree to your choice?

After selecting a framework, the trouble starts:

  • What do you do it an important feature is missing? Do you add it? How do you maintain it? Do you file a bug report? What if it’s being ignored?
  • Half along the project, you find a framework that is better suited.
  • How do you handle bugs in the framework?
  • When do you upgrade after a new version comes out? What if the new version has dramatic changes that break a lot of your code?
  • What if development of your favorite framework stops? Do you take over or walk away?
  • If one framework isn’t enough, you’ll find that dependencies tend to kill you because all the problems above multiply.
  • Sometimes, framework A has a hidden dependency on logging framework B but your company uses logging framework C.

The way to answer these questions:

  • Know your architecture. What do you need where?
  • Instead of using the framework directly, put in an abstraction layer that says what you want and does it using the features of the framework. If “something” happens, chances are you only have to change the abstraction layer.
  • Use dependency injection to clean up your code from unwanted dependencies.

%d bloggers like this: