JS UI Widget design

the work in progress, content will evolve over time.

Requirements

HTML,CSS and other resources to represent insulated independently designed and developed module.
While those component types are not mandatory, using standard components increases manageability, productivity and reliability. From managing point having the component in publicly-accepted standard allows to easier find worker, reassign the job, pick the best expert for critical peace, match the standard and utilize this standard-based tools including validation, tests, compilation and transformations, other tiers(component types) interfacing protocol  and so on.

The resource types listed individually in order of development life cycle:

Requirements and overview documents. Alternatives are online docs and static file format. Online is more about collaboration, static is the currently accepted snapshot. Static content ideally to refer online threaded discussion with ability to back-refer location inside of static content. As static content for now HTML is universal. It is popular, has ability to include raster and vector graphics, print-friendly.

Prototypes and mockup. Adobe (Photoshop & Illustrator), Visio are most industry-accepted tools. All have ability to keep the project in cross-platform and -media format. SVG is the best candidate. Another approach is to have public format(SVG, PNG, PDF) be a secondary, synchronized on each modification of original. I personally like 3D MAX for those purposes, but as project manager will not use it unless have at least few people on team familiar with concept and product.

HTML based templates.All UI developers are familiar with this format. Any custom one is narrowing the number of people familiar with it and as result cut managing ability. The balance of given and taken out functionality is always in place. HTML itself does not have all "template" functionality of course. But it is popular to under estimate its power.
I like the ability to fuse different technologies in compatible way. For example dojo toolkit dijit 1.x has given HTML customization via data-dojo-xxx attributes leaving the HTML functionality intact.
While among "native" templates the XSLT is oldest and most robust one, it is not 100% HTML compatible. It is not easy to find people skilled in both XSLT and HTML.

The a lack of development cycle support is applicable to all template versions. XSLT has best coverage on that( preview, debug, rudimentary documentation and test suite).

Another reason of tempate format selection could be the native engine(parser and binding) support. On web client the browser itself is one of such engines.On server side multiple HTML parser available, XML is the simplest one. Native support given performance via native code, multithreaded and asynchronous processing.
IMO for simple widgets DTK 1.x dijit format is best(but with browser loading and parsing instead of JS one). For complex is XSLT.

CSS and style formats. CSS is outdated in terms of complex project requirements. XStyle provides rudimentary but still way more powerful control over complex styling rules. For relatively simple UI the set of rules is limited and as result will (and should) fit into CSS limits. If not, than styles are subject for insulation into own module(style themes and i18N localization are samples of such). Good styling format will be back-compatible with native CSS and give as shim as OOP abstractions. At the moment it does not exist.

Tiers Plumbing. The configurable loader should be sufficient to support distributed compile, server- and client-side modules bindings in case the tier resources will be loadable directly or by loader plugins ( see cssI! as sample ).  AMD or UMD loaders are good fit.

Design

Phases of widget life. 

Placeholder, Facade, UI and runtime. (de-)serialization and View Model. Interaction with data model.
Incremental and steaming rendering. Interruptable and prioritized rendering.

Presentation variations.

I18N,  media device (display|print).

Shims.

Declarative programming as effective way to target rendering options according to destination environment and configuration.
The shim name has dual meaning: "marker" in declarative programming and implementation module for it.