The other real reason we're upset about Sparrow's acquisition

The big tech news the other day was Google's purchase of Sparrow - a popular email client. Future development on Sparrow will be limited to critical bug fixes. In The real reason we’re upset about Sparrow’s acquisition, Rian van der Merwe argues that we expect small companies with no long-term business model to get bought out, but sustainable companies that we support with real money are "supposed" to resist the temptation. His theory sounds pretty solid to me. However, I think there's another way to think about it that explains some of the angst:

The Sparrow developers used to work for us, but Google hired them away by offering more money.

ECMAScript test262 - Awesome, But...

Today the IE blog linked to ECMAScript test262, a test suite to verify conformance to the JavaScript spec.

First, kudos to ECMA for coming out with a test suite - having a benchmark for compatibility will drive the browser vendors to improve their interoperability. Everyone wins there. Also, the visual design of the page is very nice - something we don't always get from standards bodies.

Second, kudos to the IE team for getting the top score with their IE 10 preview! And IE 9 is way up there also. Seriously, good job guys. We know that I have my problems with Microsoft's browser policies, but nobody can deny that the IE team is doing great work over there.

Now, the bad news (emphasis mine):

Test262 is being developed by the members of Ecma TC39. Ecma's intellectual property policies, permit only Ecma members to directly contribute code to the project. However, a public mailing list is used to coordinate development of Test262. If you wish to participate in the discussion please subscribe. Bug reports and suggestions should be sent to the mailing list.

(I can't link you directly to that quote because they didn't use a separate URL - it's revealed by JavaScript when you click on the "Development" link in the top navigation. They didn't even use a hash-bang link!)

If those are your policies, guys, change your policies. This is exactly the kind of thing that should be open source. You're not trying to sell it. Lots of talented people have incentive to contribute to it.

Why do developers hate IE?

It has to be a tough gig being on the Internet Explorer team at Microsoft. Mention IE in a room full of web developers and the best reaction you can probably expect is a sigh. You’re more likely to see fists shaken at the sky or hear muttered curses. But why?

Some people explain the IE hate as just part of an anti-Microsoft prejudice. That’s sort of a non-answer. Why do people have negative feelings toward Microsoft? There are reasons for those anti-Microsoft feelings. One of those reasons is certainly just discomfort people have toward large companies that have power over them. But those kind of feelings apply to Google and increasingly Apple as well. In the case of Microsoft, though, web developers can look back at an incident where that power was wielded against something they loved - Netscape.

The Ghost of Netscape

For many web developers today, Netscape was their first web browser. Think about that. Netscape was the web at a time when a lot of us fell in love with the web. What are we today? Web developers. Turns out we liked the web quite a bit. And we liked Netscape.

Microsoft killed Netscape in a way that seemed very unfair.

Microsoft bundled IE with its near-ubiqutous operating system. This was in the bad old days of the “Browser Wars” when there were no web standards to speak of. If you wanted to do anything fancy at all (and standards for “fancy” were much lower), you had to think very hard about which browser you were on. Microsoft’s move to tie the browser to the OS said: “Target what you want, but everybody’s going to have IE. They might not have Netscape.”

It still pains me to say it, but Microsoft pushed the state of the art for web browsers forward a lot in those years. A lot of the great browser features we have today came from IE. Internet Explorer became the better browser. But what we remember is what Microsoft did to Netscape. We remember how they betrayed our trust and killed something we loved.

---

But that’s all in the past, right? Ancient history in Internet years. Microsoft got slapped by the DoJ and some European anti-trust stuff also - they’ve done their time. What about the IE of today? Well, not so fast.

The IE of Yesterday

Microsoft had won the browser wars by the time it released IE 5.5. Netscape 5 was never released. When Netscape gave its source code to the community, the community decided: “uh, let’s just start from scratch.” Netscape 6 was released as just a re-branded copy of a pre-1.0 version of Mozilla. It was buggy and a resource hog.

It’s not surprising that Microsoft released IE 6 and declared victory. Netscape had been vanquished. Microsoft had proven that they could come from behind and create a better browser. I imagine there were ticker-tape parades in Redmond.

The year was 2001. Little did anyone suspect that the year would stay 2001 for more than a decade.

Support Cycles

Complex software tends to have bugs. The more complex, the more chance for bugs. Bugs in network-connected software tend to get exploited and turned into security holes. The web browser is simultaniously one of the most complex and one of the most network-connected pieces of software on any given computer. If you don’t keep your browser up-to-date with the latest security patches, you’re going to get exploited.

So Microsoft supported IE 6. Patches came out at regular intervals. But they were mostly just security fixes. Microsoft wouldn’t fix rendering bugs because they didn’t want to rock the boat. Sites out there depended on the sometimes quirky (to put it politely) rendering that IE gave them.

Meanwhile Mozilla hit 1.0. Then Firefox grew out of Mozilla. Then it turned out people really liked Firefox. Even Apple got in to the browser race with Safari. Microsoft decided they had to step up their game, so they got the team back together and came out with IE 7 around the same time Firefox 2.0 was coming out - late 2006.

IE 7 was a huge improvement over IE 6. It had a tab-based interface that had become popular - that was nice for users. Developers cheered because a lot of the rendering bugs they had been tearing their hair out over with IE 6 had been fixed. “Finally,” we thought, “these IE 6 bugs we have been wrestling with for five years are no more!”

Microsoft put IE 7 out through Windows Update… but as an optional update. Optional? It turns out that some “enterprises” didn’t want to update to IE 7. They all had internal apps that depended on the rendering bugs in IE 6.

And enterprises weren’t the only IE users that stayed on IE 6. Lots of Windows users never consider installing optional updates. They’re barely comfortable installing the required updates - an optional update just sounds like an invitation to break their computer.

So at the end of 2006 Microsoft was supporting two browsers - IE 6 and IE 7. And that meant that web developers had to support IE 6 and 7 also. All our cheers at the release of IE 7 turned to cries of frustration.

The pattern repeated when IE 8 came out in 2009 - optional updates. Microsoft started supporting three browsers - web developers supported three versions of IE.

Earlier this year Microsoft released IE 9. It is a huge improvement over IE 8. It supports nice things like box-shadows and rounded corners. It has a vastly improved JavaScript engine. It is still an optional update for all IE users. Actually not all IE users - users on Windows XP can’t update to IE 9 - the browser requires Windows Vista or 7. Now we are all supporting four very different versions of IE and nobody is happy.

Why is IE 6 still supported?! It is apparently Microsoft’s policy to keep supporting the major browser version that was current when the operating system was released. For Windows XP, that browser was IE 6. And when will Windows XP support end? I think it’s not until 2014. At that point IE 6 will have been on the market for thirteen years. Thirteen years!

This should have never happened. Microsoft bowed to the wishes of some of its big business clients by supporting old major releases of IE. In doing so they decided to screw over web developers. Does that piss us off? You bet it does!

When IE 7 came out, IE 6 should have ended. You want a security patch for IE 6? Here - it’s called IE 7. Sure it would have been painful for a lot of companies, but guess what - supporting multiple versions of IE is a hell of a lot more painful to a lot more companies. And those companies that still haven’t broken out of IE 6-land? They are in for one hell of a rude awakening when XP support ends. All this “don’t rock the boat” policy has gotten us is a really unstable boat.

And Microsoft hasn’t changed their policy. They’re still going to support IE 7 until Vista falls out of support. And IE 8 until Windows 7 is no more. How long will that be? How many different versions of IE will we have to worry about?

Make no mistake - IE is a giant dick in the eye of all web developers. And Microsoft has chosen to make it so.

How can they fix it? They can stop supporting major releases for so long. Just support the latest version! What the hell is a “major” release anyway? Google increases the version number of Chrome any time someone sneezes. It doesn’t matter. Call the next version of IE 9.0.1 and make it a required update to all 9.0 users! Do not make an IE 10 that you support along side IE 6, 7, 8 and 9! What the fuck is wrong with you people?

A Big Problem

Remember Steve Ballmer’s “Developers, developers, developers” speech? He was right. Developers are important. It is not good business for Microsoft to be hated by the developer community. And guess what - a large percentage of developers are web developers. And Microsoft has fucked us over for years.

Could they make us happy now? I don’t know. Maybe Microsoft’s best strategy would be to continue fucking us over forever. Eventually all developers will hate Microsoft and never build on one of their platforms again. But in the meantime they can squeeze all their locked-in customers to the fullest.

I really can’t imagine a Microsoft that could win me over now. A more useful web just makes Microsoft’s main products less important. Why would they help it? But the web is moving forward weather Microsoft comes along or not. And in spite of anything Microsoft does, it’s a wonderful ride.

Vim-Columbus

I'm really excited about the new Vim user group we're starting up in Columbus: Vim-Columbus. I started the page while we were talking about it at Code and Coffee yesterday. That evening after work, inspiration struck and I decided to make the page itself look like Vim. I am inordinately pleased with myself (I get like that sometimes).

Is Ruby the Best Language?

I was noodling around with some Ruby the other day, and all of a sudden I ran into a situation where I wanted to do a partial function application. But how do you do that in Ruby? It can certainly be done, but it felt very awkward to me and made my code less readable than the non-partially-applied alternatives. So I didn't do it.

For me, higher-order functions in Ruby are the language's only blemish. It seems almost unfair to ding Ruby for that, because Ruby (at least since 1.9.x) does higher-order functions pretty admirably. It's just not as elegant as the rest of the language.

Ruby has set an extremely high bar. The lack of ceremony in the language makes it extremely readable. The purity of its "everything is an object" stance makes it very writable. And its pervasive methods of introspection make it amazingly powerful.

But why did I even have the urge to make a partially applied function? Because I've been doing a lot of JavaScript lately, and JavaScript is all about the functions.

Ruby and JavaScript take sort of opposite approaches to object properties vs. methods. When you want to reach into an object in Ruby, you always talk to a method. So-called "properties" on Ruby objects are really just getter and setter methods with a little syntactic sugar applied.

In JavaScript, objects mostly only have properties. A "method" in JavaScript is just a property that happens to be a function. (You can define real getters and setters in modern versions of JavaScript, but browser support is not yet pervasive.)

Which approach is better? I would have to say Ruby's. JavaScript seems more fragile in its property-centricity. For example, if you want to pass a method as a callback in JavaScript you have to think about weather it needs to be called as a method or if it is OK to be called as a stand-alone function. If it needs to be called on a particular object you end up wrapping it in another function.

When it comes to JavaScript's advantage - higher-order functions - Ruby sort of cheated. By making a special case of passing a single function (a block), Ruby made the 80% use case extremely easy and simple.

So is Ruby the best language? Well, I probably wouldn't have worried about higher-order functions so much if I wasn't using JavaScript. What other blemishes might Ruby have that I just never run into? I guess it's not surprising that you can only compare languages that you have really used.

But Ruby is definitely the best language that I know.

node.js

I can't stop thinking about node.js.

node.js is Google's V8 JavaScript engine tied together with some non-blocking IO libraries. Those libraries include DNS, TCP, HTTP and file access.

Now, I've been dreaming about a good server-side JavaScript solution for quite a while. JavaScript is an excellent language, and chances are you're using it already on the client side. Why not use it on the server side also? That's not the main reason that node's author (Ryan Dahl) chose it though. He chose it because JavaScript is already very callback-centric, and node is designed to use callbacks in place of multi-threading. Whenever you do something that might take a little while (like hitting the network or disk), you set it up and then pass it a callback. Your callback will know how to handle the data that gets returned. Meanwhile, code keeps executing. This is much better than having one thread running for each connection, because those threads are usually waiting for the network or the database or even disk. When you have all those idle threads you pay a penalty in context-switching and memory overhead.

If you still need more convincing, check out Ryan's slides from his JSConf.eu talk (PDF). They're very readable slides.

It's still early days for node.js. The project (what do you even call it - a server, I guess?) can serve up HTTP very well, but it doesn't give you a framework by itself. Consequently there are frameworks popping up all over for it, following all the patterns of frameworks implemented for other languages. One thing the server is genuinely missing is database support. A PostgreSQL binding is in the works, which sounds great to me. MySQL might be harder because it doesn't have a non-blocking library, but who needs MySQL when you have Postgres? :-P

Network Printer

If you're trying to set up a printer that is attached to the network, do you think you should select the option that says "Local printer attached to this computer" or the option that says "A network printer, or a printer attached to another computer"? Hint: this is Windows.

Scroll down to the bottom of the dialog box for the answer. I can't understand why they don't just relabel the options. I would make a guess, but Al Gore tells me that my sarcasm footprint is already too high.