In defense of browser implementors

After several years of web development, plus two years of C++ programming, I have to confess that I do not understand why web developers sometimes blame browser implementors. In many web tutorials is repeated the expression "it's not rocket science" to denote something that's easy to understand and use effectively. Well, implementing a web browser is something very similar to rocket science, in the sense that we're talking about extreme complexity here, not some fancy effects that you can achieve with some jQuery's plugin.

We're talking about thousands and thousands lines of code, broken down in several components and subcomponents, something that, if downloaded, occupies hundreds megabytes of disk space. We're talking about the inner interaction of components with each other, something that from a simple URL resolution and DNS querying leads to a complete page layout. We're talking about network interfaces, memory management, OS interfaces, interface design, web standards implementation (from parsing to rendering), user interface, widgets, extensions and so on.

What's more, how these web developers who criticize implementors would implement web standards themselves? It's easy to write float: left but it's incredibly harder to make it properly work on a web page. It's easy to use jQuery on our documents, but let's stop just a second and think about how much efforts are required to make $('#test + #foo') select its target element. Now they may say: "Well, this is not our job.". Sure, but why don't you try to help instead of complaining? Why don't you create some useful test case for filing a bug? Why don't you try to analyze a broken web site and report it? Never complain: cooperate.

This is probably the strongest post I've ever written on this blog but I do believe that cooperation is the only way to get the results we all want: better browsers, better sites.