It has no notification LED.
It's a decent if unexceptional device. I can live without a real keyboard. I can live without a microSD slot (especially given the broken way that Android uses external storage). NFC is neat if extremely premature and consumer-only at this point.
The lack of a notification LED on Google's flagship device, however, is deadly.
I don't want to endlessly turn the screen on or suffer disruptive notification sounds (that I miss if I'm not nearby at that moment) just to know that an email dropped.
Hence why I like devices to have a notification LED. Preferrably one that is easily visible when it's in a case (beside the power connector would be perfect).
The Nexus One has such a notification behind the trackball. It's suboptimal given that it suffers from a very slow cycling rate by default (meaning you have to stop and look at the device for 10 seconds to see if it pulses), and the fact that it's hidden when the phone is in a case, yet it's far better than nothing.
Purportedly there are some fixes conceived to use several of the OLED pixels as a hacked out notification LED. Aside from the poor positioning and minimal visibility of the low brightness screen, my big concern there is OLED fade. Like plasma OLED has a finite lifespan, and the pixels that shine the brightest live the shortest, so you may end up with a notification burn in pattern on your screen.
My LED notification is just as valuable when it isn't blinking. It communicates with accuracy and reliability (meaning I'm assuming the battery hasn't run dry) that there is nothing demanding a response.
This "negative notification" concept eludes many, yet it's incredibly valuable.
Tracks in snow tell a lot, but snow without tracks tells just as much. A dog barking at an intruder tells you plenty. A dog quietly sleeping tells you as much.
Many are predicting that the smartphone market is set to explode in 2011, some speculating that Android is poised to capture much of that growth.
Not a very risky prediction, really.
MG Siegler weighed in via a TechCrunch piece in which he repeats a couple of myths that somehow bear truth only through repeated assertion.
And so the only way for the iPhone to “beat” Android would be for Apple to either open iOS up in the same way that Android is, or to create a huge variety of iPhones spread across the spectrum in terms of features and price. Neither of those things is going to happen.
My young daughter happens to enjoy Angry Birds, so recently I thought I'd grab her a little portable device to play it and her movies and music on. Being a casual mobile app developer, targeting Android for almost arbitrary reasons, I looked to see what Android devices were available so it could double as a convenient testing target.
There is nothing. The few devices I found were in the $400 range and generally featured underwhelming processors, terrible screens, and shoddy builds.
You simply can't find an Android PMP as economical as what Apple has achieved with the iPod Touch. A4 processor. Brilliant display. Great GPU. Facetime. Dual cameras. That thing is just a crazy value.
Sure, technically the iPod Touch isn't an iPhone, but for how most people use their smartphones (where the "phone" part of it is utterly irrelevant, and it's merely a mobile computing device), with the widening deployment of WiFi it is increasingly just as capable.
And make no mistake: The iPod Touch is a critical element of the iPhone's domination. We're talking platforms here, and while Google was busy actually undermining the non-smartphone devices (until recently Google treated tablets with incredible antipathy. Whatever the internal politics — perhaps the perceived birthright of ChromeOS — they were not supportive whatsoever, at one Google I/O acting both irritated and confused when an audience member asked about tablets. Nor are they supportive of PMPs where they pull market access and essentially cripple the device at birth), Apple was busy spreading iOS far and wide, creating a healthy ecosystem for developers to target.
Apple knows how to price down technology with the best of them, and they have demonstrated a strong ability and willingness to do so. The dated 3GS is still being manufactured and sold as new, just as the 3G hung around long after the 3GS became the starter.
The 3GS is incredibly dated by contemporary standards, and its slow processor, limited RAM, and old-school screen resolution place it firmly in the "low end" market. Apple still sells it. Read what Siegler had to say above and consider that.
When Apple feels pressure to segment the marketing of iOS more than they already do ("You can get an iPhone minus the 3G radio and fine-GPS for just $240 full retail, or you can get your subsidized 3GS if you're a chump and can't afford a couple hundred when signing up for a two thousand dollar contract commitment...."), they will. Any illusions that they won't, or moreso that they haven't already is just blind zealotry, lost in the weeds desperately trying to feel around for some comfort to assuage against Apple's marketshare competition.
I recently gained an interest in American football (after becoming aware that there was so much more to the game than just a bunch of guys smashing into each other, not to mention the "be prepared to explain man things" motive given that I have three young sons) and one of the things I have noticed in that live-can't-fast-forward world is that Apple advertises like crazy. From my limited sampling they are easily the overwhelmingly dominant pitchman on television, alternating between iPod Touch, iPad, and iPhone commercials. They are as mainstream as a corporation could get.
Stop your PVR fast forwarding for a while and pay attention to the commercials. Microsoft, Intel, Dell, even McDonalds...they are drown out by Apple's message.
They’re perfectly happy “at the top of the market” where they make a ton of revenue and profit. Billions more, in fact, than Google does with Android.
A recurring claim is that Apple will be pleased to retreat to their profitable little niche: That they're a purveyor of high markup, limited-run technology devices for the connoisseur, and they'll continue happily in their grey poupon ways, Android be damned.
Of course for much of Apple's history it was an incredibly unprofitable enterprise. Through the 90s, despite having their confident bevy of expensive devices and their single-digit saturation, Apple was an economic basket-case, posting billion dollar losses or cutting to the bone and barely breaking even. At one point in Steve Jobs' reign they were bailed out by Microsoft (an investment that would be worth untold riches for Microsoft today had they not quickly divested it).
The iMac started to turn that around by providing an inexpensive all-in-one computer that was novel and accessible for everyperson USA, going back to its middle class Apple II roots. My wife still berates me for not hopping on the AAPL train after correctly predicting what the iMac's impact would be.
After it, of course, the iPod stormed the market. It was a good device that was marketed right, and it laid the groundwork for the iPhone to make some major inroads on day 1. Again, the iPod sat at virtually every price point, easily winning the value race in most categories.
Cars and televisions and stereo receivers came with iPod connectors or docks. They didn't for any competing device.
Apple's profitability grew.
Apple's ability to squeeze a growing profit margin out of their business came by escaping from the niche. In the smartphone market there was a period where Apple was effectively closing on 100% of the market, which is exactly how developers and the media treated them (see the countless organizations that made an iPhone app and that was it -- they felt the consumer was served). Sure, the graphs would include Blackberries and Nokias, but come on -- Apple had the market to itself outside of things your work makes you carry and "What, you mean this thing is supposed to be a smartphone?" devices.
And like most businesses Apple is great at working the synergy. Many of their PC sales came about because they first got the user with an iPod or an iPhone. In the development world, a million developers ran out and bought an Apple equipment stack to try to write their own lottery ticket on the grand iPhone AppStore bet.
Apple has no plans on retreating to a niche. Nor was that niche ever profitable for them. Their strategy pounds home this point, with a focus that is engineering around significant if not dominant market positioning, with network lock-in that makes it difficult to challenge or break. Their application strategy, the top to bottom segmentation, and the "you're with us or you're against us" decisions like Facetime, there should be no confusion that Apple is targeting anything less than being the Microsoft of the decade.
You can't get more mainstream than Apple. Apple is no more exclusive than the GAP or Target or eating at Red Lobster.
They make great devices, no doubt about it. I've been riding the Android train for 17 months now based upon the promise of many capable companies working together, but until the latest generation of devices, such as the Desire Z, I have never felt confident in recommending the devices to anyone else. Really I'm a little surprised it survived thorugh those birthing pains.
But it did. Android today is a very decent device and it's only getting better. Pundits like Scoble (whose fame still confuses me) lament that Android isn't deserving because the apps are better on the iPhone. Apps don't appear overnight, Scoble, and the surge in developer sentiment towards Android has been overwhelming over the past months. On my device I'm getting app update notices literally daily now, as development teams rush to fix up what previously was nothing but a second thought.
It's getting better everyday.
We came periolously close to a unipolar smartphone market, and despite the pains that I had to suffer with Android during its terrible toothing years, I'm glad that we now have a market that's open for any and all. Like Firefox did for Chrome, by making multiplatform support the default Android leaves an opening for Blackberry, Microsoft, Nokia, or anyone else to come along with something better, without being crowded out by an existing and impenetrable ecosystem surrounded by an unassailable network lock-in.
The flip-side to this Android domination is what we’re already seeing. The carriers (again, in the U.S. in particular) are using Android’s openness to perform many of their same old tricks. I can’t help but think sometimes that it looks as if Google actually did the carriers a huge favor in the long-run because they’ve taken many of the bells and whistles that drove users to the iPhone in the first place and opened them up for the carriers to use as glittering lures to rope customers back into their traps.
This is the myth that I find simply extraordinary, the overwhelming evidence that it is utter nonsense being so obvious.
In the US Apple has been laying in bed with AT&T for years. Want to go to Verizon? Sorry, not an option. T-Mobile? Not an option. There is zero competition if you want an iPhone in the entire US of A.
Gave the power to the users, did it? First they came for your choice of carrier, with AT&T paying heavily into Apple's treasure for the priviledge.
Apple originally had a no app policy — as demanded of them by AT&T due to fears that apps would go crazy and take down the network — just as Facetime refuses to work over 3G, and various apps that threaten the AT&T / Apple relationship will get quietly squashed.
While Apple doesn't have NASCAR apps or similar bloatware that have very unfortunately appeared on a small minority of Android phones, every single choice on the device is made for you if you're set on an iPhone.
Compare that to Android: Pick your carrier among all available. Pick your device among literally dozens of top rank devices. Use standard consumer discretion to align interests with vendors.
Heard that Verizon stuck some bloatware and a Bing default on their phone? Okay, as a consumer you have countless alternative choices to choose instead while still using the apps you know, the data you've accumulated, and the platform that you've invested in, sending the message that it isn't viable. If Apple, on the other hand, decided that one half of your display will henceforth show nothing but ads (another ridiciulous myth is the proposition that the iPhone represents a purer transaction, which is utter tripe. Apple is locking you in as a consumer to their various media, application, and advertisement platforms), you have no options aside from simply abandoning the platform and whatever you have invested in it.
The iPhone only empowers users in a 1984-esque redefinition of the meaning of empowering. Any control it took from the carriers it placed firmly in the hands of Apple.
Some wager that the upcoming iPad 2 will pixel double both axis, similar to what the iPhone 4 did relative to its predecessor, while others believe that it will keep the resolution of the current generation.
Doubling both axis is a formidable technical challenge and would be a unique, likely expensive display. Continuing with the current resolution would represent a significant competitive disadvantage. As people acclimate to high density smartphones, such as the iPhone 4, the iPad's low density is really starting to stand out.
Few believe it will do anything in between. It won’t, the common wisdom goes, go to say 1536 x 1152 or 1280 x 860, or any other fractional improvement less than an outright doubling or quadrupling. The logic is that pixel scaling issues eliminate the possibility of such a half measure.
This harkens to discussions that occurred over 20 years ago.
It should be an embarrassment that such a discussion is occurring in 2011.
In the TiPb article linked above the author leads off with a slur towards Android, saying “Either iPad 2 will have a standard 1024×768 display or a doubled 2048×1538 Retina Display, or developers and users will be in for the type of frustration usually ascribed to Android.”
That makes for an odd, if not outright ignorant, statement: I can’t recall ever reading anyone complain about the density independent pixel of Android, or its awareness and accommodation of a wide variety of profiles. That’s a problem that it has solved very well, and a large ecosystem of sizes and resolutions of displays exist in remarkable harmony.
Consumers like being able to choose between 3” – 15”+ devices with a wide variety of densities. Choice is good.
Because of course the DPI issue has long been solved. Otherwise you would be lamenting that your 72dpi word processor isn’t compatible with your 300dpi printer: “Everything prints out all tiny-like”. Is that the case?
Vector fonts with pixel independent abstractions have been around for a long time (in TrueType and Postscript form), with Apple as one of the primary inventors. Most GUI frameworks, including iOS, have the ability to scale UI rudiments to virtually any resolution and pixel density with ease.
That is an ancient problem, long solved.
But what about icons? What about bitmap graphic artifacts?
In an ideal world icons would come in vector graphic form. That isn’t the case on Android (the platform doesn’t support SVG, including in the browser, which is a huge deficiency), but it is still shocking that Apple, which usually takes the lead on such innovations, doesn’t use them for iOS, as had been widely speculated as a given before the iPhone OS was first released.
With a vector graphic the rendered image is always perfect for the target, ideally with hints that suppress decorations at very low sizes.
Even with bitmap graphics, however, while it’s easy to contrive ridiculous examples to demonstrate the worst of scaling, the reality is that given that text should always be UI generated from vector fonts, perfect for the target, and graphics are usually just supplementary decorations, where scaling up or down by partial multiples is often perfectly adequate.
For your consideration below are some iOS icons (used for fair use purposes but owned by Apple) at their original pixel size, and then scaled to 125% and 150%. Scaling was done using Sinc (Lanczos3), which is a good algorithm to use when scaling up and you want to maintain fine detail.



The horrors! Just to be clear (as it's hard to imagine what the larger images would look like when shown in the same physical space), we're comparing this to simply pixel-doubling, which would look like the following (cropped to avoid exceeding most reader's screen bounds).

There is no universe where a straight pixel-doubled image looks better than an interpolated image, unless you have fine detail in the image (like text) which shouldn't be in the image to begin with.
Not only do they still look great, but remember that in such a case the actual viewed sizes would also decrease proportionally, so the marginal artifacts would be rendered completely irrelevant. Reading some of the blog entries on scaling you would think you’d end up with some sort of blob.
Not to mention that most iPad apps would be fixed up to handle the new platform shortly after the SDK were released.
I find it incredibly hard to believe that Apple will maintain the same resolution. The device was already considered under-pixeled when first released, and has succeeded despite that deficiency. With the appearance of actual competition over the coming months it would put the successor at a serious disadvantage out of the gate. Apple has always emphasized and often led in the spec department (the thinnest, lightest, brightest screen, widest viewing angle, highest pixel density, etc), so I don’t believe that Apple would allow such a scenario.
At the same time, doubling the pixels is a big expense because such a panel doesn’t yet exist, and that sort of density is rare in larger displays.
Then again, Apple, in talking about their blockbuster quarter yesterday, spoke about a mysterious $3.9 billion dollar supply chain investment. It would not surprise me in the least if they managed to get the volumes and process in place for such a display given how critical the iPad has become to their bottom line, and Apple's tendency to set new benchmarks.
If I had to place a wager, however, I would bet that Apple neither keeps their current resolution, nor will they double the resolution. I would guess that they will go to 1536 x 1152, or more likely 1280 x 960.
Some are hoping that Google gives away nothing at Google I/O 2011.
I strongly agree.
It's possible that I'm motivated by sour grapes after trying to register for Google I/O mere minutes after registration opened, to be met with a sold out notice.
The quick sellout is partly a reflection of the astonishing success of Android, coupled with the setup that last year's attendees were given first dibs over the preceding week: They knew with close to certainty that they'll leave with $1000+ in freebies, so it's a pretty easy choice.
Now that I'm not in the running for what will likely include a free Motorola Xoom and Nexus S, maybe I'm just trying to urinate in the waters.
But really, such giveaways do provide the wrong motivations. Trade shows are notorious for this, with herds of incredibly cheap attendees — hotel and flight paid for by their employer, if not simply locals — motivated primarily by free pens, t-shirts, and so on.
Such a spectacle is an embarrassment. It was, I suspect, one of the things that killed COMDEX: When most of the floor is occupied by people just looking to enter draws and score swag, the value of the show is seriously undermined.
"Yeah, great demo. Where's my freebie?"
I refuse to believe that it enables development for Android. Is there really a credible Android developer who couldn't accommodate that minimal capital expense themselves? Does Apple need to give out free iPads and iPhones?
Worse still, it devalues the entire ecosystem because it makes you a sucker if you paid real money for something. It makes buying that Xoom for development even more painful because you know that so many got it for free, courtesy of Google, quickly flipping it on Ebay.
I'm a big fan of Android's permission model. To recap, it's a system where you're told, in advance, the rights that an application requires to run. A simple calculator, such as the excellent RealCalc Scientific Calculator, should demand no permissions at all.
It can't send or receive data on the internet. Nor can it read my phone number, SMS messages, make calls, etc. I know, by the rights system, the "surface area" exposed to it.
Other applications, such as the ZXing Team's Barcode Scanner, have a much broader rights demand (click on the permissions tab). I originally put off installing that application after seeing that it demanded the right to read and write contact data. I later learned that it uses that to turn contacts into barcodes, and to import contact barcodes.
As ideal as the Android security model is, it was widely panned as being too complex for an average user. That users would simply click past the warnings, as they tend to do when it comes to security matters.
This past week Angry Birds pushed an update that added a new right request: the ability to read and send SMSs on your device. Such a right change disables auto-update for the application, forcing the user to approve or deny the new version. Many users denied the update, many taking to the comments to raise the warning bell about this disturbing change in permissions.
People were paying attention. Rovio quickly attributed it to human error (?) and pushed out a new version that retracted that permission escalation.
It was an excellent example of the permission system working brilliantly, and perhaps an example of a small subset of users acting as the sheepdogs, looking out for wolves.
Aside from the third-party curation of the market that I described previously, whereby a third party could validate appropriate permission sets relative to the functionality of the application, one huge improvement would be the addition of optional permissions.
In the case of Barcode Scanner, it has access to a large surface area despite the fact that I have no intention of ever using that functionality of the application. Ideally I should have been able to deselect contact access, for instance, and the application simply, through discovery, disables that aspect of the application.
Optional permissions would stop the "kitchen sink" element of permissions that is growingly common.
I recently decided that it would be a fun experience to make a mobile game with my children (aged 7, 5, 3, and 0, each contributing per their age), drawing on their unbounded creativity and openmindedness, while making it an educational experience about the technology, the code, and the commercial process after publishing to the market.
I've tried to casually make games for Android before, to discover that the Java-platform SDK just doesn't foster a love for code: the APIs are unelegant and obtuse, and the Eclipse IDE, while very powerful in its own way, just never feels like home.
It makes it something that I don't really look forward to, which is weird because I love coding.
What really hurts my motiviation, however, is the absolutely brutal experience that is the Android emulator.
I recently upgraded to a beefy new machine purely to try to run that thing at a tolerable speed, to find that it's just as slow (I haven't even attempted the Honeycomb emulator, as it's purportedly beyond unusable). Compared to developing for the iPhone, this puts Android at a serious disadvantage. I suspect it's the reason why many Android applications just aren't as polished.
There are some very real technical reasons why it's such an abomination (namely that it's a full ARM emulator, whereas the iPhone "emulator" is an x86 instance running x86 code), but the fact remains that it seriously hinders productivity.
I still believe in the compile seldom model of productivity, but such a process is only possible when the platform is well known, well documented, and proven. Unfortunately that isn't entirely the case with Android, where often you're simply mixing things up and running it to see if it adapts as expected.
With the increased availability of the OpenGL ES API in the NDK, however, I've now found a beautiful medium where I develop in Windows — with Windows x86 binaries against an OpenGL ES emulator (a thin layer ontop of OpenGL) — simply reusing much of the same code in the Android project.
My productivity and enjoyment has absolutely blossomed. Better still, much of the same code is immediately portable to iOS, which is an important consideration.
Of course I need to consider the limits of the platform — smartphones are getting pretty powerful, but they are weaklings compared to a modern desktop — especially the upcoming dominant platform (tegra2), so I signed up for an nvidia tegra2 development kit. I'm fully willing to pay the cash, but it turns out that you need to be approved and I still haven't been, two weeks after applying. I guess I'll have to sign up again with some fantastical account of my great success as an EA-sized gaming house.
That's kind of annoying. Other Tegra2 platforms, such the gTablet, aren't even available in Canada.
Blaze, an Ottawa-based web optimization company, drew from the playbook of easy publicity by publishing the results of a benchmark pitting Android and iOS against each other in a webpage loading deathmatch.
Android was the victor, hitting the finish line (the onload event) an average 34% faster (2.1 seconds versus 3.2 for iOS).
The test measured the elapsed time until the onload event fired loading a selection of Fortune 1000 websites, which as a generalization average towards being simpler sites that are less exploitive of recent advances in web technology.
More important still, the actual comparison was between the Nexus S and the iPhone 4 as proxies for their respective operating systems. The Nexus S being the 1Ghz Hummingbird-processor equipped Samsung device pitted against the Apple iPhone 4 running a very similar processor — the A4 and the Hummingbird are twins separated at birth, both designed by Intrinsity and Samsung — at a slower 800Mhz.
All else being equal, I would expect that in this matchup the iPhone 4 would lag behind by a good 25%.
Of course all else isn't equal: the operating systems are completely different, and the browsers greatly diverged from their shared WebKit roots. Yet a number of comparisons of recent incarnations of Android and iOS on similar devices have found their browsing performance converging: In most cases iOS gives the sense of progress quicker (showing partial pages earlier), while Android tends to complete rendering first. Android has made big gains from 2.1 to 2.2, and again from 2.2. to 2.3.
The Android 2.3 browser is fantastic, and is an absurdly responsive platform. Indeed, the whole operating system has gone from being a endlessly halting stop-the-world garbage collection demonstration, to a smooth as butter, refined UI.
So in this case an Android device with the latest OS on a faster processor comes out on top. No big surprise, so no big controversy, right?
Hardly. Turns out it was a pretty big controversy.
It turns out that these results riled up a hornet's nest.
And on, and on, and on. Pretty extraordinary how reactionary the defensive hoardes are whenever Apple or the iPhone comes out the loser (look at some of the enraged comments below the Blaze pages — this is an absolute embarrassment to the technology world, and these raging defenders are the reason online comments are seldom of value or insight). There have been countless ridiculously flawed surveys covering the Android and iPhone ecosystem, and they are trusted and repeated verbatim so long as the iPhone is the beneficiary.
I think my favourite ridiculous defense came from Michael Gartenberg (the go-to guy if you're looking to fluff up some empty tech story)-
"Consumers don't buy smartphones by going into the store and timing web-browsing experiences with their stopwatch," Gartenberg said. "I don't think this has any impact on the buying public, per se. The headline becomes a lot more misleading than the actual performance because performance gains of less than a second just don't matter."
What a silly statement: The desktop browser wars have been waged on the battles of milliseconds here and there. Android's biggest deficiency prior to Gingerbread (2.3) was interface halts that lasted generally in the order of 60ms or so, and this was something that virtually every user rightly complained about. If these results held, and one device imposed a one second+ tax on each and every page load, that is very significant.
The benchmark is far from perfect. Immediately I would question the choice of target websites: The top websites that people actually visit, particularly on smartphones, have little correlation with the Fortune 1000, and the former will tend to be far more dynamic and leading-edge than the latter. Alas, most benchmark are deeply flawed.
The common complaint about this benchmark, however, has been to argue that the study is invalid because it used the embedded browser control which while obviously heavily overlapping with the full browser code base (if not directly using the same binaries) — if Apple knows how to develop software properly, which evidence seems to show that they do better than most — has some features toggled off for various justifiable reasons. This apparently yielded the loss of a couple of optimizations, namely JIT Nitro JavaScript compilation, and the use of HTML5 async attribute behavior (something that no more than a minute fraction of those Fortune 1000 sites use, if any. I would place odds on zero of them making use of it).
Says Daring Fireball-
It’s easy to see that Mobile Safari is faster than UIWebView — just run something like the SunSpider benchmark twice, once in Mobile Safari and once in any app from the App Store with a web content view. On my iPhone 4, Mobile Safari runs SunSpider almost three times as fast as an app using UIWebView.
I think there's a general misunderstanding of the benefits of JIT compilation, especially in the context of a test such as this.
The study also found that despite significant JavaScript performance gains in the latest Apple iOS 4.3 and Google Android 2.3 releases, they made no measurable improvements on page-load times at the sites tested.
Of course they didn't! I would actually expect that JIT compilation/tracing profilers were actually a minor net negative for the performance of simple webpages of the sort you're going to find hitting up the corporate websites of the Fortune 1000. Only dynamically rendered AJAXy sites like Rdio.com are going to see "render" benefit from a JIT JavaScript engine, but if you're simply measuring to the execution of the onload event, on pages where it's rare for the same piece of JavaScript to ever get executed twice, the return just isn't there.
Firefox 4, released today and highly recommended, is a vastly improved browser in almost every way over its predecessors. The one thing earning the most attention, however, has been the performance of the JavaScript engine. For computationally intensive JavaScript uses it is a dramatic step forward, representing a huge improvement of an already optimized platform.
Sites that demonstrate the benefit of these JavaScript improvements are very few and far between, however, and are far less prevalent than benchmarks that show dramatic gains.
Go ahead, completely turn off JIT compilation (about:config, filter on jit and toggle all of the .content items to false) and see what the impact really is. You'll find that it's still a shockingly speedy browser, even though it is suddenly a Sunspider weakling.
Addons gain from JIT, though of course that is completely immaterial to an embedded browser control on a mobile device.
Everything in the browser is faster and smoother and slicker, having nothing at all to do with the JavaScript engine. Pages render quicker because of a greatly improved, native rendering engine (written in C). Hardware acceleration, retained layers, native property representations...these are the nothing-to-to-with-JavaScript advances that make it a much better, smoother browser than it was before.
Javascript performance is, however, often an important indicator of where team attention lies. Chrome really shot to the lead in the JavaScript war, also bringing a slick and speedy, responsive browser: Their focus was on speed, and it shone through in both aspects of the browser, however it's a loose correlation. Safari on Windows, as a counterpoint, is an atrociously slow pig of a browser that feels like someone toggled your PCs turbo button off, yet it has an amazingly fast JavaScript engine.
SunSpider results are hugely overemphasized. They will matter more in the future as JavaScript on the sites that we use grows more complex, especially once JavaScript starts getting delivered in a pre-compiled intermediate language form, however it's surprising to see how many intelligent people expected so much from Nitro's very impressive JavaScript speedups in a simple test measuring basic page load times. Your browser is not written in JavaScript (yet...), so some perspective correction is in order.
I commend Blaze, however. They played the media and community like a fiddle, and their PageRank will benefit heavily as a result. They do offer an interesting service which many of us were completely unaware of before.