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 getting out of core browser development altogether. Then again, the age of that bug just underscores one of the problems with WebKit. It took five and a half years to make a half-line fix! Now as a first commit it's a great one for the Opera team, since it lets them get the feel of the system and of course they had to write a few more lines of unit tests. But five years? Why so long to fix a trivial bug? Because fixing bugs doesn't make news.

Each release of Chrome or Safari generates excitement about new bleeding-edge features; nobody seems to worry about the stuff that's already (still!) broken. jQuery Core has more lines of fixes and patches for WebKit than any other browser. In general these are not recent regressions, but long-standing problems that have yet to be addressed. Opera probably doesn't have any more incentive to fix the common bugs than any of the other diners at the WebKit table -- especially when jQuery continues to cover up these mistakes. Instead, Opera will want to focus on their own bleeding-edge unique features, all while people complain about jQuery's "bloat".

When we started our jQuery 2.0 cleanup to remove IE 6/7/8 hacks, we were optimistic that we would also be able to remove some bloat from lingering patches needed for really old browsers like Safari 2. But several of those WebKit hacks still remain. Even when they have been fixed in the latest Chrome or Safari, older WebKit implementations like PhantomJS and UIWebView still don't have the fix. We've had to put back several of these as users reported problems with the beta. It's starting to feel like oldIE all over again, but with a different set of excuses for why nothing can be fixed.

Please Post A Test Case

I spend a lot of time writing little scraps of HTML, JavaScript, and CSS to demonstrate a technique or prove/disprove the existence of a bug. It is a royal pain to do that in a classic web page development process and make them available to the world, because it involves creating a file that is 80 percent boilerplate, adding my own code, coming up with a unique name, and dropping it in some place on a web site that I control. Ugh, so tedious.

Fortunately there already is a way to publish these working code snippets, similar to the ease of creating a blogging platform. Type some code into a box and let someone else take care of the boilerplate. For code samples you can choose from jsFiddle.net and jsbin.com. If all you need is some CSS/HTML hacking area there is also cssdesk.com, but I'll focus on two scripting-capable solutions here.

Both jsFiddle and jsbin do basically the same thing, but use different interfaces. It's mainly a matter of preference as to which one you like and use. With either, you can:

• Choose an appropriate boilerplate for your code, including external JavaScript or CSS if needed.
• Edit the script, HTML, and CSS for the sample code.
• Easily change the boilerplate (for example, change jQuery versions) without editing your sample code.
• See the live results, either in a sub-window or a full browser window.
• Save multiple versions of the example, and go back to any previous version.
• Share versions with other people, and allow them to create their own variations.

Just like blogging revolutionized web authorship, these sites are an incredibly powerful way to share and create code. Rather than copy/paste sample code fragments into an email and trust the person on the other end to understand the context, you can give them a completely working example with almost no additional effort. It's great for teaching as well. The HighCharts charting package has based their API documentation on jsFiddle, for example, so you can run and change the live code in their examples.

You can even embed a working code sample into another web page! The information is read-only while embedded here, but click the plus-sign to be taken to the jsFiddle web site where you can tweak to your heart's 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.

This Hover Cruft is Full of Ills

Recently I spent time refactoring much of the event system in jQuery for version 1.7. Since we added some new event methods as well, I took another pass at the event-related documentation. It was an opportunity to rewrite the pages in a way that make more sense (at least, to me) and eliminate things that were important five years ago but not so much today. Just like code, documentation accumulates its own cruft over time. I also find that when things get ugly or inconsistent in the code, they often get ugly or inconsistent in the documentation as well.

Here's an example: In jQuery 1.4.2 we started allowing people to use the "hover" event name for the .live() and .delegate() methods. This is the equivalent of attaching a "mouseenter" and "mouseleave" event to an element. Really. That is all it does. If you said $("button").bind("mouseover mouseleave", myFunc) you can now say $("button").bind("hover", myFunc) and save 16 taps on your keyboard. Many people seem to just love it, and I don't understand why.

jQuery's hover event is not a hover event at all. First of all, unlike any other event, when the actual events occur the event.type is "mouseenter" or "mouseleave", not "hover". Then there is the API confusion, since there is also a .hover() method that can accept two functions (separate functions for each event). Some people expect that somehow the .live() event binding method knows about the powers of this magic hover event and thus it will accept two functions as well. But no. Thank goodness.

Then there is the question of what .trigger("hover") would do. Somehow this peculiar behavior didn't infect triggering, so that will truly trigger a custom event named "hover" and have no effect on the mouseenter-mouseleave "hover" that was bound. Of course, you'll have a mighty hard time binding an event handler to your custom "hover" event anyway. I suppose that for consistency and symmetry it should trigger mouseenter and mouseleave events in quick succession. But that would be silly, right?

More bothersome still is the misappropriation of the term "hover" for both of those cases. When an airplane flies through the airspace directly over my house, it's not "hovering" there. When a helicopter flies to the vicinity of my house and hangs out in mid-air over the roof, now that's hovering. The word "hover" implies that the mouse at least slowed down for a while and spent time over the element. With the current implementation, you'll know only that the mouse happened to touch the element for a fleeting time. You'll see many naive dropdown-menu implementations that use bare mouseenter-mouseleave events and act way too jumpy. Either they drop down as your mouse pointer flies by, or they quickly close if your mouse strays the slightest bit off course.

Brian Cherne's jQuery hoverIntent plugin takes mouse velocity and timing into account and follows that intuitive idea of what hovering really means. If your mouse-tracking needs exceed a simple mouseenter-mouseleave situation, the odds are that you need that plugin. One day I'd love to remove the "hover" hack and the special-case code that goes with it.

Steve Jobs

By all accounts, Steve Jobs was the kind of guy who you didn't want to work with. To put it bluntly, he was a perfectionistic pain in the butt, the Boss from Hell for whom good was never good enough. Yet that intensity was driven by a vision that has transformed technology in the past decade.

Many successful businesses make their fortune by carefully calculating how much people can spend and squeezing every bit from them via tricks, gimmicks, and sometimes even outright lies. Advertising and marketing create demand for a product that is often much different than it appears to be. When people find out that the reality doesn't match what they were promised, the outcome is bitterness and anger towards the company that deceived them.

Jobs was different in that he figured out what people really wanted--so often in sync with what he really wanted--and gave it to them. He seemed to figure it out not by focus groups or statistical analysis of consumer trends, but by a gut feeling that was in tune with the public's inner desires. For Apple the product itself, not the advertising, inspired good feelings. Those products are often defined by what they don't have, a Zen simplicity that lets their essential qualities shine through.

Plenty of companies take one idea and ride it for years, making only small tweaks to the formula. Not so with Jobs. He had no problem branching out from Apple's core business of personal computers. First with the iPod, then the iPhone and iPad, Jobs put his company into markets against established players and blew them out of the water. He dived headlong into markets left for dead after multiple attempts by competitors who had nothing to show but a crimson balance sheet. He reminded us that a great product is the best foundation for a great business strategy.

Clearly, Jobs was not the only one responsible for Apple's past decade of incredible success. To his credit, he never claimed he was. In a "60 Minutes" interview, Jobs said, "Great things in business are not done by one person, they are done by a team of people." Yet he provided a successful vision the company could follow, and--to their credit--one they did follow.

Jobs passionately knew what he wanted, and wasn't happy with the people around him delivering anything less. Yet passion by itself isn't a recipe for success, especially when it creates such tension in the organization. Jobs was effective not just because he was passionate, but because the ideas behind his passion were so often proven right. No doubt there were stressful times inside Apple given Steve's style. In the end, however, everyone must be deeply satisfied with the success of the products they created under his leadership.