This document discusses the development process behind a popular JavaScript charting framework. It describes how the framework was designed with a flexible, plugin-based architecture to support evolving customer needs during the transition from Flash to HTML5. Key aspects included an event-driven core that supported standardized inheritance and interfaces to allow modular development. The code examples show how new modules can be added while maintaining a consistent API through an extension method. Maintaining coding standards, documentation, and a linting process from the start is advised for frameworks developed by multiple engineers.

1. THE CLOCKWORKS BEHIND A
JAVASCRIPT FRAMEWORK
that powers a billion charts a month

2. What everybody (secretly) wants to do?
 Create popular frameworks and apps
 Help a lot of people and organizations
 Make a lot of money out of it

3. Avoiding the vicious cycle
Scrap Develop
Let it
out Release
again!
Re-
Scrap
Develop

4. What do we lose in this process?
 Enthusiasm for innovation
 Delay in product shipment
 Possible reduction in quality
 Difficulty in migration
 Trust of your consumers
 MONEY

5. The story of our framework
• Transparent transition for existing users from
Flash to SVG and VML.
• We had no way to anticipate the roadblocks
that we would face while developing for this
transition.
• Thus, we created a model flexible enough to
support any design required to attend
customers’ needs.

6. Developing the “play dough”
 Treated the core of our framework as a mini-
framework that would allow us to develop our
framework around it!
 Plugin-like architecture.
 Event driven.
 Standardized inheritance.
 Managed interfaces.

7. Add Module
Event Dispatcher Inject
Module
Command
Interface Interpreters
Facilitator
Policy Parsers

8. The code that does it!
FusionCharts([’private’, 'modules.api.sortdata',
function () {
var ns = this,
core = ns.core,
sortData = function () { /* define it */ };
ns.extend(core.prototype, {
keepDataSorted: function (yes) {
this[yes ? 'addEventListener' :
'removeEventListener']('BeforeDataUpdate',
sortData);
}
});
}]);
// Fiddle: http://jsfiddle.net/shamasis/RNe3h/

9. (new Tips()).cliché()
• Set coding style standards including in-line
documentation standards. – allows easy
maintenance on multi-developer environment
• Lint your codes from the very first day. It may be
costly to do later.
• Follow inline documentation standards – maybe
javaDocs, jsDocs, etc.
• Even better, if your minifier engine has its own
rules (such as of Closure Compiler), use that.

10. Points to Design a Good API
http://www.shamasis.net/2009/07/how-to-design-a-good-api/
Why to Design a Good API
http://www.shamasis.net/2009/05/why-to-design-a-good-api/
FusionCharts Beginner’s Guide
http://www.fusioncharts.com/resources/fusioncharts-beginners-guide/
shamasis@fusioncharts.com
@shamasis