企業開發：Flex or HTML5?

本文是一段記錄談話，是我跟 Anatole Tartakovsky 和 Victor Rasputnis 的談話內容，他們是我的商業伙伴，來自 Farata 系統，這次談話發生在我們滑雪后的雪山上。

        Yakov.有多種方法可以為它們的企業創建 Web 應用程序，這和給鄰居里的披薩店開發 Web 站點并不相同。在過去五年中我們一直主要使用 Adobe Flex 作為前端 Web 應用程序的開發。Flex 應用程序運行在可預測的運行時環境 Flash Player 中。可編譯 actionscript 代碼，并且擁有成套方便的開發工具。

        這些天，flex 的地位正在”新的戰略”中發生轉變。即使 Flex 仍然是用于開發 Web 應用程序的最佳框架，你仍然可以感覺 HTML5 的壓力。但是，只使用 HTML5 是不足夠開發 Web 應用程序的 —  你仍然需要 DHTML —  HTML、 JavaScript、 CSS 和 XMLHttpRequest 對象。

        Anatole. 過去我們使用它們進行開發，現在似乎我們再次進入同一水域，難道經過七八年后，它還是同一條河流？DHTML 在 ie5 中就有了，幾年后更名為 AJAX。

        Y. 回到 1999 年，微軟創建 XMLHttpRequest 對象，讓他們的郵件客戶端 Outlook Web 版本在瀏覽器窗口中不需要刷新整個頁面就能更新。這么做對嗎？

        A. 部分對吧。 IE5中也有 XSL 轉換工具生成 HTML 和支持自定義插件開發。IE5的市場占有率在 90％左右（指的是 1999 年），在企業，這是唯一核準的瀏覽器。

        Victor. 與此同時，IE5 支持 HTML 組件稱為 HTC 的模型。它允許您創建包含自定義組件的屬性和方法的 htc 文件，所有這些屬性在 Web 瀏覽器的 DOM 中是可見的 。

        A. 事實上，比起那些提供 HTML5 支持的框架，這是一個更加進步的模型。因為您可以使用一種標記語言結合 JavaScript 來支持您的組件。這種模式是類似于 Flex 所提供的。今天，我們看一些插件環境 ，允許使用各種框架。這種情況并沒有任何好轉。

        積極的一面，已更改的 Web 瀏覽器和 JavaScript 的性能大大改善。瀏覽器支持 12/6/8 每個域的連接 （相對于 2 五年前），這給 AJAX 應用程序帶來性能提升。

        Y.但讓我們實際點來說說，我作為一個企業的 IT 經理擁有有限的預算和 5 人團隊來開發 Web 應用程序。如果我使用可預測的基于良好開發環境的 Flex 或 Java 等(IDE，編譯器、 調試器、 分析工具) 我的工作會比較容易。但使用 JavaScript，情況就不同了。首先，使用 JavaScript 開發周期長 （光閱讀代碼的操作成本就高）。

        第二，我不光需要找到熟練的 AJAX 開發者，而且他們需要掌握一堆現代 JavaScript 框架。

        第三，編譯器不捕獲程序員錯誤，所以我需要分配更多的時間進行測試。維克托，你怎么看這個？

        V.如果你問我有什么大變化 — — 就是感覺。在這世紀之初，我們工作在 DHTML 環境中。只有少量的開發者參與這種”令人懷疑”的開發。企業架構師也難采用這一 pre-AJAX 模式，并且經常問同樣的問題，”這不是 J2EE，對嗎？”，我們會回答，”對，它不是”。然后，很顯然，就被劃歸到業余產品。

        在過去六年，用 Flex 開發慢慢成為核準的企業技術 – 它可編譯，可控制的環境，具有良好的性能、 測試工具和國際化支持。然而，adobe 竟然對 flex 不管不顧了。

        Y.他們處理的方式可以列入教科書作為極壞的公關例子，而不是什么值得驕傲的在 2011 年 10 月舉行的 Adobe MAX 大會上宣布將 flex 捐獻給 Apache 基金會，博得大家起立鼓掌。事后才一個月，他們又發布消息宣布，adobe 將不再支持 flashplayer (Flex 運行庫) 瀏覽器插件。這聽起來像是，他們想要殺死 flex。但是，我們都知道 flex 還活著！

        V. 是的它是活著。從技術上講，它仍然是開發 Web 應用程序最理想的環境，但政治上成為過去的產品。

        Y.現在很多企業創建者會說，”5年前我們告訴過你與 JavaScript 呆在一起的…”，但我想聽聽你們的觀點，關于使用 Flex 與 JavaScript 開發的成本，那一樣更貴？

        V.這取決于管理這個項目的人的類型。如果一個企業的經理人是一個臨時的角色。他工作6-12個月后，可能被轉移到另一個位置，或者離開公司。他對最終結果是不感興趣的，他可以在特定的時間內，留在預定的范圍內，但該項目從長遠來看可能會失敗。

        JavaScript 開發者每小時工資，低于那些知道 Flex 的開發者。而使用 Flex 開發更容易，結果似乎很好與基于 JavaScript 的應用程序進行比較。用 Flex 開發費用可能最初更多，但產生更好的結果，而這對于企業經理人來說并不重要。

        Y. 是的企業經理人的主要目標是往上爬和獲得良好的獎金和退休金，而不是創建先進的應用程序。

        V. 他們不總是要往上爬。有時他們跳槽到另一家公司，在相同的位置會帶來更多的錢或其他職業機會。這就是為什么對于這些企業經理人來說，特定項目的成功可能優先級較低。

        Y.所以哪個更昂貴 — — Flex 還是 JavaScript 項目？

        V. 如你所知，在 Farata 系統，我們用 Flex 開發所有的內部項目。但是，如果客戶打算為 JavaScript 打開他們的錢包，我們也很樂意幫助他們。

        A.如果你想用 Flex 和 HTML5 開發兩個完全相同的項目，HTML5 項目將更加昂貴的可能性很大。但我懷疑，有人甚至嘗試用 HTML5 項目來達到 Flex 級別的質量。首先，任何 HTML5 企業項目會有較低的要求。從基本的參數，如可靠性，能夠適應不同屏幕大小和簡化密度。實現這些功能，將在包括七個瀏覽器中測試通過才行，測試和開發人員將 花費大部分時間在調試中。

        你會節省編譯的時間，但會花更多時間運行時測試。最后 HTML5 項目可交付的結果可能不到 Flex 開發項目的一半。但是，您將獲得一點 Web 適應性強、 容易執行全文搜索和聚合的優勢。與其他技術的集成也將變得更容易。使用 HTML/JavaScript。你得決定對于您的應用程序來說這些優勢是否都是重要的。如果是，就選擇 HTML5。

        但通常 HTML 部分這是只是整個項目的冰山一角。基本功能通常在 Java 或 .Net 開發，后臺辦公應用程序無論如何都要使用 Flex 作 UI 開發 。

        Y. 踏著 HTML5 標志的所有這些人會很高興地開始新的 JavaScript 項目，因為它適用于任何地方，它是免費的，許多開源的框架，不屬于這些財大氣粗的公司，如 Adobe。在過去，恨透了微軟，在 2012 年年初，又恨透了 Adobe。你可以做任何事情，刪減任何角落，去掉功能，但不要使用 Flex 啟動一個新項目。這樣，我們就屬于主流 – 我們將使用 JavaScript 開發。

        A.是的，但是 JavaScript 將限制任何重大和復雜的企業項目。您可以開發一些相當獨立的窗口，但在 HTML 中創建一個好調試的應用程序 （不是站點） 并非易事。

        現在讓我們返回到瀏覽器的性能大幅度提高的前提。由于 JavaScript 框架開始支持不同的瀏覽器，在性能和總體用戶體驗方面，減小了 Flex 和 JavaScript 應用程序之間的差距。我建議建立前端和后端的辦公應用程序之間的明確的邊界。你不用擔心外部用戶的生產力。但如果是企業內部用戶（內勤），他們每個人是工 薪階層，他們需要更好的生產力。

        我們花了六年多時間在在 DHTML 上。我們寫我們自己的框架和為財富 100 強企業實施 DHTML 企業應用。我們知道，在這些環境中的所有漏洞，和那些仍然未打補丁的的。截至今天，你無法比擬 Flex 和 DHTML。但也有一些狹窄的領域，在那里你必須為 Flex 應用程序補充 DHTML。

        大多數企業應用程序的前端，后端，和內部辦公（支持錯誤修復等）。前端層可以包含 DHTML 和 Flex 部分，因為今天開發前端和后臺辦公應用程序是在相同的環境。

        Y.讓我們談談在市場上的 JavaScript 框架的情況。五年前有約 200 種框架。在 2012 年的形勢是有一點點不同 — — 我們說的數十個 JavaScript 框架。但盡管如此，沒有一種框架能涵蓋所有 Web 應用程序的需要。維克托，你怎么看？

        V. Adobe 動搖了 Flex 世界之后，我很震驚了一會兒。然后我意識到任何好的工具或環境總有一天會被新事物替代。花一些時間研究現在市場的 JavaScript 框架之后我注意到，框架有兩個主要類別：

        a) 那些允許你以現有的 Web 站點為基礎，并由一根魔杖，將新屬性添加到所有或某些標記上，他們會開始閃爍，閃耀，或做一些其他有趣的東西。這種框架不提倡基于組件的開發。他們可能不 包含導航組件、 網格、 樹，正如阿納托爾所說，它們是非常典型的企業開發任務中的用于 UI 的框架。

        b)類似于 Flex 提供高級別的組件，它們可能基于標記，并且在 Flex 中編碼，每當你需要知道 Flash Player 內幕時，你甚至能夠深入挖掘此類組件。但總體而言，此類組件是為了解決不同的問題 — 顯示和 CSS 在這里不太重要。這些組件主要處理某些事件，提供模型-視圖-控制器的支持等等。

        通過進一步分析，我學會了 Ext JS 框架，它跟 Flex 相似，但沒有提供編譯，數據綁定，而且更少的控制。

        我經常舉一個例子，假如一只貓，從我的手提電腦的鍵盤上跑過，而此時我正好在文本編輯器中打開著一個 JavaScript 文件。面即使我沒有注意到這一點，我還是可以成功簽入此文件到代碼庫，但過后可能無法正常工作。由此可見未編譯環境是危險的地方。

        Y.你這個示例，是否也可以用到那些有狗的開發者身上？

        V. 可以，但錯誤的數量將增加。

        Y.目前，開發者軍團正轉向 JQuery 框架。但我們縱向討論。如前所述，JQuery 有利于提高現有 JavaScript 站點。Ext JS 使你開始設計應用程序的用戶界面更接近面向對象的原則。Ext JS 具有豐富的用戶界面組件，集加載程序，提供事件模型 — 這是一個不同和更好的方法，阿納托爾，你認為是嗎？

        A.現在我主導項目使用這兩種框架。JQuery 是一種小型的框架 （明智的代碼），它可用于開發大約 80% 的 Web 站點。您應該使用它的外觀和用戶交互體驗的功能。但是，您不能將它用于構建您的應用程序組件模型。Ext JS 的組件模型適用于約 20% 的 Web 站點，其中包括應用程序模塊，而不是只是一組 Web 頁。通常它是重要的視圖導航或向導，用來執行重要業務流程，或者工作流包含客戶端的部分。

        Y.Data grid，哦，好…

        A.是的，高級別組件和工作流因為用戶通常需要執行幾個步驟來完成業務流程。而這些應用程序的 20% 將需要花費項目 80% 的開發時間。所以，你不需要在這兩個框架之間作出選擇。我的 AJAX 項目的主要問題不是選擇什么框架去開發，而是找到合適的軟件開發者。

        V.絕對，極端的專注和注意力是必須的。

        Y.或者你可以使用更多的框架，幫助測試。

        V.一切必須徹底反復測試。在 JavaScript 中重構是一場噩夢。

        A.軟件開發人員必須記住— 所有未完成的代碼。我們的許多在已編譯的語言中很有把握的代碼，在 JavaScript 中都是不支持的。

        值得一提的另一類用 Java 開發的框架， 用于生成進一步的 JavaScript，這是一個有爭議的想法，因為寫代碼之后，您需要調試它。這時你將認識 JavaScript，這是你的一門外語。

        Y.我猜，你的意思是 GWT。為什么這是一個胎死腹中的主意，有一很大原因。 JavaScript 和 Java 編程的的思想和心理都不相同。五年前，我已經寫了 articledemonstrating 講了 Cobol、 Java、Lisp 程序員如何以不同的方式解決同一任務。我想，是時候將 JavaScript 版本添加到此示例中了。

        A. 在寫 Java/GWT 的人已經知道如何讀懂和解釋在調試器中的 JavaScript 代碼。另外，GWT 隱藏了很大一部分 JavaScript 功能。

        Y. 加上 Java 不支持動態 programming…

        A. 并非太多人使用動態編程，但是這將很好的改變語言。二十年前，有混合的語言，允許使用點符號，要求一些代碼片段，來執行一些動態和靜態編程。我們有一個選擇，要么操作員編譯，要么在運行時解釋。作為開發者，我的心態難以平復，直到 JavaScript 支持這項功能。

        V. 阿納托利，通過多年，人們才接受一種解釋型語言（JavaScript 中，ActionScript 中，等）在瀏覽器內運行的概念？

        A.這個問題在許多年前就提出了 – 記得 curl 語言嗎？這些語言在R＆D …

        V.但他們從來沒有成為 Web 瀏覽器使用的標準。

        A.完全正確！蘋果禁止讓 Flash Player 進入其流行的設備中，這成為 Flex 發展的一個巨大的障礙。如果一些廠商決定在他們的設備中不允許任何其他語言或環境，殺死這些新的想法，同樣的事情也可能發生。例如，Google 推出了一種新的語言稱為 Dart，但微軟表示，“不，我們將改進 JavaScript。”

        Y.JavaScript 框架承諾向你隱藏所有不兼容，并做到定制功能，如果供應商不要他們的某些功能。

        A.我不認為任何人可以將世界文學翻譯成 tribe Tumba-Yumba 這種表現力非常有限的語言。這就是為什么不同語言適合不同的任務或大小不同的應用程序。JavaScript 只是一種非常基本的語言。

        V. 但如果你使用 Ex t JS，他們的文檔建議使用 ext.create 方法替代 new 操作。從技術上講，他們是擴展或替換 JavaScript 本身的結構。任何框架架構師，他要創建一個受控的環境，就會闖進 JavaScript 的困境里去。

        A.部分是正確的。如果你想創建一個真正的動態或靜態的帶有錯誤檢查和運行時編譯的語言，你會設置它們的數據為強類型，從而可以拋出異常。

        C + + 支持操作符重載，人們使用了一段時間這個功能。但它并沒有持續多久 – 他們意識到，閱讀和理解自己的代碼變得十分困難。如果一種語言允許你寫一段很難理解的代碼 – 那最好是刪除此代碼。

        V.我想添加一個對 JavaScript 和 ActionScript 進行比較的話題……我感到不舒服的是別人會讀，支持，重構我的 JavaScript 代碼。其實，我在幾個月后都會很難受的重構自己的 JavaScript 代碼。在非編譯的環境中，它很棘手。我不記得函數特定的參數是什么類型。

        在編譯環境中，我一直都知道每一種對象的類型，是否一個對象仍然有某個屬性，或者被移除。但是在解釋環境中沒有這些。

        A. 你可以研究代碼，打開每一個基類，檢查參考，并找出它的屬性是什么 – 語言將幫助你。在我 26 歲時，我喜歡動態語言，開發經理也聘請年輕，很熱情，但經驗不足的開發人員。

        V.今天的勞動力市場，由這樣的人組成 — — 價格便宜、 熱情，和缺乏經驗。

        A. 關于 Ajax 的項目，這樣的開發人員將花費前兩個月的時間學習，第三個月，他將開始工作，并在 6 個月內退出，退出的原因很簡單 – 開發已經很困難，項目到達了窮途末路。當此類項目的代碼庫達到臨界點，發展過程將被卡住。

        V. 開發者退出也不一定是因為該項目卡住了。開發者在就業市場會獲得更有價值的信息。

        A. 換句話說，該項目將停止在5-6個月內 – 它變得無力的，因為它的項目規模。這就是為什么我想強調的 AJAX 項目和編譯環境中正在開發的項目，如 ActionScript 項目，有很大的區別。

        Y. 我想回到 JavaScript 框架和瀏覽器的兼容性問題。我喜歡電視機的比喻。即使我的最新，最偉大的 3D 液晶高清電視機，你有一個 30 年前的黑白電視，我們都可以觀看同一部電影，即使畫面的質量會有所不同。在如今，可以說“用戶體驗會有所不同。”

        現在讓我們來談談瀏覽器。你可能使用最新的谷歌瀏覽器，但我是企業用戶，使用 IE 6。JavaScript 應用程序，如何確保在這兩種瀏覽器上做到相同效果？

        V. 框架的核心部分，嘗試解決瀏覽器的兼容性。他們盡可能在其限制范圍內確保每個網頁在每個瀏覽器中盡可能好的工作。

        A.我不同意。在我看來你不需要通過框架的層級來解決瀏覽器的兼容性，只需要把你的應用程序在不同的瀏覽器中測試和調整就可以了。

        V. 是的，我已經開始對框架作一些修改，對于任何支持框架的廠商而言，保持兼容性是一個巨大的挑戰。我記得我們在本世紀初創建的 XMLSP 框架。我們有一個大不列顛的客戶說，“這個產品是比你的公司大”。如果我沒有記錯，我們有五人在 XMLSP 上工作。

        我敢肯定，Sencha 有更多的開發者為 Ext JS 工作，這是一個前所未有的大框架。大部分的代碼庫和任務，正在努力實現 Adobe Flex 的功能。這也難怪，任何這樣的框架都始終需要修復和改進。

        我沒有懷恨，當我在別人的框架內進行修復時。我知道這些家伙只是沒有時間搞定一切。您需要構建一個 JavaScript 框架類似于一個好的樂高玩具集，很需要你的創造力，別生氣的態度。花一些時間在框架上來治愈框架，然后在您的應用程序代碼上工作，至少這是我當前看到的狀 態。

        A. 重新措辭一下要么使用的簡單框架組件，但不解決兼容性問題，要么準備卷起袖子，了解框架底下是什么，重新為你的項目配置人員，不僅是應用程序開發人員，還包括系統工程師，還有那些要花一半時間自定義框架的人。

        V. 這么看來框架也成為你的產品了。我不同意在自定義框架上花一半的時間。這一切都依賴于長期計劃。您押注在一個特定的框架，并計劃使用多年，而不是投入改進，但這個框架只是為解決一個項目需要，只適用于一些補丁和變動。在大多數項目修補一個框架就足夠了。

        Y. 總之，JavaScript 開發人員將需要面臨跟 Java，JavaFX，Silverlight 或 Flex 開發者相同的任務：

        - 通信的可靠性。如果數據沒有到達服務器或從服務器發出？是否有可能恢復丟失的數據？從哪里獲得丟失的數據？我們可以重新發送丟失的數據？并重復做什么？

        - 您的應用程序的模塊化。如果用戶沒有點擊在主屏幕上的某些菜單項目，就不加載到應該處理此菜單的代碼。

        - 如何快速將應用程序的主窗口加載到用戶的計算機？框架的核心代碼是否沉重？

        - 在哪里存儲應用程序的狀態 - 在服務器還是客戶端上呢？

        - 框架是否提供了豐富的組件庫？

        - 框架是否支持創建松耦合的應用程序組件？是否有精心設計的事件模型？

        - 你選擇的框架內有沒有覆蓋大部分應用程序需要，或者你需要使用幾個框架？

        - 是否有寫很好的參考文檔可用？

        - 是否有一個活躍的社區，可以幫助你解決技術問題？

        我能繼續在這個清單中添加項目。因此，如果 HTML5 這個字眼很容易讓你感到興奮，那么冷靜下來吧。它不只是添加一個視頻標記到網頁中。這是一項艱苦的 JavaScript 工作。可以預見，我們公司將迎來很多有趣和富有挑戰性的項目，辛勤工作，我們不要抱怨。

        英文原文：Enterprise Development: Flex or HTML5?