4 ms·

I think your statement is a bit extreme. While relying exclusively on a cdn to serve your static assets is risky, doing it using require.js with a local fallbac

I think your statement is a bit extreme. While relying exclusively on a cdn to serve your static assets is risky, doing it using require.js with a local fallback works very well. You still benefit from cdn caching, while preventing your assets to become unavailable (even in China).

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 ago
  It 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 ago
    if 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 ago
      We 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.
lerouxb 13y ago
Really? Have you ever sat through the experience of waiting for the primary source to time out so that the fallback can kick in?
- moystard 13y ago
  Ultimately, the timeout issue will be problematic for countries forbidding the access to cdns servers (ie China for example). For the rest of the users, there are three cases: - the user has accessed the application in the past (or any other webpage that uses the cdn): a cached version of the library is served by her browser. - the user has never accessed the page, the cdn is unavailable: * either the Internet connection has failed, and our application won't be available anyway * the cdn is indeed down, the user has to wait for the timeout before her browser fetches the local fallback. The third case sounds extremely rare (look at the statistics of major cdns out there, they often have better uptime and response time than your own servers). And the advantages provided by the first case do more than compensate in my opinion.

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 ago
It 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 ago
  if 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 ago
    We 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.

lerouxb 13y ago

Really? Have you ever sat through the experience of waiting for the primary source to time out so that the fallback can kick in?

moystard 13y ago
Ultimately, the timeout issue will be problematic for countries forbidding the access to cdns servers (ie China for example). For the rest of the users, there are three cases: - the user has accessed the application in the past (or any other webpage that uses the cdn): a cached version of the library is served by her browser. - the user has never accessed the page, the cdn is unavailable: * either the Internet connection has failed, and our application won't be available anyway * the cdn is indeed down, the user has to wait for the timeout before her browser fetches the local fallback. The third case sounds extremely rare (look at the statistics of major cdns out there, they often have better uptime and response time than your own servers). And the advantages provided by the first case do more than compensate in my opinion.