Polymer.js：Web 應用程序開發的未來？
已發表: 2022-03-11大約一年前的 2013 年 5 月，Google 推出了 Polymer.js。
所以我們在這裡，一年後。 問題是：它準備好迎接黃金時段了嗎？ 是否有可能使用 Polymer Web 開發技術創建生產就緒的應用程序？
為了回答這個問題，我帶 Polymer 進行了一次測試，以開發一個 Web 應用程序，看看它的表現如何。 這篇文章是關於那次經歷以及我在這個過程中學到的東西。
Polymer.js：概念
在我們進入 Polymer 教程之前，讓我們首先定義 Polymer.js，不是為了它聲稱的那樣，而是為了它實際上是什麼。
當您開始查看 Polymer 時，您不禁會立即被其自稱的獨特世界觀所吸引。 Polymer 聲稱自己採取了一種回歸自然的方法，“將元素重新置於 Web 開發的中心”。 使用 Polymer.js，您可以製作自己的 HTML 元素並將它們組合成可擴展和可維護的完整、複雜的 Web 應用程序。 這一切都是關於創建新的（即自定義）元素，然後可以以聲明的方式在您的 HTML 頁面中重用這些元素，而無需了解或理解它們的內部結構。
畢竟，元素是網絡的基石。 因此，Polymer 的世界觀是，Web 開發從根本上應該基於擴展現有元素範式以構建更強大的 Web 組件，而不是用“腳本”（用他們的話）代替標記。 換句話說，Polymer 相信利用瀏覽器的“本機”技術，而不是依賴於越來越複雜的自定義 JavaScript 庫（jQuery 等）。 確實是一個有趣的概念。
好的，這就是理論。 現在讓我們來看看現實。
Polymer Web 開發：現實
雖然 Polymer 的哲學方法當然有其優點，但不幸的是，它（至少在某種程度上）是一個超前於時代的想法。
Polymer.js 對瀏覽器提出了大量要求，依賴於許多仍處於標準化過程中（由 W3C 制定）並且尚未出現在當今瀏覽器中的技術。 示例包括 shadow dom、模板元素、自定義元素、HTML 導入、突變觀察者、模型驅動視圖、指針事件和 Web 動畫。 這些都是了不起的技術，但至少到目前為止，這些技術還沒有出現在現代瀏覽器中。
Polymer 的策略是讓前端開發人員利用這些領先的、即將到來的、基於瀏覽器的技術，這些技術目前正處於標準化過程中（由 W3C 提供）。 同時，為了填補這一空白，Polymer 建議使用 polyfill（可下載的 JavaScript 代碼，提供當今瀏覽器尚未內置的功能）。 推薦的 polyfill 的設計方式是（至少在理論上）一旦這些功能的本機瀏覽器版本可用，就可以無縫替換。
好的。 但讓我直截了當。 至少現在，我們將使用 JavaScript 庫（即 polyfills）來避免使用 JavaScript 庫？ 嗯，這很“迷人”。
因此，底線是我們處於 Polymer 的一種不確定模式，因為它最終依賴於（或者更準確地說，近似於）尚不存在的瀏覽器技術。 因此，今天的 Polymer.js 似乎更像是對未來如何構建以元素為中心的應用程序的研究（即，當所有必要的功能都在主要瀏覽器中實現並且不再需要 polyfill 時）。 但是，至少目前，Polymer 似乎更像是一個有趣的概念，而不是在此時此地創建強大的改變你的世界觀的應用程序的實際選擇，這使得編寫（或查找）Polymer 教程在外面變得困難谷歌的文檔。
聚合物架構
現在，進入我們的指南。 Polymer.js 在架構上分為四層：
原生：目前所有主流瀏覽器都原生提供所需的功能。 Foundation：實現所需瀏覽器功能的 Polyfills，這些功能在瀏覽器本身中尚不可用。 （目的是讓這一層隨著時間的推移而消失，因為它提供的功能在瀏覽器中本機可用。）。 核心：Polymer 元素利用 Native 和 Foundation 層提供的功能所必需的基礎設施。元素：一組基本元素，旨在用作可以幫助您創建應用程序的構建塊。 包括提供以下功能的元素： 基本功能，如 ajax、動畫、flex 佈局和手勢。 封裝複雜的瀏覽器 API 和 CSS 佈局。 UI 組件渲染器，例如手風琴、卡片和側邊欄。
創建聚合物應用程序
首先，有一些文章和教程文章可以幫助您了解 Polymer、它的概念和結構。 但是，如果您像我一樣，當您完成它們並準備實際構建您的應用程序時，您很快就會意識到您真的不太確定從哪裡開始或如何創建它。 既然我現在已經完成了這個過程並弄清楚了，這裡有一些指示……
Polymer Web 開發都是關於創建元素的，並且只是關於創建元素。 因此，與 Polymer 的世界觀一致，我們的應用程序將成為……一個新元素。 不多也不少。 哦，好的，我明白了。 這就是我們開始的地方。
對於我們的 Polymer 項目示例，我將命名應用程序的頂級元素
然而，下一步需要更多的思考。 我們需要決定如何組件化我們的應用程序。 一種簡單的方法是嘗試從視覺角度識別我們應用程序中的組件，然後嘗試將它們創建為 Polymer 中的自定義元素。
例如，假設我們有一個具有以下屏幕的應用程序：
我們可以確定頂部欄和側邊欄菜單不會改變，應用程序的實際“內容”可能會加載不同的“視圖”。
在這種情況下，一種合理的方法是創建
然後我們可以創建兩個主視圖，我們將它們稱為 ListView 和 SingleView，以加載到“內容”區域。 對於 ListView 中的項目，我們可以創建一個 ItemView。
這將產生一個類似這樣的結構：
好消息
現在我們有了示例 Polymer 應用程序，我們可以將其插入到任何網頁中，只需導入“toptal-app.html”並添加標籤
事實上，Polymer 範式的強大之處和美麗之處確實在於其中。 您為應用程序創建的自定義元素（包括整個應用程序的頂級元素）被視為網頁中的任何其他元素。 因此，您可以從任何其他 JavaScript 代碼或庫（例如，Backbone.js、Angular.js 等）訪問它們的屬性和方法。 您甚至可以使用這些庫來創建自己的新元素。
此外，您的自定義組件與其他自定義元素庫（例如 Mozilla 的 X-Tag）兼容。 因此，無論您使用什麼來創建自己的自定義元素，它都與 Polymer 和任何其他瀏覽器技術兼容。
因此，我們已經開始看到元素創建者社區的出現並不奇怪，他們在自定義元素網站等論壇上公開和分享他們新創建的元素。 你可以去那裡獲取你需要的任何組件，然後在你的應用程序中使用它。
另一方面…
Polymer 仍然是一種足夠新的技術，開發人員，尤其是新手應用程序開發人員，可能會發現它有些脆弱，有許多不那麼難發現的粗糙邊緣。
這是一個示例：
- 缺乏文件和指導。
- 並非所有 Polymer.js UI 和非 UI 元素都已記錄在案。 有時，關於如何使用它們的唯一“指導”就是演示代碼。 在某些情況下，甚至有必要參考 Polymer Element 的源代碼，以更好地了解它的工作原理以及可以/應該使用的方式。
- 如何組織更大的應用程序並不完全清楚。 特別是，你應該如何在元素之間傳遞單例對象？ 您應該採用哪種策略來測試您的自定義元素？ 在這一點上，關於這些類型問題的指導充其量是很少的。
依賴錯誤和版本問題。 即使按照推薦的方式下載 Polymer.js 元素，您也可能會發現依賴項錯誤，指向同一元素中的不同版本依賴項。 雖然據了解，Polymer Elements 目前正在大力開發中，但這類問題可能會使開髮變得相當具有挑戰性，削弱開發人員的信心和興趣。
- 移動平台上的問題。 Polymer.js 在移動平台上的性能通常介於令人沮喪和有問題之間。
- 下載整個庫和 polyfills（沒有 gzip'ing）很慢，你需要下載你打算使用的每個 Polymer Element。
- 在移動平台上處理 polyfill、庫和自定義元素似乎是一項昂貴的任務。 即使下載完成，您仍然經常會出現幾秒鐘的空白屏幕。
- 特別是對於更複雜的功能（例如拖放或渲染到畫布），您可能會發現在桌面上運行良好的功能在移動平台上無法正常運行或尚不支持。 在我的特殊情況下，我遇到的一個挫折是在 iOS 上渲染到畫布上。
- 錯誤報告不足或令人困惑。 有時，當您拼寫錯誤的屬性名稱，或者只是破壞了與核心層本身相關的內容時，您會在控制台上收到一條奇怪的錯誤消息，其中包含兩個調用堆棧，您需要對其進行調查以確定問題所在。 有時很容易解決這個問題，但有時你最終需要嘗試完全不同的策略來避免錯誤，因為你無法追踪它的來源。
結論
聚合物是一種有趣的技術，但不可否認它仍處於起步階段。 因此，它還不太適合開發大型企業級生產就緒應用程序。 此外，針對 Polymer.js Web 開發的指南或教程並不多。
至於以 JavaScript 為中心還是以 DOM 為中心的方法是否真的從根本上更好，尚無定論。 Polymer 提出了一些令人信服的論點，但確實存在相反的論點。
也許最值得注意的是，Polymer 在使用 DOM 等瀏覽器技術方面需要相當高水平的專業知識。 你在很多方面都回到了 jQuery 之前的日子，學習 DOM API 來完成簡單的任務，比如從元素中添加或刪除 CSS 類。 至少在某種程度上，這確實讓人感覺像是在倒退而不是前進。
但話雖如此，自定義元素似乎確實很可能在未來成為 Web 開發的重要組成部分，因此對於今天的 Web 開發人員來說，越早越好。 如果您以前從未嘗試過創建自己的自定義元素，Polymer（和本教程）可能是一個明智的起點。