Framework Decision Process

Introduction

Pentaho's web-based applications have been written using a variety of different techologies, Plain JS, Dojo, GWT, JQuery and others. This has had a number of negative effects:

1. The thin interfaces are difficult to maintain as developers are required to be proficient in all of the tech in use.
2. The number of developers which can effectively work in a particular area is limited to those which are familiar with the tech.
3. New work which spans across areas written in different technologies is slowed down by the need to integrate in each area uniquely.
4. Regressions are frequent due to all of the custom integration points.
5. The Script loading and Building system is strained by technologies which want to load their own scripts
6. JS Unit testing is difficult and as such is almost non-existant in our thin-client codebase.

Going forward, we want all new development to be done using a unified Thin-client technology stack (Unified Stack). This Unified Stack must be able to integrate with the existing areas now and have the capability to replace those legacy areas in the future.

The criteria for the Unified Stack and process for evaluating potential stack candidates follows:

New Stack Criteria

The following criteria must be meet by the Unified Stack

1. Compatible License
   LGPL, MIT, APL or another liberal license.
2. Capable
   The Unified Stack must meet the following:
   
   • Dom querying and manipulation
   • Works well with others and with multiple instances of itself.
   • Good Class/Type system to allow for code re-use and customization.
   • Functional JS support (iterators, map, reduce, etc.)
   • Browser event abstraction, unified with synthetic eventing is possible (custom application events)
   • Browser History handling (forward/back).
   • Location routing. The ability to link to a particular area directly from the address bar (Deep linking)
   • MV* architecture. Some sort of loose-coupling architecure, i.e separation of models from views and app logic (controllers)
   • RESTFul service support, ideally with Model layer integration (automatic Model class generation from JSON)
   • Widget Set with Layouts
   • Templating System. The UI should not be constructed in Javascript. A declarative templating system, XML based to allow easy plugin template modification.
     • must support template snippet re-use (custom tags), collection looping, data binding, conditional blocks, recursion.
   • View <--> Model databinding to automate the task of keeping each in sync.
3. Able to be "Built" into a minified form. Obfuscation-safe.
4. Flexible server layout. Shouldn't enforce a particular app structure, or at least allow for custom resource layouts.
5. Easy to debug
6. Testable through automated JS unit tests
7. Customizable. We must be able to replace any part of the stack with another technology as needed (no framework lock-in)
8. Plugin script integration. Runtime needs to be flexible enough to incorporate scripts provided by plugin.
9. Well documented
10. Active Community. Higher mindshare the better.

The Candidates

1. AngularJS http://angularjs.org
2. Dojo http://dojotoolkit.org
   Dojo is the framework used to write both Analyzer and Interactive Reporting.
3. BackboneJS (http://backbonejs.org)
   Used in the Browse Perspective
4. Backbone Derivatives: Marionette http://marionettejs.com, Chaplin http://chaplinjs.org
5. EmberJS http://emberjs.com
6. Distal templates https://code.google.com/p/distal# Distal templates https://code.google.com/p/distal
7. Y(Yahoo)UI http://yuilibrary.com/
8. KnockoutJs http://knockoutjs.com/

Evaluation

Candidates need to be proven-out in the various areas of our product using different tech. This involves ensuring bi-directionality between existing areas and the candidate.

1. PUC
2. Dashboards
3. Analyzer
4. Interactive Reporting

Candidate Analysis