Allow me to preface this with some context. I <3 PHP. It’s probably my favorite language for a variety of reasons, but the number one reason being I’m pretty expert at it. But I’m not above recognizing that the majority of PHP programmers are generally idiot script kiddies, and don’t know how to write code that is not terrible. In that way, all PHP programmers get a bad name, because, like in all other aspects of life, the morons far outnumber us geniuses. It’s our cross to bear.

Anyway, PHP is dead. Probably. Here’s why.

PHP is Stagnating

PHP 4 was released in May 2000. PHP 5 was released in July 2004. PHP 4.4 was released in July 2005. PHP 5.3 was released in June 2009.

These dates are not enumerated here to poke fun at the slow release cycle of PHP (I’ll get to the core team later). Rather, it’s to illustrate a point. Here are some numbers that I pulled from some random data dump from some non-English site that’s probably totally legit:

SELECT
	SUBSTRING(libelle, 1, 1) `php version`,
	SUM(nombre) `count`
FROM stats
WHERE libelle REGEXP '^[3-6](\\.\\d(\\.\\d)?)?$'
AND `date` LIKE '2008-10-06%'
GROUP BY SUBSTRING(libelle, 1, 1)

php version  count
-----------  -------
3               8096
4            2396211
5            1977067
6                 23

If it’s not abundantly clear to you unwashed masses what a “libelle” is, I’m pretty sure that’s “label” in some kind of European language. The dataset represents a census documenting what technologies people use to power their sites. Basically, this query is saying that in October of 2008, 2.3 million people used PHP 4 on their website and 1.9 million people used PHP 5 on their web site.

At that time, PHP 5 had been stable for 4 years, and PHP 4 had been stable for 8 years. Their usage in production is pretty much even. PHP 5 added a lot of features, such as, you know, object-oriented programming. And yet it takes ten years (and counting) for PEAR to get off their asses and convert their code to PHP 5.

For those who don’t know, PEAR is the PHP Extension Application Repository. It’s a packaging mechanism similar to yum or apt-get, as well as a repository for extensions to the PHP language written in PHP (as opposed to PECL, which are extensions to the PHP language written in C). It defined a coding standard, and generally did a lot of good for the PHP community, except that it’s written in freaking PHP 4, and the coding standard is embarrassingly terrible.

For example, they prefix member variables with underscores to indicate that it’s not public, since PHP 4 didn’t have the notion of member variable accessibility. PHP 4 also didn’t have the notion of static. You should see the way they implement the singleton pattern in PHP 4. It’s pretty hilarious.

PHP 4 also didn’t pass objects by reference. That means you manually had to insert ampersands everywhere to make sure that your objects wouldn’t be treated like a value type. And when I say everywhere, I mean everywhere. This is a very common occurrence in PHP 4:

$myReferenceType =& new AwesomeClass();

DEAR GOD YOU COULDN’T EVEN USE THE NEW KEYWORD WITHOUT EXPLICITLY DEFINING THE REFERENCE. WHY ARE PEOPLE STILL USING THIS VERSION OF PHP?

This is all a long way of saying that PHP 4 is hideously outdated, both in calendar time and technologically, and yet it remains very prominent. I die a little inside when I see someone using a host that’s rocking Apache 1.3 and PHP 4.3. It’s like seeing someone using the cgi-bin directory. Aren’t we past that yet? This isn’t 1997 anymore.

The same argument goes for PHP 5.3 as well. It added some sorely missing features, such as namespaces and true anonmyous functions, as well as a plethora of classes in the SPL, and yet no one is upgrading. It’s been a year, and people are still creating classes called Awesome_Controller_Abstract instead of using namespaces like a normal person. It’s heartbreaking.

This is what will cause PHP to always be slightly behind the curve technologically: its users’ snail’s pace upgrade rate. Eventually, its one strength, the extremely low barrier to entry, will be nullified as other languages figure out how to be more accessible to the masses.

The PHP Core team is separated from reality

So, I imagine this is a problem for a lot of languages, and I’m definitely making unfair blanket statements, but I want to bring it up for one very specific reason. Try to read the next sentence without laughing.

In PHP, the namespace separator is the backslash.

You laughed, didn’t you?

Allow me to give a bit of backstory without citing any sources.

There was fairly raging debate among the core developers on what to use for the namespace separator in the months before PHP 5.3 was released. You see, it wasn’t as simple as you might think, because PHP isn’t primarily an object-oriented language.

The original solution was to use the paamayim nekudotayim (scope resolution operator, but the Hebrew version is way cooler) as a namespace separator. But oh no! That caused problems in situations like this:

//bar.php
namespace Bar;

function foo() {}

//meanwhile, in baz.php
require_once bar.php;

class Bar {
  static function foo() {}
}

Bar::foo(); //which foo gets called? in the Bar namespace or in the Bar class?

So, the core team realized they had a problem. There were several solutions:

1. Only apply namespaces to OO code (classes, interfaces, etc.)
2. Change the namespace separator character to something unambiguous

Hindsight is always 20/20, but the second option there seems pretty retarded to me. It’s hard to find an unambiguous character in any language that has previous releases, because they’re all being used. What happens is you’ll end up choosing a character that’s hard to type (i.e. one you have to press shift for), or you’ll choose something that’s unambiguous technically (meaning not significantly used) but has ambiguous semantics (like, say, the escape character in every language besides T-SQL).

At one point, the core team actually created a matrix where each row was a different character (I think the triple colon was in the running at one point, which would probably be even more awesome when translated to Hebrew), and each column had funny stuff like “is hard to type” with a numeric value. The last column summed up the numeric values and the row with the highest number was the winner. It was all very democratic (THROUGH PURPLE MOUNTAIN MAJESTIES…).

The backslash won.

Well, kind of. Pretty much everybody who typed code for a living hated the backslash because, you know, IT’S THE BACKSLASH. Nobody wants to look at that.

But PHP is an open source project, which means most or all of them don’t get paid to work on it, so that means that the easiest solution will win. And in this case, the easiest solution was the one that was already done. One of the core developers got tired of the bickering and the matrices and the Hebrew and he spent a weekend implementing the backslash namespace separator and committed it to the branch. Then he wrote tests covering all possible cases, and created a patch against trunk.

He had everyone at “tests” and “patch”. And that’s how the backslash became the namespace separator for PHP.

This was all a a long way of saying their decision was made with their brains instead of their guts. If they used their guts, they would have realized that NOBODY GIVES A CRAP ABOUT NAMESPACES EXCEPT PEOPLE WHO DO OBJECT-ORIENTED CODE. Nobody cares if the 4000 lines of random functions in stuff.php is in a namespace. The only people who care about namespaces are those that experienced it in another language (like say, an object-oriented language) and would want to apply the same organizational structure to their PHP code. And those people are only writing classes and interfaces.

Ergo, they should have ignored the collision issues illustrated above, only applied namespaces to classes and interfaces, and rocked the PAAMAYIM NEKUDOTAYIM like it was going out of style. But since the PHP core team are experts in C, not PHP, they didn’t really realize this.

Instead, we are condemned to a life full of backslashes. I’ve already started a support group.

PHP 6 is a disaster area

I don’t have a lot to say about this, except that it seems like it’s an absolute disaster. The main thing going on in PHP 6 is unicode support.

yay.

I’m not totally sure why that’s so awesome, but it’s a lot of work, and it isn’t going well. Again I’m not going to cite any sources, but it’s been in the works for about two years to add unicode support to PHP, and I don’t think it’s very close to being done.

The problem seems to be that they can’t just add unicode support, because every extension would be incompatible. So they’re trying to retroactively add unicode support to everything at once, which is as terrible as it sounds. I could be making all this up, but it sounds similar to something I might have read once.

Basically, they’re attempting to add a feature that will be of minimal value, and it’s taking forever. Instead, they could be adding cool things, like some of these:

• C#-style properties
• Auto-boxing
• Traits
• Enumerations
• Function call chaining (oh god yes)
• Static classes

In Conclusion

PHP is dying. Probably. I hope I’m wrong, because I think PHP is a very expressive, convenient language. It has, by far, the best function library of any language. It also has, by far, the best documentation of any language, as well as a giant, open community around it. For those reasons, I hope it doesn’t die. But I’ve seen little evidence that it’s not going to march straight to hell.

I’m so sick of Lisp hackers. Functional programming is pretty awesome, but every single Lisp/Erlang/Haskell/Clojure/Emacs guy thinks Lisp is the greatest thing since list processing (what?).

So I implemented Reddit in (properly formatted) PHP in 97 lines. Granted it took a bit longer, but I had to remember how to use the low-level mysql_* functions. Oh, and I used MySQL. I don’t know what the Lisp people used for data persistence. Some of the lines were taken up by CSS and JavaScript, and making things look nice(r).

Reddit in 61 minutes of alone time with Notepad++

Source | Playground

I hate Lisp people.

A touch of JavaScript, and now they see this:

Just say NO to frames. And kiwis.

It’s not all bad, though. Agile and scrum are basically a fancy way of saying “communicate more”, and if you can get “the business” to talk to you more and all it takes is an overloaded word like “scrum”, go for it. Mostly, though, I hear “scrum” and “agile” and “tdd” as cop-out explanations used by developers to explain why they aren’t very good at their jobs.

• The project is late because the requirements were constantly changing.
• We didn’t catch the bug because we didn’t have enough time for testing
• 100% code coverage is impossible

All of these issues can be solved by being better at your job. Learn how to communicate with your customers. Learn how to budget your time. Learn how to write tests. Scrum and agile and tdd mitigate these issues, they don’t solve them. They force you to communicate, and write tests, but if you’re not good at communicating or writing tests, doing more of it isn’t going to help you.

Of course, if your manager is an idiot, then you’re screwed, and you will always have these problems.

But this article is less about whining in general and more about whining about TDD. Let’s commence.

Case Study: Sudoku Solver

Peter Norvig works at Google as Director of Research (I’m sure that actually means something) and before that he worked at NASA as some kind of AI genius/hacker. He’s a smart guy who’s been programming for a long time.

In Coders at Work, Norvig talks about a TDD experience of his involving an algorithm for solving Sudokus. It was interesting to me because I wrote a Java applet (shudder) to do that for a college assignment. It was an interesting problem involving recursion, threading, backtracking, memoization and other stuff that academics love.

What happened is that he wrote an algorithm to solve them, and then someone else, from the TDD community, saw it and attempted to write the same algorithm using test driven development: that is, by writing the tests first, and allowing the tests to influence the design of the algorithm.

It’s also important to know what you’re doing. When I wrote my Sudoku solver, some bloggers commented on that. They said, “Look at the contrast—here’s Norvig’s Sudoku thing and then there’s this other guy, whose name I’ve forgotten, one of these test-driven design gurus. He starts off and he says, “Well, I’m going to do Sudoku and I’m going to have this class and first thing I’m going to do is write a bunch of tests.” But then he never got anywhere. He had five different blog posts and in each one he wrote a little bit more and wrote lots of tests but he never got anything working because he didn’t know how to solve the problem.

The problem that the TDD guy encountered was twofold:

1. He didn’t know anything about Sudoku
2. He tried to solve that by writing tests

Tests are not a replacement for knowledge. That seems like a stupid statement, but it’s something that a lot of TDD/Agile advocates sometimes forget. They might complain that we’re not practicing scrum correctly, but practicing scrum correctly doesn’t guarantee that anything will get better. Instead of blindly following a wikipedia article to determine how to run your project or write code, you should figure out what’s wrong, and then solve that in the way that makes the most sense. You might even discover that you’ll start practicing scrum correctly as a byproduct of common sense. Common sense is why most development methodologies exist. Stuffing your current situation into the fad-of-the-moment is not going to solve your problems, although it might by accident. But I wouldn’t hold your breath.

Anyway, back to Sudoku. The TDD guy tried to solve the Sudoku problem by writing tests for a problem he did not understand, which meant whatever tests he was writing were totally worthless, which is something he actually admits in the very first article. After five articles and a great deal of code and a great deal of tests, a Sudoku solver did not exist.

From the first article:

Arguably this is a violation of YAGNI, but since I don’t really know how to start or how to know when I’m done, writing some Spike code in TDD style seems to me to be a good way to get my feet wet.

WRONG. A good way to get your feet wet is to do some research about the problem (the internet is your friend) to see if you’re going in the totally wrong direction.

My plan, subject as always to change, is to code something up in that way that I have, to see what happens

FAIL. “To see what happens?” I’m glad I don’t work with this guy. If you’re randomly writing code to determine if your plan is either absolutely perfect or absolutely idiotic, you’re doing it wrong.

Norvig solved the Sudoku problem by understanding the problem, understanding the solution, and then writing the code. He probably wrote some tests at some point, but they most definitely did not influence his design. What influenced his design was personal experience and a vast knowledge of search algorithms.

Of course, you aren’t going to have vast knowledge of every problem you’re trying to solve, but that’s not the point. The point is that writing tests first is not always the correct decision. If you don’t know anything about the problem or how to solve it, writing a test is not going to help you. All it will do is make you write a lot of code that is probably worthless.

Read for yourself:

• Norvig’s original Sudoku solver
• The TDD approach: 1, 2, 3, 4, 5
• The article Norvig references
• Another summary

Case Study: Wiki Engine

Recently, I decided to write a wiki engine. Why? Because I wanted to. I’m aware of the hundreds of other wiki engines, but it’s an interesting problem, and reinventing the wheel is a lot of fun, just make sure you’re doing it on your own time.

Anyway, I started and stopped several times, deleting large chunks and rewriting them as I went. That is probably not the best way to develop, but whatever. At one point, I wrote a test that looked similar to this:

public function testHeaderGetsParsedCorrectly() {
  $wikitext = <<<WIKI
!Header level 1
!!Header level 2
WIKI;

  $expected = <<<HTML
<h1>Header level 1</h1>
<h2>Header level 2</h2>

HTML;

  $this->assertEquals($expected, $this->wikiEngine->toHtml($wikitext));
}

Nothing wrong with that. It’s testing that the given wiki text gets transformed into the correct HTML. Pretty straightforward.

However, this gives me absolutely no insight to the design of the overall engine. I could easily write a function that will do this, but will it be the correct design? Let’s probe deeper.

I’ve written wiki engines before (they sucked). I’ve looked at other wiki engines, and done a bit of research into Lexical Analysis and certain kinds of parsers. I know a little bit about how to write something that parses something else. I didn’t really use any of that knowledge in my own personal wiki engine, because using yet another parser generator in a wiki engine written in PHP would be an impressive waste of my time, even from a purely academic point of view. But I digress. I was talking about why TDD was a bad idea in this situation.

All this test can tell me is that I need a function that should transform some text into some other text. How do I handle scoping? How do I handle block elements vs. inline elements? How do I handle escaping? Can the solutions to these problems be reused, or is it a one-off kind of thing that can be hard-coded in one place?

I ran into all of these problems after I had already written several tests. Everything worked, but the design was crap. There was no way I could handle a nested element (like say, a string of bold text inside a list item). I had to completely rethink my design. The amusing part is that the tests did not change, only my design. TDD utterly failed in influencing my design.

It could be argued that my tests were not good enough. I would argue that my tests are fine. The actual implementation of the engine is not something I care about. I don’t care if use a scope stack or if I keep track of nested elements in a different way, which is why my tests are only interested in results, not design. I could write some tests that look like the following:

public function testBoldIsAddedToScopeStack() {
  $wikitext = '__bold text__';
  $this->wikiEngine->toHtml($wikitext);
  $this->assertContains(array('type' => 'strong'), $this->wikiEngine->scopeStack);
}

Oh wait, that’s an absolutely terrible design, for several reasons. First of all, the scope stack should not be publicly available. I suppose I could add a public scopePeek() method that just returns the last pushed scope, but why? To satisfy a unit test? Testing should influence design, but you shouldn’t sacrifice design for testing. Don’t make methods public because you can’t test them otherwise.

Secondly, toHtml() is not incremental. When I pass text into it, I want HTML returned. I can’t just parse half of it and then check that it was parsed correctly; that makes no sense for a wiki engine. There isn’t ever a time when you would want to parse something halfway. Again, I’d have to sacrifice design to satisfy my unit test. That’s not going to happen.

Another solution is to just not close the scope, something like this:

$wikitext = '__bold text'; //no closing "__"

However, I want the engine to automatically close scopes when it reaches EOF. So the toHtml() method does that at the end automatically, which means that after I call toHtml() the scope stack will always be empty. I could move that functionality into another public function, but why would I want to expose that functionality publicly? There’s no reason. I always want to close scopes; I don’t want that decision left up to the implementer of the wiki engine.

In the end, there was no way for me to test that a scope got pushed onto the stack correctly. In fact, I realized that I really didn’t want to test that anyway. What if I wanted to change the scope stack to a queue? Then I’d have dozens of breaking tests because now the internal data structure is FIFO instead of LIFO. Is that something that should be tested? In my opinion, absolutely not. A long as the parsing works correctly, I don’t particularly care about the internal data structure of the engine. If performance is a concern, I can write tests to verify that parsing some hideously long whiny anti-TDD article takes x amount of seconds at the most. Then if a change to the internal data structure causes that test to break, then I know I’ve got something to fix. In that way TDD could influence my design, but up front, there’s no test that could have told me what my design should look like. I had to analyze problems that were hidden to the public interface and solve them without tests.

This seems a rather contrived example, but it’s an example that I encountered while trying to employ TDD to help me write some code (IRL, as it were). The fact is, this methodology just didn’t work for this problem. It was creating hindrances and forcing me to sacrifice a solid, safe design for the sake of testing something that didn’t really need to be tested. And it didn’t even give me the help I needed, which was how to construct the internal engine so that nested elements were rendered correctly. The fact is that I needed more experience in parsing engines before I could confidently design a parser that correctly handled nested scopes. This was something that required some trial and error before a design that solved the problem emerged. TDD wasn’t going to give me that no matter what kind of tests I wrote.

Conclusion

I’m not here to bash testing. I’m all for testing, in ways that might surprise you. I’m all for testing in ways that make people develop better. Some people just aren’t suited for TDD, and not every problem requires a unit test. In most cases, common sense will solve more problems than writing a test ever would.

And if anyone actually looks at my wiki engine, I had specific goals in mind, which is why it’s shoved in one giant class and uses arrays for stuff instead of objects. I don’t want to hear it.

In Review: A History of Suck

In the early 90s, it was all about Netscape Navigator and its little ship helm logo. Anybody who was in junior high in the 90s should have seen it. Then, while Netscape basked in its glory, doing nothing to improve itself, along came IE and the little blue E that we’ve all come to know and love despise with the wrath of a thousand suns. Netscape pretty much disappeared, largely due to the fact that the early IEs were much, much better, and also because everyone started using Windows, which of course shipped with IE (since it was made by Microsoft).

The pinnacle of browser beauty culminated in the advent of Internet Explorer 6 in the late 90s, and pretty much spelled the doom for Netscape, which hadn’t been significantly improved for 6 years. You could look at futhermucking PNGs with IE! How could Netscape possibly compete with that!?

Anyway, IE and Microsoft enjoyed its reign as king of browsers, until Netscape realized they had no hope of ever competing because they were ugly and lazy and stupid. So they sold their souls to the Mozilla corporation, which took out all of the good stuff in Netscape (the Gecko engine), and left the suck to rot in versions 8 and 9. They created Firefox, which hipsters and linux geeks the world over have heralded as the second coming of Christ. Firefox basically was just a way for nerds to assert their superiority over other nerds by name-dropping it. Because everyone knows that if you haven’t heard of Firefox, you can haz a n00b. Kind of like what I did with RockMelt several paragraphs ago. Try to keep up.

Meanwhile, a bunch of Norwegians, in true viking style, started their own browser called “Opera”. I can only assume they named it something so lame because of the language barrier. Opera began being used by an even smaller clique of nerd know-it-alls than Firefox. They are even more annoying than their Firefox counterparts, albeit less vocal. Opera proclaimed a love for standards-compliant (an admirable goal), lightweight, portable browsers, and they pretty much succeeded. Unfortunately, nobody gives a crap, because it looks hideous.

Back at Microsoft, the genius engineers behind IE6 were enjoying their throngs of groupie women, failing to realize that in the last 10 years things have actually happened! Say what!? IE6 is a horrible, horrible abomination? I thought we could just build an application and then let it stagnate for a decade and it would still be awesome! How did we miss this!?

Microsoft scrambled to alleviate the most vocal of the complaints against IE6 (“no tabbed browsing!? what is this, the 12th century? Firefox is safer LOLZ”). IE7 came out, to no buzz whatsoever. Since all the people who knew how to use the web were already using Firefox (all 20 of them), and most people turn off automatic Windows updates as soon as they plugin their computers, IE7 was pretty much not adopted by anyone. All it really did was give web developers one more browser to test. Granted, in terms of standards compliance, it was far better than IE6 (transparent PNGs gasp!), but it was still worse than Firefox 1.5. And Opera. So nobody was converted, but frankly, that wasn’t really the goal of IE7 anyway, because IE still had 95% of the market share anyway. They were still sitting pretty, until…

Mozilla Add-Ons, or How Firefox Lessened the Suck

This was Mozilla’s most brilliant breakthrough, and frankly, it’s the only thing that’s currently keeping people from switching to a browser that doesn’t require 300MB of memory to sit idly. Mozilla created this thing called XUL, but didn’t put it to good use until they created the addons site, and people actually started using it. Suddenly, the browser wasn’t just an application, it was a way of life. The Firefox bigots finally had a solid reason why their browser was better: it was customizable. In a way in which pretty much no other desktop application was. It really was and is still a remarkable amount of genius. Firebug is the only only that reason I still use Firefox. It’s bloated, slow, resource-intensive, ugly, and its users are among the most annoying on the internet, but it’s the only way I can actually debug anything on the web.

Meanwhile, in Microsoft Land, IE7 was stagnating (surprise). Business managers are mostly Nazis (Godwin’s law) and don’t want anyone browsing anything besides their intranet and/or SharePoint, so they had no reason to allow their underlings to upgrade their browser to IE7. That hideous rite still rages on today. In Norway, Opera was developing rapidly to the tune of CSS3 and standards compliance, but nobody cares about that besides web developers, and they weren’t about to leave Firebug behind. Not to mention the fact that they were still verifying that their websites are IE4+ compatible, so any technology more recent than an animated gif was not used anyway. In version 9.5/6, Opera released Dragonfly, their own version of Firebug, which was a giant step forward, but still much worse than Firebug. Nobody was converted. The market share had shifted slightly in favor of Firefox, but IE still held a commanding 4:1 lead.

Google Starts Sucking, Too

Then, suddenly, a new player emerges! Google enters the fray with Chrome, a brand new browser!… Except that there wasn’t anything new or innovative about it. The one nice feature that Chrome had was that each tab was its own process, which meant that while Flash was busy crashing in one tab, the other tabs would independently and cheerfully continue to load…. Until they eventually crashed as well. Chrome captured approximately 2% of the market, which is actually pretty impressive for a browser that has nothing to offer, besides the coolness of its brand. That figure is even more impressive when you factor in how it was only available on Windows for over 6 months.

And here we are, in 2009, with about three browsers to choose from, all with huge, gaping flaws. You’ll notice that I left Safari out of this little anecdote. That’s because it was an egocentric history of browsers, and I’ve never used Safari except for testing, and marveling at how incredibly difficult it is to turn on the JavaScript error console (defaults write com.apple.Safari IncludeDebugMenu 1: are you %@#!ing kidding me!?).

A Full Circle

So, why did I go through all the trouble of outlining this? My negativity towards browsers is universal, as I’ve sampled all of the major ones and a few of the minor ones, and they all have one thing in common: sucking. The world of technology is evolving. Even though the open source community is strong, all of those people have day jobs because they can’t make a living by writing awesome software. They write awesome software on the side while they support their families by implementing SOA through REST visa vis SaaS. The software industry is a wave of fads and trends that executives latch onto to try and be the next Google, despite the fact that companies like Google never employed such empty things like SOA. Well, maybe they did indirectly, but that was never their strategy. Every developer who has a job now is a slave to these trends, even when they’d rather not be. Money and greed rule the day; in any industry, really. It’s the one downside of capitalism: it always seems to morph into pure greed.

So, allow me to come full circle on how the the browser wars are similar to the trials and tribulations of the software industry. The new waves of browsers are very similar to how non-techie executives would mandate that a software application would develop.

Firesuck

New features in Firefox 3.5 include one-click bookmarking, an improved address bar (awesome bar), something about tabs, better memory management and session restore. Useful features, sure, but where’s support for CSS3, or improved stability of Flash, or a faster rendering engine, or more standards-compliant HTML rendering? Besides improving the memory management, they were clearly more focused on improving the user experience than improving the actual software.

Not that improving the user experience is bad, but when a YouTube video causes Firefox to lock up for 30 seconds, that seems like something that should be fixed before, say, a more convenient way to bookmark pages. I mean, who even uses bookmarks anyway? I have like four bookmarks (all to login pages for paying my bills online). There’s only about 10 sites that I visit on a regular basis, and I don’t have trouble remembering the fully qualified domain names of 10 sites.

Unite the Suck

Opera 10 introduced Unite, which basically turns Opera into a web server. Kind of cool, I guess, but how trying to take some competition away from Firefox by making Dragonfly not the slowest piece of tripe ever? Or use a font that doesn’t look like it was created by a three year old with a box of crayons? Or make the default skin less hideous? Or support JavaScript features past version 1.5? And if someone is actually smart enough to know what a web server is, they’re probably already running their own web server, and are not going to relinquish control to a web browser.

I’m Feeling Sucky

Google recently announced that their new operating system will be available in 2010 sometime, which is basically a wrapper around their browser. A novel idea, but why I would leave my current operating system for one that’s based around a browser that I don’t use? Maybe their idea will work, but I don’t think people are quite ready to turn their computers into a giant, fancy web browser. More importantly, I don’t think the web is ready for it. Connections are too slow, servers are too easily assaulted, and web applications are too unusable (compared with desktop apps) that being as productive on the web as you are on the desktop is still 10 years away.

This guy says it pretty well, with some MSPaint-inspired graphics to help you learn. Because learning is fun!

The Conclusion

The next generation of browsers need to focus on delivering content in the easiest, fastest and least painful way possible. I would happily give up 90% of the features in Firefox if the application never crashed. Firefox crashes so often that it has its own built-in crash reporter. I might use Chrome exclusively if flash didn’t crash the browser 10% of the time. I might use Opera if Dragonfly was slightly usable. I might use Safari if… well, I’ll never use Safari. I might use IE if Microsoft didn’t insist on deviating from every known web standard.

RockMelt, like Chrome, seems to be focusing on bridging the gap between desktop and web. Why don’t they just focus on fixing the problems with all the other browsers? What if they made an easily debuggable, solid, secure, fast, easy-to-use, lightweight browser? Instead, we’re probably going to get another Opera Unite, with the absolute latest in bookmarking technology. We’ll be able to bookmark freaking everything! Our lives will never be the same!

Plz.

I appeal to the browser makers: stop giving me new features, and fix the stuff that is already broken. Right now, nobody is winning. Let the users win the browser wars.