Page History

Perhaps nothing in Tapestry has changed over the years so much as the way client-side JavaScript is supported. From the get go, the goal was to make JavaScript a first-class citizen in the Tapestry world, and make it easy to encapsulate JavaScript within components.

The legacy JavaScript page discusses the earlier approaches; the main feature of Tapestry 5.4 is a total rewrite of all things client-side, with the following goals:

• Break the hard linkage of Tapestry to Prototype and Scriptaculous, by introducing an abstraction layer
• Remove the clumsy Tapestry and T5 "namespaces"
• Reduce the amount of page-specific JavaScript initialization
• Make it easier to override behavior associated with client elements
• Support CoffeeScript and (potentially) other languages that target JavaScript
• Organize client-side JavaScript using modules
• Make pages load faster
• Integrate Bootstrap
• Make it easier for rich client libraries such as Backbone or AngularJS to operate within a page
• Properly document Tapestry's client support

The Overall Vision

The overall vision for the client-side in Tapestry is encapsulation, at several different levels.

On the server-side, a Tapestry component (or mixin) will exposes configurable parameters. The component will write DOM elements or attributes, as well as some amount of JavaScript initialization. The encapsulation here allows developers with little or no knowledge of client-side JavaScript to enjoy the benefits (as consumers of components created by developers who are versed in client-side coding and Tapestry components).

On the client-side, the JavaScript combines with the special markup to produce the behaviors that are desired ... anything from controlling the initial focus field, to performing client-side input field validation, to running complex Ajax workflows.

Where possible, all of this behavior is driven by data- attributes on the elements, combined with top-level event handlers. On the client side, events are used not only to respond directly to user actions (with "click", "mouseOver", "submit", or other event listeners) but also to allow elements to collaborate in various ways.  For example, input validation is based on triggering a specific custom event on each form control element, and top-level event handlers can then manage the validation for any number of fields.

Prototype vs. jQuery

For several years, it has been obvious that Tapestry "backed the wrong horse" with respect to Prototype and jQuery. When the first code was being laid down in 2007 or 2008, it wasn't so clear that jQuery with its odd abstractions and unfamiliar approach, would go on to conquer the world. Meanwhile, Prototype was very strongly integrated into Ruby on Rails and had first class documentation and books.

That being said, jQuery may not be the be-all and end-all. Tapestry 5.4 introduces an abstraction layer, that allows many components to write code that doesn't care whether the foundation framework in Prototype or jQuery. This is especially useful during the arduous process of moving Tapestry 5.3 client-side code forward to 5.4.

If you like jQuery then there's no problem: write your application using just jQuery and you can ignore a lot of the features in the abstraction layer. Your code will likely be just a bit more efficient.

If you are building a reusable component or library, writing to the abstraction layer may be worth the effort; it is entirely possible that someone may write a replacement for the abstraction layer that targets your favorite foundation framework, such as ExtJS, MooTools, or something not even known of today.

Heavy vs. Light

Earlier Tapestry JavaScript was heavy. Essentially, each component would write some very specific JavaScript initialization that would include the component's DOM id and many other details. This initialization would reference a function on the T5.inits namespace.

The function there would typically locate the specific element by its client DOM id, then attach event handlers to the one element. It might also create some form of client-side controller object. There were issues due to this: for complex pages (or perhaps even typical pages), the "blob" of JavaScript initialization at the bottom of the page could be quite large.

The use of individual event handlers meant that Tapestry applications would use more client-side objects that a bespoke jQuery solution ... because the normal approach in jQuery is to attach a single event handler to the document or body that handles any events that bubble up to the top and match a CSS selector.

In Tapestry 5.4, the goal is to make things light. In most cases, there will not be a specific initialization function; instead a JavaScript module will be loaded, and it will install one or more top-level event handlers; the elements will have data- attributes that are used by those top level handlers to recognize which elements they are responsible for.

This is more of a full lifecycle approach; there's no danger of