-3

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.

Erx_VB.NExT.Coder
  • 4,838
  • 10
  • 56
  • 92
  • +1 because I think it's an interesting question. Essentially what you're asking for is generating a DOM diff in the form of a JS update script that's generated server side. – Davy8 May 06 '11 at 17:54

4 Answers4

1

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.

Davy8
  • 30,868
  • 25
  • 115
  • 173
0

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

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

Community
  • 1
  • 1
o.k.w
  • 25,490
  • 6
  • 66
  • 63
  • thats missing the point, together with the low-bandwidth efficiency, you can update any part of the html without issue. currenlty you can't do this in mvc ajax unless you nail the server with as many calls as you have regions of updating needed. the questions still remains. read my other post for more on this if you want – Erx_VB.NExT.Coder Jan 16 '10 at 09:25
  • if worked, we'd never need to use js again (for the most part/for most users) and can write proper mvc apps in mvc only. at the moment i am using jquery to do everything because of mvc's lackings. this defeates the purpose of mvc, seperating view logic from business logic, its just not elegant code, and too many hacks to get things done right. – Erx_VB.NExT.Coder Jan 16 '10 at 09:26
  • 1
    This is not a short coming of MVC, it's how HTTP and browsers work. JavaScript is absolutely necessary if you only want update a portion of the page. – Justin Johnson Jan 16 '10 at 09:38
  • @Erx_VB.NExT.Coder: Pardon me if I didn't understood your question. I'm just offering an opinion which unfortunately is 'missing the point'. I'll still leave the answer here as the comments are worth a read or two. – o.k.w Jan 16 '10 at 09:45
  • 1
    @justin: the shortcomming of mvc is you can't update multiple parts of the page unleess you hammer out multi ajax requests hittign the server unnecessarily, or loading the entire view... with webforms you could do this with one call and one return. the thing i suggested is an option that would provide benefit, for people who do not want to use javascript to use mvc, making mvc a proper, fully contained framework! there are plenty of people that hate writing js/jquery to write a proper app! – Erx_VB.NExT.Coder Jan 16 '10 at 10:23
  • @Erx I think you're failing to realize that this is not possible with current technology. What you are suggesting is equivalent to AJAX, except that AJAX doesn't have the misplaced notion of generating JavaScript on the fly to alter the current page. Also, the shortcoming of MVC is that it's not entirely suitable for stateless applications. I'm sorry if people hate writing JavaScript. If that's the case, they should get out of web. – Justin Johnson Jan 16 '10 at 11:51
  • 1
    @justin: why do you think my suggestion is a misplaced notion? how is it not possible? you cache/save the last html sent, based on what user does in his mvc controllers etc to their views, and how their views change, whatever change there is, mvc can generate the js to make that change on the client instead of sending everything again. you have cached-like bandwidth saving while still having everythign dynamic and updatable. best of both. its perfect. i cant see how it is not possible as a side feature, NOT a replacement of course. – Erx_VB.NExT.Coder Jan 16 '10 at 12:18
  • also think of the benefits of seperation of concerns, code abstraction, all the main arguments for mvc. having to write half ur business and display logic on the client and not being able to do it all on the server is just plain poor, the ideal is to have all your logic in one place, the server, and let the framework figure out the js that needs to be written based on what you do on the server. – Erx_VB.NExT.Coder Jan 16 '10 at 12:57
  • 2
    The point is that all that can be done with AJAX, *in one request.* What you're suggesting is not possible with current browser technology. You're essentially proposing that the browser magically handle your AJAX behavior for you. I agree that there are better ways to display and update content, but we're stuck with HTTP, HTML and the browser idiom. – Justin Johnson Jan 16 '10 at 17:58
  • 1
    well, im jsut proposing that a server side class write the js to update the html on the client for me, so i dont have to write the js... thats all... this way all my code logic exists on the server. – Erx_VB.NExT.Coder Jan 16 '10 at 18:35
  • 1
    also, the code generating the js would be on the server of course, and it may not make sense in every request, but the server can decide when to send back js and when to send back the updated html. im just curious to know, as i think i might be missing something, why it is that this would not be practical or useful? of course, client code will still be needed for client only interactions and when client doesn't want to go to the server... but at least, when u go to the server, you wont need client code for the response. – Erx_VB.NExT.Coder Jan 18 '10 at 01:01
0

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.

Karsten
  • 14,572
  • 5
  • 30
  • 35
  • @karsten: output caching wouldn't be needed! however the output cache could just save the base page html. then all returned items (where it makes sense to do so) would just return javascript which instructs the client on how to change the html to update the current display. i won't need to use javascript to update my html all the time, smaller amount of data being sent (js to do the updating), don't you think it'd be an option worth having? im thinking maybe i suck at explaining... because i would kill for this. – Erx_VB.NExT.Coder Jan 16 '10 at 10:28
  • Sounds like using javascript to update small parts of your page via AJAX to me. You will need javascript for any kind of non-standard-request anyways. – Karsten Jan 16 '10 at 10:31
  • @karsten: yes thats right, BUT the difference is the mvc framework would be generating the javascript, so you do not have to do anything on that front!!! get me? – Erx_VB.NExT.Coder Jan 16 '10 at 10:42
  • I get what you want to do, but I see no advantage over partial AJAX requests. Your MVC Framework does process AJAX requests, right? – Karsten Jan 16 '10 at 10:47
  • yes the recommendation would be implemented in ajax. well the benefit is monstrous bandwidth savings & updating multiple views via ajax without doing numerous ajax calls and hammering the server, as you know you can only return one view, you cant update multiple views in mvc unless u make multi ajax requests. this is really bad, which is why i would love something like this. especially when all you need to do is update a few items on different parts of teh page. – Erx_VB.NExT.Coder Jan 16 '10 at 12:12
  • also, with output caching, you have the bandwidth savings at the cost of not being able to update your html - not entirely comparable. where as here you have the best of both worlds. maybe im not seeing something and getting overly excited about nothing? i just can't see what it is i might not be seeing tho :) cuz i would so love this feature :) – Erx_VB.NExT.Coder Jan 16 '10 at 12:14
  • why would every client need a different response? javascript is the same (almost always) everywhere on all clients. and the client request will go back with an id so that the server knows which one its dealing with. so it would make every bit of sense in the http world. this is why im really thinking i've been unable to explain something central to what im thinking. – Erx_VB.NExT.Coder Jan 18 '10 at 00:57
0

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.

Anish
  • 3,045
  • 3
  • 27
  • 29