整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
reamweaver對一個web前端工作者來說，再熟悉不過了，像我07年接觸web前端開發就是用的dreamweaver，一直用到現在，身邊的朋友有跟我推薦過各種更好用的可替代dreamweaver的工具，一開始我是拒絕的，但是后來我發現竟然真有比dreamweaver好用的工具，智能提示，自動補全工具，模糊編碼這些用上手了以后根本停不下來，sublime text當之不愧是最佳替代方案第一選擇。
1. Sublime Text
Sublime Text2是一款跨平臺的編輯器，再也不用為換平臺而找不到合適的、熟悉的編輯器擔憂了。
Sublime Text2 是一款具有代碼高亮、語法提示、自動完成且反應快速的編輯器軟件，不僅具有華麗的界面，還支持插件擴展機制，用她來寫代碼，絕對是一種享受。
Sublime Text 2 的特色功能：
良好的擴展功能，官方稱之為安裝包(Package)。
右邊沒有滾動條，取而代之的是代碼縮略圖，這個功能非常贊
強大的快捷命令“可以實時搜索到相應的命令、選項、snippet 和 syntex， 按下回車就可以直接執行，減少了查找的麻煩。”
即時的文件切換。
隨心所欲的跳轉到任意文件的任意位置。
多重選擇(Multi-Selection)功能允許在頁面中同時存在多個光標。
支持 VIM 模式
支持宏，簡單地說就是把操作錄制下來或者自己編寫命令，然后播放剛才錄制的操作或者命令。
更新非常勤快
2. TopStyle5
TopStyle 是一款 CSS 開發輔助工具，即 HTML5 / CSS3 編輯器，它專注于 HTML CSS 設計輔助，提供比較多的功能，如 CSS 代碼檢查等，據稱 TopStyle 的幫助文件非常好，有詳細的 CSS 指令，適于初次接觸 CSS 的學習之用。
不過如果你想對 CSS 了如指掌，對 CSS 網頁布局非常熟練，還是扔掉一切輔助軟件，用記事本開發，而熟練 CSS 之后，再使用此類輔助軟件，可以提高工作效率和開發速度。
TopStyle 5 在 CSS3 / HTML5 方面的增強：
*??CSS3 for Inspector, Insight and Style Checker
*??Prefixr
*??CSS3 Media Queries
*??CSS Gradient Generator
*??Text Shadow Generator
*??Improved options for Preview Files (CSS-only)
*??HTML5 for Inspector and Insight
*??HTML5-only Validator
*??HTML Structure Panel
*??Wrap HTML Tag
*??Image Map Editor (HTML-only)
3. Chocolat
Chocolat是Mac系統上最新出現的一款強大的文本編輯器，兼具原生的Cocoa及強大的文本編輯功能。Chocolat支持多種編程語言的關鍵字高亮顯示、窗口分割、標簽頁、色彩主題等功能。界面和MacVim非常相似。
4. Aptana
Aptana 是一個非常強大,開源,專注于JavaScript的Ajax開發IDE。它的特性包括： *JavaScript,JavaScript函數,HTML,CSS語言的Code Assist功能。 *Outliner(大綱)：顯示JavaScript,HTML和CSS的代碼結構。
*支持JavaScript，HTML，CSS代碼提示，包括JavaScript 自定函數
*代碼語法錯誤提示。
*支持Aptana UI自定義和擴展。
*支持跨平臺。
*支持FTP/SFTP
*調試JavaScript
*支持流行AJAX框架的Code Assist功能：AFLAX，Dojo，JQuery，MochiKit，Prototype，Rico，script.aculo.us，Yahoo UI，Ext。
*Adobe AIR與iPhone開發工具
5. Komodo IDE
Komodo 是一個跨平臺支持多種程序語言的Integrated Development Environment （IDE）軟件，目前他支持了在Windows與Linux上 ，Pythone, Ruby, Rails, Perl, HTML, CSS, and JavaScript,等的程序語言開發，以及多種程序語言語法著色。
6. Eclipse
Eclipse是 著名的跨平臺的自由集成開發環境（IDE）。最初主要用來Java語言開發，但是目前亦有人通過插件使其作為其他計算機語言比如C++和Python的開 發工具。Eclipse的本身只是一個框架平臺，但是眾多插件的支持使得Eclipse擁有其他功能相對固定的IDE軟件很難具有的靈活性。許多軟件開發 商以Eclipse為框架開發自己的IDE。
Eclipse的基礎是富客戶機平臺（Rich Client Platform, 即RCP）。RCP包括下列組件：
核心平臺(啟動Eclipse，運行插件）
OSGi（標準集束框架）
SWT（可移植構件工具包）
JFace（文件緩沖，文本處理，文本編輯器）
Eclipse工作臺（即Workbench ，包含視圖（views）、編輯器（editors）、視角（perspectives）、和向導（wizards））
Eclipse采用的技術是IBM公司開發的（SWT），這是一種基于Java的窗口組件，類似Java本身提供的AWT和Swing窗口組件；不 過IBM聲稱SWT比其他Java窗口組件更有效率。Eclipse的用戶界面還使用了GUI中間層JFace，從而簡化了基于SWT的應用程序的構建。
Eclipse的插件機制是輕型軟件組件化架構。在富客戶機平臺上，Eclipse使用插件來提供所有的附加功能，例如支持Java以外的其他語 言。 已有的分離的插件已經能夠支持C/C++（CDT）、Perl、Ruby，Python、telnet和數據庫開發。插件架構能夠支持將任意的擴展加入到 現有環境中，例如配置管理，而決不僅僅限于支持各種編程語言。
Eclipse的設計思想是：一切皆插件。Eclipse核心很小，其它所有功能都以插件的形式附加于Eclipse核心之上。Eclipse基本內核包括：圖形API (SWT/Jface)， Java開發環境插件(JDT )，插件開發環境(PDE)等。
Eclipse由各種不同的計劃組成。以下列出了部分計劃。
Eclipse計劃：本身包括Eclipse平臺，Eclipse富客戶端平臺（RCP）和Java開發工具（JDT）。
Eclipse測試和性能工具平臺（TPTP）：提供一個允許軟件開發者構建諸如測試調試、概況分析、基準評測等測試和性能工具的平臺。
Eclipse Web工具平臺計劃 （WTP）：用Java企業版Web應用程序開發工具來擴展Eclipse平臺。它由以下部分組成：HTML、JavaScript、CSS、JSP、SQL、XML、DTD、XSD和 WSDL的 源代碼編輯器；XSD和WSDL的圖形界面編輯器；Java企業版的“項目性質”（project nature）、建構器（builder）和模型（model），與一個Java企業版的導航（navigator）；一個Web服務（Web service）向導和瀏覽器，還有一個WS-I測試工具；最后是數據庫訪問查詢的工具與模型。
Eclipse商業智能和報表工具計劃（BIRT）：提供Web應用程序（特別是基于Java企業版的）的報表開發工具。
Eclipse可視化界面編輯器計劃（VEP）：一個Eclipse下創建圖形用戶界面代碼生成器的框架。
Eclipse建模框架（EMF）：依據使用XMI描述的建模規格，生成結構化數據模型的工具和其他應用程序的代碼。
圖形化編輯器框架（GEF）：能讓開發者采用一個現成的應用程序模型來輕松地創建富圖形化編輯器。
UML2：Eclipse平臺下的一個UML 2.0元模型的實現，用以支持建模工具的開發。
AspectJ：一種針對Java的面向側面語言擴展。
Eclipse通訊框架（ECF）：專注于在Eclipse平臺上創建通訊應用程序的工作。
Eclipse數據工具平臺計劃（DTP）
Eclipse設備驅動軟件開發計劃（DSDP）
C/C++開發工具計劃（CDT）：努力為Eclipse平臺提供一個全功能C和C++的集成開發環境（IDE），它使用GCC作為編譯器。
Eclipse平臺COBOL集成開發環境子計劃（COBOL）：將構建一個Eclipse平臺上的全功能COBOL集成開發環境。
并行工具平臺（PTP）：將開發一個對并行計算機架構下的一組工具進行集成的平行工具平臺，而且這個平臺是可移植的，可伸縮的并基于標準的。
嵌入式富客戶端平臺（eRCP）：計劃將Eclipse富客戶端平臺擴展到嵌入式設備上。這個平臺主要是一個富客戶端平臺（RCP）組件子集的集合。它能讓桌面環境下的應用程序模型能夠大致同樣地能運用在嵌入式設備上。
但是我個人用的其實還是國產的hbuilder，有點像中文版的sublime text，sublime text提供了很多自動補全，提示等插件，而hbuilder則集成了這些，像我這種懶人就更偏向于傻瓜化點的。
----------------------------
切圖網（qietu.com）是一家專門從事web前端開發的服務機構，長期致力于提供高品質的psd轉html5、響應適配、webapp切圖，h5切圖等web前端開發服務。
專注web前端開發技術，關注用戶體驗，加我們公眾微信賬號：qietuwang（長按復制）
言
以前的項目大多數都是Java程序猿又當爹又當媽，既搞前，又搞后端。
隨著時代的發展，漸漸的許多大中小公司開始把前后端的界限分的越來越明確，前端工程師只負責前端的事情，后端工程師只管后端的事情。正所謂術業有專攻，一個人如果什么都會，那么每一樣都很難達到精通。
大中型公司需要專業人才，小公司需要全才，但是對于個人職業發展來說，我建議是分開。你要是這輩子就吃 Java 這碗飯，就不要去研究什么 css，js 等等。
把你的精力專注在 Java，JVM 原理，Spring原理，mysql鎖，事務，多線程，大并發，分布式架構，微服務，以及相關的項目管理等等，這樣你的核心競爭力才會越來越高，正所謂你往生活中投入什么，生活就會反饋給你什么。
曾幾何時
我們的Java Web項目都是使用了若干后臺框架進行開發，Spring、Spring MVC、MyBatis、Hibernate等等。
而且大多數項目在Java后端都是分了三層，控制層、業務層、持久層。控制層負責接收參數，調用相關業務層，封裝數據，以及路由到JSP頁面。然后Jsp頁面上使用各種標簽（jstl/el）表達式將后臺的數據展現出來。
我們先看上述這種情況，需求定完了，代碼寫完了，測試測完了，然后發布：
你需要用maven或者eclipse等工具把你的代碼打成一個war包，然后把這個war包發布到你的生產環境下的Web容器里，發布完了之后，你要啟動你的Web容器，開始提供服務，這時候你通過配置域名，dns等等相關，你的網站就可以訪問了。
那我們來看，你的前后端代碼是不是全都在那個war包里？包括你的js，css，圖片，各種第三方的庫，對吧？
好，下面在瀏覽器中輸入你的網站域名：www.xxx.com，之后發生了什么？
瀏覽器在通過ip路由到你的服務，在tcp3次握手之后，通過tcp協議開始訪問你的Web服務器，你的Web服務器得到請求后，開始提供服務，接收請求，之后通過response返回你的應答給瀏覽器。
我們先假設你的首頁中有100張圖片，以及一個單表的查詢，此時，用戶的看似一次http請求，其實并不是一次，用戶在第一次訪問的時候，瀏覽器中不會有緩存，你的100張圖片，瀏覽器要連著請求100次http請求（有人會跟我說http長鏈短鏈的問題，不在這里討論），你的Web服務器接收這些請求，都需要耗費內存去創建socket來玩tcp傳輸。
重點來了，這樣的話，你的Web服務器的壓力會非常大，因為頁面中的所有請求都是只請求到你這臺服務器上，如果1個人還好，如果10000個人并發訪問呢（先不聊web服務器集群，這里就說是單實例Web服務器），那你的服務器能扛住多少個tcp鏈接？你的服務器的內存有多大？你能抗住多少IO？你給web服務器分的內存有多大？會不會宕機？
這就是為什么，越是大中型的Web應用，他們越是要解耦。
理論上你可以把你的數據庫+應用服務+消息隊列+緩存+用戶上傳的文件+日志+等等都扔在一臺主機上，但是這樣就好像是你把雞蛋都放在一個籃子里，隱患非常大。
正常的分布式架構，是都要拆開的，你的應用服務器集群（前，后）+文件服務器集群+數據庫服務器集群+消息隊列集群+緩存集群等等。
步入正題
下面步入正題，首先以后的 Java web項目都盡量要避免使用JSP，要搞前后臺解耦，玩分布式架構，這樣我們的應用架構才更強。
使用 JSP 的痛點：
1. 動態資源和靜態資源全部耦合在一起，無法做到真正的動靜分離。服務器壓力大，因為服務器會收到各種http請求，例如css的http請求、js的、圖片的、動態代碼的等等。一旦服務器出現狀況，前后臺一起玩完，用戶體驗極差。
2. 前端工程師做好html后，需要由Java工程師來將html修改成jsp頁面，出錯率較高（因為頁面中經常會出現大量的js代碼），修改問題時需要雙方協同開發，效率低下。
3. JSP 必須要在支持Sava的Web服務器里運行（例如tomcat等），無法使用nginx等（nginx據說單實例http并發高達5w，這個優勢要用上），性能提不上來。
4. 第一次請JSP，必須要在web服務器中編譯成servlet，第一次運行會較慢。
5. 每次請求JSP都是訪問Servlet再用輸出流輸出的html頁面，效率沒有直接使用html高。
6. JSP 內有較多標簽和表達式，前端工程師在修改頁面時會捉襟見肘，遇到很多痛點。
7. 如果JSP中的內容很多，頁面響應會很慢，因為是同步加載。
基于上述的一些痛點，我們應該把整個項目的開發權重往前移，實現前后端真正的解耦！
老的方式：
1. 客戶端請求
2. 服務端的servlet或controller接收請求（路由規則由后端制定，整個項目開發的權重大部分在后端）
3. 調用service,dao代碼完成業務邏輯
4. 返回JSP
5. jsp展現一些動態的代碼
新的方式：
1. 瀏覽器發送請求
2. 直接到達html頁面（路由規則由前端制定，整個項目開發的權重前移）
3. html頁面負責調用服務端接口產生數據（通過ajax等等）
4. 填充html，展現動態效果。
有興趣的童鞋可以訪問一下阿里巴巴等大型網站，然后按一下F12，監控一下你刷新一次頁面，他的http是怎么玩的，大多數都是單獨請求后臺數據，使用 json傳輸數據，而不是一個大而全的http請求把整個頁面包括動+靜全部返回過來
這樣做的好處是：
1. 可以實現真正的前后端解耦，前端服務器使用nginx。
前端服務器放的是css，js，圖片等等一系列靜態資源。甚至你還可以css，js，圖片等資源放到特定的文件服務器，例如阿里云的oss，并使用cdn加速，前端服務器負責控制頁面引用，跳轉，調用后端的接口，后端服務器使用tomcat。
這里需要使用一些前端工程化的框架比如nodejs，react，router，react，redux，webpack
2. 發現bug，可以快速定位是誰的問題，不會出現互相踢皮球的現象。
頁面邏輯，跳轉錯誤，瀏覽器兼容性問題，腳本錯誤，頁面樣式等問題，全部由前端工程師來負責。
接口數據出錯，數據沒有提交成功，應答超時等問題，全部由后端工程師來解決。
雙方互不干擾，前端與后端是相親相愛的一家人。
3. 在大并發情況下，我可以同時水平擴展前后端服務器，比如淘寶的一個首頁就需要2000臺前端服務器做集群來抗住日均多少億+的日均pv。
去參加阿里的技術峰會，聽他們說他們的web容器都是自己寫的，就算他單實例抗10萬http并發，2000臺是2億http并發，并且他們還可以根據預知洪峰來無限拓展，很恐怖，就一個首頁。
4. 減少后端服務器的并發壓力，除了接口以外的其他所有http請求全部轉移到前端nginx上。
5. 即使后端服務暫時超時或者宕機了，前端頁面也會正常訪問，只不過數據刷不出來而已。
6. 也許你也需要有微信相關的輕應用，那樣你的接口完全可以共用，如果也有app相關的服務，那么只要通過一些代碼重構，也可以大量復用接口，提升效率。
7. 頁面顯示的東西再多也不怕，因為是異步加載。
注意：
1. 在開需求會議的時候，前后端工程師必須全部參加，并且需要制定好接口文檔，后端工程師要寫好測試用例，不要讓前端工程師充當你的組專職測試，推薦使用
chrome的插件postman，service層的測試用例拿junit寫。
2. 上述的接口并不是java里的interface，說白了調用接口就是調用你controler里的方法。
3. 加重了前端團隊的工作量，減輕了后端團隊的工作量，提高了性能和可擴展性。
4. 我們需要一些前端的框架來解決類似于頁面嵌套，分頁，頁面跳轉控制等功能。（上面提到的那些前端框架）。
5. 如果你的項目很小，或者是一個單純的內網項目，那你大可放心，不用任何架構而言，但是如果你的項目是外網項目，呵呵噠。
6. 以前還有人在使用類似于velocity/freemarker等模板框架來生成靜態頁面，現在這種做法也被淘汰掉了。
7. 這篇文章主要的目的是說JSP在大型外網Java web項目中被淘汰掉，可沒說JSP可以完全不學，對于一些學生朋友來說，servlet等相關的Java web基礎還是要掌握牢的，不然你以為Spring MVC這種框架是基于什么來寫的？
我是一個從事IT行業十多年的技術熱愛者，如果大家對于學習Java有任何問題。比如如何提升技術、學習方法應該注意什么、以及如何才能提升薪資或者缺少比較新的Java學習資料，都可以隨時來咨詢我，私信我“Java”會自動回復我的交流方式以及全面的Java系統學習教程，希望大家可以多交流，找到屬于自己的圈子。
苑?2015/05/28 16:28
這是「 NEXT Collections | Google I/O」系列的開篇。NEXT Collections 是NEXT 用戶基于產品集的干貨分享專欄。Google I/O 期間，我們邀請和聚集了 NEXT 用戶中的 Google 工程師、國內 Android 頂尖開發者，為大家分享和呈現關于 Google 的最干貨信息與觀點碰撞。
文章的作者 CJ 是 Google 八年的資深工程師，現回國創辦了在線協作文檔「一起寫」，這篇文章也是他與 geek 范的同事們在「一起寫」協作完成的。點擊 NEXT 產品集「Google 開源項目」，完整查看文中提到的技術與開源項目。
過去十幾年來, Web 開發技術從最初的純 HTML 到 CGI、PHP / JSP / ASP、Ajax、Rails、Node.js，已經發展到了一個非常成熟的階段。去年的 Google I/O，谷歌開發者中心推出了關于 Web 開發的最佳實踐手冊；而今年的 Google I/O ，「The Next Generation of Mobile Web」依然是其中的一個重要議程。
不過，前人栽樹，后人乘涼。現在大家拷貝的代碼可不是自己從土里自己長出來的，而是技術大牛一行行敲出來。即便是谷歌這樣的互聯網巨鱷，在 Web 開發上也經歷過無數的努力和踩過一個又一個的坑。今晚 Google I/O 正式開啟之前，我就給大家講講這些事兒，聊聊從 Desktop 時代到今天的 Mobile 時代，谷歌 Web 開發技術的變遷、踩過的坑。
| Gmail、Google Map : 世界瘋了兩次
大家知道,最早期的 web 開發指的就是 HTML，CSS，JavaScript，很多剛畢業的學生就會說，“切，會寫 HTML，JS， CSS 不算寫程序, 會寫 C++ 的才算”， 這可大錯特錯了。你們想想，寫一個 C++ 程序只需要會一種語言，寫個 Web 應用得學三種語言，而且這三種語言還以一些神秘的、很多時候還沒有文檔的奇怪方式聯系在了一起，再加上某些西北角的公司在里面再搗搗亂，導致 Web 應用非常的難以維護，直接的后果就是 99% 的應用都是簡單的網頁加上一點點可憐的邏輯，完全無法取代桌面上的應用。
這個時候，英雄出現了。Google 在 2004 年愚人節那天發布了一個叫做 Gmail 的東西，當時 email 的容量只有可憐的 10MB 或者 20MB，Google 突然說提供 1GB 的郵箱并且不斷增長，于是，全世界瘋了。可是在大容量的背后，大家發現原來 Gmail 不僅僅只是大，而且讓你覺得你在使用一個桌面的應用，而不是一個以前傳統的網頁的應用。所以可以說，Gmail 是 Web 開發的一個里程碑，第一個大規模部署的 Ajax 的應用程序。
緊接下來的一年，也就是 2005 年的情人節前后，Google Map 神奇般地出現了，世界再一次瘋了。所有人都覺得不可思議，原來網頁的程序可以做得那么酷炫，而 2000 年左右科技泡沫鼎盛時期的那些網站是多么的可笑。當時 Map 的組里面有 2 個人很值得一提，一個叫 Lars Rasmussen 的澳大利亞人，一個叫 Bret Taylor 的美國人，后面我們會慢慢的提到。
| 重寫 Gmail
在開發 Map 和 Gmail 的過程中，Google 的工程師逐漸意識到一個高度結構化的JavaScript 庫的重要性。因為邏輯越來越復雜，代碼量越來越多，功能也越堆越多，之前寫得那些代碼已經根本滿足不了不斷變化的需求了。于是偉大的工程師們做了一個 Googler 經常做的決定：我們重寫吧。
一個偉大的重寫 Gmail 的計劃逐漸張開了，也就是今天大家看到的 Gmail 的前身。在整個重寫的過程中，一個高度獨立、結構化的 JavaScript 的庫被抽象出，這就是可能很多前端工程師們知道的 Google Closure。用今天的話來說，Closure 不是一個簡單的 JavaScript 的庫，他是一種方法論，一種情懷，所以任何拿 jQuery 和 Closure 相對比的言論都是一種對 Closure 的侮辱。Closure告訴大家，大家應該像寫 java 一樣的去寫 javaScript，分清楚什么是一個類，什么是類的成員變量，什么是成員方法，什么繼承，什么是接口等等...所有你熟悉的面向對象的概念都可以在 Closure 里面找到。Closure 的出現極大地改變 Google 內部寫 JavaScript 的效率，導致復雜的 Ajax 的應用如雨后春筍一樣在 Google 內部迅速出現。
| 聰明人太多的產物：奇葩技術 GWT
如果讓 Google 的工程師們自己找 Google 一個不好的地方，一定有一點，那就是聰明人太多，沒法管理。就在 Gmail 如火如荼重寫的時候，另外一個團隊在悄無聲息的做著另外一個類似的努力去改變 Web 開發，那就是 2006 年發布的 GWT（Google Web Toolkit）。這是一個無比奇葩的技術，程序員寫的代碼是 java，出來的是 JavaScript，就像你吃的是草，擠出來的是奶一樣。這個技術的根本目的和 Closure 是一樣的，就是為了讓程序員用寫 java 的方式去寫 Web 應用，只是他的方式更直接，連 JavaScript 都省了。其實原理也很簡單，就是通過編譯器在編譯階段把 java 轉成了 JavaScript 代碼。可是，這個技術有一個致命的缺點：你想想，要有多麻煩才能在瀏覽器里面調試一堆由編譯器生產的JavaScript 代碼。于是無數的各種附加調試技術出現，告訴大家怎么去簡化 GWT 的調試，但是都沒有解決根本問題。GWT 的最大的好處就是如果你的網頁是由標準的控件組成的，比如輸入框、選擇框、多選等，那么 GWT 會極大的簡化你的代碼量.就是因為這個好處，GWT 一直活到了今天，因為 Google 最賺錢的廣告系統的前端是就是用 GWT 寫的。可見，計算機語言的世界也是看爹的哈哈。
2007，2008 貌似很平靜，Google 也沒發布什么驚人的、大的前端產品和框架。事實上，他們并沒閑著。Google 在那兩年期間做了幾個重要的收購，奠定了后面著名的 Google docs 的基礎。
2009 年，在 Google 內部雪藏了很久的 Closure 庫終于開源了，同時開源的還有一個對應的叫做 Closure Compiler 的東西，一般人理解 Closure Compiler 不就是另外 jQuery Minifier 嘛，其實可沒那么簡單，Closure 的 Compier 是可以真的理解你的 JavaScript 代碼的類型的。通過一個叫 JsDoc 的注釋形式的語法，你可以完全地把 JavaScript 當做是一種強類型的語言來寫，并且有一個編譯器來幫你查錯。在強大的工具面前，jQuery 被無情地碾壓。在接下來幾年，Google又陸陸續續的發布了對應的 Closure 的模板語言，和對應的 Closure Stylesheet 編譯器，于是 Web 的三件套，HTML + JS + CSS 在 Closure 的世界里都有了對應的工具，在 Google 內部,大部分的前端項目也都是基于這套工具來開發的。
與此同時，GWT 的小組也沒閑著，一方面更好的支持 Google 最賺錢的廣告系統前端；一方面默默的憋了一個超級大招 -- 大名鼎鼎的 Google Wave。對，Google Wave 是用 GWT 寫的，Wave 的 founder 就是我們前面提到的 Map 的創始人 Lars 。
| 又把最賺錢的廣告系統重寫了一遍
2011，2012 的 IO 上，關于 web 開發的主題很多都是基于 GWT 、Closure 展開的，一直風平浪靜地到了 2013 年。但與此同時，Google 內部已出現了一股暗黑勢力，悄悄地開發了一個完全顛覆式的前端框架 -- AngularJS 。它，就是以HTML 標簽起始符形狀命名的 AngularJS，簡稱 Angular。顛覆在哪呢？Google 的 web 前端開發框架基本采用著名的 MVC (Model-View-Controller) 結構，有效地分離數據模型和最后顯示的視圖，使代碼更清晰、更容易維護。早先的 MVC 大都是在服務器端實現的，包括先前提到的 GWT 神器。但是 AngularJS 不一樣，是一個完全在客戶端也就是瀏覽器里的 MVC 框架。這個框架在 HTML 中標注新的屬性，運行時用 JavaScript 動態解析和綁定數據關聯，簡化了 web 應用尤其是單頁應用 (single-page application) 的開發。不少數據雙向同步邏輯甚至不用手工編寫 JavaScript 就能實現了。更重要的是它制定了一整套前端組件的開發規范。雖然各種繁雜的條條框框讓它無論在 Google 內部還是開源社區都備受微詞，但它還是迅速獲得很多企業的青睞，近幾年來以異軍突起之勢成為眾多公司招募前端程序員的一項標準需求。于是瘋狂的程序員們又瘋了，開始把很多陳舊的系統用 Angular 重寫，包括前面提到了那個最賺錢的廣告系統前端。甚至Angular 一出來的時候就有人預測，Angular 就是早期的 HTML6 。
| 異類語言的誕生
說到這里，不能不提一個異類語言了，叫做 Dart 。這個 Dart 可是出自名門，是由 V8 的首席程序員 Lars Bak 在他工作之余發明的， 他一邊改善 V8 的性能，一邊琢磨如何能突破 JavaScript 語言本身諸如弱類型等限制，讓 web 程序執行速度更上一層樓。他最后決定，干脆擺脫 JavaScript 的束縛，重起爐灶設計一門全新的、為新時代 Web App 專門打造的語言 -- Dart。
在了解 Dart 前，簡單科普一下同父同母的兄弟 V8。 Google 的 Chrome 瀏覽器當年發布時以其遠超 Internet Explorer 和 Firefox的網頁渲染速度震撼了世界。其中一個核心優勢就在于全新的 V8 JavaScript 引擎。當競爭對手還在吭哧吭哧解釋執行 (interpret) 網頁中的腳本時，強大的 V8 引擎采用即時編譯 (JIT) 技術把 JavaScript 的運行速度提升到了一個全新的層次。在之后的幾年里，各家瀏覽器廠商紛紛效仿，推進了整個 Web 平臺的發展。目前深受追捧的 Node.js / io.js 其實也都是 V8 開源后的衍生產品，造就了一個前后端用同一種編程語言的新興開發生態。
Dart 語言借鑒了廣大程序員熟悉的 Java 語法，支持面向對象、單繼承、interface、泛型、非強制的類型標記等語言特性。Dart 的虛擬機在 V8 大牛的打造下性能當然也是超強的。Dart 程序還能被編譯成 JavaScript，運行在沒有 Dart VM 的環境中。
然而，Dart 從發布日起一直倍受爭議和質疑。它被認為是一項分裂 web 之舉，而且長期以來沒有得到任何其他瀏覽器廠商的支持。2015 年初，Google 宣布取消將 Dart VM 綁定在 Chrome 瀏覽器里的計劃。不過這并不是 Dart 的死刑判決。Google 仍然支持并使用 Dart 開發大型 web 應用，因為比起 JavaScript，Dart 更能提高開發效率和保證代碼質量。
綜上，大家可以看到，web 在開發上兩個趨勢，第一個是從腳本語言層面去改善代碼的質量，提高效率，第二是從 web 標準入手，提供更多抽象的模塊化的組件，讓編寫 web 應用更加容易。
而說到第二點，不得不提提 Google 的一個項目叫做 Polymer ，如果你們去 Polymer 的網站，你會發現 Polymer 的口號是「leverage the future of web platform now」。 的確，Polymer 是一個庫用來實現 Web component 的，而 web component 是 W3C 關于下一代 HTML 的一個標準，這可是根正苗紅的一個項目。可以說 Polymer 項目的進展某種程度上就代表了下一代 HTML 標準制定的進展。讓我們一起期待在本次 IO 上 Google 會對 Polymer 做出怎樣的更新吧。
「 NEXT Collections | Google I/O」系列將持續更新，請保持關注。你也是一枚 Googler 或 Android 開發，并且有話要說？對文章觀點有質疑？想加入 Google 工程師和 Android 開發大牛的線下討論？歡迎郵件 xinyuan@36kr.com。文章作者的新項目「一起寫」也在招聘 geek 范的同事，歡迎簡歷快遞至 CEO 直聘郵箱：c@yiqixie.com。
原創文章，作者：馨苑
作者
歡迎專心練劍的產品人和技術宅來聊：xinyuan@36kr.com ：）
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
