Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming IT Technology

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!*)"
This discussion has been archived. No new comments can be posted.

How Much Smaller Could Web Browers Be?

Comments Filter:
  • by Anonymous Coward
    I'm doing fine browsing /. using Lynx. I've never tried it before, but it is usable just about and less stressful than the bloated IE and NS.
  • This was the whole point of OpenDoc, a great technology Apple killed because it was taking too long to become commercially viable. For awhile Apple had the Cyberdog browser, which was based on OpenDoc components.

    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.)

  • My feature list is based on my view of what is necessary to make full use of the web pages that I visit. While CSS may, indeed, have a lot of potential, my casual observation is that it isn't important for using the web as it stands today.

    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.
  • Wow. Helper apps. Strange concept.
  • if only all browser manufacturers had agreed not to display anything for pages which failed an HTML validation

    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...

  • Note that unlike others, I consider FTP to be critical.

    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)

  • Konqueror supports SSL, JavaScript (aka EcmaScript), Java, Netscape Plugins, HTML4, CSS, etc...
    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.
  • From what I've hear, HTML is't exactly the cleanest or elegant of languages and ain't a walk in the park to render. I'm not sure if this means just time or ram, or if it applies to large code too.

  • Galeon [sourceforge.net] attempts some features of calling other programs to perform the tasks. Downloading is handled by the Gnome transfer manager (which in turn calls wget). It can use gecko's (ie. mozilla's) built-in ftp browser or call your preferred ftp program.
  • Just click on the minimize button.

    Ok, I'll stop now.
    --
  • 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 ;-)
    --

  • Luxury items: * CSS (Cascading Style Sheets)

    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.


    ---
  • I don't think it could get much smaller, because of the complexities involved in the increasing scope of the HTML standards

    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)

  • I'm not sure about the memory footprint, but Opera [opera.com] is fast. I'm guessing that means streamlined source code, i.e. small. Anyways, hope it helps.

    nick

  • I don't think browsers could get that small without someone re-writing history and dumping all the, lets face it, superfluous crap that infects out web browsing these days. HTML WAS a great concept. The web in it's infancy was great, now it's been polluted with Javascript which, while it has it's place, has done very little for web design other than make people take the cheap route and use JS when CGI is a much slicker alternative.

    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.

  • Careful. I don't think there's a Sun-supported version of Java for BSD yet. Hell - I can't seem to find ANY Java 1.2 or 1.3 SDK, natively compiled for BSD! This issue is currently voted #1 on their "RFE" list in the Java Developer Connection by the users.

    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.
  • Just use a hair trimmer on 'em. Then you'll have a much smaller brower.

    - A.P.

    --
    * CmdrTaco is an idiot.

  • First, you need a solid list of what features you really want in your web browser. In theory, you could then use Mozilla and compile out all the ones you don't really want. In theory, you could use the fully-featured Mozilla with some extra code to log which features you use, then use that to only compile in what you want. In practice you can only cut out some of the major chunks like mail and news.

    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.
  • 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.
    Now if only all browser manufacturers had agreed not to display anything for pages which failed an HTML validation. Then people would have to write true HTML, or they wouldn't even be able to see it themselves!
  • You're joking right?

    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 .xls file available internally for the execs? Trivial with Windows Scripting Host and OLE Automation.

    -JF
  • (assuming we define usable as meaning capable of displaying a Slashdot page reasonably correctly )

    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.

  • I've been waiting for this moment to unveil my newest creation: the Smallest Browser Ever.

    Here is the source:

    cut here
    ----

    #!/bin/sh

    wget $1

    ----

    The Java virtual machine still needs fleshing out a bit, any help appreciated.
  • While this isn't the strongest Mac site on the internet, a browser named iCab [www.icab.de] exists for the Mac. It is around 1.4MB in size (it uses 4MB of RAM however), and it supports HTML, XHTML, Java, (basic Javascript support...still in beta) and all sorts of cool features like ad banner blocking and cool stuff like that.
  • A: It doesn't. Almost every..scratch that. Every decent OS out there, and even some of the not-so-decent ones support Java. So why not put hooks in your web-browser to use your OS's jvm? Of course you'd have to do a little security checking, so the applet coudln't create, rename, move or alter files, and coudln't call other programs. But other than that, isn't that the best way to get java into a browser? Not have it there at all.
  • The title for this article is

    How Much Smaller Could Web Browers Be?

    What next? Brwr?

  • The biggest thing on your list will be the Java support. A Java VM will make your browser quite large as a download, if you have to include the VM in your distribution.

    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 .jar file, plus get it executing reasonably fast if you get the right JVM to run it. Better yet - I'm pretty sure that decent garbage collection would help you out a lot, plus thread support which makes for easy multiple connections.

    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.
  • by JediTrainer ( 314273 ) on Thursday February 08, 2001 @06:32PM (#444782)
    Lose the Java support, and you've got a fantastic browser in Opera [operasoftware.com] in just over a 2MB download, which seems to support just about everything you described. If you want Java, it's closer to 10.

    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.
  • by aidoneus ( 74503 ) on Thursday February 08, 2001 @06:39PM (#444783) Journal
    If you ever have the chance, take a look at the now famous QNX demo disk (available here [qnx.com]). It's a full OS with a fairly capable (graphical) browser that seems to meet your requirements, and the entire thing fits on a 1.44MB floppy. If they can fit all that on a floppy, I'm impressed.

    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

What is research but a blind date with knowledge? -- Will Harvey

Working...