auto generate javascript to update client html compared to previous html?

do you think it would be difficult to write a framework where mvc compares last html it output to the current html we want to output, and instead of sending the entire html, figure out what has changed and generate js code that will do the updating as compared to previous html? (presuming nothing was manually changed on the开发者_开发知识库 client using js)... maybe an idea for a codeplex project? or maybe something like this exists? if so, do tell. thanks.

I think it's an interesting question, but one without a practical solution..

If I understand correctly you want to generate a diff from the current DOM into a new one, and you want to generate this change script (which is javascript executed client side) on the server.

The issue with that is that in order for the server to generate a diff, it needs to know what the previous DOM structure was in order to compare it with the new one (i.e. the new html page)

The only ways I can think of are:

1. The client sends back the full current page or some representation of it.
2. The server stores a copy of the previous page.

The problem with #1 is that you've already negated any performance benefit you from it. Sending a full page back to the server is just as bad or worse than sending it from the server to the client. You can achieve the same effect by requesting the full page body via AJAX and replacing it, and it would be just as efficient and simpler to implement.

The problem with #2 is now the server needs x copies of each page where x is the number of users. That's a lot of memory, unless you're persisting it to disk, in which case that's a a moderate sized disk write for every request. Then there's the problem of figuring out how long to keep these around, because if someone visits the site once, you don't want to keep it around forever.

The performance of either situation is most likely going to be worse than just getting the full page and will only get worse with more users.

That's not including the complexity of actually getting it right. I think hypothetically it could be done, but other than as a fun experiment there aren't any practical benefits that would outweigh the cost of such a solution, which is why I doubt you'll find one.

Have you considered caching? E.g. Caching in asp.net-mvc

Will be more straightforward and it makes more sense to me too.

You would need to save the state of any client at your server, and no response could be cached anywhere because every client needs a different response.

Even if this is possible, it would make no sense in the "HTTP world" imho.

You are attempting to suggest a solution for a problem that has already been solved. AJAX solved your question. You can use AJAX requests to load html that you know will change thus saving round trips.