

DynoSRC - Eliminate HTTP requests for JavaScript files - selamis
http://dinosrc.it/

======
getdavidhiggins
Ilya Grigorik talks about how the Gmail devs keep all their JS modular, so
that when a change really needs to be made on the live web-app; only one small
file needs to be affected. Another huge JS file does not need to be sent down
the wire. If you modify a massive file, you inadvertently DDOS your own
server.

He talks about it here →
[http://www.youtube.com/watch?v=E9FxNzv1Tr8#t=600](http://www.youtube.com/watch?v=E9FxNzv1Tr8#t=600)

------
afandian
My first instinct is "how bad is the motivating problem, really?". How often
do you have a single massive JS file where a small number of lines change?

I'm not saying it's a bad idea, but starting with a case study would be nice
rather than jumping in with "we've completely changed everything about how
script files are delivered, it's amazing and we have cool graphics to prove
it". The dinosaur looks a bit hand-wavy.

There are a lot more moving parts, a lost more surface area for things to go
wrong, etc. Yes, downloading huge JS files is a problem, but you're going to
have to download them one way or another.

~~~
bilalq
I imagine its probably fairly common. Lots of sites will minify and
concatenate their JS, after all.

~~~
josteink
> Lots of sites will minify and concatenate their JS, after all.

Most with absolutely zero data to back up that it provides any sort of useful
improvements to justify the difficulties it introduces in debugging.

Considering how almost all web-servers and browsers support HTTP compression,
minification is mostly a cargo-cult ritual.

~~~
byroot
As much as I would like your statement to be true:

    
    
        jquery-2.0.3.js       236K
        jquery-2.0.3.js.gz     70K
        jquery-2.0.3.min.js    82K
        jquery-2.0.3.min.js.gz 29K
    

Minification pay off a lot even with compression.

~~~
michaelmior
To be fair, this doesn't show a performance improvement, it shows a file size
reduction. Of course you can assume one leads to the other, but it doesn't
fully prove the point.

~~~
byroot

        time curl http://code.jquery.com/jquery-2.0.3.js > /dev/null
        real	0m0.433s
    
        time curl http://code.jquery.com/jquery-2.0.3.min.js > /dev/null
        real	0m0.210s
    

Is it proved now ?

Edit: Off course I didn't ran these requests only once.

~~~
bct
The obvious next question is "can't you achieve the same thing with gzip":

    
    
        time curl http://code.jquery.com/jquery-2.0.3.js > /dev/null
        236k bytes
        real	0m0.432s
    
        time curl http://code.jquery.com/jquery-2.0.3.min.js > /dev/null
        83612 bytes
        real	0m0.323s
    
        time curl http://code.jquery.com/jquery-2.0.3.js --compressed > /dev/null
        87509 bytes
        real	0m0.273s
    
        time curl http://code.jquery.com/jquery-2.0.3.min.js --compressed > /dev/null
        34066 bytes
        real	0m0.215s
    

I think that people should be more skeptical of the complexity introduced by
things like minification, but the advantages are pretty clear, even with
compression.

------
dsr12
How well will "Differential Updates" work for minified files?

~~~
talles
Good question, definitely needed to know before using.

------
wyuenho
I see the repo the Github Docs points to is a fork of
[https://github.com/DynoSRC/dynosrc](https://github.com/DynoSRC/dynosrc),
which one is actually the canonical repo?

BTW, how does differential updates do under minification? Don't the
differences usually end up replacing the entire functions?

~~~
lloeki
> BTW, how does differential updates do under minification

Don't minify. Minifying is a kludge. This (and gzip) actually looks like a
properly engineered solution.

------
cedias
isn't that what's browser cache is for ?

~~~
k__
mabye they use the localstorage for incremental updates

------
michaelmior
This seems like it would really complicate use of a CDN given that page
content is now different based on what users have cached. You could look at
cookie values and still get some caching, but this would hurt your cache hit
rate. It also bars you from using a lot of the cheaper CDNs which won't let
you inspect the request deeply enough to efficiently cached based on the
cookie.

So if you can't use a CDN or your cache hit rates are much lower, you might
end up with slower page loads with technique. But of course I have no data to
back this up.

------
bungle
What does this mean to local storage requirements if every site does this?

------
tlarkworthy
Be nice if it did something about images too

~~~
stereo
And CSS, of course. Cram the entire page in a single HTTP request.

------
viraptor
This really looks like the wrong layer to do that... It could be interesting
to extend HTTP / etag to do something similar globally. Instead of "tell me
nothing changed, or send a new version", browser could request "tell me
nothing changed, or send a patch from version XXX".

~~~
samworm
I agree the "send me differences" model is appealing. A version based off
rsync was created back in 1999 but patents killed it. I think the patent in
question runs out pretty soon though...

The Tragedy of the RProxy:
[http://ozlabs.org/~rusty/rproxy.html](http://ozlabs.org/~rusty/rproxy.html)

------
asdfaoeu
Are there any benchmarks? I have a hard time seeing this make any significant
improvement over minified concatenated javascript files. And are you really
updating your javascript files enough thats it's a problem?

------
Kiro
> Eliminate HTTP requests for JavaScript files

Great! We already do this manually for mobile sites so I will definitely try
it out.

> and serve differential updates

I didn't understand this part.

~~~
arkitaip
Differential updates means that only line changes in your javascript will have
to be downloaded instead of downloading entire files.

------
gulbrandr
This only works with Git, right?

[https://github.com/DynoSRC/dynosrc#how-does-it-
work](https://github.com/DynoSRC/dynosrc#how-does-it-work)

------
alien3d
Sorry,i'm quite confuse.i reloading the page .seem request for js file still
exist ? Shouldn't browser cache javascript file normally upon second time
refreshing web page.

~~~
prottmann
Yes the browsers do it.

But this is in case you have a bigger JS-File (e.g. for a Web-App) and your
customer visit again, so you only have to transfer a small peace of data.

But iam not sure if the performance / traffic advantage is so high, that dyno
justify the effort. And you have one more source of possible error, so i did
not think many developer will use it.

The idea is good, but the solution should work automatically in background on
the transportation layer, between browser and server, not for app developer.

@Jason Anderson: Call google - chrome developer if they implement it in their
Browser and write an apache Plugin ! :-)

