5 ms·

Most of what you're describing as "madness" is already done in head.js and require. They have no particular speed penalties and handle dependencies better than

by tghw 13y ago

Most of what you're describing as "madness" is already done in head.js and require. They have no particular speed penalties and handle dependencies better than just putting script tags in the right order. The one difference is that a system like this would check the hashes to verify the code. The one possible catch, as you mention, would be getting access to these scripts before they are loaded without having cross-origin problems. There are a number of problems with serving from your own domain. It is, in fact, much less convenient for developers, as it adds an extra step to the build process and requires the system to properly handle caching so that old resources are not still served after a build. It is also slower to serve from the same domain as there are connection limits. Lastly, it gives up all advantages of a CDN. My proposal is an attempt to continue taking advantage of CDNs and third party resources, but without giving them the keys to your site. Did you ever consider that Google has access to all of your users' cookies, if they wanted to add a small modification to jQuery or Analytics? Considering recent revelations about government involvement, is it really out of the question to believe that they never would take that information?

rictic 13y ago
head.js and require do have significant speed penalties unless you're just using them as for tracking dependencies and for developing locally. It may be the right tradeoff of effort vs performance for some projects to leave this going even in production, but there's nothing to gain in denying the huge performance boost you're leaving on the table by not compiling your js. I'll try to extract the core of my argument. The hashing proposal is madness for two reasons: 1) it's slower and less secure than just serving all of your js in one file; 2) it will not actually work without the cooperation of a CDN. 1) The proposal requires you to have one trusted server that you're serving javascript resources out of (because you need to load the script loader and fingerprints from there). If you want fast and secure, you've already paid the cost of a round trip to server #1, and the risk of trusting server #1. The sane thing to do from a performance and security standpoint is to load all of the javascript that you can in that request. Otherwise you're going to be blocking on that request returning, then the renderer reaching that script's location in the html, then that script being executed before it fires off the requests. 2) I'll phrase this as a challenge. Try to load jquery from a CDN with an ajax request. Remember, the key is to get the source of the script into memory without executing it, so that you can hash and validate it first. Feel free to try it right now in your developer console, I'll even give you a code snippet to start from: url = '//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js' var request = new XMLHttpRequest(); request.open('GET', url); request.send();

by tghw 13y ago

rictic 13y ago

head.js and require do have significant speed penalties unless you're just using them as for tracking dependencies and for developing locally. It may be the right tradeoff of effort vs performance for some projects to leave this going even in production, but there's nothing to gain in denying the huge performance boost you're leaving on the table by not compiling your js. I'll try to extract the core of my argument. The hashing proposal is madness for two reasons: 1) it's slower and less secure than just serving all of your js in one file; 2) it will not actually work without the cooperation of a CDN. 1) The proposal requires you to have one trusted server that you're serving javascript resources out of (because you need to load the script loader and fingerprints from there). If you want fast and secure, you've already paid the cost of a round trip to server #1, and the risk of trusting server #1. The sane thing to do from a performance and security standpoint is to load all of the javascript that you can in that request. Otherwise you're going to be blocking on that request returning, then the renderer reaching that script's location in the html, then that script being executed before it fires off the requests. 2) I'll phrase this as a challenge. Try to load jquery from a CDN with an ajax request. Remember, the key is to get the source of the script into memory without executing it, so that you can hash and validate it first. Feel free to try it right now in your developer console, I'll even give you a code snippet to start from: url = '//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js' var request = new XMLHttpRequest(); request.open('GET', url); request.send();