A component browser would be a standard tool alternative to HTML more geared on components.

As this page is quite old - we see now that more browsers are indeed becoming more compentized (installable flash components, quicktime components, and such).

---
A Component Based Browser is a browser that would use components like editboxes, listboxes, buttons,  RTF widgets, grids, menus, plugin components, (even HTML widgets,  even though that's what component browsers are recursively trying to replace) etc. It differs from the current (as of 2004) 'html' browser in that:
 
*it talks to a server and receives data, but parses the data to components, whereas an HTML browser basically parses all the data in a very limited 'HTML widget'.
*offers a user interface rather than an 'HTML interface' or 'web interface'. i.e. instead of a user reading an HTML document in the browser, he/she could download RTF files directly in an RTF component, download instructions for placements of buttons, panels, on that RTF widget, TXT widget, Listbox widget,  etc. which take the user to other components, open new components, (instead of hyperlinks).
*Component browsers are extendable not through what some "HTML standard" offers,  but rather with what the OS offers. Anything the OS can do, the component browser should be able to do, when someone implements it.
*Things like popup menu's can be customized for the web 'site', rather than being limited to the HTML browser's pop up menu. Instead of using tables, one could use a listbox or gridsheet to display data. Instead of using cookies, a web site visitor could use normal files in a specified directory. 
** Security issues however, would be need to be considered 
*acts like a software application instead of an HTML application.
*uses more of the real languages (any language that is offered on the OS, really): C++, C, ,Perl, Pascal, , etc. to display and organize the application (not just HTML and server side HTML wrappers).
*Security may be an issue to think about,  since HTML is a very "read only" system, and components offer more interaction with the user than any HTML browser will ever dream of. However a component based browser can still use server side languages so that files, instructions (code), are hidden from users. 
*Still communicating by HTTP
*Instead of building HTML websites, web programmers can now build actual web enabled software applications (but load up in a generic Component Based Browser). Programmers could also port their application to their own executable if they felt they wanted to offer an even more custom web service,  due to them using real languages like C++, C, ,Perl, Python, Pascal, , etc. (not HTML).  Instead of separating offline coding projects from online coding projects, the code is more similar now.  
*Making an offline software application port over to a "website" is not a joke, unlike what HTML currently offers (although it is getting more powerful and reliable these dayts with Ajax and Javascript, a website is still indeed a messy a joke of HTML these days. CSS has made it slightly better.). 


----
Not to be confused with ObjectBrowser

----
''Sorry I am think. I would have thought at least OpenSource MozillaFirefox with its XpCom implemented addons function as well as any ComponentBasedBrowser described above. And on that, so is MicrosoftInternetExplorer with the dreaded ActivexTechnology addons. Please tell me the material difference for users of RichInternetApplication? -- dl ''
----
From what I have seen dl, (I've rarely visited pages using these technologies) the websites are still based on HTML, and you just request these activeX objects and etc through the HTML. Whether through HTML forms (buttons) and links, or what not. The website is still based on HTML and then the user is just linked out into some other object later. There is no design from the ''ground up'' through components. Most of what we see for components are just add-on HTML after-hacks. 

I have for example visited anti-virus websites which allow me to do a virus scan right within the website through activeX, but they are extremely slow and still based on an HTML "to get me in" to their activeX. They seem to be more "add-on hacks" from my standpoint, rather than a ground-up well thought out design. Tricks such as ActiveX are of course not cross browser compatible usually, either.

I once whipped up a clone of one of my websites in a software application instead of HTML, actually. 

A software application that talks to the server is all a component based website is, but the component based browser I see as the 'future of the web' should be a generic software application that caters to all people and operating systems. Everyone could create a web component and display it in a component browser. ActiveX and the above mentioned technologies don't seem to support a lot of browsers and the last time I was at an activeX website, again it was a painful experience. 

I see activeX as a failure. 

Some web based software apps actually already exist which don't use ActiveX, JavaScript, Java Applets, VBscript, DOM, DHTML: 
*E-mule, 
*Ebay TurboLister 
*ml-donkey
*KPackage for linux. Gets information from the net without using HTML

These above applications are not generic component browsers, however. They are separate fragmented applications that don't follow a component browser standard. But they offer some interesting ideas, since they connect to the net and browse files through P2P or through servers of some sort. My thinking: a user needs a more generic "ComponentBasedBrowser" to fire up 'web applications',  and not these fragmented individual thin/fat client applications. A browser just offers organization and a common place to type in "url addresses", along with offering a common component framework to make it easier for the  software applications to be hosted. 

From history, we learn that a convenience oriented web user is not going to download and install a different software application for each website they visit - but in a component browser they would load the components through URL's or a similar resource system.  One generic component browser displays each website. Hence, nobody would need to download a separate software application for each software web application they use. They should visit them through a 'online software application browser' or what I coined as a 'ComponentBasedBrowser'. 

----
A ComponentBrowser is like a thin client. But since thin clients vary, they are not generic enough. A ComponentBrowser is a client that connects to the internet like a web browser. But this web browser does not have to parse HTML. Really, an HTML browser is just a client connecting to the internet, and it happens to only deal with html. A ComponentBrowser connects to the internet and can deal with ComponentBrowser language, compiled binary files, or even html files. It doesn't just download HTML files and deal with them. It doesn't just run HTML inside the browser. 
----
A ComponentBrowser could deal with binary files. It's binary ability would make a ComponentBrowser much faster than current HTML applications. A ComponentBrowser would not focus only on E-Brochure like documents. It would focuses on components and widgets.  Those components and widgets can run or parse documents them selves.  A component browser could literally create a software application within it just by visiting a URL.
----
A ComponentBrowser is more complicated than an HTML browser, since a component browser can still run html inside it's components.
----
ComponentBrowserMarkup would brainstorm ideas for a language that a component browser could parse. Others will notably be HTML, RTF, and more.  
----

Examples of problems with maintaining HTML and how Component Browser and its languages can solve these problems:

''severe messiness and non-maintain-ability of HTML in a simple CGI application.''
''This application just is simply trying to post some information from a form. That is all. Why does it have to be so messy? I feel it's because the HTML gets in the way.. and that document (html) is not fit for application.''

   '''var'''
    FileA:FileStrList;
   '''if''' GetEnvVar('Ed') = 'yes' '''then''' ''//the signal to edit a page''
   '''begin'''
    FileA:=stringlist.Create ;
    FileA.LoadfromFile('info1.txt');    
    ''//if someone clicks the submit button on the form in the HTML page, we can send a post to AcceptPost1.cgi or wherever.''
    writeln('<form action="AcceptPost.cgi" method="post">'); //post editbox text to cgi program
    writeln('<TEXTAREA NAME="ed1" ROWS=20 COLS=85 >');
    writeln(FileA.Text);//gotten text from file
    writeln('</TEXTAREA><br>');
    writeln('Enter Key Pass: <INPUT NAME="pw" ROWS=1 COLS=30 >');
    writeln('</INPUT>');
    writeln('&nbsp;&nbsp;&nbsp;<input type="submit" name="button" value="Submit"></form>');
    writeln('<hr>');
    FreeAndNil(FileA);
   '''end;'''

Using a component browser, the code could look something like this:
   '''var'''
    FileA:FileStrList;
   '''if''' (Env.Name := ed) '''and''' (Env.Message = 'yes') '''then''' ''//the signal to edit a page''
   '''begin'''
    FileA.Open('info.txt');
    ''//if someone clicks the submit button on the form component, we can send a post to AcceptPost1.cgi or wherever.''
    Form.Action := 'AcceptPost1.cgi';  
    Form.Method := 'post';
    ''//instead of a <TEXTAREA>, it's an Edit component on a form...''
    '''with''' Form.Ed1                    '''do begin'''
                 Text := FileA.Text, 
                 Rows := 20;  
                 Cols := 85;
                 Left := 5;   Top := 7;  Height := 20;
    '''end;'''
    Form.Label.Text:='Enter Key Pass: ';
    Form.Input1.Rows := 1, 
    Form.Input1.Cols := 30;
    Form.Button1.left := Form.Button1.left + 3; 
    FileA.Close;
   '''end;'''

----
Some people might question: 

''But what about asp.net or Php Dot Net,  ASP Dot Net, etc. They use components don't they?'' 

Answer: Those are still wrappers built on top of HTML. A component browser could load components directly via more direct approaches without going through complex HTML wrappers. ASP.NET or php classes are simply wrappers for HTML, not individual from HTML.

----
As this page is quite old - it is interesting to see that now in 2008 a lot of Web 2.0 ideas are actually similar to some of the ideas listed on this page, along with macromedia flash plugins, etc. However, Ajax and browser plugins today are still based on HTML after-hacking - instead of a ground up new design as recommended on this page many years ago.