I needed some locale date and number parsing fucntion for javascript today. As it goes for what the user sees i do usually do parsing and validation on the server-side. But this time i needed something for an admin interface that does also some javascript-based price calculation on the client-side.

So far i searched via Google for Prototype-based Libs on i18n, sprintf and so on. I found  JEL (JavaScript Enhancement Library)  and gave it try, but hardly to say: it is too bloated and the author implemented much english-language based method, but so far no sprintf, which i find is essential. And in overall the lib was ober 200KB for only doing I18n stuff!

Then i found out DOJO implements Date.POSIX and also a a String.sprintf that seemed very complete and began browsing the DOJO-Website. DOJO so far is IBM-sponsored and it was nice to see it reached a mature stage of development. I don’t like the namespaced function calls in JavaScript much, but on the server side doing java stuff like in GWT would be nice with that.

Still one big problem remains with DOJO: it just fucking hangs my browser and loads too damn slow!

DOJO has a nice dojo.require() which loads required dependencies on-the-fly. I had my own approach on that via the Prototype-based Postload.js. But the main problem with DOJO is that every class has again it’s own dependencies. You just have to inlcude one line of javascript in your HTML header, but when you do following require-statements…

… it results in firing up about 40 requests on .js-files!  That’s horrible! No wonder, my little Firefox hangs until all files are loaded! So, please, don’t harm the web, DOJO!

I don’t know if there is any solution out by the DOJO team, so please tell me. My conculusion so far is that for default load process of the website the dependencies should be resolved before the page is even sent to the browser. The browser should have just to load one JavaScript-file that is compressed and contains all default dependencies used by DOJO on the page. So far that can only be done having a little reference of all dependencies, so the haeder can be written accordingly.

If there isn’t such a thing someone should do that! So far I think think DOJO is a good for my future use, as long as there isn’t an Prototype- or jQuery-equivalent for i18n. 

KAURI has also a nice comparision chart of JavaScript-libraries.

UPDATE #1: Probably i could now also check out localisation-support for Ext.js… which seems to miss parse()-functions (or does it automatically). And in overall i don’t find any great localisation support either

UPDATE #2: There seems to be such a thing for DOJO called DOJO Build System that uses ant. It could be used as base for automatic server-side file generation in PHP… great I just everyone who uses DOJO is also using it, otherwise I am gonig to hate your websites!

Prototip.js is my favorite prototype.js-based tooltip-script at the moment. I’ve just written this piece in morning because we needed the capability of having dynamic content (or postloading big bits of HTML with images). Enjoy!

And here’s a replacement for a better default CSS style:

You can create a neat AJAX-Loader GIF here. Use  #FFFFDD for background and #999999 for foreground color.

If you look at todays web 2.0 sites you will realize there is often a heavy load on external JavaScript resources, CSS files and probably images. Above compressing and optimizing the files and merging multiple files (also background-images), there is not much room to further optimize the page loading process.

One problem of many modern sites is that they often provide optional functions for the user at the price of loading the main libraries all at once ending in a terrible site- and javascript-performance. I’ve already spoken about that once before and see more and more a good chance for web-applications based on Flex, or a real interface-language or perhaps Java. But we’re speaking about web-sites here not applications (anyway you could intermix them)!

Imagine a „passage-way“ or „pass-by“ page: How many of your users will use your “godly” fully featured search-window that you’ve implemented with Ext or the Prototype Window-Script and that runs inside the page? And what about  overall JS and CSS footprint about 150KB? Really needed? And oh, it’s the only part of the website you’re using these scripts.

Maybe one of ten users will use your “godly” feature. The others all have to load the site, the slow JavaScript and you will pay bandwidth.

So, why don’t you just simply load the parts of the site when you need them? AJAX – it’s all about that but still people are loading tons of libraries on every single site!?

As you might guessed i worked on such a script today. It works pretty well in Firefox and Opera (not yet Safari and fucking MSIE), and i still have to come up with some issues and heavy testing (especially on older browser that probably don’t wanna let their DOM injected JavaScript or CSS; so a good wrapper for <script> is necessary). I just wonder why no one didn’t come up with that idea and a working script before. It saves me about 120KB on a product page. And 50KB on other sites. Now that’s ok?!

Here’s a little preview of the alpha sourcecode

Example usage

The syntax is very simple. Just use it like require from your PHP or Java language. The only difference is that it handles more than one file and calls a complete-handler when all files have finished loading. So chaining it into your applications should be very easy.

Ah schon wieder eine Interface-Library, werden viele rufen. Aber dieses mal wieder eine, dessen Name man sich merken sollte. Die Interface Elements sind für jQuery endlich das, was script.aculo.us für prototype.js bereits ist. Wahrscheinlich gibt es sie Bald auch in einer Plugin-Distribution für Drupal, welches ja mittlerweile jQuery integriert hat. Das ist damit eine sehr feine Bilbliothek, wie ich finde.

Wie schön, dass man mittlerweile so gut wie freie Wahl hat, was die Bibliotheken angeht, oder wie ich finde alles was Ext.js unterstützt ist definitiv gut. Ich frage mich nur wie es mit dem DOJO-Toolkit nur weitergehen soll… ohne vernünftige Widgets und vor allem ohne endlich mal kleine JS-Scripts, die den Browser nciht aufhängen wird’s bei denen nie etwas!

Nachtrag: Prototype.js und Scriptaculous gibt es mittlerweile in einer kombinierten Fassung, namens – tadaaa – Protoculous. Wer hätte das gedacht?

Nachdem es gerade einmal ein paar Wochen etwas stiller um die YUI-Ext geworden ist, meldet sich Jack Slocum mit seinem generellen nun Ext JS genannten Componenten-Paket für jQuery und erfreulicherweise auch gleich noch prototype.js zurück, was nun in der Beta1 erschienen ist!

Das ursprünglich für die YAHOO UI (kurz YUI) entwickelte Extensions Paket namens YUI-Ext (Calender, ComboBoxes, EditGrids) wurde auf Anfrage der jQuery-Entwickler jetzt nicht nur für jQuery sondern auch für prototype.js und scrip.aculo.us umgesetzt. Letzgenannten Bibliotheken zählen mit der YUI zu den derzeit beliebtesten und besten JavaScript-Bibliotheken.

Ich finde vor allem die Unterstützung für prototype.js wirklich super, da mir prototype.js oft mehr Spaß macht zu programmieren und eher für kleine Sachen geeignet ist, obwohl ich die YUI auch echt zu lieben gelernt habe. Aber natürlich bracht sich jQuery, was jetzt auch mit Drupal daherkommt kommt, keinesfalls zu verstecken

Wollen wir mal vermuten das auch Jack Slocum womöglich auch hinter den SpeedUps des Element.getElementsBySelector von prototype.js in der 1.5.1 RC1 steckt

Der Typ mausert sich echt immer mehr zu einem JavaScript-Gott

Hier eine Liste der herausragensten Beispiele:

• zwei TreeControls mit AJAX und Drag’n'Drop
  
• ein Image-Selektor-Dialog
• Menüs-, Menübuttons und Menüleisten
  
• Der „FeedViewer“ in Ext-Gewand
  
• Verschiedene Message- und Confirm-Dialoge
  
• Das Layout-Control für WebApplication-Layouts
  
• Grid aus Markup erstellen (somit unobstrusive Websites möglich!)
  
• Paging von Grids mit XML oder JSON-Input (wichtig bei vielen Daten!)
  
• Editierbares Grid samt Datums- und Combobox-Komponente

Sehr nützlich:

• Dokumentation zu prototype.js im Windows CHM-Format
• Dokumentation zu YUI-Ext
• Dokumentation zu YUI