Wednesday, June 10th, 2009

Ample SDK: Browser-in-a-Browser

Category: Framework, JavaScript

<p>

Sergey Ilinsky, formerly of Ajax pioneer Backbase, has created a new Ajax toolkit called Ample SDK. The best way to describe Ample SDK is that it’s a browser-within-a-browser, but not in the visual sense. Rather, it aims to implement in JavaScript the stack of rendering technologies typically delegated to the browser. For example, Ample currently lets you use Mozilla’s XUL to create cross-browser applications.

Here’s an example of how you could use Ample SDK to render a XUL interface in the browser:

<body>
    <!-- other HTML code -->
    <script type="text/javascript">ample.open()</script>
<xul:menulist xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
    <xul:menupopup id="items-popup">
        <xul:menuitem label="Item 0" value="0"/>
        <xul:menuitem label="Item 1" value="1"/>
        <xul:menuitem label="Item 2" value="2"/>
    </xul:menupopup>
</xul:menulist>
    <script type="text/javascript">ample.close()</script>
    <!-- other HTML code -->
</body>

(Sorry for the old-school, ugly <pre> above–our code formatter chokes on XML namespaces, used in the XUL elements above.)

The Ample SDK compatibility table, shown above, gives you a sense of the scope of the project: to implement technologies like XUL, SVG, HTML 5, XHTML, and so forth, all in JavaScript–and render them across modern and legacy browsers like IE 5.5.

Ample even takes over CSS parsing:

  1. <style type="text/ample+css">
  2.     @namespace "http://www.w3.org/1999/xhtml";
  3.     b {
  4.         color: red;
  5.     }
  6. </style>

Check out the examples and documentation at the site. Note that Ample is not (yet) open-source but is free for non-commercial projects.

When Brendan Eich first hinted several years ago that the browsers would get fast, it spurred a lot of folks to wondering whether the future of feature innovation would be primarily in the JavaScript library space, and the browsers would focus on being JavaScript run-times and graphics abstract layers.

Ample SDK raises the question anew. Should we push the rendering layer to JavaScript libraries? What do you think?

And, what do you think of Ample?

Related Content:

Posted by Ben Galbraith at 6:00 am
27 Comments

++++-
4 rating from 36 votes

27 Comments »

Comments feed TrackBack URI

To me this looks very interesting. Kind of like Google Gears but without the annoying plugin and focused on rendering technologies instead of back-end technologies. But the premise is the same. Bring cutting edge features to browsers that do not yet support them.

That being said a big factor in determining if this platform will be successful is:

* How fast is it at rendering. Would someone using IE 6 get a very second-rate experience? I.E. would it render very slow and not quite right? Reminds me of the VRML/Canvas compatibility work that has been done in JavaScript for IE. Yes it somewhat allows the use of Canvas in IE but it has a few places where compatibility is not quite right and it is much slower. OK for some web pages but not a real replacement.

* Even if the rendering is fast does it let the browser do the rendering if the browser supports the given technology. In other words if I write a XUL application and happen to view it in Mozilla does it let Mozilla handle it? Or does it still do it’s own rendering. The JavaScript rendering will never be as fast as native rendering. So it seems native should be used whenever possible. But the problem is what if the native implementation is less than perfect?

Will be looking into the answers of these questions but would be curious what others know.

Comment by eric2 — June 10, 2009

Don’t apologize for an erring code formatter – replace it with something that works! :D

Comment by sixtyseconds — June 10, 2009

OK. I’d like to elaborate just a bit on the framework philosophy.

The main idea with that was to enable natural development process, where: the UI would be layout with an XML based technology (like XHTML, XUL, SVG or other, including custom), the styling would be done with CSS (consider xul|colorpicker::button {background:url(.)}), and the logic would be written against standard DOM interfaces (right if you were writing it against modern, that is not IE, browser).

Normalized events flow makes sure the events get dispatched in a right oder in the application DOM, default actions are handled (think of mousedown default action that is supposed to prevent text selection start, but does not in IE) etc.

The componentization model allows for creation of custom UI components or even entire UI languages, whenever developer is not happy with the provided ones. BTW, UI technologies are Open-Source already.

@eric2:
E. How fast is it at rendering.
S. It renders UI components faster then many GUI frameworks

E. Would someone using IE 6 get a very second-rate experience?
S. Even in IE6 in real world scenarious (for example a client-side interface to Google analytics) the UX experience is way above satisfactory. IE6 could be a concern, since it is about 3 times slower than IE8 and ~30 times slower than Safari 4, but it is going away.

E. I.E. would it render very slow and not quite right?
S. Almost any IE6 quirk can be resolved, right? Slow rendering is not the only concern in IE6: there is way more compex problem of runtime performance degradation (caused by the persistent usage of JS obejcts on a page)

E. Reminds me of the VRML/Canvas compatibility work that has been done in JavaScript for IE.
S. Right, you probably mean VML. VML is very slow, that is true, so running neither complex rendering nor animation with that is satisfactory enough. However it is good enough to draw simplier graphs, figures etc. Ample SDK makes use of VML to implement several modules of SVG1.2Tiny, see example: SVG Tiger (better viewed in IE!)

E. Even if the rendering is fast does it let the browser do the rendering if the browser supports the given technology. In other words if I write a XUL application and happen to view it in Mozilla does it let Mozilla handle it? Or does it still do it’s own rendering.
S. Great question. No currently Ample SDK renders its UI in HTML always, in order to not introduce incosistency. In the ideal world it would indeed be cool. But you also touched abnother intersting point – codebase reuse is the future. When browsers catch up on equally implement DOM API, the application logic written now against Ample SDK will then work against native one.

E. The JavaScript rendering will never be as fast as native rendering.
S. Agree. However if there will never be XUL in browsers or other UI technology that provides required level of UX, you will have to keep on using ExtJS, Dojo, YUI, Backbase or Ample SDK.

E. But the problem is what if the native implementation is less than perfect?
S. Nothing is perfect, right? And Ample SDK is indeed less perfect than browser just by definition – it runs in the browser and renders to /derives events from web browser. However it does very well browsers equalization job plus adding on top tons of sugar…

Comment by SergeyIlinsky — June 10, 2009

It’s very interesting. It really provides cross-browser look’n'feel.
I’d really wondering if there is a theme system, so we can customize the skin of the fake XUL elements?
As HTML5 coming, there must be a bunch of works need to be done. For example, native Video and audio elements (need a flash as fallback?), Canvas 2d/3d, SVG animation…
1. About the future of this lib:
As tracemonkey, SFX, V8 … all seems like to generate bytecode/native code. So if this lib can be standardized to be part of those browser, it would be more interesting.
2. About the rendering speed:
I’ve tried some examples, speed is acceptable, even in IE.
Nowadays, modern browsers are willing to add HW accel to the GFX layer which will help a lot here.
So 2009 Q4 / 2010 Q1 will be a really great time for the whole web. :)
Forgive my poor English.

Comment by ssssssssssss — June 10, 2009

The idea of a cross platform XUL implementation might not be new, but the quality of the implementation impresses me. An this time it’s not a leaky abstraction like GWT, hiding away all markup.
If they really go Open Source then I am quite sure this will reshape Web Development !
The “getElementById” and “getElementsByTagName” functions look a bit clumsy for someone getting used to jQuery.

Comment by Rusco — June 10, 2009

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?

So far the only thing I’ve found that can is a good old and some server-side code.

Comment by Darkimmortal — June 10, 2009

@Darkimmortal:

If a client want this or you than you have to rethink of web clients. I think.

Comment by Aimos — June 10, 2009

How the heck does Firefox have 90% support for XUL, along with the other browsers? Firefox is built on the platform that defines XUL itself, XULRunner. What am I missing here?

Comment by EliGrey — June 10, 2009

What’s the benefit of using this over standard HTML enhanced with JS?

Comment by WillPeavy — June 10, 2009

@ssssssssssss: I’d really wondering if there is a theme system, so we can customize the skin of the fake XUL elements
S: Yes, you can use CSS for that (with namespaces, pseudo-classes and pseudo-elements support), for example:

xul|datepicker {
border: double 1px green;
}
xul|datepicker:focus::value {
outline: solid 2px lightblue;
}
xul|datepicker::button {
background: url(mybutton.png);
}

@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.

Comment by SergeyIlinsky — June 10, 2009

And how would you compare it to Ext JS? I mean, AMPLE design is completly different (and AMPLE choice of technologies is impresive just by itself), but essentialy both frameworks aims similar targets – let developers layout complex applications UI more effectively, without writing much of HTML code (except the fact that with Ext we write only JavaScript code and AMPLE let us use XML-based languages to define layout structure).
Am I right that out of most popular frameworks Ext JS looks like it’s main competitor?

Comment by ffreak — June 10, 2009

Crashed my IE8 :(

Comment by mjuhl — June 10, 2009

Well this is very interesting it seams many people are centering their efforts over XUL as a future rendering platform for the web… I was thinking a Canvas rendering engine for HTML would be awesome if anybody ever gets the time to doing that.

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?

Comment by jhuni — June 10, 2009

@ffreak: And how would you compare it to Ext JS?
S: I think ExtJS is way more nicer at the quality of the UI components now. Ample SDK will catch on that soon. Otherwise there is no major difference, they both serve pretty much same need: client-side GUI development, still Ample SDK has standard APIs.

@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.

Comment by SergeyIlinsky — June 10, 2009

Also, if such insane, non-semantic (I mean, completely non-semantic, not just a bit) HTML code that Ample generates is really a necessity? Nice HTML really has it’s advantages…

Comment by ffreak — June 10, 2009

I just jump in to test svg.
http://www.amplesdk.com/examples/svg/
IE8 causes browser hang and takes over 30 seconds to complete the drawing, while chrome only takes five seconds

Comment by johnnymm — June 10, 2009

I very much like the approach of treating browser as a VM interpreting arbitrary programs.

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…).

Comment by chiaroscuro — June 11, 2009

First impression: feels solid, fast and only minor quirks. Reminds me a helluva lot of Backbase’s development model (including terminology like shadow tree and SPI), although it’s too long ago since I’ve last used it for me to comment on the specifics. I’m wondering how Backbase feels about this.

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)?

Comment by Menno — June 11, 2009

@johnnymm:
Something must be wrong with your IE8. Mine renders that page in 5 seconds.

@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.

Comment by Joeri — June 11, 2009

@Joeri
XBL is concerned with neither recursive design nor seamless integration with other standards (such as SVG). It is a good stopgap measure, though.

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).

Comment by chiaroscuro — June 11, 2009

Working for over 6 months now with Ample SDK definately proved to me that Ample is one of the best frameworks to use for creating bigger enterprise applications. Ample completely standarizes the DOM model, Event model which leads to less code and no more annoying browser specific code. Also the ability to create your own custom namespace which will be used to create your own custom Components (eg. a calender, listview or any component that other frameworks offer) is a big plus. Those components can be created by markup or dynamically loaded through XMLHttp.

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).

Comment by shock01 — June 11, 2009

@johnnymm: IE8 causes browser hang and takes over 30 seconds to complete the drawing, while chrome only takes five seconds
S: Yes, complex SVG is drawn very slowly. However drawning graphics and other “primitives” is fast enough (so fast that you will not see).

@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.

Comment by SergeyIlinsky — June 11, 2009

It’s a re-tooling of the old Liquid language then?

Comment by MikaelBergkvist — June 11, 2009

(Which was launched at CEBIT, 2000, by the way)

Comment by MikaelBergkvist — June 11, 2009

@Sergeyllinsky
Why do we need XBL here?
Code re-use? I think JS itself can handle it.
As even mozilla have not nailed down XBL2(true?), do you really need to implement it and throw it to web?

Comment by ssssssssssss — June 12, 2009

@ Sergey: Nice presentation. Well done. Congrats on your new framework.

Comment by Tavs — June 12, 2009

@ Sergey: Here is another compliment on what looks to be an outstanding framework. Also, here is another recommendation to consider augmenting the framework to use JQuery selector syntax as the default (instead of pure DOM) in the SDK documentation.

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.

Comment by dreftymac — June 17, 2009

Leave a comment

You must be logged in to post a comment.