Die Beste Aller Zeiten

Going direct to heaven, going direct the other way

Category: Javascript

And another problem with javascript libs

A while ago I wrote about why javascript libraries are not necessarily helpful in my line of work (namely because of their high potential for abuse). Just now I stumbled upon another problem that makes them even less useful for me.

A javascript lib provides – in theory – a common framework to write reusable and exchangeable modules and widgets that can be distributed over the web and plugged into existing applications. After all we all use a common code base, so there is no room for conflicts, or is there.

Actually there is. Today the attempt to use three different prototype based widgets (and the subsequent attempt to find replacements) landed me right in version hell. Evidently every prototype based snippet uses a different version of the lib and backwards compatibilty, if at all intended by the prototype makers, is extremly limited. I’m not sure that it is actually faster if I write the required functions myself, but I bet it’s a lot less frustrating.

And while I’m at it, here’s a heartfelt “Fuck you!” to all you browser manufacturers out there. I don’t know if you know how much unpaid overtime your crappy software causes for people like me, but my guess is you know it and break things on purpose. Oh well, who needs sleep anyway.

    Move Javascript to the bottom of the page

    I have blogged about this before, but right now I’m happy to repeat myself: The Yahoo Developer Network has excellent advice on how to optimize load time for your web pages, and the best thing is that so much of it can be easily implemented.

    Yahoos Rules for High Performance Web Sites start from the somewhat amazing observation that it’s not so much the response time of the server the time it takes the server to generate the page that slows down a web site but the things that happen after the HTML has been sent to the client.

    Most relevant for my case was that a) the browser makes a new http request for each ressource (style sheet, script, image etc) in the page (and the more request the slower the page) and that with external javascript files progressive rendering is blocked for all content below the script, meaning the rest of the page will not render before the script files are downloaded. An easy workaround is to call the scripts near the page bottom (though there might be scripts where this is not possible).

    I’m working on a site that uses prototype and various parts of the scriptaculous effects library, and I ended with six external javascript files. When I moved the script tags from the head section to the bottom of the page the load improved from about six seconds to two seconds (how do I know? I used Yahoos yslow to measure site performance).

    Now you might say that two seconds over a DSL connection is still pretty slow. But so far I have tripled load speed and it didn’t cost me more effort than a single cut and paste action – I call that amazing.

    I think most of Yahoos rules make sense only if you work on large sites with tens of thousands millions of visitors – I certainly will not set up a Content Delivery Network for a site with a few hundred visitors per day. Even so I think this proves that looking at the big boys can be a valuable excercise for us one man shops.

    I any case I’ve ordered Steve Souder’s (Yahoo! performance chief) book High Performance Web Sites – I don’t know if there’s anything in it that I couldn’t find as well on the YUI-Blog, but to buy the book seems a nice way to appreciate his work.

      Chris Heilmann: Seven rules of Unobtrusive JavaScript

      Unobtrusive Javascript is Javascript that latches into a page without the need to mix javascript event handlers  and HTML.  Chris Heilmann has a good article about the “Seven rules of Unobtrusive JavaScript” – there is a short summary on his blog and an expanded version here.  If you are not familiar with unobtrusive javascript this is a good start, if you use it regularly and want to spread the gospel this is a good list to prepare for a presentation, so you should read it in any case.

        A Problem with Javascript libraries

        A couple of days ago thelist – the mailing list of the evolt web developer community – had a short discussion about javascript libs (like e.g. jquery). Do they help with coding or not – i.e. do they help you to become an actual programmer or are they a simple way to do nifty stuff that you don’t actually understand?

        I couldn’t contribute to the discussion, but still I’d like to mention here one of my problems with libraries. I often take over maintenance for sites that have been deserted by their original programmers, and usually when one of these web geniuses spontaneously combusts he burns with him all documentation. One of the sure signs of a web prodigy is that comments in the frontend code usually fail to tell anything useful. Instead I find little essays on why “Javascript sucks”, which is why they have used this amazing library (usually nebulous 0.1 or the promiscuous 0.0.5 pre-alpha) that allows for otherwise unsurmountable tasks like adding a rollover to an image or toggle display of a named element (and even if they used one of the better known scripting frameworks there are still at least a ten or twelve to choose from). So instead of programming in the one language javascript, which I by and by get the hang of (mostly due to Christian Heilmanns excellent book and web site) I suddenly have to look up documentation for a dozen or so libraries. And sometimes I wonder why my predecessors bothered at all to include a couple of hundred kb worth of Javascript when they then decided to rather use some method they’d concocted themself.

        This is of course not an argument against libraries – I think by now it would be somewhat insane to built a Rich Interface Application without a javascript framework – but I still have to say that the purpose of libraries is often defeated at my end, when simple Javascript would be much easier to understand and maintain.

        My suggestion would be not to use libs for the more mundane tasks but rather small, well documented scripts, never to include a library (or worse, multiple libraries) just because it has one effect that you particularly like and, if you can’t help to use a library then to actually use it and not replace parts of it with your own functions.

        And if you are interested in Javascript your really should visit Chris Heilmanns web page wait-till-i.com (it feels a bit strange to advertise for him, since he’s some kind of web guru and I’m a goofball from Berlin, but still). While many people still look at JS as something that is slapped on top of a web page he sees it as a regular programming task, which means that the task at hand gets analyzed step by step before he starts writing code. I tried it and was amazed how much time you can save by taking the long way round.

          Powered by WordPress & Theme by Anders Norén