At Caplin, we build very complex web applications for financial trading, and we are often asked for advice about which of the many JavaScript toolkits out there are the best.
Embarking on developing a web application can be bewildering: there’s no shortage of JavaScript toolkits of all different shapes and sizes but there’s no guiding light. Microsoft and Adobe, by contrast, offer a much greater degree of comfort with their methodologies, libraries and tool support – but only if you are willing to restrict your application to running on their respective platforms.
There are some great JavaScript tools out there, however, and this article attempts to navigate through the maze of toolkits to assist making technology choices when building a web application.
User Experience is Paramount
The GUI is the most prominent part of the application, and is usually the most expensive to develop. An important part of the UX rests on your choice of widgets and how customisable they are. You should choose widgets that will give you the best possible starting point; if you can’t find what you want, you will have to consider composing your own.
Most widget toolkits are general purpose, but more sophisticated widgets are emerging. ExtJS, jQuery and Dojo provide widgets ranging from grids to email suites. Caplin specifically targets widgets for financial sector clients that are oriented to financial domain specific objects and delivering real-time prices to the screen.
Widgets are typically customised using templates, configuration and programatically. Templating is by far the quickest approach, and this has been well proven with Silverlight’s XAML. HTML also works very well as a view templating language, and HTML5’s data attributes can be used to further this approach. Caplin has developed some easy-to-use frameworks that use HTML/CSS templating to build new widgets quickly.
UX does not stop at widget selection though: how they interact is also crucial. User workflow across all the widgets in the application needs to be implemented with due respect to the overall application structure.
Structural Patterns
Most GUIs conform to some kind of structural pattern. Passive View, Presenter First and Presentation Model (aka MVVM) are all good design approaches. There’s little merit in debating which precise pattern is “best” – if it were that simple then Martin Fowler would have told us the answer by now. The most important thing is that you should be able to build your widgets with the appropriate degree of composability, isolation and testability.
All MVC-derivatives leverage the observer pattern, and it’s crucial to choose an implementation to support the right level of decoupling (such as pub/sub). For example, a web application typically comprises a layout manager which houses its widgets and manages screen real estate, and you will need to consider how your component-level widgets will communicate with application-level code.
You may decide to use additional utilities to implement structural patterns in your application, but you need to proceed with caution.
Toolkit Selection
JavaScript toolkits come in two categories: widgets and utilities. Utilities such as prototype.js and backbone.js can serve as the basis for building your own widgets, but that starting point doesn’t suit everyone.
The lack of JavaScript standards means that, invariably, widget toolkits come with their own JavaScript extensions that are both integral to the widgets themselves and also feature in the API. Combining widgets from more than one toolkit requires special care, and each toolkit brings its own idiosyncratic syntax. For example, jQuery has its own $() selector syntax, and underscore.js which (as suggested by its name) entirely revolves around the ‘_’ symbol. This can be quite distracting when trying to standardise development across an enterprise.
For each toolkit you adopt, ensure that the benefits outweigh the incremental burden that you are taking on, and ensure that you are happy to embrace its idioms and syntax.
At Caplin we’ve made enthusiastic use of toolkits such as ExtJS, jQuery and Emprise charting, but have found it necessary to build our own frameworks for layout management, real-time grids and templating/data-binding. The last one of these has proved so useful that we are planning to open source this in the near future.