Hitachi Vantara Pentaho Community Wiki
Skip to end of metadata
Go to start of metadata

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

    Candidate

    License

    Documentation

    Mindshare

    AngularJS

    • Yes

    Dojo

    • Yes

    BackboneJS

    • Yes

    Marionette

    Chaplin

    • Yes

    Distal

    EmberJS

    • Yes

    YUI

    • Yes

    KnockoutJs

    • Yes

    Capability

    AngularJS

    Dojo

    BackboneJS

    Marionette

    Chaplin

    EmberJS

    YUI

    Knockout

    Dom Query/Manipulation/Eventing

    • Yes
    • None (requires jQuery)
    • None (requires jQuery)
    • jQuery
    • None (requires jQuery)
    • Yes. Node is base element
    • No

    Plays well with others and multiples of itself

    • Yes (multiple modules per page)
    • Yes, restrict namespaces
    • Yes
    • Yes, module and sub-module architecture
    • Yes, restrict namespaces
    • Yes, restrict namespaces
    • Yes, restrict namespaces
    • Yes, unique data-binding syntax

    Good Class/Type system

    • Yes
    • Customization and code reusal
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes

    Functional JS support

    • only a few from jqlite (subset of jQuery)
    • Node list, query, map
    • Yes
    • Via jQuery
    • Via jQuery
    • Via jQuery
    • Yes
    • No, via jQuery

    Event Bus

    • Yes, Scope methods
    • Events via Evented Class
    • Yes
    • Via, jQuery
    • Via jQuery
    • Via jQuery
    • Events via EventTarget and Custom
    • Yes, via Custom Bindings

    Browser History handling

    • Yes, $location
    • dojo.router
    • Yes, Backbone.History
    • Yes, Backbone History
    • Yes, router
    • Yes
    • Browser History Manager
    • No, history.js is one option

    Location routing

    • Yes, $routeProvider
    • dojo.router
    • Yes, Backbone.Router
    • Yes, AppRouter
    • Yes, router
    • Yes
    • Yes, Router
    • No, pagerjs or sammy are Knockout specific options

    MV* architecture

    • Yes
    • dojox.mvc
    • Yes
    • Yes, via Backbone.Model
    • Yes
    • Yes
    • Yes
    • No. It is MVVM

    RESTFul service Model support

    • Yes, $resource
    • dojo.xhrGet/Post/Put
    • Yes
    • Yes, via jQuery
    • Via jQuery
    • At least via jQuery
    • Yes, restful-xhr
    • No, via jQuery

    View <--> Model databinding

    • Yes
    • dojo Data Modeling
    • Yes
    • Yes, via Backbone
    • Yes, backbone
    • Yes
    • Yes
    • Yes

    Able to be "Built"

    • No
    • dojo srinksafe
    • No
    • No
    • No
    • No, at least native
    • Yes, YUI Compressor
    • No

    Flexible server layout.

    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes

    Easy to debug

    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes

    Testable

    • It doens't look perfect, need other libraries
    • DOH, dojo Objective Harness
    • No, QUnit or Jasmine
    • No
    • Yes
    • Yes
    • Yes
    • No, Qunit or Jasmine

    Customizable, cafeteria model

    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes

    Plugin script integration

    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes
    • Yes

    Candidate

    Programatic Overlay-like support

    Data Binding

    Looping

    Conditionals

    Recursion

    AngularJS

    Distal

    XUL-HTML

    YUI

    • Yes
    • Yes
    • Yes
    • Yes
    • Yes

    Error rendering macro 'deck'

    java.lang.NullPointerException

    • No labels

    1 Comment

    1. user-9e8e4

      One thing that I consider to be very important is the existence of type system utilities (creating OO-like classes in JS, enumerations, mixins). 
      This is more missed for creating things like components, plugins, etc.

      • Dojo does provide this, extensively.
      • jQuery doesn't.
      • CDF uses Base.js for defining components.
      • CCC uses the home-brewed def.js' def.type.

      Another thing that I consider very important is the existence of iteration utilities, in the style of functional programming.

      • underscore.js provides this extensively.
      • jQuery provides for DOM/Array/Object all-in-one enumeration with #each. But not much more.
      • Dojo has #each as well. Don't know what else in this area.
      • CCC uses def.js for lazy query enumeration.

      If jQuery ends up being inevitable, it is not sufficient.

      We should adhere to other less-DOM oriented, and more JS-oriented, for filling gaps in these areas.

      d3.js is also a very good DOM manipulation utility, featuring animation. It uses one-way data-binding for accomplishing dynamic DOM-generation, from data.

      Edit 1: Just remembered about YUI, from Yahoo: http://yuilibrary.com/.

      Other framework-related interesting features:

      • text resources, messages
      • error handling