Google Maps - Diffable: only download the deltas(stevesouders.com)
stevesouders.com
Google Maps - Diffable: only download the deltas
http://www.stevesouders.com/blog/2010/07/09/diffable-only-download-the-deltas/
5 comments
Notice how that the chart scale doesn't start with zero. In reality they win maybe 10-15% in speed, but they have all the crap overhead to support and manage.
I think in this case speed/size benefits would NOT worth additional level of complexity that Diffable would introduce.
In which case? Google Maps? You're right that in most cases, it's major overkill, but I'd guess there are many applications where it makes a lot of sense. Big sites with many millions daily visitors could save a decent chunk of bandwidth.
In Google's case, speed/latency for their users is what they're really trying to optimize.
I mean in general with JavaScrips trying to save dataload by sending diffs of that JavaScripts instead of full new version -- does not worth the complexity of dealing with it.
Diff functionality is more complex and therefore:
- Requires a lot of time to develop and maintain.
- Could have bugs which might result in a weird web application behavior.
Bandwidth is not as expensive as the overhead of maintaining JavaScript Diffs.
Why not use HTTP Content-Range (along with javascript) to make the latest version cacheable (instead of getting a patch every time)?
Correct me if I'm wrong, but wouldn't you then have to make a separate HTTP request for each non-contiguous block of modified lines that you request? Also, wouldn't the client have to know in advance which lines were changed in the new version? Maybe I'm misinformed about how Content-Range works.
Also, in regards to getting a patch every time, Josh Harrison (one of the creators) responds in a comment on the blog post:
Also, in regards to getting a patch every time, Josh Harrison (one of the creators) responds in a comment on the blog post:
You are correct in noticing that the patched version is
not cached. However, the v1->v2 patch itself IS cached,
meaning that the next time the user visits, if there has
not been a new release, then both v1 and the v1->v2 patch
are retrieved from cache. Also, we are working on
incorporating local storage, which would allow the
updated version to be persisted each time it is patched.Yeah... most peoples js code-base is more like 3kb.
This isn't made for "most peoples" web sites, it's designed specifically for web apps with large Javascript footprints. Of which there are quite a few - the site I work on has ~200kB-400kB of JS resources.
It is for sites with large JS code, very high volume, and frequent revisions. I wouldn't do this if my site only had 1k logged in users per day or if I changed the code once a month.
[Citation required]^H^H^H^H^H^H^H^H Do you have any data which supports the statement regarding average size of script?
I suspect that the sites which might consider deploying something like this have "most" of the Javascript code on the internet if you look at bytes transferred, rather than number of URLs.
I suspect that the sites which might consider deploying something like this have "most" of the Javascript code on the internet if you look at bytes transferred, rather than number of URLs.
The snarky [Citation required] didn't add anything to your more useful second paragraph.
Perhaps the internet could go back to calling people on generic statements in long-hand form.
Perhaps the internet could go back to calling people on generic statements in long-hand form.
My apologies. The original comment was quite throwaway, so I didn't want to present too much of a formal refutation. However, I have adjusted the text slightly.
The snarky [Citation required] didn't add anything to your more useful second paragraph.
Yeah. Because it's actually [Citation needed].
Yeah. Because it's actually [Citation needed].
It's tricky to keep track of all these internet memes.
[deleted]