What Is It

• A core library. For an overview of what is in the library, you might start with File Reference or Class Hierarchy pages. Some of the utilities in the core library require only ECMAScript and are useful in either a browser or a command-line shell (or other server-side environment).
• A selection of widgets which rely on a DOM environment. All of them rely on the core library, but are not part of it. These widgets support "inline constructors" which allow for their insertion on a web page with little or no javascript, just a special markup declaration.
• Some tools which may be useful to others, independent of the library. These includes tools for: ECMAScript "linking" (to find minimal code for required functionality), code extraction, comment extraction, a fake DOM (for command-line testing), and unit testing .

Some of the relatively standalone functionality includes: fixing deficient native ECMAScript objects, date formatting, sprintf, XPath in pure ECMAScript, uneval, URI parsing, many generic DOM utilities, many HTML DOM utilities, functional programming primitives, C++-style collection algorithms, and AOP/MOP utilities .

There is also more "infrastructure-ish" functionality for: logging, runtime environment, reflection, properties, widgets, script loading, and IO .

The source code is documented quite heavily; in fact there are about twice as many comment lines as executable lines (these are stripped out in the single runtime-loaded library file). Even if you choose not to use the library, you may very well want to mine it for ideas. As an example, see our documentation for burst.io.IframeURIRequest or burst.xml.XmlDoc .

As of this writing, the core library after comment stripping is approximately 4k lines and 200k bytes.

Philosophy

• Assume a standard environment.
  We do not attempt to support 4th generation browser DOMs or pre-edition 3 ECMAScript implementations (except for IE5.0 PC; see below). It is hard enough to work around the vagaries of 5th generation browsers. Furthermore, we want to spend our efforts adding higher-level functionality, not making up the functionality that should already be there.
• Complement the language, don't build a new one.
  We do not extend core ECMAScript objects such as Array and Function. In general, we do not attempt to layer a whole language or paradigm on top of ECMAScript. We also do not attempt to interject a wrapper API when DOM compliance is sufficient.
• Support any environment that is standards compliant.
  In particular, we do not rely on any IE-specific technology unless there is a correlate in at least one other browser. We do for example leverage the XMLHTTP support available in both IE and Mozilla. We provide a workaround however for environments that do not have the proprietary extension but are standards compliant (such as Opera).
• Produce a library, not standalone "scriptlets".
  This does mean that the total size is larger than a dedicated single-purpose script. In many cases, that should not matter: the browser caches external library files, so for any web application this policy should be acceptable. If your requirement is a widget to be used only on a main web page that will typically be visited only once by a user, this policy is more of an issue. We do not intend to isolate just portions of the library for individual distribution. We do however plan on automated "linker" which will determine what is required at build time, and also potentially support some runtime mechanisms such as a "module proxy" to decrease sizes. Specifically for widgets, we do already support loading of only widgets actually used.

Hello World

What Sets Burst Apart

• bsd-style license.
• inline constructors.
• associated tools, including command line testing of even DOM-dependent scripts.
• attention to such quality matters as performance and strict warnings.

History

The initial version of "Burst" was written by Mark D. Anderson (mda@discerning.com) .