If you're sold on the HTML .. uh ... "platform", then you need to rethink process flow for your users first and foremost. For example, I've got a general ledger app custom-built for my company. As you have no doubt found out, asking the HTML renderer to rewrite a large grid of data for each new data point is cumbersome; equally cumbersome is the "too many blank rows" problem. So the first step might be to enter data a row at a time and return a new blank row on submit.

Unfortunately, this cuts into users' perceived workflow time. So you have to redesign your apps to help the user out. For example, my GL app uses multiple frames to give the user something to do in one window while the other is being submitted/redrawn. I also ended up doing a lot of predictive javascript, so the values that they are likely to type in are either already there in the textbox when they (re)load the page, or are a click away. It really takes a lot of process and workflow analysis to get it right. But the payoff is worth it.

Keep in mind this is just a couple examples. If you have specific questions about it as you starting prototyping/spot-testing, I'd be happy to discuss them further with you.