Utah Open Source Planet

I wanted to add an example of the yuiImgUploader script working with YUI version 2.6.0. If you haven't read the original YUI Image Uploader page, start there. After that, you can use this page for an example getting the script to work with the latest YUI. That changes from the previous 2.5 Image uploader [...]

Julien Lecomte from Yahoo! is speaking about creating performant AJAX applications. The most important point: plan for performance from day 1. Interestingly many of his initial points are about telling the developer to work with the product manager and not just say "no."

Julien references an Web Site Optimization: 13 Simple Steps by Stoyan Stefanov. Here's some tips:

Less is more. Don't do unnecessary things.

Break rules. Make compromises and break best practices when needed. For example, you might decide to forgo CSS. Especially CSS expressions.

Work on improving perceived performance. Cheat by making users think things are done before they are.

Measure performance. Test using a setup similar to the user's configuration. Profile your code during development. Automate profiling and performance testing. Keep historical records of how feature perform.

Minify CSS and Javascript files. Use something like the YUI Compressor. Stay away from compression schemes that require run time compression. You can also combine the CSS and JAvascript files. Optimize images.

Loading and parsing HTML, CSS, and JavaScript code is costly. Be concise and write less code. Make good use of libraries. Splitting JS libraries into bundles for specific uses might save time.

Close HTML tags. Unclosed tags take longer to parse. Load assets (even images) on demands.

Most DOM events can be accomplished before the onload even has fired. You can also load the scripts after the page has fully loaded.

In JavaScript a lookup is done each time a variable is accessed. Declaring variables with the var keyword and making them local helps. Avoid global variables at all costs. Avoid with. You can use a local variable to "cache" the value of a variable outside the current scope when it's going to be accessed repeatedly.

Limit the number of event handlers. Attaching a even handler to hundreds of elements is very costly and can be the source memory leaks.

Reflows happen when the DOM tree is manipulated. You can minimize reflows by taking advantage of browser built-in optimizations. For example, modifying an invisible element doesn't trigger reflow.

Use onmousedown instead of onclick to take advantage of the time between the start of the button press and the release.

Avoid using JavaScript for layout. Use CSS where possible.

Never resort to a synchronous XHR. Asynchronous programming is more complicated but it's worth it. Deal with network timeouts programmatically.

If you validate user data on the browser, 99.9% of the time, the request will succeed, so lock the affected elements, let the user know something's happening, and process the request while the user continues to use the application.

Use JSON rather than XML. Consider local storage and just process diffs. Multiplex AJAX requests where you can.

Tags: velocity08 ajax performance browsers

Recently, I was browsing the YUI JavaScript forums and found a post about nesting the tab control. I haven't done that before personally, but have done things where my tabs had Ajax or DHTML dependencies inside the tabs. I decided I'd take a whack at this one and see what I could come [...]

If you develop sites anything like I do, you'll end up setting up a site wide layout and theme before you start coding any individual pages. I like to add YUI components where they are useful, but I've come across a couple little quirks that were annoying me. Here are my observations and [...]

I still develop JS in basically the same way I did back in 2001. Back then IE had more of a stranglehold on the browser market, but it was a horrible JS development environment. So one would use Mozilla with the Venkman debugger to make things a li

The YUI team has been making further enhancements to the YUI library. I decided to stick together in one post all the previous resources I've added for the YUI Image Uploader and make sure the uploader was compatible with the latest version of the YUI Rich Text Editor. Image Uploader Client Code To use upload images [...]

After my previous image uploader and turbogears image uploader posts, the overwhelmingly most requested information has been a PHP implementation of the upload script. I’m not much of a PHP guru. Luckily, a few users have posted possible solutions for this. I’ve added an editor to this post that uses a PHP [...]

The Yahoo UI Library provides a nifty helper for creating tooltips. I started playing around with it when I wanted to add the same tooltip to a large number of elements on a page. What got me interested in this implementation, is the ability to use the same tooltip on a number of [...]

After completing the YUI Image Uploader, I received a lot of requests for a working example. I didn’t originally create a working example, because that requires server functionality that this server didn’t have. I’ve remedied the situation and have completed an example with TurboGears. Of course, any server side language or framework [...]

I’ve had nothing but good things to say about the Yahoo User Interface tools. It seems to me like the developers continually add all the things from other libraries that I like into one simple to use, well documented, overall good quality library. The new addition of the rich text editor has left me [...]

I just posted my interview with Bruce Johnson on the Google Web Toolkit. This was a fun interview and I learned a lot. GWT allows you to write AJAX applications in Java that then gets compiled to Javascript.

Tags: google java javascript ajax web

Many of my loyal readers recognize the strife I have with the iPhone. Its elegant, sexy interface is alluring, yet as it draws you in it immediately pushes you away like a magnet, turned the opposite direction in reverse polarity. My goal in buying an iPhone originally was to figure out how to write apps for it. With its AJAX browser interface it seemed not too complex an interface to actually use as a development platform. However, as I mentioned earlier, I bought it, and immediately returned it because I realized that first, I had no way of using my wonderful T-Mobile plan rather than being locked into a 2-year contract with AT&T, and second, the iPhone DOES NOT support 64-bit operating systems at the moment, and I’m not about to downgrade my OS for a simple phone.

So I just recently had the opportunity to buy a MacBook for my daily business efforts and Facebook development. I have owned Macs in the past, and find them ideal development desktop environments because I get the best of almost 3 worlds, the Mac, Unix, and Windows through Parallels. It’s an ideal testing environment for a web developer.

The same day I bought it (yesterday), it was announced that finally a free unlock solution was available to free yourself from AT&T. Finally, I was in an ideal situation to buy an iPhone, try it out, review it, hack it to my T-Mobile, without having to switch carriers or downgrade my OS to an inferior architecture. I know, I’m a hypocrite, but all along I’ve really just been trying to make this work and Apple just wouldn’t let me!

I’ve realized my belief in that is completely wrong. I now totally understand why Apple is locking people into AT&T (why no 64-bit support, I have no idea)! You see, Apple knew people would unlock their phone. They know us developers way too well. Yes, we would complain and gripe, but Apple knows we all secretly love their products.

The issue is, Apple needed carriers to embrace and support their phone to make it big and “cool” in the market. Scoble says all you need to be cool is a small group to promote the heck out of your product. Verizon actually turned them down in initial deals. GSM I belive is a better network worldwide, so I believe they started seeking out partners in the GSM market. AT&T was the biggest US partner so they worked out a deal with them, which was a huge bonus for Apple, as they had exclusive marketing rights at AT&T stores all across America.

You see, Apple knew people would complain about being locked into one provider. The thing most people are neglecting (including myself) is that Apple knows their customers. They knew developers would soon hack the OS - it is a UNIX OS after all, and while they would have to protect their agreement with AT&T and try to patch the hacks, developers would always get around that until AT&T caved and let them just leave it open to the hacks. The iPhone would expand into other markets, and voila, Apple has T-Mobile and other GSM providers without even trying!

I hacked my iPhone last night. I now run my iPhone on T-Mobile, no contract, and excellent customer service! I have a shell prompt into my iPhone. I can ssh and SFTP into my iPhone. It was actually unbelievably (with a few quirks) easy to set up! Will Apple update it in the future? Probably, but you can also bet hackers will quickly have a new hack to keep it unlocked - there is no way around it, and Apple knows this. They built the software to make working around the hackers hard! I find it very hard to believe this wasn’t part of their underlying business strategy.

Share this article with a friend...