Re: [Jeff Covey @ Freshmeat] We Are Losing the Browser War

From: Dave Winer (
Date: Sun Mar 25 2001 - 07:21:23 PST

He's just figuring this out *now*?

Oy he's about three years too late.

I don't think there's any prior art for recovering market share from
Microsoft. I heard a theory that explains Kleiner investments, they only buy
into things that they can sell to one of the Telcos. They're finished
challenging Microsoft. Too bad, so sad. Sometimes Microsoft doesn't make
great software. (Heh.) This is what happens when you turn over the reins of
a new industry to a neophyte from Illinois or Wisconsin or where ever he was
from. "Oh they're just device drivers," he said. "Get that boy," says Uncle
Bill and the legions of softies swarm, and a couple of years later it's all
over and the browser is legacy and here we go round the loop again.


----- Original Message -----
From: "Adam Rifkin" <Adam@KnowNow.Com>
To: <FoRK@XeNT.CoM>
Sent: Sunday, March 25, 2001 12:24 AM
Subject: [Jeff Covey @ Freshmeat] We Are Losing the Browser War

> It's 2001, and people are advocating taking Flash, JavaScript, and/or Java
> out of the Web. Didn't those languages arise because Web developers
> needed them?
> To see commentary on this article go to where I found it...
> We are losing the browser war
> by jeff covey, in Editorials - Saturday, January 27th 2001 23:59 EST
> Anonymous has had his eye on his Web server logs lately, and is worried at
> the shift in the ratio of Netscape to IE browsers hitting his pages. He
> worries that, if we're not careful, this trend on the desktop could undo
> the progress Linux has made in the server room, and he offers some ideas
> how we could fix things.
> I have been watching It is pleasing to see that Apache is
> increasing its slice of the pie with almost every new report.
> Unfortunately, I have also been looking at Web server access logs, and I
> have been seeing a decline in the use of Netscape with a corresponding
> increase in Internet explorer. That is a problem.
> Without a decent browser, it will be difficult for alternative operating
> systems to remain viable. We owe the old Netscape a great debt of
> for releasing a Linux version of Netscape so early on; it quickly made
> a viable desktop, and later did the same for the other free Unices. Only a
> few wise men seem to realize this.
> To paraphrase Linus: "It's the desktop, stupid." Backend infrastructure
> be replaced quickly; user desktops cannot, so we are vulnerable to being
> leveraged out of the server space. Microsoft could use its increasing
> dominance at the client side as a wedge to lift Linux out of the server
> room. FreeBSD's motto "The power to serve" means nothing if it can't serve
> up the proprietary or patented protocols spoken by the clients.
> We need some nontrivial presence on the client side to prevent the
> bastardization of protocols and file formats. Don't think that just
> a file contains the pixy dust of XML it can't be made proprietary. I am
> convinced that there are people patenting DTDs as I write this.
> In the newer Linux distributions, we have an operating system capable of
> holding its own on the desktop; now we need a viable browser.
> Netscape and Mozilla have lost their way. Netscape had its air supply cut
> off by a better-funded opponent. Mozilla... well, I am unsure what to make
> of it. I am guessing that when it was released it was a mess understood by
> few. Now a couple of valiant individuals have undertaken the thankless
> of cleaning it up. They might even be succeeding.
> Unfortunately, it appears that Mozilla still carries the legacy of some
> management decisions. I think (and I might be wrong) that the plan was to
> turn Netscape into an operating system of its own. In a horrible way, they
> have succeeded; Mozilla is about as bloated as some of the largest
> systems.
> The problem is not only that Mozilla is big and slow, removing it as the
> browser of choice for older and embedded systems (exactly the place where
> Linux is a viable contender), but also that it is difficult to understand.
> Heck, simply compiling it can be tricky. Getting up to speed on Mozilla
> appears to be difficult, so contributing is difficult.
> I believe that the strength of the Open Source movement is that its
> components are highly modular. Forget the big projects such as gcc or the
> Linux kernel which need to be run by experienced wizards. Most Open Source
> projects are small; a talented programmer can understand the entire
> If contributers get in on the ground level, they too can keep track of
> own part. The modularity is much stronger than the (IMHO rubbish) OO
> methodology advocated by dubious software engineering textbooks. An Open
> Source system breaks into objects at the executable level -- a level which
> both the developer and system administrator understand -- not at lower
> levels where it slows down development and execution.
> An FTP server is an object. An FTP client is an object. The interface is
> well-defined in a couple of RFCs. Don't like a particular server? Plug in
> your own! It doesn't matter if the client is written in C, Python, Perl,
> Intercal. It doesn't matter how the internals of the FTP server are
> structured. It's an object. No need to rely on inconsistent mangling of
> classes in obscure libraries with undocumented interfaces and side
> No need to worry if the object fails; if the FTP client crashes, the
> keeps running. No esoteric marshaling or transport mechanism tied to a
> particular language; objects communicate via vanilla Unix pipes or TCP/IP.
> This point is really important. As long as the maintainers understand the
> internals of their object/package and there are not too many dependencies,
> Open Source works beautifully. Don't like sysvinit? replace it with
> simpleinit or minit. Think you can do better than syslogd? Replace it with
> syslog-ng or idsa. Think inetd is vulnerable to DoS attacks? Try xinetd or
> tcpserver. Don't like bash? Try zsh or tcsh. Think wu.ftp is an exploit
> waiting to happen? Install oftpd or troll ftpd. We have an amazing amount
> biodiversity (or should that be cyberdiversity?.
> Open Source objects seem to do best when a replacement can be written by a
> smart teenager during summer vacation or as an after hours project of an
> experienced sysadmin. The replacement need not do all the original does
> won't be bug free, but it should be enough to show promise. Later, it will
> become large and nastier, but the skeleton will be the same. This is
> probably the core of the Open Source world, even if it means that there
> too many half-finished IRC clients.
> Back to Mozilla. Mozilla is much larger than most Open Source projects.
> Becoming a contributer is hard. Writing a replacement is harder. The
> at the W3C appear to have fallen into the same trap as the people who
> C++, and have added more and more baggage. No doubt they were under
> to formalize the extensions added by Netscape, Sun, and Microsoft, but
> still...
> A browser is no longer something that speaks HTTP and renders plain HTML.
> now needs to do Javascript, cookies, Java, ActiveX, Flash, frames,
> style sheets, and XML disasters. Building a replacement browser is no
> a vacation project for a couple of smart teenagers. Oh, sure, none of the
> extensions are essential to a browser, but only a minority of sites don't
> make use of at least one of the features.
> So, we have a problem. Mozilla is too large to attract casual programmers
> the numbers it needs, and the Web itself consists of too much cruft. The
> entry cost of the Web browser business is considerable. Large companies
> large entry costs since it keeps out the smaller players, including the
> volunteers. Microsoft can throw programmers at Internet explorer.
> Programmers at large corporations have to wade through spaghetti code
> whether they like it or not, and paid programmers can spend their days
> regression tests. Volunteers like doing neither of these things.
> The free software community desperately needs a decent Open Web browser to
> stave off the .net effort. It is probably the biggest software gap we
> Solving it won't be easy, and losing it might be fatal.
> I have thought about a number of approaches to the problem. One is to have
> more people working on Mozilla. Mozilla is being cleaned up -- some
> subsystems are probably quite solid by now -- but it is still large and
> slow. If you think you are a hotshot programmer, consider helping out
> Mozilla. If Mozilla makes a comeback, you'll be a hero.
> Another method is to simplify the Web. We need to lower the entry costs
> the people writing alternative browsers. Web sites need to lose the Flash,
> the Javascript links, and the font tags. That too is hard work. If you
> a Web page, resist the temptation to add clever stuff to it. Disable
> Javascript, Java, and remote fonts in your browser. Ignore sites which
> on these things. If you visit pages which do, drop the author a line and
> tell him about it. Email is best. If you can't be bothered with email, try
> the approach I use: I request links such as
> r/ or in the
> hope that somebody reads the error logs.
> Making the Web simpler is difficult, but we have a window of
opportunity --
> cell phones and other wireless browsers are still too small to run a large
> browser, and WML is (rightly so) falling from favour. A restricted subset
> HTML might just work. Maybe the cHTML used in Japan might be a good
> candidate (do we have a Linux cHTML browser?). We could kick up a stink
> about accessibility -- put pressure on sites to keep it simple so that
> and partially sighted people have a chance at viewing them. Emphasize the
> risks of running Javascript and Java on the local machine. Point out the
> risks to ecommerce sites. Point out the savings of turfing the Web design
> division to the CEOs of failing dotcoms, letting them spend more funds on
> the backend and order fulfillment. Inform people that fancy Flash pages
> Java applets won't be viewable in 20 years. Lead by example. Full marks
> freshmeat using HTTP authentication and not cookies. Use the "best viewed
> with any browser" button. Focus on content, not looks.
> And then there are the alternative Web browsers. Konqueror is showing
> promise. Zen has the right approach. Express might be worth taking up
> Maybe we could learn from the NCSA/Apache experience. When NCSA httpd was
> longer viable, some smart people put together Apache. Apache has something
> important going for it -- it can be easily extended. It might be worth
> trying the same for a new Web browser. Make it simple. Use wget to fetch
> pages. Pipe it to a simple caching program. Have the caching program pipe
> the output to a simple renderer -- the GTK HTML render or maybe a diet
> gecko. Control the pipeline from a simple X interface, and we have a Web
> browser. X has a neat feature which lets a window of one application
> the window of another. One of the people who designed X wondered why it
> wasn't used more often. Think about it -- for an HTML form input box,
> instead of using a crummy text widget, we could spawn an xterm the exact
> size of the text box, and use vim or any editor to fill out the form. It
> would be nice. It would be easy to maintain. Crashing the editor would
> the browser running.
> In the last few years, the Open Source community has made good progress.
> now have several impressive operating systems. Apache is the most popular
> Web server, but we need to have a viable Web browser, be it a working
> Mozilla or a lighter alternative. Without it, we don't stand a chance
> against .net.
> ----
> Adam@KnowNow.Com
> Let's be serious. The web is getting more complicated. Designers like
> are demanding more control over presentation. Consumers are demanding more
> rich, interactive, and immersive experiences. And as complete as CSS, DOM,
> JavaScript, and HTML are, they are still losing ground quickly to
> Macromedia's Flash technology - an inferior, binary, and proprietary
> (everything the web was never supposed to be) - because it offers
> and designers exactly what they want.
> But complication is not necessarily a bad thing. Space exploration is
> complicated. Microprocessors are complicated. Hell, my car is
complicated -
> a beautiful, efficient, yet terribly complicated synergy of a hundred
> different technologies.
> The point is that the web, which is essentially a completely free market,
> will not be held back because progress isn't "fair" to open-source
> development. Consumers will continue demanding better displays. Designers
> will have to create them. Technologies which deliver will survive, and
> that don't will die.
> I work with designers who will do anything to get the right effect. We've
> created kluges so thick they'd make you sick to your stomach. We've
> animated individual Flash objects around the screen with javascript and
> layers to get a particular effect. To suggest that such a breed would give
> up even an ounce of control to subsidize open-source development is just
> plain dumb.
> In place of emailing webmasters and thinking up snappy things to write in
> bogus HTTP requests, I'd like to see the open-source community rally
> and support Gecko. I'd like to see an improvement in DHTML performance,
> a plugin to support XSLT. Fixing those weird scrollbar problems would be
> nice too...
> There is a war for the web, but it's not against who you think. No matter
> what you think of it, Flash is gaining ground. Web authors are using it
> more and more things that are difficult or impossible to do with
> cross-browser DHTML. And in contrast to the elegant and open nature of
> Flash is very proprietary, very binary, and very presentation-friendly. So
> if you want to fight the real enemy, upgrade to a decent browser and
> "demand" the efficient use of standards. Then, check out some of the best
> Flash implementations and learn how to match them with standards-based
> CSS, and JavaScript.
> In the end only consumers - and the designers and engineers who give them
> what they want - can win. If developers want a standards-based web, then
> they must expand and improve the standards. Lowering consumer expectations
> is impossible, and a complete waste of time.
> -- Aaron at

This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:14:54 PDT