|
 Hi, my name is Les, and this is my plan. Looking for my usual blog? Try 0xDECAFBAD. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hello world. Biked in again. Yay for me! Alex Iskold, How JavaScript is Slowing Down the Web (And What To Do About It): "Use Standard Libraries. Probably the worst thing is to reinvent the wheel, since JavaScript is so easy to get wrong. Unlike Java there is no set of standard libraries, but some like prototype have effectively become a standard. The libraries are written by experienced people who know and understand the pitfalls of the system, so it is a good idea to reuse their code." In isolation, I agree 100% with that statement. When developing a site that's going to have lots of JavaScript, you should pick one of the leading modern JS libraries. I like YUI. Others like jQuery, prototype, mochikit, and Dojo are good too. Pick one, work with it, but don't mix and match. The problem with Alex's statement, however, is that he's talking about third-party widget development. That is, bits of JS intended for inclusion in others' pages, on others' sites. And the problem is that the including site has probably already picked a standard JS library to work with. And, most likely, it's different than the one you like. And, unfortunately, many of these libraries don't play nice with each other when mixed on the same page - not to mention that they tend to weigh in at between 20-120k to download. So, you've already got the weight of the host page, but then as a widget developer you want to haul in all your own favorite wheel-reinventions as well? No, when developing JS-based widgets, you're in a different mess than the usual web development scenario. You need to travel light and unobtrusively. The rest of Alex's article highlights this brilliantly - defer loading of this and that until after the rest of the page has loaded, get in quickly and get out of the way until later. Do only the minimum work needed once it's your turn. Fail gracefully. Be polite, because you're a guest in someone else's home. What I really think this calls for is a smaller, portable JS lib devoted to the concerns of widgets. If that's possible, anyway. Make it polite, unobtrusive, and very very tiny. Limit it to just the things a widget would tend to want to do. It's something I've kind of wished to see for awhile now - which is the reason that this particular point in this article prompted me to rant. Maybe I should play with something. |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
