SourceForge Logo



Why another browser? And why in TCL?

BrowseX  addresses 7 specific problems:
Problem 1:
There isn't really a lightweight, cross-platform browser available. With Linux for example, there's only one frames capable browser: Netscape, and it's big, ponderous and really not maintainable. That and Netscape is now owned by AOL.
Problem 2:
Using the Web is easy, but developing for it seems problematic. There are many overlapping standards, and client side scripting just isn't reliable. In the end, Web developers have trouble delivering even moderately sophisticated apps, partly because the Web-Browser cage is just too confining.
Problem 3:
There is a plethora of languages involved in the end-to-end delivery of Web applications: C/C++, Perl, Python, HTML, XML, Java, Javascript/Jscript/ECMA/J++, Shell script, PHP, BAT, VB, ActiveX, COM, C#, and PL/SQL. This is of course just a partial list.
Problem 4:
When something goes wrong at the browser side, even crack programmers are pretty much helpless.
Problem 5:
There is virtually no crossover between developing standalone applications, and web deliverable/enabled apps.
Problem 6:
Databases play a central role in the Web, but browsers themselves have no native direct DB connectivity.
Problem 7:
There seems to be no simple but universally available HTML macro language for use with browsers and servers. Is simple file inclusion and string defines really so tough.
And there is probably more. What BrowseX  is trying to do is address these problems. What it is not trying to do is become the smallest, or the fastest, or the most standards conforming browser. In fact, BrowseX  is not really trying to compete head-on with any of the existing browsers, each of which are truly fine pieces of software in their own right. Rather, it is about looking at the problems from a new perspective.

Traditional browsers started life as HTML rendering engines and then layered on more and more standards and extensions in an attempt to expand client side capabilities. With BrowseX , I have in fact done the reverse. Starting with a rich, stable, extensible GUI capable environment (Tcl/Tk), a browser is written therein which can render most web pages reasonably well. Then many areas of functionality (embed/scripts and a macro language) are backfilled by leveraging Tcl. If you look at the BrowseX  feature set, each of the above problems is engaged.

Put Another Way ...

Browsers have become the single most widely used software. That said, the general level of satisfaction with browsers has not been particularly high. No where has this been more true than from the Web developers point of view. This is not meant to impune the functionality of existing browsers, but rather it is more a function the black boxes that our browsers have become.

This is even more the case under Unix where there is effectively only one (frames capable) browser: Netscape. In January 1998, Netscape released into Open Source its browser code base. This induced many (myself included) into thinking that now Browsers on Linux would now improve by leaps and bounds. Unfortunately this has not been the case. Possibly this is because the source for Netscape is rather large and unwieldy, and so modifying it has proven nontrivial. Supporting this observation is the fact that Netscape has aborted version 5 and is embarking on version 6: a virtual rewrite. At the same time, control of Netscape has passed to AOL, which has it's own agenda and timelines.

Now rewind a bit. Browsers initially were intended for previewing HTML documents. There has however been an ever increasing tendancy away from this and towards generalized GUI capabilities. Driving this are Web developers who are demanding ever more freedom on the client side. Animated gifs, Java/Javascript and the Document Object Model (DOM) were the first steps. Initial implementations of Java and Javascript however, were rather unstable so newer, not wholly compatible versions appeared. As well there has been a profusion of new standards: JScript, ECMA, DHTML, C#, and XML. Despite all these standards (or perhaps because of them), Web developers feel hemmed in. On the one hand, overwhelmed by the complexity of learning and using all these standards. On the other, singularly unhappy with uneven browser support and the constraints on what they can and can not do. Simultaneously, the number and variety of "plugins" has exploded. The situation is all becoming rather cloudy and confused.

Then there is Tcl/Tk: a generalized GUI API that has been around 10 years or so. It's widely used for standalone environments on most major platforms. It also does not suffer from web dependant design quirks. And in general, Tcl is easy to learn and extend.

Implementing a browser in Tcl can give access to a preexisting, rich, and stable environment with a plethora of extensions already implemented. More importantly, Tcl has a "Safe" mode which can allow Web pages to execute Tcl in a secure fashion on the client side. Safe Tcl is analagous to Javascript or the Java sandbox.

That's pretty much it, but some additional interesting comments can be made. Most browser functionality is algorithmic in nature and requires access only to a couple of priviledged operations. For example, there is a need to be able to read and write to the cache directory, and to place outgoing socket calls. This implies that the the vast majority of the browser itself could be implemented in "Safe Tcl". The implication is rather stunning. There is no practical reason why a browser could not only be "extensible" but also "dynamically modifiable" even at its most fundamental level. Adding in an on the fly site/content filters for example would be trivial.

Another thing: the dividing line between an embedded app and "plugin" is no longer firm. Applets can be tried and, if to be useful, be saved becoming in effect part of the regular browser functionality.

Copyright © 1999-2001   Browsex Systems Inc