js腳本的在線采購和最佳實踐有多強大

我來自一個R背景，我開始學習一些javascript用于資料可視化目的（想想，，，leaflet...... ）d3。chart

我試圖理解許多教程和模板建議直接從在線資源加載包、CSS 甚至資料的事實。例如，https ://leafletjs.com/examples/quick-start/建議：

在為地圖撰寫任何代碼之前，您需要在頁面上執行以下準備步驟：

Include Leaflet CSS file in the head section of your document:

 <link rel="stylesheet" href="https://unpkg.com/[email protected]/dist/leaflet.css"
   integrity="sha512-xodZBNTC5n17Xt2atTPuE1HxjVMSvLVW9ocqUKLsCC5CXdbqCmblAshOMAS6/keqq/sMZMZ19scR4PsZChSR7A=="
   crossorigin=""/>

Include Leaflet JavaScript file after Leaflet’s CSS:

 <!-- Make sure you put this AFTER Leaflet's CSS -->
 <script src="https://unpkg.com/[email protected]/dist/leaflet.js"
   integrity="sha512-XQoYMqMTK8LvdxXYG3nZ448hOEQiglfqkJs1NOQV44cWnUrBc8PkAOcXy20w0vlaXaVUearIOBhiXZ5V3ynxwA=="
   crossorigin=""></script>

并不是說你也不能做那樣的事情R。但是，由于來自“一種R文化”，我習慣于這樣的感覺，即我的代碼所依賴的每個包和資料都有一個本地“硬拷貝”。然后，當我發布我的代碼時（例如，當我發布一個Shiny應用程式時），所有必需的依賴項都會立即發布，因此它可以作為獨立的。我理解服務器存盤空間方面的缺點，但我的感覺是這可能更快，更不可靠。

我想知道的是我對在線采購及其權衡的理解是否javascript正確，如果是，解決潛在缺點的最佳實踐是什么。特別是：

• 我是否正確理解每次重繪 頁面時都會重新加載依賴https://unpkg.com/[email protected]/dist/leaflet.js項https://unpkg.com/[email protected]/dist/leaflet.css？
• 因此，該頁面依賴于那些不會中斷的鏈接，對吧？還是有一些我不知道的內部機制可以避免這種浪費的重新加載和冒險的依賴？
• 如果沒有，人們是否只能承受鏈接斷開的風險？還是最好的做法是保留腳本的本地副本https://unpkg.com/[email protected]/dist/leaflet.js并在本地獲取它們？甚至，是否還有另一種最佳實踐，例如使用“更安全的提供者”作為依賴項的來源（我是否正確理解這是https://www.jsdelivr.com/ 之類的服務的作用？）？

uj5u.com熱心網友回復：

我是否正確理解像https://unpkg.com/[email protected]/dist/leaflet.js或https://unpkg.com/[email protected]/dist/leaflet.css這樣的依賴項每次都會重新加載我重繪 頁面？

不，HTTP 客戶端執行快取。

因此，該頁面依賴于那些不會中斷的鏈接，對吧？

是的。（其中“破壞”包括“被防火墻阻止”（中國用戶的一個特殊問題，他們經常發現他們可以訪問網站但 JS 無法正常作業，因為它托管在被防火墻阻止的地方）和“ CDN 服務器被惡意人員接管")

人們只是忍受鏈接斷開的風險嗎？

是的。不過風險是相對的。通常選擇 CDN 是因為提供商是受信任的。

潛在的好處包括通過使用邊緣服務器的 CDN 更快地訪問 JS ，以及（至少對于流行的庫）客戶端可能已經快取了資料，因為另一個站點使用了相同的庫。

您還使用 CDN 主機的帶寬來服務 JS 而不是您自己的，這可以節省成本。

uj5u.com熱心網友回復：

我是否正確理解每次重繪 頁面時都會重新加載依賴https://unpkg.com/[email protected]/dist/leaflet.js項https://unpkg.com/[email protected]/dist/leaflet.css？

是和不是。這里重要的是快取。瀏覽器將快取已加載的資源。因此，如果用戶在頁面上反復點擊重繪 ，他們只會下載這些資源一次，并且每次重新加載都將使用快取的版本。因此，不，它們不會每次都重新加載。

但是，任何時候用戶清除快取或新用戶進入時沒有快取中的資源，則檔案將被下載。瀏覽器的快取過期不能完全預測，因為它在很大程度上是由用戶控制的。但是，如果用戶今天和下周使用相同的瀏覽器再次訪問，他們的快取中仍然有該專案。但是，如果他們的快取被重繪 ，或者他們使用不同的瀏覽器，或者不同的機器，或者訪問的是完全不同的用戶，那么是的 - 他們會再次加載資源。

因此，該頁面依賴于那些不會中斷的鏈接，對吧？還是有一些我不知道的內部機制可以避免這種浪費的重新加載和冒險的依賴？

內部機制是從上面快取的。但是，如果某個資源鏈接因某種原因而被洗掉，則該頁面將無法使用它。這可能是因為：

• 鏈接的來源不再有效。
• 源被防火墻或其他機制阻止，因此用戶無權訪問它。
• 用戶使用了一些阻止機制，例如廣告攔截器或腳本攔截器擴展，這意味著他們已選擇阻止對某些資源的請求。

在所有這些情況下，結果都是相似的：如果用戶擁有所需資源的快取副本，則他們可能有權訪問頁面的全部功能。否則，他們無法使用它們。不會執行腳本檔案，不會應用樣式表，不會顯示影像等。

解決這些問題的方法會有所不同：

• 對于非作業鏈接，您需要找到新的來源，甚至自己托管。
• 對于被阻止的資源，您可能需要找到一個可以接受阻止機制的托管站點。自托管可能是一種選擇。
• 如果用戶阻止了您的腳本，他們很可能需要取消阻止它們。盡管上述兩種方法的組合也可能有效 - 托管在不知道廣告的域上可能會避免被阻止，并且自托管也可能有效。至少在 uMatrix 的情況下 -默認情況下，插件會阻止頁面外部的所有腳本（很少有例外）。如果腳本來自同一個域，則默認情況下 uMatrix 將允許它們。

如果沒有，人們是否只能承受鏈接斷開的風險？還是最好保留腳本的本地副本，例如https://unpkg.com/[email protected]/dist/leaflet.js并在本地獲取它們？

這里基本上有兩種方法。每個都有自己的優點和缺點。快速細分是：

• 您可以接受外部托管的資源。

  • Advantage: There are several big content delivery networks (CDN) such as unpkg or jsdelivr. They are widely used for their reliability. In addition, some libraries might offer their own CDN - jQuery does that, for example. Getting the resource from a CDN saves you badwidth and space but can also improve the load speed. CDNs might have better speed than your hosting does. Furthermore, for widely used libraries, the CDN copy is likely to be cached on the user site from visiting another site that used the same CDN copy as you.
  • Disadvantage: it does leave you dependent on resources you do not control. Big CDNs are reliable but you still cannot have any direct control if anything happened. And if you use a smaller CDN (e.g., library specific or otherwise) then you do not have data about its reliability. If an external link dies, your website will not work until it is fixed and that might take days - you have to find out about it, figure out what was changed, hopefully find a replacement link, update the site. If you cannot find a drop-in replacement, you might need to make more changes.

• You can host the resources yourself.

  • Advantage: You are in complete control of when and how are things stored. You can even process the resources in some way to help with your application. Scripts can be minified, images can be scaled and resized into several different sizes to to optimise the display in different places (e.g., an icon, a small image, and a full size image).
  • Disadvantage: more space taken, more bandwidth taken. Also, now you have to manage all of these resources and make sure they exist, they are available etc.

You can of course also use a mixed approach. Host some resources, use others from an external place. Depends on what you want to do with your application and what level of control you want to retain versus how much extra effort and costs you want.

Saying all that, for a lot of small projects it does not matter that much which path is chosen. If you only use a handful of libraries it matters little whether you use them from a CDN or host them yourself. As long a reliable CDN provider is chosen, the chance of an outage is acceptably minimal. If you host the resources, chances are they would take up few hundred kilobytes (if that).

If your project grows and the list of dependencies you have starts to get bigger and bigger, it might be time to take stock and decide how where you host them and how you consume them. There is no single answer to this question, it will likely depend on what you already have. Perhaps your hosting has very little space. Or you pay per megabyte downloaded. In that case, external hosting would make more sense. Or perhaps you have a robust storage option for yourself and you are confident you can ensure the availability of your application, in which case self-hosting might be preferable

標籤：javascript html 稳健性

上一篇：Jqueryappendtodiv類選擇器

下一篇：打開/關閉側邊欄更改按鈕