The ThinWire Way
Around the beginning of 2000, a small independent software vendor just outside of Dallas, Texas, was one of a number of companies experimenting with various Ajax techniques, with the goal of providing a more interactive user experience in the browser. Historically, they had built complex financial applications that ran on the desktop, but increasingly they needed a way to provide similar capabilities in the browser. After building a number of small projects that included Ajax, they started to flush out a framework that not only included Ajax techniques but also encapsulated a number of those techniques into a reusable component framework. The framework they created never made it into the hands of the public, but the concepts that were flushed out during that time inspired the development of something significantly more ambitious.
Design Considerations
ThinWire started its life in 2003 as a private R&D project within the same company. It stands out from the other Ajax frameworks in a number of ways because the development team went back to the drawing board and threw out the preconceived notions about how a Web application should be built. For instance, the team considered the following:
- How can we eliminate 80 percent of the complexity required to build a complex enterprise Ajax application?
- If the framework can talk to the server at anytime, the request/response model is unnecessary in a traditional sense. So, why not eliminate it from the developer's perspective?
- If the request/response model is concealed, you no longer need to generate full HTML pages. Because generating HTML fragments would be cumbersome for developers to get right, could we build a framework that keeps the developer away from HTML and CSS, too?
- If the developer is only concerned with responding to user-initiated events, why not let developers handle events by adding listeners for the kinds of events they care about.
- If developers were confined to handling user-initiated events on the server side, they could write code in a server-side language they are familiar with, use any language API, prevent end users from seeing business logic with View Source, and allow developers to debug the application with a standard IDE.
Key Goals of ThinWire Create Simplicity
From these ideas, the goals behind the framework were mapped out, with simplicity being the guiding principal. The first two goals are now quite common to many Ajax frameworks, but the latter bunch set ThinWire apart from the rest:
- Rich user interfaces. Use DHTML and DOM techniques with JavaScript to provide a more comprehensive component set, including things such as grids, trees, and combo boxes.
- Responsive user experience. Eliminate most, if not all page refreshes. Instead, use a hidden communication channel to send information to and from the server and then update the user interface on-the-fly.
- Single-technology development. Cut out the need for developers to use HTML, CSS, JSP, JSF, EL, JavaScript, DOM, DHTML, and so on. Instead, allow an entire application to be constructed using a single, server-side language.
- Component model. Instead of working with the bits and pieces that make up a Web application, the framework allows developers to interact and change things in the UI in terms of well-defined components.
- Event-driven development. Keep developers focused on responding to user interactions, not on responding to lower-level concepts such as HTTP requests. With event-driven development, developers simply attach a listener to a UI component, indicating what kind of event they are interested in (that is, click button, select tree item, click tab, text changed).
- Natural state management. Restore the concept of state to Web applications. Although Representational State Transfer (REST) design principals are great, the majority of Web applications are better off with simple state management. Therefore, eliminate the need for developers to juggle various states within a session object. Instead, allow for state to be managed in an object-oriented way, stored as members on event listeners or directly on objects passed between methods.
- Security built in. Let the framework manage the communication channel, not the developer. This allows the framework to constantly change what kind of requests it considers acceptable, thus eliminating any spurious requests.
