Freestyle reduces the complexity of deploying a user interface to the browser by erasing the client-server divide entirely. This means serious enterprise-class applications, without having to worry about cross-browser compatibility, without client-side scripting, and without DHTML/AJAX. We believe in building applications just like you would for a .Net, Java, or Ruby desktop. The only difference is, with Freestyle, you deliver them over the web.

In-Depth: Why Freestyle?

The Problem

Anyone who has used a full-featured UI toolkit such as Swing or WinForms knows that there is a fundamental (and not-so-pleasant) difference between the way you develop applications for the desktop and the way you develop applications for the web. Even with the recent advances in client scripting techniques such as AJAX, writing web applications, when compared to their desktop counterparts is at best frustrating; at worst excruciating. The reason is simple: Web applications as they are currently developed are based on page requests across the client-server divide, which have very serious drawbacks when it comes to building and maintaining a decent user interface.

• Custom Protocols

  Page-based architectures require the developer to manually implement the logic that generates the page required by a given request. This an inescapable fact of their design. The server accepts a set of input parameters, and returns html (or xml in the case of AJAX). There are many tools on many platforms to aid in this endeavor, but they have the same basic structure input(parameters) output(html/xml). In effect, this means that code handling the request must implement a custom protocol for each page request that the application wishes to serve.

  

  Fig 1. Classic AJAX Micro-Page Model

  Developer is forced to implement A, B, and C

  AJAX applications improve performance, and UI responsiveness by decomposing the scope of their page-requests into small chunks, or micro-pages and then integrating those micro-pages into the enclosing page. Fundamentally however, they are still page-request based, and the server code handling AJAX requests must still code around the client-server divide. It must implement a custom protocol for each request to accept the proper inputs and respond with the proper XML.

  Regardless of how it is bandaged, there remains an inherent tedium in the process of first defining and then implementing (on both client and server) which input parameters the client will send with a request, and what will be the form of the server's response that the client knows what to do with it.

• Client Driven

  Another serious drawback to building web interfaces with both classic and more recent techniques is that they must be implemented in the paucity of the browser runtime.

  The javascript language was designed from its inception to derive most of its functionality by binding to objects implemented in other runtimes. As a result, its standard library is sparse almost to the point of non-existence in that it lacks many vitally useful objects like Sets, LinkedLists, and true Hashes and these are only the basics! Lacking the solid fundamentals provided by server-side environments, most applications that make extensive use of DHTML and javascript end up implementing a hodge-podge of non-standard solutions for common work-a-day programming tasks that would have been provided to them under any normal circumstances.

  For resources and libraries that are only available on the server, a custom page-request must be designed and implemented to present those resources to the client.

• Custom Data Marshaling

  As a direct result of the system being developed for two separate runtimes, there must be logic to translate data from a form suitable for the client into a form suitable for the server and vice-a-versa. There are many "helper" tools for doing this, but it still remains a burden to the developer, and a necessary part to consider when implementing the custom page protocols that constitute a web application.

The Freestyle difference

Freestyle takes a different approach. Rather than treating your application as a sequence of pages, or micro-pages which must each implemented on the server, and requested by custom code on the client, Freestyle applications are component-oriented. They are built with first-class user interface objects which reside on the server, and are programmed by the developer to react directly to user input.

• No Custom Protocols

  The freestyle server handles all client interaction in a generic fashion, so that the application developer need not worry about how to implement a custom page request. By the very action of connecting user interface events to application logic, he is specifying both the protocol and its implementation in one clean step.

  

  Fig 2. Freestyle Model

  Developer only implements Server Components
• Server Driven

  In applications built with Freestyle, all application logic is specified on the server, not the client, so that the entire server-side runtime is available all the time. This means that for applications written in Java, for example, the developer is free to leverage all the core JRE classes, as well as any preferred third-party libraries he may wish to include.

  It also means that access to server-only resources such as files and databases is implicit. There is no need to wrap simple database requests with custom micro-pages.

• No Custom Data Marshaling

  Server-side runtimes such as the JVM already come with a way of passing data to application logic, the built-in data types. Freestyle applications always deal with data in the form in which it appears on the server, be it simple strings and integers, or more complicated user-defined types.

The Way Forward

Freestyle introduces a new way to develop your applications by building on the time-tested strategy of single-runtime, component-oriented user interface design; the same strategy employed by all modern user-interface toolkits. Forget about developing web applications. With Freestyle, you develop for the desktop, but deploy over the web.