6 min read

The landscape of client-side technologies

Since 2005, when the term AJAX was invented, many JavaScript libraries and tools have popped up. In fact, there have been several tools earlier to aid DHTML development, which can be seen as predecessors for the AJAX tools and libraries. One of these is the earlier version of the Backbase framework, and another example is Bindows.

Some of those libraries survived the AJAX technology hype and grew into a solid base for many RIA projects and services, whereas some vanished.Libraries that survived have gone through a series of transformations and refactoring phases as well as marketing repositioning attempts. By now, there are hundreds of libraries, frameworks, and other tools, and it is not easy at all to find your way in this abundance and make the right choice.

Before we get to the actual comparison of the Backbase AJAX framework against similar solutions, we should look around to see how the canvas of relevant technologies is laid out. So, let’s first go through the tree of technologies until we end up in a group where Backbase resides.

We mentioned earlier in this book that there were a number of other versions of the Backbase framework, all Java-related, such as a JSF Edition. These products are currently supported only for existing customers and not available for new development. Therefore, they are not included in this comparison. Of course, it is still possible to easily use Java with the Backbase Client Framework!

Server-side and client-side

Until recently, we thought of web applications as websites being created and run on a web server somewhere on the Internet. The server-side application was entirely responsible for the page generation: it checked for authorization, retrieved data from data sources, and generated static web pages filled in with the data.

With time, server output in HTML became enhanced with scripts running on the client-side, but the page generation and the business logic between user interactions was still processed on the server-side. To aid such rather complex development, several technologies and frameworks are available, for example, GWT, ASP.NET MVC, and ZK.

Today, web applications development has radically changed; the frontend of the application is moving to the client-side, the web browser. Both application logic and UI generation are moving with it. This is exactly where client-side toolkits come into play.

Let’s proceed with those and ignore the server-dependent frameworks in the rest of this article. See the end of this article for more information on the frameworks mentioned earlier in this section.

Client-side libraries and frameworks

Most of JavaScript toolkits position themselves today as frameworks, although they called themselves libraries earlier. Some may really have evolved into a framework, whereas others are still, libraries.

In reality, it is not easy to differentiate between the two types of software: libraries and frameworks.

  • The common understanding of a library concludes that a library is designed to execute a well-defined task, for example, a library can decode data or, in the case of a JavaScript toolkit, it can simplify DOM traversal. As a library is designed to execute a certain task or a couple of tasks, it is usually not extensible in nature.
  • A software framework usually has wider scope. Eventually, it could be composed of several libraries. A framework, opposite to what a library does, allows and sometimes even requires extensions. A JavaScript framework often provides means to create widgets; it enables its own event’s flow and provides well-designed APIs to those widgets.

Is it important to know whether a certain JavaScript toolkit is a library or a framework? We believe, yes, it is important.

In practice, you will see that a library is often used to fine-tune web pages, while a framework is used to build true client-side applications. For example, the Script.aculo.us library provides great visual effects that can be used to improve web page appearance and interaction, while the framework qooxdoo can hardly be used for that purpose; it is only suitable for building an application.

Being categorized as a library does not decrease the quality or capabilities of a toolkit. Instead, it properly positions software so that a right choice can be made based on the purpose of using it. jQuery, MooTools, Prototype.js, and Script.aculo.us are all JavaScript libraries, and they are great at what they had been designed for: enhancing web pages without changing much in the overall development process.

We will not include the JavaScript libraries mentioned in this section further in our comparison.

Flash, Silverlight, and JavaScript-based frameworks

For the sake of completeness of the technology comparison, it may also be interesting to check out how some AJAX frameworks stand compared to plugin-based solutions, such as, Flash or Silverlight.

Both Flash and Silverlight employ XML for application layout, MXML and XAML respectively.

Both Flash and Silverlight have a way to extend their component base by implementing custom tags in custom namespaces, something that the Backbase AJAX framework also offers.

Both platforms, similar to some JavaScript-based frameworks, implement the Document Object Model, which enables document access and event flow, although Silverlight provides a custom, lighter version of the DOM API. Styling is not done with CSS, in either Flash or Silverlight.

The plugin-based solutions such as Flash and Silverlight are both great choices for building Rich Internet Applications that run on a desktop. They are not usable for mobile devices because these plugins do not run on them.

Client-side GUI framework and application framework

There is another category of frameworks that we would like to exclude from our comparison: the application frameworks. Examples of such a framework are Cappuccino, SproutCore, and PureMVC.

PureMVC is, as the name suggests, a framework that is there to help you implement the MVC part of your application.

To position Cappuccino, we quote here some text from their website, which sums up very nicely what it is trying to achieve:

Cappuccino is not designed for building web sites, or making existing sites more “dynamic”. We think these goals are too far removed from those of application development to be served well by a single framework. Projects like Prototype and jQuery are excellent at those tasks, but they are forced by their nature to make compromises which render them ineffective at application development.

On the other end of the existing frameworks are technologies like SproutCore . While SproutCore set out with similar goals to Cappuccino, it takes a distinctly different approach. It still relies on HTML, CSS, JavaScript, Prototype, and an entirely new and unique set of APIs. It also requires special development software and a compilation step.

The Backbase AJAX framework is not an application framework; rather it is a GUI framework. For smaller to medium-sized applications, you do not need an application framework, as long as you structure your application correctly. For larger applications, you could consider developing your own client MVC support, or try to integrate with a framework like PureMVC.

LEAVE A REPLY

Please enter your comment!
Please enter your name here