RE: client side includes

Murray Macdonald, at 22:53 -0800 on Fri, 2 Feb 2001, wrote:

    I am surprised that no one on this list has mentioned the obvious
    flaw in this logic.  It makes me wonder what kind of people are on
    this list.  Includes in HTML are a very inefficient way to achieve
    the desired results.  As with JavaScript includes, a client-side
    include would require another round trip (from the UA to the
    server and back again) before the page could be fully rendered.
    End users do not want to wait for two or more pages to load, let
    alone one.  If designers nested client side includes (an include a
    file that includes a file that includes a file...) this would
    increase the delays by multiples.  Remember, includes do nothing
    for the end user, they are merely a convenience for the programmer
    to assist in site management and code reuse.  To do so at the
    expense of your user's experience is a very poor and selfish
    design philosophy.  Also, client side includes would not support
    any of the existing UAs.  Do you really want to abandon millions
    of users like that! ??! ! ? and for what benefit?

I think you overstate your case.  Hitting the server for another chunk of
data is not that expensive.  It happens all the time for images, CSS
files, etc.

     Using Server-side includes by comparison achieves all the same
    advantages, reduces server load, causes fewer hits on the web
    server, speeds up the experience for the viewer (by a multiple),
    works with all existing UAs, reduces UA memory requirements and
    complexity, and reduces all around net traffic and latencies.
    Also, nested server-side includes (a file that includes a file
    that includes a file...) have nominal impact on the server and the
    user.  Nested includes are a convenient (and sometimes required)
    way to efficiently manage content and code reuse...and after all
    that's what you're looking to achieve right?  Would you (or your
    users) really be content with a solution that slowed down many
    times to offer you the convenience of realistic include usage?

Reduces server load how?  It certainly doesn't lower CPU load.  Perhaps
you mean connection load; I've already stated my objection to this.

    Also, I am wondering, how many of you people serve HTML off a web
    server that does not already support SSI, perl, PHP or some other
    more efficient solution?  Certainly IIS, Apache and any other
    self-respecting web server has had this functionality for many
    years.  Are you people promoting this just unaware of how to use
    the functionality you already have?

Sure, most of us are aware of ssi's and the like.  But these solutions
aren't portable, and aren't part of the markup language itself.  The best
solutions are the ones you can carry from any server to another.

    You people seem like don't know what you are doing, and have not
    taken the time to read the manual.  I hope none of you charge
    people for your "services" because suggesting or implementing this
    type of a solution would be of no service to your clients or their
    end users.  It would only serve to allow under educated
    "designers" keep their heads buried in the sand at the expense of
    their client and users.  Try learning.  Its not a scary as you
    might think.

On the contrary, I think many of us do know what we're doing.  We do know
that server-based solutions are, in general, evil.  If the markup language
itself handles the situation, that is the best solution.

Personally, I've learned that entities seem like a good way do external
includes.  So your entire argument is negated, since this functionality
already exists in XML.

-- 
Frank Tobin		http://www.uiuc.edu/~ftobin/

Received on Saturday, 3 February 2001 02:48:20 UTC