Google I/O looks like it’s right up my alley. I was surprised to see Steve Souders is presenting there. He’s the author of YSlow and Yahoo! was printing his 14 tips for speeding up website front-end performance on cards for Blogher last year (under the unusual title of “How to be a Better Binary Babe”). I have used YSlow to improve my own sites’ performance though I definitely don’t get an A on all of them yet. I’d love to hear what else he has to say on the subject.
I also see there’s one on Caja, another attempt to make Javascript “Safe”. While my first reaction to this and Douglas Crockford’s Adsafe is to roll my eyes, I know I’m going to hear a lot more about both soon so it’s best to dive in and find out what’s what. Really, I think the whole AJAX and Javascript topic is the most interesting part to me right now.
Jeff and I started tossing around the idea of making a trip out to I/O a few days ago. It doesn’t look like a real possibility but I saw that registration is open this morning so if any generous reader wants to contribute to sending me then drop me a line and we can talk 
.
On Pavlov.net talking about some improvements in memory handling on Firefox 3:
It isn’t reasonable to expect all those authors to write code to manually break the cycles themselves.
This reminded me immediately of an MSDN article that took a decidedly different stance on pretty much the same problem in Internet Explorer:
The good news is that memory leak patterns can be easily spotted if you know what to look for.
The fact that the MSDN article is from 2005 really drives home just how stunned I was when I first read it. The page goes on to describe how web developers should analyze their Javascript and write their code to work around bugs in garbage collection. I understand the idea that sometimes users have to work around bugs in a program but that’s definitely not the message I got looking at the MSDN article. It read a lot more to me like “we sent out IE 6 SP2 about a year ago and we have no intentions on fixing this any time soon.”
Then look at the audiences that these two very different standpoints are aimed at. The Mozilla post is about extension developers, a relatively small and advanced group compared to the number of web developers - the ones most likely to understand the issue if anyone does. The MSDN post talks to “every web developer” and says to “Use defensive coding practices and assume that you’ll need to clean up all your own memory.” While this may be practical advice for advanced coders, in this context it says to me that there’s no intention from Microsoft to really fix this problem.
Kudos to Mozilla for working to improve efficiency and close leaks instead of blaming web developers.
Here’s a quick tip for PHP error reporting and display in development.
When a project is in the early stages of development you want to see all the error information you can. You probably want E_STRICT on especially when you’re starting from scratch, to help avoid relying on deprecated behaviour. The E_STRICT flag is only available as of PHP 5 and is not included in E_ALL until PHP 5.2 (there’s a little disagreement on php.net between the definition of E_ALL in this table and the earlier note about error_reporting on the same page).
In an early development project you also don’t want to have to keep tailing log files to see the error messages. That’s a pretty sure way to miss errors. So you want to set the display_errors flag on. You also want to control this on a per-project basis, since some projects will have legacy bugs that you’re not fixing right now and those can be left spouting errors to logs until someday in the future when you decide to fix them.
Read the rest of “Displaying PHP Errors in Development”…
