JSForms is an open source (under BSD-like License) JavaScript library that aims to simplify rich applications development for the Internet. It provides a single model for creating and manipulating controls on an HTML page. JSForms aims to be highly extensible to make meeting any custom requirements a simple task. At the same time, it ensures that the page will be responsive to user input, load fast and will remain complaint with W3C standards.

The library uses JSOLait. JSOLait is a free and open source JavaScript framework designed to simplify JavaScript OO development. It also comes with a set of modules that provide a wide array of additional functionality for developers.

JSForms - the future and the past in road map and change log.

JSForms goals

Here's a short list (in no particular order, all of them are important) of goals I have for this library. Some are already completed, but others are still at the infancy stage. At this point they're not set in stone. I often feel the need to update this list when I'm coding and think of something I might have missed, so changes are to be expected. Nevertheless they are adequate to direct JSForms to move in the right direction.

• Simple - The structure of the framework should be very simple and well-designed. Classes should be relatively small (but there can be a large number of classes). Staying simple will make it easier to develop, design, document and for the people to use and extend the framework.
• Intuitive - Framework should be intuitive to use (as Ruby on Rails is, for example). There should be just a few ways to do something and they should be well described. In most cases doing something should be so simple that the user will need to only look at the API reference without the need to read detailed documentation.
• Well documented - The framework should have well structured and simple documentation. All aspects of the framework should be covered, but documentation should not mix public API (for users) with private implementation (for developers). Both should be present, but they should be separated and not mixed together. Examples should be present that show how to use and extend the framework. Demos should be present to display certain aspects or features of the library.
• Extensible - The framework should be very, very easy to extend. I cannot write all controls on my own so people should be encouraged to extend any aspect of the framework to make it better. Extensibility is closely related to the project being customizable. Not only the user should be able to create new controls, but any aspect of controls or even internal parts of the framework should be extensible. Any such extension should be pluggable into working application to improve the whole framework. Essentially it should be simple to add and replace parts of the framework with custom components.

  The library will provide basic classes required to make GUI controls creation as simple as possible. There will be support for separation of concern (layout vs. behavior) as well as support for most commonly encountered control features or patterns (control serialization, flyweight pattern).

• Customizable - All controls in the framework should be easy to customize. Control appearance and behavior are never the same from application to application so both of these aspects should be simple to change. All aspects should also be separated well enough that developer doesn't have to worry about one class when he wants to change another.
• Stable - If the framework isn't stable people will not be able to use it in an application. Error catching and recovery mechanism should be in place, but the framework also needs to be thoroughly tested. All issues must be documented and available to the public. Any possible erroneous situations should be described.
• Light on resources - Browsers by their nature like to consume resources. Showing big documents often require large chunks of memory, especially if at the same time several browser windows are opened. Allocating large chunks of memory can slow the whole system down. If paging is required to allocate those chunks situation just gets worse. Framework should not add significant overhead (not in tens of MBs) to the memory required to show the web page. Objects should be reuses aggressively to ensure low resource requirements.
• No memory leaks - IE is infamous for its memory leakage and even Mozilla hasn't completely escaped the problem. The causes for the leaks are usually the same in both browsers and I hope to eliminate them without sacrificing advanced features of JavaScript (such as anonymous delegates and closures programming). I'm not sure if memory leak problem is present in other browsers, but I will certainly attempt to update the code to eliminate any problems if (when) they will be discovered on other platforms.
• Fast and lightweight - JavaScript is an interpreted language, so all code is executed much slower than it does in native applications. Still, users expect user interface to be responsive. Page load time should not be worse due to the utilization of the library and the page should remain responsive to the user input. As such there should be mechanisms in place to measure performance and ensure all code is as fast as it can be.

  In some instances where the page will be full of rich controls this might be harder to achieve, but the library should try not to add noticeable overhead. Often people are prepared to sacrifice looks for responsiveness. Another option for the framework is to automatically degrade in appearance to ensure that interface remains responsive.

• Abstracted browser differences - Most of the browsers support W3C standards to some degree, but all browsers also have proprietary features. Often different JavaScript is required to do the same thing in different browsers. For example event handler registration in IE doesn't adhere to the standards and so the code will be different from standards compliant browsers.

  The framework should abstract away those differences and provide a common coding ground (single API) for developers. The API should be simple and easy to understand. It must be as close to the standard (W3C) DOM API as possible. There should also be a standard procedure (guideline) to abstract away the differences.

• Standards and quirk modes compliance - Currently most (all?) modern browsers support different modes of showing a web page. There is a standards compliance mode (browser attempts it's best to follow all W3C regulations) and a quirks mode (browser falls back to default behavior which is more compatible with legacy or badly formed HTML). I want the library to work in either mode. In rare cases where it's impossible to support both modes it needs to default to the standards compliance support.
• Support for other libraries - There already are several popular JavaScript libraries (consult similar projects page for the list). Many of them do things I want to do. I would like to either reuse some of their code or make accessing those libraries from JSForms as easy as possible.

  In addition if a developer builds web pages using another library it should be easy for him to use JSForms to fill in that library's gaps.

• Modern technology support - There are a lot of features that were present in the browsers for some time but are only becoming popular now. CSS and XMLHttp come to mind. The library will do its best to simplify working with those technologies to make customization easier and feature support richer.