News for hackers. Stuff that matters.

Poll: Where do you assemble your on-the-fly HTML?

On the server, in your chosen language, with access to your data base.

PROS: Complete control, one version

CONS: Have to make a round trip to change it on-the-fly, lots of data sent down the line, more load on server

On the client, using Javascript:

PROS: Much less data needs to be sent, can modify appearance without a round trip

CONS: Need to preload a lot of Javascript, unknown machine and resources, may actually be slower

What am I missing?

( 10 comments | 6 points | on HN )

Poll

On the server, to be delivered to the client. 38 votes
On the client, using Javascript. 16 votes
Other (see my comment below) 2 votes
Re:Poll: Where do you assemble your on-the-fly HTML? by nostrademons on Sunday March 02, 2008 @11:02AM (#127403)
Both. App is divided into components - the editor is one component, which is written as a JavaScript application that's kicked off with a single JS function call and handles all the HTML for itself, dynamically. The rest of the website is generated on the server and uses JS only for decoration.

I'd worry more about ease of programming than machine constraints. Webapps are rarely CPU-bound, so the overhead of template instantiation isn't likely to make much difference. You definitely want to keep related functionality together - in earlier drafts, I'd generated the HTML for the editor on the server and manipulated it with JQuery. This was a disaster - I could never remember whether functionality was in the HTML template or in the JavaScript, and I had to duplicate some logic in both places.

Re:Poll: Where do you assemble your on-the-fly HTML? by jsjenkins168 on Sunday March 02, 2008 @09:33AM (#127353)
GWT falls under your 2nd option, but avoids some of those CONS. It sends a small amount of javascript to bootstrap the process and determine what browser you are using. It then makes a round trip to obtain the rest of your code specific to the clients browser. This avoids sending unnecessary code for other browsers and cuts down on the need to preload a lot of javascript.
Re:Poll: Where do you assemble your on-the-fly HTML? by edw519 on Sunday March 02, 2008 @09:45AM (#127360)
Interesting. Thanks for that feedback.

We may need a followup poll on frameworks.

I think I'm beginning to like this poll facility.

Re:Poll: Where do you assemble your on-the-fly HTML? by ratsbane on Sunday March 02, 2008 @11:05AM (#127406)
I voted for both the first and second choices. The thing we're working on now is sort of a mixed approach. Everything is assembled first on server but then sections can be swapped out without reloading the whole page.
Re:Poll: Where do you assemble your on-the-fly HTML? by michaelr on Sunday March 02, 2008 @05:54PM (#127634)
Is it feasible for you to start on the server and wait until it presents a noticeable performance problem(if ever) before going client side? This would be my initial inclination.
Re:Poll: Where do you assemble your on-the-fly HTML? by mechanical_fish on Sunday March 02, 2008 @10:33AM (#127381)
"It depends." Not a very useful answer, I know. :)
Re:Poll: Where do you assemble your on-the-fly HTML? by edw519 on Sunday March 02, 2008 @10:42AM (#127387)
I infer that it means that you struggle with the same pros and cons I do. Right?
Re:Poll: Where do you assemble your on-the-fly HTML? by mechanical_fish on Sunday March 02, 2008 @11:03AM (#127404)
Bingo. I can't even say I lean in one direction or the other. It depends on the nature of the specific problem.
Re:Poll: Where do you assemble your on-the-fly HTML? by wlievens on Monday March 03, 2008 @03:48AM (#127932)
You're missing the fact that you almost always do both.
Re:Poll: Where do you assemble your on-the-fly HTML? by sovande on Sunday March 02, 2008 @12:31PM (#127446)
On server, on client and from cache