[Banana]

Looks like I may end up dabbling in a bit more of web stuff, so figure I'd make sure my head is screwed on straight.

I'm well aware of some techinques available to make the experience better (e.g. AJAX & lazy-loading js files) but it seems that the more AJAX-y a given web application is, the more bloated & slow it is. Sure, elements may render instanteously when it's handled by JavaScript but loading is consistently slower and that's kind of fucked up, I think.

I've started to wondering if some of this is a case of the fact that we have to add several kludges & conditional branches to ensure our spiffy little functionality will work with everyone's browsers that the amounts of bytes actually exceed any saving that JavaScript would have promised to save from not requiring a roundtrip to the server? How often do we end up that way?

Does it make sense to want to use JavaScript + DOM to render parts of page, especially one that may repeat several times? Seems to me it'd be less bandwidth to send in a script + template once than to build the page server-side with 100 similar elements. Or did I just re-invent AJAX? (I'm not sure if this kind of thing is already happening and from what I'm (very superficially) seeing, I don't think this happen expect for few pieces.

And to use something more concrete, let's consider the requirement to allow user to sort on a selected column of a given table. Normally if the table itself would span more than one page, I'm thinking it's better done server-side, since that's only way to guarantee up-to-date & accurate sorting (that expands across pages). Sure, we can use AJAX to render that portion, but I'm imagining that the logic required to build the new table may result in script too large that it offset the saving gained from saving a roundtrip (which isn't really saved since we still have to roundtrip nonetheless, albeit for data only instead of data + markup). Is that a reasonable assessment?

I do apologize if my questions are vague and too open-ended -- even if all you can offer me a is a link to a source that discuss the web design in general, I'd be more than grateful. From my meandering you can see that I have lot of preconeived notions that I fear that may not be always spot-on so best that I get them blew away.

So, thanks!

[Banana]

Just to partially answer my own questions:

Yahoo's tips on Performance
Google's suggestions on caching.

I note that there's basically silence on the idea of using JavaScript to write out a repeating template so we only need to send over the prototemplate and build it client-side which suggests to me that the idea may not be feasible or practical.

The suggestions also doesn't address my concerns over apparent large number of kludges & workarounds to write compatible code that'll work on any browsers which may end up defeating the whole point.

[Gargoyle]

Don't write your own cross browser code! Use jQuery or the likes.

[Banana]

Sure, I keep hearing how awesome jQuery is and don't doubt it, but I'm also aware that it's not always feasible to assume we can use 3rd party libraries (this shouldn't apply in my case but I do want to be at least aware of such considerations where we may be building a web application atop a platform that limits the options available to the developer. I also have no idea how often it turns out that 3rd-party libraries or other add-ons are nonstarter for a given project, either.)

There's also another issue I'm trying to understand - if all I wanted was a simple javascript function on this one page, wouldn't I be actually introducing more overhead if I were to rely on jQuery or similar than if I just had them suck it up and download the js file synchronously? After all, if it also won't change often, slap on a 1-year expiration date on the .js and that's much cheaper, no? I also imagine similar considerations applies where it may be actually less overhead just to build the page entirely server-side with no javascript at all. I guess I'm trying to get a feel for what tools I actually need to serve it in most efficient manner.

[Gargoyle]

I think you are worrying too much! jQuery will probably save you more download bandwidth in the long run than the 29K it will take to download.

[Brad]

One major drawback to having Ajax load significant parts of your content: it makes it more difficult for search engines to crawl and index the material.

IMHO, one should only use Ajax to load content that's visibly changing after the page has initially loaded (like interactive forms) and to load content that is so slow to retrieve synchronously with the initial page request that it significantly slows down page load.

[Gargoyle]

I think the main thing you should think about if it is an app for public consumption is progressive enhancement.

[Banana]

I don't doubt that I worry too much.

I'll definitely use jQuery and other libraries where they are apropos since they are going to be several orders of magnitude better than what I ever could hope to write out. However, it still doesn't address my desire to understand why some applications I've seen uses javascript, CSS, AJAX and other fancy doodads yet are so slow and I didn't want to run into the same pitfalls. It also doesn't address the scenarios where third-party libraries, for whatever, may not be an option.

[Banana]

(and that's what happens when I spend so much time editing my post, thinking about it, and wandering off... )

Yes, Progressive Enhancement does makes a lot of sense - get basics right, then worry about fancy-pant stuff later and only toward users who actually want it. I see there's a wiki for that, so will definitely look at the tricks available there.

Thanks!