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.
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.
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.
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:
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.
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.
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.
