Poll: Where do you assemble your on-the-fly HTML?
7 コメント
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.
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.
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.
Interesting. Thanks for that feedback.
We may need a followup poll on frameworks.
I think I'm beginning to like this poll facility.
We may need a followup poll on frameworks.
I think I'm beginning to like this poll facility.
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.
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.
"It depends." Not a very useful answer, I know. :)
I infer that it means that you struggle with the same pros and cons I do. Right?
Bingo. I can't even say I lean in one direction or the other. It depends on the nature of the specific problem.
You're missing the fact that you almost always do both.
On server, on client and from cache
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?