Component Based Browser

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:

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:

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.

EditText of this page (last edited May 22, 2008) or FindPage with title or text search