本節書摘來自異步社群《第三方javascript程式設計》一書中的第1章，第1.3節，作者： [美] ben vinegar anton kovalyov 譯者： 郭凱 更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
在本章前兩小節中我們探讨了一些第三方javascript的流行用法。你已經了解了在開發微件、資料收集、作為用戶端web服務的api封裝等方面是如何運用到它的。希望這能夠給你一些啟發，當你設計自己的第三方應用程式時候能夠了解哪些功能是能夠實作的。
現在，你已經看過了一些現實中的執行個體，是時候開發一些自己的東西了。讓我們先從相對簡單的入手：一個極其簡單的嵌入式微件。
假設你在運作一個提供當地最新天氣資訊的網站。一般而言，使用者直接通路你的網站是為了獲得最新的天氣消息。但是為了使使用者更廣，你決定更進一步，讓使用者可以在你的網站之外通路你的資料。你可以通過提供一個可嵌入的微件服務做到這一點，如圖1.7所示。你需要向那些有興趣通過引入第三方腳本即可為自己的使用者提供本地天氣資訊的網站釋出者推廣這個微件。
幸運的是，你已經找到了一個對此興緻盎然的網站釋出者，而且他們已經開始試着使用你的微件了。為了讓他們能夠使用，你需要給他們提供html代碼片段，進而在他們的web頁面上加載天氣微件。網站釋出者需要将代碼片段粘貼到他們的html源代碼中想要展現微件的位置。代碼片段本身很簡單：即一個
标簽指明weathernearby.com所在伺服器上第三方javascript的路徑：
你會注意到腳本的url中包含了一個zip參數。通過這個參數你就可以識别需要渲染什麼位置的天氣資訊。
此時，當浏覽器加載釋出者的web頁面時，遇到這個
标簽就會向weathernearby.com的伺服器請求widget.js腳本檔案。當widget.js下載下傳完畢并且執行後，就會在釋出者的頁面上渲染出天氣微件。不管怎麼說，這就是我們想要達到的效果。
要做到這些，widget.js需要有權限通路公司的天氣資料。這些資料可以直接釋出到腳本檔案中，但是考慮到美國大約有43 000個郵政編碼，這樣一來，一個請求中會有太多的資料。除非使用者從瑞典或者南韓通路，因為這兩個國家100mbit/s的傳輸速度是常态。在通常情況下，微件需要請求天氣資料可以通過使用ajax來完成。為了簡單起見，我們使用另一種不同的方式：服務端生成腳本。
1.3.1 服務端生成腳本
與提供一個包含微件代碼的靜态javascript檔案不同，你需要寫一個服務端應用為每個請求生成一個javascript檔案，如圖1.8所示。因為伺服器能夠通路天氣資訊的資料庫，它可以将所請求的天氣資料插入到輸出的javascript檔案中。這就意味着，在釋出者頁面上渲染天氣微件的所有代碼和需要的資料都包含在javascript中，而無需發起任何額外的請求。
這個服務端應用可以用任何程式設計語言或者能夠在伺服器環境運作的平台，像ruby、php、java、asp.net——甚至服務端javascript，這些都是很不錯的選擇。本例中，我們選用很受歡迎的腳本語言python來進行示範。本例用到了flask，一個基于python的小型架構，用于建構小型web應用。如果你并不熟悉python，也不用擔心——代碼很容易了解。如果你想自己嘗試程式清單1.5中的例子，可以參照配套的程式源碼，程式源碼中同時也包含了安裝python(2.x)和flask的介紹。
為什麼選用python
本書中一小部分服務端的例子都是使用python語言。我們選用這種程式設計語言完全是因為偏愛：它是我們在disqus每天都在使用的語言，并且我們對它最熟悉。倘若你不知道如何使用python也沒關系。本書首先是一本關于javascript的書，服務端的例子可以很容易的使用其他語言代替。
當這個服務端腳本啟動後，一個請求
的
标簽将傳回如下javascript代碼。進而渲染出你在本節開頭看到的示例微件，如圖1.7所示。同時，注意這些代碼是python應用産生并且對于浏覽器請求而言是完全透明的。
現在看來，這是一個極其簡單的例子，并不是開玩笑。這個毫無樣式輸出的天氣微件幾乎沒有為使用者提供互動界面。看似非常糟糕，而且可能會将你剛起步的公司陷入困境。但是它能夠工作，而且展示了釋出者網站同第三方代碼之間的互動。
這裡提及的一些技術，像使用document.write和服務端的python，都不是唯一生成微件的方式。不要皺眉，我們稍後會解釋原因。在後邊的章節中，我們将探讨更好的替代方案，并介紹更為複雜的功能，如樣式表，通過ajax進行服務端通信以及使用者間會話。
1.3.2 通過iframe分發微件
如果你對于web開發相當有經驗，可能會有這樣的想法，“是不是通過iframe分發這個微件更容易？”乍一看似乎如此，但是有一些潛在的差異使得第三方腳本成為了更好的實作選擇。為了知其是以然，首先我們看一下如何通過iframe重新建立之前的微件示例。
iframe是塊級html元素，用來從url嵌入外部内容。如果你對它并不熟悉也能夠完全通過一個iframe元素很容易的重新實作天氣微件示例，如下。
你會注意到src屬性改變了：不再指向一個javascript檔案，而是指向一個html文檔。這一次你的伺服器将傳回一個完整的html文檔，包含了微件的标記，完全避免了使用javascript。你也會注意到微件的尺寸作為iframe的style屬性的一部分。iframe元素并不會擴大以适應其内容，是以需要為iframe設定明确的尺寸。
像這樣使用iframe将産生同javascript示例相同的輸出。那為什麼要使用javascript代替iframe呢？有很多的原因，其中大部分原因都圍繞iframe的特性：通過iframe加載的外部内容不能被父頁面通路（釋出者的頁面），反之亦然。
靈活性：如果你希望改變微件的尺寸，就沒有那麼幸運了。因為iframe的尺寸是在父頁面中iframe标簽中指定的，而且這些屬性不能被iframe加載的内容更改，是以沒有辦法動态的改變微件的尺寸。
美學：微件的外觀需要完全獨立于父頁面的樣式。微件将不能繼承基礎的樣式，例如字型種類、字型大小或顔色等。
互動：微件需要通路或者修改釋出者頁面的dom嗎？釋出者是否需要在微件的内容上附加一些互動？是否會有多個微件執行個體存在并且互相通信的情況呢？這些通過靜态iframe都不可能做到。
報表：浏覽器使用者是否真能看到微件？在看到它之前，他們在頁面上耗費了多長時間？收集這些和其他有價值的資料都需要在釋出者頁面上運作javascript。
這些隻是一些簡單的例子，但是你或許能看到一種趨勢。iframe或許是天氣微件示例最簡單的分發方式，但是這麼做你将失去第三方javascript提供的衆多引人注目的能力。但是，不要讓它改變了你對iframe的看法。它們是第三方javascript開發者工具集中一個寶貴的資産，在本書不同的任務中，我們都會頻繁地用到它們。