Doing this sooner instead of later will increase the attractiveness of this framework for those developers who are coming onto the scene and never used DOM and JQuery is all they know.

@chiaroscuro: …DOM is not very useable in JavaScript…
S: That is true to many developers – they either do not get DOM or do not like. Well, if there was another API I would be more than happy to implement it (since it would eventually just wrap low-level DOM calls, like jQuery does, right?)

@chiaroscuro: How to extend XUL widgets?
S: This is possible. for example XUL tree and XUL listview component both extend on XULSelectElement. The tutorials will come.

@chiaroscuro: How to compose XUL widgets into another XUL widget?
S: This is not supported and will not be. I believe the implemented level of granularity achieved by allowing creation of widgets is sufficient in 95% of cases.

@Menno: First impression: feels solid, fast and only minor quirks
S: It is not even a beta yet…, we are still pretty much away from 1.0

@Menno: I’m wondering how Backbase feels about this.
S: I guess Backbase feels like: Wow, our approach seem to be proven by

@Menno: The main thing I am missing in both the examples and documentation is how to dynamically create/append/move/update/delete (custom) elements from the UI. Can this be done?
S: Indeed, you use DOM API for that, read more in tutorial Part I – Building the User Interface

var sXULNameSpace = "http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul";

var popup = ample.getElementById("items-popup");
var item4 = ample.createElementNS(sXULNameSpace, "xul:menuitem");
popup.appendChild(item4);
item3.setAttribute("label", "Item 3");
item3.setAttribute("value", "3");


@Menno: Is the CSS live (including pseudo-classes like last-child, etc)?
S: Yes, it is live. Although there are indeed certain limitations.

@Joeri: @johnnymm: Something must be wrong with your IE8. Mine renders that page in 5 seconds.
S: Mine renders 30s too. That is normal, the Tiger drawning is big and VML is slow. You can still implementation of SVG modules in Ample for graphics and other primitives.

@Joeri: XBL…
S: XBL2 is not yet implemented in Ample SDK. It has lower priority since the value it adds is lower comparing to other cool things that are now in development. By the way, there is a half-finished prototype on http://code.google.com/p/xbl/ although this is designed to operate against browser DOM, so it won’t work for Ample.

Creating custom components is far easier than eg. YAHOO. You are completely in control of the rendering and you don’t end up with an HTML structure that is created by eg. YAHOO.

Also the way the framework works is that it’s completely extendible to any specification. Eg. Sergey also created an implementation of XSD schema validation.

All you have to know to use this is just HTML,XML,CSS,DOM. All proven technologies. This framework doesn’t require you to learn a new “language”. (Only thing you need to learn is the ample API, which is pretty straight forward for creating the custom components).

What am I talking about is an approach akin to Fudgets, which really are a joy to work with. It’s a pity they haven’t got the attention they deserved.

Fudgets are based on stream processing. You basically connect atomic (predefined) stream processors (e.g. buttons, text input fields, text areas) together to get more stream processors (note the recursion, it gives us extensibility for free), and then feed input to the resulting network to see it coming to life; all in all, this scheme is very flexible, as the number of combinations you get is very large.

You can’t easily achieve this given the current stack of web standards (XUL+XBL+SVG+XForms+XPath).

@chiaroscuro:
XBL is the component model you can use in combination with XUL. No need to define extra standards, because XUL+XBL+JS is what all firefox extensions are written in, and it works just fine.

The main thing I am missing in both the examples and documentation is how to dynamically create/append/move/update/delete (custom) elements from the UI. Can this be done? Is the CSS live (including pseudo-classes like last-child, etc)?

Actually, I think it would be way faster and easier to extend browsers using this approach, than doing the same on lower layers of abstraction. Think Emacs done the right way.

As for the Ample SDK, it looks great, but too much adherence to standards might harm. DOM is not very useable in JavaScript, since the language is more expressive than what DOM permits (note that DOM uses an IDL for imperative procedural statically nominatively typed programming languages). Most of the time DOM is not just too low-level (that is not a problem per se) but not fitting into the idioms we are used to when programming in JS.

Also, standards are not integrated and do not permit recursive design. (How to extend XUL widgets? How to compose XUL widgets into another XUL widget?) There isn’t an all-encompassing model underlying them all, so you can’t really tell how the parts should interact (and you have to invent a yet another standard describing all the corner cases that you could think of…).

@ffreak: Am I right that out of most popular frameworks Ext JS looks like it’s main competitor?
S: Ample SDK is not trying to be a competitor to anyone. This is more an attempt to show what a natural (standards-based) development experience could look like. Maybe it is worse than the one enabled in ExtKS or Dojo. The end developer is there to decide what does he like more.

@mjuhl: Crashed my IE8 :(
S: That is quite an experience. You probably had similar crash experience in other modern browsers even when displaying plain HTML pages? I did.

@ :There already is many ways to convert one markup to another so this isn’t really that useful right now…
S: Agree. This is however not the goal of the framework (although the framework has implementation of XSLTProcessor enabled cross-browser too)

@jhuni: …what is this about it not being free software?
S: It is a free software that can be used in free projects. Actually parts of it are open-source (these are UI technologies). It will go open-source entirely on 1st November 2009. However, I believe that aside the pure academic need, the source of the technology core is not relevant much to the end developer.

There already is many ways to convert one markup to another so this isn’t really that useful right now and what is this about it not being free software? Who is going to use it then?

@ssssssssssss: I’ve tried some examples, speed is acceptable, even in IE.
S: The speed of rendering should be very high, since the rendering in Ample SDK hapens in one [browser] run, not by a bunch of DOM operations. Also while rendering there is no overhead of inline handlers or similar performance-critical operations.

@Rusco: …but the quality of the implementation impresses me…
S: Truly, I think, the quality of XUL components is not acceptable yet unfortunately. This is due to I’ve been more busy with the core technologies, such as DOM Core, DOM Events (these are Ample DOM, not browser DOM), UI managers, etc. The UI components will be pimped up soon for sure!

@Rusco: If they really go Open Source [...]
S: Yes, the runtime will go open-source on 1st November, The UI components are already open-source though!

@Rusco: The “getElementById” and “getElementsByTagName” functions look a bit clumsy for someone getting used to jQuery.
S: Well, they can use querySelector/querySelectorAll. And also, it is indeed possible to create jQuery-like API for Ample SDK! (look, if you see jQuery being an API to browser DOM, then it can be adjusted/adopted to Ample DOM)

@Darkimmortal: Can this render 3000 expandable table rows totalling at about 3mb of HTML (~2mb in JSON) instantly (minus download) and without interface lag, even in IE6?
S: No. It cannot. As @Aimos noted, this is sue it is simply never needed (3000 expandable table rows will hardly fit in a user screen) Think of using progressive rendering.

@EliGrey: How the heck does Firefox have 90% support for XUL?
S: It is Ample SDK that has support for 90% of XUL UI, not Gecko indeed.

@WillPeavy: What’s the benefit of using this over standard HTML enhanced with JS?
S: I like your question, it is straight. Well, I believe HTML capabilities are not enough to build client-side applications efficiently. To layout hypertext – yes, but trying to build a qualitive User Interface with HTML is a pain. Specifically this can be a pain to the developer. Ample SDK enables componentization model with help of which the level of granularity which application developer has to work with is higher than low-level HTML. So the main benefits from using Ample SDK, I think, are: easier code base maintance and standard-based (known to many developers) APIs – all these cross-browser.