Man, I was wrong in my post on what about us? and the iPhone SDK. All I knew about was the VP of Phone Software saying “we have stuff coming”, but there is a lot more that that, it is just not mentioned in many places.
If you head over to the iPhone DevCenter (registration required) you will find a video titled “iPhone SDK for Web Developers” that goes into detail.
When you watch it you will see a ton of great stuff:
Fantastic news. For a minute I worried that Apple would try to lure in us Web folk to learn Objective-C and Cocoa to grow that platform, but it looks like they are giving the mobile Web love as well as the native APIs. You just have to fork up $99.
We have seen a barrage of performance and compliance information this week haven’t we. Wow. We got a little more yesterday too.
The WebKit team talked about the Acid 3 test and how they are up to 90/100:
Support for CSS3 Selectors
We added support for all of the remaining CSS3 selectors. These include selectors like nth-child, nth-of-type, last-child, last-of-type, etc. These selectors were already implemented in KHTML, and the KHTML developers had even kindly provided patches for us in the relevant WebKit bugs. Therefore it was a simple matter of taking those patches, updating them to the WebKit codebase, and then merging them in. A big thanks to the KHTML developers for their hard work in this area.
Parsing Bugs
WebKit had a number of minor parsing bugs that Acid 3 targeted. The boxes did not render properly because of an obscure parsing bug that the test exploited (thanks, Hixie). In addition a number of other parsing bugs kept us from completely passing individual tests. We have updated our parser to be much closer to the HTML5-specified parsing rules.
WebKit has also never parsed DOCTYPEs before. I re-wrote WebKit’s DOCTYPE parsing to match the HTML5 specification, and so now if you put a DOCTYPE into your page it will be present in the DOM. In addition many bugs centered around proper mode resolution (quirks vs. strict) have now been fixed. You can document.write a DOCTYPE for example in a new document and have the correct mode be selected.
SVG
Acid3 has many SVG tests. We’ve been hard at work making these tests pass. In particular SVG font support and other aspects of the SVG DOM have been tested. Many of the remaining 10 points are SVG failures. We’ll be working on SVG animation in order to pass the last few SVG tests.
DOM
Acid3 tests a lot of DOM level 2 features, like traversal and ranges. It particularly focuses on the “liveness” of objects, e.g., making sure everything updates properly when you dynamically change a document by adding/removing nodes. Most of our failures in this area had to do with not behaving properly in the presence of these dynamic changes (even though we tended to pass the more static tests).
The JScript team also blogged about JScript improvements including fixing String concatenation.
Prior to this optimization of string concatenation, most developers used Array join operations to achieve the same result. We were aware of this tradeoff and made sure that the Array operations are also optimized. In either scenario, developers will experience significant performance gains.
I would love to see a benchmark of + vs. join() and hopefully see that join isn’t needed anymore. This feels like some of the moments in Java where the verbose code that you wrote to make things faster started to back fire (e.g. String concat too, and object pooling as creating an object became so cheap).
Ralph Nader of Browsers
This is a very random thought. Watching the WebKit and Firefox teams grinding away makes me wonder if one of them is like the Ralph Nader of browsers. Does WebKit take away share from Firefox? I have seen many developers prefer it recently, and a lot use both (myself for one). Having said that, the bulk of users are probably the folk who buy a Mac and click on the browser icon and don’t really care.
Is having the third candidate in the race a good thing? Does competition between WK and FF itself help both projects and spur them on to greater heights, or would it be even better to have a meeting of the minds and merge the WebKit and Gecko teams, at least in a way where they both aren’t optimizing the JavaScript engine etc. Hmm.
NOTE: There is still a lot of room to innovate in the browser itself, but share the low level engines. Maybe it is most to do with personalities. If the teams could work together that would be one thing (and remember Dave H used to work on Firefox), but it not…. then it is obviously silly. What do you think?
Steve Souders, the Web performance chap, has been inspired to calculate how green your website is based on the correlation between fast pages and energy:
Intrigued by an article on Radar about co2stats.com, I looked at my web performance best practices from the perspective of power consumption and CO2 emissions. YSlow grades web pages according to how well they follow these best practices. What if it could convert those grades into kilowatt-hours and pounds of CO2?
Let’s look at one performance rule on one site. Wikipedia is one of the top ten sites in the world (#9 according to Alexa). I love Wikipedia. I use it almost every day. Unfortunately, it has thirteen images in the front page that don’t have a far future Expires header (Rule 3). Every time someone revisits this page the browser has to make thirteen HTTP requests to the Wikipedia server to check if these images are still usable, even though these images haven’t changed in over seven months on average. A better way to handle this would be for Wikipedia to put a version number in the image’s URL and change the version number whenever the image changes. Doing this would allow them to tell the browser to cache the image for a year or more (using a far future Expires or Cache-Control header). Not only would this make the page load faster, it would also help the environment. Let’s try to estimate how much.
- Let’s assume Wikipedia does 100 million page views/day. (I’ve seen estimates that are over 200 million/day.)
- Assume 80% of those page views are done with a primed cache (based on Yahoo!’s browser cache statistics). We’re down to 80M page views/day.
- Assume 10%, no, 5% of those are for the home page. We’re down to 4M page views/day for the home page with a primed cache. Each of those contains 13 HTTP requests to validate the images, for a total of 52M image validation requests/day.
- Assume one web server can handle 100 of these requests/second, or 8.6M requests/day. that’s six web servers running full tilt year-round to handle this traffic.
- Assume a fully loaded server uses 100W. Six servers, year-round, consume 5,000 kilowatt-hours per year or approximately 500-1000 pounds of CO2 emissions.
Wow, even more pressure for you to not be sloppy with your apps. Who knows if Green Peace will be using YSlow to find culprites and start boycotts because of it ;)
NOTE: Steve is co-chair of the O’Reilly Velocity conference which is taking place on June 23-24.
SitePen’s Dylan Schiemann has posted about the recent InfoQ interview of Joe Walker and the upcoming release of DWR 3.0. The newest features for DWR include:
Joe gave a nice example of how the offline functionality could work:
For example, InfoQ uses DWR. If we get it right, it should be easy for you to make it so that if the network dies while a user is writing a comment, then the comment doesn’t get lost. When the network is next up, and the user visits InfoQ, the comment will be resent then. It’s a cool feature, and using DWR it should come almost for free.
DWR 3.0 is set to be released in June.
UPDATE: We got new information on the new functionality in Mobile Safari for developers
There has been a touch of news about the iPhone SDK from Apple. Most of the press believe that the iPhone SDK exceeds developer expectations.
As an iPhone user I am quite happy. I look forward to email / contact / calendar push. I think that the tool chain looked fantastic (debugger, simulator, IDE, GUI-builder) and I am sure that I will be seeing fantastic new applications when June comes around (waiting for June again?????). Skype. IM. You name it (as long as Apple approves!)
There are some that don’t like the 30% tax, and Russell Beattie has some thoughts too:
I was right about the sandbox, though there’s a bit more access to hardware than I thought, there’s no VoIP over cellular or ability to interact with the Dock, no ability to change the UI. So though it’s not a technical sandbox, it’s an arbitrary Apple approved one instead.
Also right about the Orwellian doublespeak: Jobs called only being able to distribute your apps via the iTunes store “the best deal going to distribute applications in the mobile space.” Uh-huh. Who wants to be able to put downloadable install files on their own websites? Exchanging the carrier-only distribution model for an Apple-only one doesn’t do much for me. I mean, imagine if you could only install applications on your computer via Apple or Microsoft… it’s the same thing, no matter how “convenient” it may sound.
Overall though, I am happy. I would love to see how many people pick up Objective-C and Cocoa now. We should keep an eye on the book sales. James Duncan Davidson will be happy :)
But what about Mobile Safari? What about some Cocoa JS love? Apple started out showing off the Web applications for the iPhone, so how about enabling more in that development stream? Some may enjoy learning something new, but others want to just stay in the growing Ajax universe. With the ability to hide the browser chrome, access to Touch APIs, and a few others…. and we can do a lot.
During the event, the VP of Phone Software told us that the next update will include new features for the web apps, so we will see (Thanks to Arn of MacRumors for letting me know).
At this point though maybe Steve wants to shut down that world a little? This is his chance to get a ton of developers on the full OSX platform. Once they learn Cocoa and the tool chain, some percentage of the developers will go on to build desktop applications too!
Interesting times. What do you think? Getting ready to use those square brackets?