Skip to main content

Kindle Fire: Year-End Clearance

I got a Kindle Fire earlier in the month, mainly because it seemed like the best value you could get for an Android-based tablet and it would be useful for some HTML app testing. After a few weeks of playing with it, though, I've decided to return it.

The device itself doesn't inspire a lot of passion. It's just about half an inch too wide and much too heavy to be held comfortably in one hand--at least for me; perhaps Joe Flacco could palm the thing. That discomfort is compounded by the rather angular edges of the device. Now if you're going to want to hold it with two hands and/or prop it up against something, the tiny screen becomes a liability more than a benefit.

The Fire's ecosystem annoyed me right out of the box. To get started I figured I'd try some of the free books. When I tried to download them I got an incomprehensible message. Turns out you absolutely must have a credit card saved to your Amazon account, even for the "purchase" of free books. Then I decided to sample several "free" magazine apps (all Conde Nast ones BTW). Turns out that yes the app itself can be downloaded for zero dollars, but you have to pay for individual issues, get a subscription, or enter a code from an existing print subscription. Oooo-kay.

There wasn't a lot of passionate fire kindled for this device by any member of my family. My daughter took it out of my hand and immediately thought it was much too heavy for its size. My son said he preferred his Kindle Touch for reading books, especially since it's lighter and actually is comfortable to hold in one hand. My wife definitely prefers the iPad.

One of the device's major attractions to me was the Silk Browser. I'm still interested in how (and how well) Silk works, especially in the context of jQuery, but the Kindle Fire is not the kind of device I'd want to use to explore it. For now I'll wait for Amazon to come out with other form factors, hopefully one that is more like an iPad and less like a lump of coal.

Comments

Popular posts from this blog

Tragedy of the WebKit Commons

With Opera announcing that their future products will be based on WebKit, the Internet is abuzz with discussion about what that means and whether it's a good thing. Looking at it as a jQuery developer, it's a good thing if it gets WebKit participants to fix bugs and update older implementations. I can't be optimistic without some evidence that things are really going to change. We don't know how many of Opera's core developers will move to WebKit development, but the press release isn't encouraging:  "The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions."  I suspect they want some cost savings by eliminating Presto technical staff, or -- in the most optimistic case for their employees -- refocusing existing staff on the parts outside WebKit core that make browsers different. Opera did  land their first WebKit patch  so they wanted to make a statement that they weren't gettin

Please Stop the jsPerf.com Abuse!

According to many of the tests on jsperf.com , jQuery is slow. Really slow. The jQuery team gets bug reports from web citizens who've discovered these egregious flaws via jsperf and want them fixed. Now, jsperf.com can be a great tool when used knowledgeably, but its results can also be misinterpreted and abused. For example: Why doesn't jQuery use DOM classList for methods like .addClass()? There are at least three good reasons. It doesn't make any practical performance difference given its frequency of use. It complicates code paths, since classList isn't supported everywhere. It makes jQuery bigger, which makes it load slower for everyone, every time. But this jsperf shows classList is much faster! How can you say that? Well it's possible that test is running afoul of microbenchmark issues , and not measuring what it is supposed to measure due to the increased sophistication of today's JavaScript compilers. This is a big problem with a lot of t

You Might Not Need Babel

Babel is great, and by all means use it if it makes it easier to develop your application. If you're developing a library on the other hand, please take a moment to consider whether you actually need Babel. Maybe you can write a few more lines of utility code and forego the need to pre-process. If you're only targeting some platforms, you may not need anything more than plain old ES6. At the very least, make sure you know what Babel is doing for you, and what it's not. Some developers believe that Babel is protecting us from a great demon of code complexity when, in truth, browsers and node are pretty easy to deal with on their own. Let's take a look at some of the strategies for not needing Babel. ES5 is pretty okay: In the days when we used tables for layout and the debugger was named alert() , we would have been so grateful if JavaScript had the features that ES5 has today. If you truly need Babel you are not only a weak programmer, but also an ingrate. Face