How Much Smaller Could Web Browers Be? 28
geoff lane asks: "Netscape, Mozilla and IE are all large programs capable of many functions which are mostly unused (Mozilla does attempt to shrink its runtime size by using DLLs.) Lynx, Chimera and a number of other browsers are smaller but with significantly fewer functions. A modern browser needs to support Javascript, Java and SSL. It doesn't need to support News, Gopher, FTP or e-mail - all of which have perfectly good applications available already (though there should be a way for the Web browser to sub-contract work to these applications). On occasion I've wondered if I could build a halfway decent Web browser from a few specialist program components (for the display and parsing of HTML mostly) and wget, tied together with shell script or Perl and using external programs for most of the necessary support functions. How small can a usable Web browser get? (assuming we define usable as meaning capable of displaying a Slashdot page reasonably correctly *grin!*)"
I'm using a browser that's just 1.58 meg (Score:1)
Remember OpenDoc? (Score:1)
The idea behind OpenDoc was, instead of having an HTML plugin for your e-mail client, and an e-mail app in your browser, and both of them in your newsreader, you'd have a system-wide HTML rendering engine (say), and a systemwide audio player, video player, etc. In effect OpenDoc components were "plugins" available throughout the OS to any app that cared to use them.
Now I hear people talking about "document-centric computing" and "component app architecture" and I want to smack Apple for killing this back in '95. If they'd just put it in maintenance mode or even "cold storage" it could, today, be a mature, robust technology that would make MacOS X a killer desktop OS.
(OLE, incidentally, just "happened" to appear after OpenDoc; the difference was Apple tried once and called it a failure -- Microsoft is still trying, even though few would call OLE a "success". I wonder how much of Microsoft's dominance comes from simple bloody-mindedness like that.)
CSS a luxury (Score:1)
In other words, for any given feature I listed, I was rating it based roughly on the following criteria:
* How many web sites can I think of that use the feature?
Of those:
* How many won't work correctly without the feature?
(By "work correctly," I mean display the desired information and allow the user to navigate through the site to obtain the desired result.)
You'll note that I didn't list PNG support, even though I use one on my home page. It's a luxury.
Re:Galeon (Score:1)
Re:Opera? (Score:1)
that's a bit drastic (but, exactly what Netscape does if you omit /title or /table)... but they should have produced stern warning messages and bumbled on as best they could.
The other question is, which HTML? what's a browser supposed to do with a DTD that didn't exist when it was released? Would a full-blown SGML parser make the thing smaller in the end? dunno...
Re:What features? (Score:1)
I consider it to be critical too, unfortunately it's usually incorrectly implemented. I did a browser for myself once (tkHTML was the renderer, the hard part as far as I was concerned). Its only scheme was HTTP, enough to talk to Squid to get the others. Saved a hell of a lot of fuss and bother, both in schemes and cache control.
(Oops, no I lie; it also had FILE and my own X-FILE, which would do Apache-like content-type negotiation so I could locally explore my file-extension-less URIs. I also tinkered with SSL but couldn't figure out what the hell I was doing well enough to know if I was doing it correctly :p)
How about konqueror? (Score:1)
While the version that was released with KDE2 and KDE2.0.1 was a bit unstable and had broken rendering (particularily on tables), the latest CVS version is much, much more stable and seems to support everything just fine.
By the way, contrary to popular belief, you don't have to run the full KDE2 desktop environment for it to work, but you do need QT and the KDE libraries installed.
HTML (Score:1)
Galeon (Score:1)
it's easy (Score:1)
Ok, I'll stop now.
--
Re:Opera? (Score:1)
Lose the Java support, and you've got a fantastic browser
Program it in Java and it fits in 4k - HtmlViewer.java [nottingham.ac.uk]. ;-)
(Oh yeah, plus the JDK @ 40Mb
--
Re:What features? (Score:1)
CSS more of a "luxury" than plug-ins and applets?
If CSS were more widely used, the amount of HTML code in most web pages could be much smaller.
---
Re:Opera? (Score:1)
When you've implemented the HTML standards in a browser, then the implementation work really starts. Take a browser that merely implements the standards, and doesn't try to fix up broken HTML. Point it at CNN. Laugh.
Imagine writing a C compiler that had to do something sensible with code written by the kind of have-a-go back-bedroom dilettante Web site authors that most slashdotters will be only too familiar with. "Oh, I know you're not meant to be able to assign a const char* to a function pointer -- but look, Netscape C version 4.02 and later supports it..." (Plus, of course, there's have-a-go back-bedroom dilettante Web authoring software.)
A web browser that just implemented the standards could be teeny. A browser for use on real Web pages needs a lot of complexity to deal with broken HTML. That's why the QNX demo fits on a floppy and Opera or Galeon doesn't.
Peter (architect of the Fresco browser in the Bush Internet TV, ~2Mb including JS but not Java)
Check out OPERA (Score:1)
nick
Sad to say... (Score:1)
For a browser to support the myriad of scripts, plugin's and all that jazz, you're going to be looking at a very hefty download, or a very slim featured browser IMO.
Re:Q: Why does the browser have to support java? (Score:1)
Maybe the Linux version would work, I dunno. Then again, the Linux version (the Sun one, not Blackdown) of the JDK/JRE wouldn't install on our Corel Linux box at work (don't ask - it's a test box), so I don't have my hopes up on that.
err.. (Score:2)
- A.P.
--
* CmdrTaco is an idiot.
What features? (Score:2)
So my take on what you need:
* HTTP and FTP support
* HTML rendering, including frames, tables, GIF, and JPG
* Forms support
* SSL support
* Cookies
* JavaScript
You probably also would find useful:
* Support for plugins (Flash and such)
* Support for Java, probably using an external JVM
Luxury items:
* CSS (Cascading Style Sheets)
Note that unlike others, I consider FTP to be critical. I use it all the time from sites that use HTML indices for downloading software, such as Freshmeat.
Re:Opera? (Score:2)
Re:Remember OpenDoc? (Score:2)
1) OLE predates OpenDoc. OLE existed way back on Windows 3.1. The earliest reference I can find right now is a DDJ article on OLE *2.0* written in 1994. The earliest reference to OpenDoc I can find is a press release in late '95 for the OpenDoc for MacOS SDK.
2) OLE is *extremely* widely used. Anyone using Internet Explorer on Windows, or Office on Mac or Windows is using OLE. Anyone using Windows Scripting Host is using OLE. ActiveX? That's OLE too.
3) OLE Automation is *very very handy*. I've had a number of occasions where I've had conceptually simple tasks that were annoying to do in Perl or other Unix-ish methods, but a little OLE-automation of Office and the task is done. Need to parse a bunch of e-mails from my normal POP3 account (no mbox/maildir access), and update an Excel spreadsheet with the new data plus update the charts to include the new data? Need to publish that Excel spreadsheet and charts as a web page on the Extranet for the investors to use, and make the
-JF
Arrrrggghhh! Not Slashdot! (Score:2)
no no no NO!
Sorry, but not Slashdot. Slashdot produces the most disgusting, broken, brain-dead, horrible HTML imaginable. It's nearly as bad as things produced with FrontPage. As long as soi-disant Web designers [userfriendly.org] can rely on browsers tolerating their incompetence, we'll have incompetent Web designers. What we need is a browser which, when fed crud, throws an exception. This may sound extreme but it's the only way we can get a half-decent Web.
Smallest browser ever (Score:2)
Here is the source:
cut here
----
#!/bin/sh
wget $1
----
The Java virtual machine still needs fleshing out a bit, any help appreciated.
iCab (Score:2)
Q: Why does the browser have to support java? (Score:2)
Take out some more letters to make it smaller! (Score:2)
How Much Smaller Could Web Browers Be?
What next? Brwr?
Now that I think about it... (Score:2)
I guess one way around that would be to actually code the browser in Java, and to distribute the JVM separately. One advantage to all of this could be the ease of updating/replacing component classes, or on-the-fly loading and executing of classes. I'm impressed with Java's capabilities in that way.
What I am confused about is Sun's decision to cancel their development of the HotJava web browser. I thought it was quite good. Sure, it had its share of bugs, but it rendered Slashdot ok and it had SSL support. Its performance could have been a bit better (downloading ok - rendering a bit slow), but I bet that simply replacing the JVM with IBM's version would have helped that somewhat.
In any case, if you need Java, then I'd suggest you do the entire thing in Java. I'm pretty sure that you can get your code tightly packed in a
All of that, combined with Java's Exception model (great way to trap runtime issues without breaking the program), plus the java.net API which gives you excellent networking code, plus some runtime stability (arguable, I know, but I think that I can code a large Java program to be more stable than Netscape 4.x), makes for an excellent platform, IMHO. Again, arguable, but I've had much success in Java (I am a Senior Developer at my company, but I won't get into details), and I'm quite pleased with the direction things are taking. I don't work for Sun - this opinion is unsolicited, I promise you.
Start such a project, and stick with it, and I'd be happy to join, if you want to open source it! The pressure will be to not get tired or bored of the project, because geez - it really is monolithic! Web browsers have gone beyond the Mosaic days - there's a hell of a lot to worry about in there! The advantage is, there's a lot of projects which have started and faltered. Maybe it'd be good to scoop them up and build on their previous efforts.
Opera? (Score:3)
I don't think it could get much smaller, because of the complexities involved in the increasing scope of the HTML standards, JavaScript, CSS and the like, plus the fact that they seem to be writing the code to be reasonably portable.
If you really want to get insane, I'm sure somebody COULD write a browser in hand-coded assembler to be extremely small, but the benefits would be outweighed by the sheer difficulty in maintaining this code and loss in portability.
Want a lightweight Mozilla for Windows? Try Kmeleon [kmeleon.org]. Stripped down, but is fast and small (about 3MB), as well as free, and seems reasonably stable too. I use this and am pleased with it, but I prefer Opera still because it's been in development longer and seems to be more consistent in its rendering capabilities.
Ask QNX (Score:4)
With a little more digging on their site, I found this [qnx.com] information page which offers some more details on their browser. it's called Voyager, and it supports frames, JavaScript, and almost all common html tags, and it fits in less than 400k. Even more information on the Voyager browser can be found here [qnx.com].
I hope this is of some help.
-Jason