英文原文：Yakov Fain，中文編譯：Flash開發者大會
本文是一段記錄談話，是我跟 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. 但如果你使用Ext 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工作。可以預見，我們公司將迎來很多有趣和富有挑戰性的專案，辛勤工作，我們不要抱怨。