2 ms·
that's just added complexity, where it could all just work. or fail consistently at the same time if your server isn't accessible. In that case it doesn't matt
by AdrianRossouw 13y ago
that's just added complexity, where it could all just work.
or fail consistently at the same time if your server isn't accessible. In that case it doesn't matter that the public cdn is still accessible.
i just don't think the possible benefit of public cdn hosted code can justify how many moving parts it adds.
- moystard 13y agoIt does not add complexity if your project already makes use of require.js, it is literally specifying an array of paths for a library instead of a simple string. If my server is not available, my web application will ultimately fail anyway.
- AdrianRossouw 13y agoif you are worried enough about performance to start using external resources in this way, you are probably going to benefit much more by using r.js and a build step to build a single (or a few partitioned) javascript files. https://developers.google.com/speed/docs/best-practices/rtt#CombineExternalJS https://developers.google.com/speed/docs/best-practices/rtt#...
- moystard 13y agoWe do use r.js and create modules (a main one that gets download systematically, and smaller ones for less used features). However as we update often, we don't want our users to download the large third party libraries we use at each occurence, so having them as separate downloads is actually much better. For the large libraries we use that are hosted on a cdn, with a local fallback, we use the :empty value for the optimiser and they are exclude from our modules.