Thank you for covering the browser market. Many users don’t understand that they have a choice of browser and by discussing the alternatives you help promote a healthy ecosystem and honest competition. In covering this important topic it’s easy to be loose with terms, but some shortcuts cross a bridge too far. A few are listed here here along with a rubric to help you understand why they make you (and your esteemed publication) seem less interested in hard facts than I’m sure you are.

“JavaScript rendering”

As I’m sure you know, JavaScript (aka “ECMAScript”, aka “JScript”) is a programming language, not a UI toolkit or rendering technology. Yes, JavaScript drives the UI of many modern web apps like GMail and Google Maps, but it does so through a technology called DOM. DOM is not a part of JavaScript, it is instead bolted on to JavaScript by the browsers. “JavaScript rendering” would be a non-sensical thing to say even if you were describing the time it takes to build up a user interface. But I rarely (if ever) see such a story. Instead, this rhetorical abomination most often shows up in discussions of JavaScript benchmarks. These benchmarks work very hard to ensure that they aren’t affected by any DOM or UI operations. They test everything but rendering. In your defense, there is a strong correlation between faster JavaScript execution and faster rendering. But they are not the same thing. Best to just stay out of this particular gutter.

Acceptable alternatives: “javascript execution”, “javascript performance”, “DOM rendering” (but only when discussing things that measure DOM performance).

“Plugin”

Strictly speaking, a browser plugin is a bit of native code (written in C or C++) that speaks a particular set of ActiveX and NPAPI interfaces and registers itself with browsers in a particular way. This definition might as well be written as “plugins are magic”. The best known items of this class are Flash and Silverlight.

What you need to know is that there is an emerging class of things that users can install into their browsers which are similarly magical but which are not plugins. These things go by different names: “extensions”, “add-ons”, and (confusingly) “toolbars”. I’m sure there will be others. You can think of these things as being interchangeable with each other but not with “plugins”. So how do you tell which is which? A good rule of thumb is that if a web page works fine without you installing it, it’s an extension. Otherwise, if you need to install something for the page to work, it’s a plugin.

Acceptable alternatives: “extensions” (preferred), “add-ons”, “toolbars” (overly specific, may confuse).

“HTML 5 support”

This is one for the nag file since you’ll need to revisit this topic in the future. The important thing for now is to be cognizant that there isn’t yet a real “HTML 5″. Yes, there are various drafts, and yes, some browsers are doing a great job of implementing these new features ahead of formal standardization. But it’s not done yet. Saying today that something is an “HTML 5 application” or that a browser has “HTML 5 support” will cause you problems. Nobody wants to explain how what was touted as being “standard” one day became “proprietary” the next. The safest course of action here is to simply talk about “the upcoming HTML 5 standard” or “advanced web applicatons”. HTML 5 is a powerful brand and there’s going to be an enormous amount of haggling over its meaning for years to come. Best that discussion not include references to your stories.

Regards,

Alex Russell

Take, for example, ZDNet’s gutter-to-gutter coverage which, I’m afraid, simply ends in the intellectual gutter. Larry Dignan’s piece does the profession no favors by simply recycling the tried-and-true blogger formula for traffic generation:

I know about X, Google did Y, which is clearly *all about* X

The best of this flavor of “story” approaches the quality level of a plausible but objectively outlandish conspiracy theory, often pulling together bits of fact with a healthy dose of wild speculation (journalistically couched as the unfounded and unquestioned opinion of some supposedly credible third party).

ZDNet piles all aboard the loony-bin express with Paula Rooney’s “analysis” piece, helpfully asking the non-question “is this a prelude to Google acquiring Mozilla?”. In what twisted alternate universe would this wild, hair-brained straw-man garner a full ‘graf in a legit online publication, let alone a respected print daily? A small, tiny dig into the strategy of Google’s Mozilla search placement deal and the infrastructure of the Chrome browser would lead anyone (and everyone) to conclude that Google’s interest here is in keeping the browser a viable platform by any means necessary, not that they would ever gain anything by “acquiring” MoCo or MoFo (an even more nutty idea, since it would be difficult for a 501(c)3 organization to transfer resources and assets to a for-profit entity anyway).

The strategic and tactical incoherence continues with the daringly dumb quote:

Larry Dignan of ZDnet suggests that perhaps Google and Mozilla are working together as a tag team to defeat Microsoft’s Internet Explorer, and that Google may perhaps purchase the Mozilla Firefox crew and integrate the two code bases to deliver a kock out punch to Microsoft’s IE. Will Mozilla become Google browser labs? Given the close cooperation of the two projects, it’s more than possible.

Ignoring the incestuous and dubious use of a fellow reporter’s speculation as a source for an article, the idea that the Google would want much (if any) of the Firefox team (or vice versa) beyond those which they already pulled away. It does Google no good to reduce competition in the browser space, and one can imagine that there’s no love lost at Mozilla over Chrome, particularly after Google shunned the Firefox rendering engine, replaced the JavaScript engine, and re-built the entire visual and end-user experience from-scratch with completely different technology (i.e., not XUL). Good sourcing might have fleshed out the idea and perhaps even made a case for the theory, but alas, that seems far too much for ZDNet to produce on deadline. I mean, it’s not like they cover technology for a living…gosh, that’d be embarrassing. Quick tip for the next time they want to write this story: Google just became “Google’s browser labs” after giving Mozilla a good long run at it. They’re still strategically aligned, but Google seems impatient and is likely most interested in having direct leverage in the browser space (first via Gears and now Chrome) instead of the indirect influence they exerted over Firefox when it was still “Plan A”.

The coupe-de-disgrace belongs to PC World, though. After laying out 7 sensible, but “we’re just cribbing this from the press release, really” reasons to like Chrome they proceed to indulge in 7 forehead-slappingly idiotic reasons why you might consider something announced as a Beta to be…well…a beta. It feels kinda dirty just linking to it. Luckily, the PC World crew was able to get it together enough to publish a scoop-free “I played with it for 5 minutes” piece that WaPo wasn’t embarrassed to run, although the “like being there!” aspect really looses it’s punch when anyone can download the beta and, well, be there.

At least with Wired you know you’ll be getting fawning access journalism without the pretense of objectivity, but damnit, it’ll be well written and vaguely cogent.

I won’t even start on the blags. It’s to depressing. I’ll except Ajaxian and Philipp Lenssen here as they added some useful background from the inside perspective and scooped the story (respectively). “Citizen journalism” has a loooong way to go before it earns a place in the 4th estate, though.

Why, oh why, can’t we have better tech journalists?