如果我們能從頭開始，web編程會是什麼樣子？
在看elm的文檔（blazing fast html）時作者提出的一個問題 What would web programming look like if we could restart?
在回答這個問題之前，先要解答這個疑問：瀏覽器到底是什麼？
這個問題的答案可以很多：
- 一種資源的定位與查閱系統
- 一種排版與呈現體系
- 一種可用於承載應用系統的容器
在這三點中，最初的瀏覽器只是起了第一個作用：
輸入地址，請求得到文本與多媒體資源，並且呈現出基本的外觀。
後來，人們對它的展現形式和交互都作了增強，有了比較複雜的表單，有了可定製的樣式，還有嵌入的腳本語言。結構、行為、樣式這三個要素終於以大家熟悉的方式展現出來。
需要注意的是，在這個時期，結構才是重心，另外兩者只是輔助，所以會存在這麼一些現在看起來有些奇怪的使用方式：一個頁面，需要考慮到在 CSS 和 JavaScript 都不支持時候的可用性。
但我們看看現在的各前端框架，發現這三種東西的重要程度悄然發生了變化，樣式仍然處於從屬地位，但入口，已經從 HTML 變成了 JavaScript，不僅僅是入口，連骨架也是它了，主體也是它了。
展示型的Web項目中，毫無疑問HTML是入口，也是根基，不管是JS還是CSS都是作為它的輔助。但到了Web應用中，還是這樣嗎？我們很多Web應用實際上是以JS為入口的，HTML不再被視為骨架，而是視為一種動態的東西，由JS創建並管理。
上面這段，來自2015年我在平安的一次演講：Web應用組件化的權衡 · Issue #22 · xufei/blog
所以，整個 Web，從使用場景來看，實際上變成了兩個不同的方向，一類偏展示，一類偏應用，兩者的形式是不同的。
場景不同，對開發技術的需求也是不一樣的，比如說，展示型的項目，它不一定需要互動式的語言能力有多強，而是對排版之類的東西，有著越來越高的需求。直到今天，使用 Web 進行電子刊物的出版，仍然無法達到傳統紙媒的很多效果，這方面確實是有所欠缺的。
另外一方面，最近幾年，我們看到整個 Web 在往應用系統的方向狂飆猛進，一會 ES6，一會 Webpack，一會 Babel，一會 Less，令人眼花繚亂，瀏覽器自身新增的特性，比如 ServiceWorker 之類，也是一稍微可用，立刻被人用在生產系統上，可見人們對新 API 的渴望也是如同久旱盼甘霖。
那麼，結合這兩個方面，我們可以來看看，瀏覽器究竟承載了什麼。
四年前，我回答了這個問題：
在這篇回答里，我以一種調侃的方式，說出了自己對瀏覽器跟不上系統開發的能力的吐槽，在那時的我看來，缺的是這麼幾樣東西：
- 原生可用的 JavaScript 模塊化機制
- 原生可用的組件化機制
- 原生可用的數據觀測機制
- 更加好用的布局能力
然而，四年過去了，萬萬想不到。
我想不到什麼呢？去年這時候，我跟玉伯聊了一次天，我說，這幾年，我真正沒想到的是：人們不在等待 Web 標準在瀏覽器中的實現，而是習慣於在它尚未可用的時候，就直接使用，然後轉譯到瀏覽器可用的代碼。他說他也沒想到。
回到我寫那個回答的時候，國內的前端圈存在一個叫做「Web 標準翻譯」的組織，今天你們能看到的很多資深前端開發人員，都跟這個組織有很深關係，比如說，很多不了解這些歷史的人，經常看到知乎上某個回答下，冒出一個看上去不怎麼知名，或者不太正經，或者特別正能量的人，能對瀏覽器的某方面核心了如指掌，其實他就是這個組織的成員。
然而，現在這個組織哪裡去了？
在那個時候，瀏覽器新特性的推出過程，還是現在這樣：
- 提出草案
- 討論定稿（可能反覆多次）
- 各瀏覽器實現
定稿的過程往往長達數年，甚至會有幾年之後還撤銷的情況，讓翹首以盼的各框架或者業務開發人員等得心碎。以我個人而言，對組件標準的期待，真是一年又一年，一轉眼就十幾年了！！！從 HTML Components 草案到今天，已經 20 年了，然而……
迷茫的我，甚至專門寫了一篇東西提前看空它：從HTML Components的衰落看Web Components的危機 · Issue #3 · xufei/blog
到底問題在哪裡呢？我覺得，還是因為對瀏覽器的兩種截然不同的使用思路所致：
- 瀏覽
- 應用
正是因為這二者的同時存在，導致同一種東西的實現，難以兩全。今天我們看 CSS，尤其是之前做非 Web 體系開發的人，會覺得它有很多不可理喻的地方。我從業生涯中，不止一次看到同事調 CSS 導致怒摔滑鼠的情況，為什麼呢，因為它最初是一個為 「排版」而非「布局」而實現的東西。
早期的 Web 應用，由於設計規範的偏桌面化，導致大部分應用仍然是以：
- 整個窗口強行放大到最大
- 最外層窗體禁止出現滾動條
- 內層各組件內部包含滾動條
這麼一種方式來設計的，這個方式與 CSS 的典型使用場景衝突太大，瀏覽器天生就是最外層滾動的，各區塊都是有多大展開多大，從來沒有為這種情況設計，覺得不好用是很正常的。
我們部門開源的 Ant Design Pro：Ant Design Pro，在設計上打破了這種規範，採用了更貼近 Web 的方式，比較取巧地解決了這個問題，常規的管控系統應該都是可以這麼乾的，某些面向特殊領域的高頻操作的應用系統，可能還是需要比較特殊的設計。
現在看來，樣式在不同場景下的差異，可能還算是個小問題，與此類似的是 JavaScript 語言。如果是從工程角度講，現在的 JavaScript 發展得還是挺好的，用來開發應用型的系統，「夠用」，開發瀏覽型的網站，更是只要用到一個很小子集即可。
但是，如果要從使用的姿勢看，裡面差異可大了。比如說：
- 原生的 immutable data structure
我相信有不少開發人員立刻深表贊同，你們這些 FP 黨，就希望把 JavaScript 變成 Haskell，Lisp，等等。。。
又比如：
- 原生的強類型支持
又是一群人，你們這些 Java，C# 黨。
又比如：
- 元編程能力
你們這些我也說不出來什麼黨。
有鑒於此，我覺得 JavaScript 還是就現在這樣好，除了一些大家覺得不能沒有，能讓編程變得便利的東西，剩下的暫時都不加，你們覺得喜歡哪種語言，可以去寫那種語言，然後轉譯到 js 啊。
對開發語言，其實還有一個問題，除了瀏覽器，幾乎不存在哪個環境，是普遍要從遠程載入模塊來執行的，這個其實可以開很多腦洞，比如某安全小王子就用 Service Worker 開了一個腦洞。
那麼，Web 開發環境最大的問題在哪裡呢？還是剛才我最痛心的那個：一個通用的跨框架的組件規範。隨著 React 的火起來，人們對 Web Components 標準的最後一絲尊重也沒有了，事實標準從此不可阻擋地屏蔽了大多數開發者對瀏覽器底層標準的認知。
還有誰記得 AngularJS 對自己的定位？
AngularJS lets you extend HTML vocabulary for your application.
又有誰知道 VueJS 的自定義組件，為什麼不用 Pascal 命名，而是全小寫，中間加橫線？
因為這是 Web Components 規範推薦的自定義組件命名方式。
曾經的人們，心裡都還有一份對 Web 標準的尊重，然而。
瀏覽器，它承載的東西實在太多了，它的自我演化速度，可能真的跟不上人們對它的預期。曾經存在的各種插件化機制：Applet，Flash，Silverlight，全都是試圖在推不動它進化腳步的情況下，創造一個「隨處可運行的應用」的運行容器。
與此相關，還有一個值得腦洞的事。隨著很多帶有函數式思想的框架的流行，或者說，虛擬 DOM 這個東西的流行，有一些人開始質疑 DOM 這個東西了。
是啊，如果能讓我直接：data.map(d =&> v) 多好啊？
然而，DOM 提供給你的，是一個類似操作 XML 的介面，你 100 次添加一個元素，跟一次添加 100 個元素的性能可能相差甚多，你改一個東西，如果是畫出來，而不是通過這種介面添加，各操作互相不影響，真正的是把數據 map 一下就渲染出來了，該多好啊？
然而。
說實話，我也不知道 Web 體系，或者說瀏覽器發展成今天這樣好不好，但仔細想想，覺得它在 80% 以上的部分，已經做到了兼顧歷史負擔下的最好了，它的唯一缺點只是更新太慢了，不是它慢，是我們的世界變化太快了。
但瀏覽器它不僅僅是一個語言，而是一個平台，它的實現的規範汗牛充棟，代碼堆積如山，大部分人感知不到的是，像 Chrome 瀏覽器這麼一個東西，它的代碼量多得可怕，排版布局之類的地方複雜得超出想像。
而且，瀏覽器的實現特點是，它長期一直處於多個企業和團隊共同組成的標準化團隊的跟進過程中，每一種東西從草案的產生到落地，都要經歷各種各樣的討論、爭執、角力。如果從頭開始的 Web 體系還是繼續從這種機制下產生，大概率還是發展成現在這樣。
如果說我個人希望有怎樣的東西，那可能是實現得更好的當年的 Flex 或者 Silverlight 吧。
此刻是2017年12月，如果真的能重頭來的話……
0. 我們有了一種真正的web時代的彙編語言(這是一切的前提。啊，我才不是說現在的WebAssembly)
1. 我們最常用的 JavaScript 會是其中一種實現……當然語法是按照我們這個時空下的ES6來定義的2. 我們有了像 Vue、React、Angular等框架，在編譯到「web彙編」後性能確實厲害……只是某些從彙編時代過來的老一輩專家非常不習慣不能直接拿「web彙編」運行時來debug的感覺。3. 「你們能不能拿出一套能讓非web前端也能編的框架出來？」領導這樣問alex。「具體來說，我們不想寫css。其實能拖幾個按鈕過來就能跑不就對了嘛」。alex問了一下非前端的同事，他們就這麼說。4. 「你們寫的這套太專業了，我們都插不了手。」alex聽到這樣的不知道是抱怨還是恭維的話，瞬間懵了: 等等，我們……呃，你們…………好吧5. alex變得不知道自己該怎麼寫代碼，既讓大家理解當代前端技術確實已經發展到了別人難以插手的地步，也讓只學過一下老一輩玩意、其實從來輕視「前端」的人也能維護……至少會把 referrer 拼對，ES4 可能不會流產但是意義不大，其他還是老樣子。
當年瀏覽器是支持運行 Java 和 VBScript 的，他倆自己不爭氣讓 JS 火了。JS 能活下來不是因為 JS 多厲害，而是其他人給的方案太垃圾。
當年瀏覽器是支持 Flash 的， Flash 自己沒抓住移動端機會讓 HTML 5 火了。在 IE 如日中天的時候微軟推出了 SilverLight，用戶有幾個人買賬的。還是 HTML 方便，雖然體驗爛。
當年 CSS 也是有競爭者的，還是 CSS 活了下來。這條路是大眾自己選的，不是別人強加的。難道你要說『這屆網民不行』嗎？瀏覽器完全沒有欽定 JS 的意思，JS 獲選是人民的意願。
考慮到當時的硬體條件和網速，以及 KPI 壓力，你不可能一上來就把 JS 做得很完善。
說幹掉 JS 的人倒是說個好方案呀！現在有 WebAssembly 也沒看你用呢，盡說些不著邊際的話。就算 Chrome 內置 Dart，你們會去用嗎？我表示懷疑。就算內置 Python 解釋器，你們還不是一樣會遇到回調地獄和動態模塊載入問題，有什麼區別呢？難道你要在 1993 年的瀏覽器上面支持多線程？瀏覽器不是那麼簡單就能寫出來的，就算寫出來了這樣的瀏覽器，你也會因為不能操作主線程的 DOM 把代碼寫得很複雜的。比簡陋但簡潔的 JS 噁心多了。
JS 絕對是最適合瀏覽器非同步模型的語言。我見過不少傻逼在瀏覽器上調用 AJAX 默認用同步方式，這是他所用的語言賦予他的思維定勢，他無法適應 JS 的非同步思維就說 JS 爛，其實呢，就是他自己思維江化了而已。
另一個例子就是面向對象，這群傻逼只會 Java 那種面相類的 OOP，不會面相原型的 OOP。
其實類就是一個對象而已他們就是想不通，然後說 JS 爛，說到底還是他們思維江化而已。用 JS 只要做到以下幾點就特別爽
1 不用全局變數2 不用自動類型轉換3 理解基於原型的 OOP4 盡量用函數（因為 BE 當年是個函數式粉兒）
再說協議層面，除了 TCP 和 UDP 以外，選擇也不多吧，如果你要自己搞出更好的協議恐怕成本有點高，選 TCP 雖然不是最好，但也算是明智，我不是這方面專家不是很懂就不說了。應用層用 HTTP 也很合適啊，雖然一開始的版本過於簡陋，但是該有的功能都有，後來升級也都很好地解決了痛點。可能有人比較喜歡一步到位不喜歡這樣慢慢升級，但是如果不積累一些經驗，你是不可能知道要怎麼才能一步到位的。
URL 也是很科學的定位方案，唯一的敗筆就是 www 前綴，搞得民眾以為網址一定要加 www 才行。URN 雖然更準確，但是實際方案還挺難落地吧，反正我是沒想通怎麼辦 URN 應用到萬維網中。DNS 其實也挺好的，只是有些國家強行管制了。唯一破解管制的辦法就是混淆加密以及 P2P 吧，我不是很懂就不繼續說了，但是都會犧牲速度的，在那個年代，對於普通人來說完全看不到必要性。
當年李爵士發明這一套東西，我是很佩服的，既簡單又開放。只不過他原以為每個人都會有自己的伺服器，沒想到現在請大家都在用大公司的封閉網路，與他的初衷想去甚遠，這一點不知道大家有何破解方案。
再說 DOM 吧，本來這個 API 是操作 XML 的，從當年的角度看 HTML 就是 XML，所以用 DOM 沒毛病，你現在覺得虛擬 DOM 更好，那是因為你在把網頁當做客戶端在做，這原本就不是 HTML 的定位。所以瀏覽器內置虛擬 DOM 是不可能的。
總而言之，只有把 referrer 拼成 referer 是不可原諒的。最需要重做的是CSS。
大家說js垃圾什麼的，但是語言這個東西，作為一個工具，如果能做到表達自己的想法，哪怕拙劣，只要表達出來了，就證明了它 的價值。js已經向我們證明了這一點，何況還有ts這類的工具來幫我們強化js的表達能力。
為什麼我認為CSS要重做呢？因為這門語言是與用戶視覺走得最近的。但是CSS設計的初衷，是為了描述類似於報紙的排版。CSS強大在於它對文字樣式的修飾。排版能力，這兩年才用flexbox與grid給慢慢補上來，但是說實話，做得不倫不類。
為什麼說不倫不類，因為當我們閱讀CSS代碼，看著HTML，我們腦子裡頭無法快速地想像出界面是什麼樣子的，我們需要依賴瀏覽器，然後找到不合適的樣式進行修改。grid布局雖然在儘力彌補這方面的問題，但如果一切重來，你覺得CSS的語法不會被重新設計嗎？看看grid的語法，這套布局理念在往CSS語法裡頭塞的時候，只能被設計得無比奇怪。這些還不足夠，CSS還有一個致命的軟肋：交互。難道CSSanimate不夠強大？對，很弱，這套動畫系統如果足夠強大，就不會說引入canvaslike的API去彌補交互方面的不足了（Safari不支持，所以可能有人不了解，2018年可能能慢慢走入大家的視野了）。
但是隨著交互領域的發展。我們可以把交互的名詞灌入到新的語言中（如果重做）。但是CSS和HTML是一體的，所以如果說要重做，HTML也要帶著重新設計。
-----
有興趣了解這一方面的話，可以去看看fusetools，很接近我想表達東西。
但fusetools做得還不是很完善，缺少從人類的思維角度去描述布局的能力。算了，這是個大坑，我就不用嘴挖了。Brendan Eich可能會花二十天來設計JavaScript
最近在看ES6的一些基礎資料，看的時候總覺得很彆扭。比如引入let,之後還要引入一個do。為的是在var全局大魔王下面開闢出一個局部作用域。這種區分代碼塊作用域的設定在Python，c++這些語言之中是很自然的，局部變數會從頂層的代碼塊傳入到內層的代碼塊之中，然後逐步傳遞出來。
這種加let,do關鍵字只是為了避開var帶來的問題，進行局部改善的做法。是因為JavaScript有超級多正在運行的代碼。改進步伐太大，會有多少網站停止運行?誰也不敢說。所以目前只能是補丁打補丁的改進語言，在後端程序看來,前端編程很容易。的確，如果語言本身設計的好,是很容易。但前端開發是在一個到處是坑的世界中幹活的，而且是地基有坑。
我看了ES6之後,覺得前端開發真不容易。
如果有重來一次的機會，Javascript的設計一定和現在的Java，Python之類的類似，前端開發難度會更流暢一些，坑會少很多。
至於Web的變化，這個不敢說，畢竟這個整體需求的問題。全宇宙一起來減少ghcjs吐出的代碼量，然後大家一起愉快地用Monad傳json
應該是前端暴露 RDF ，或者鏈接好的 yaml 之類格式的數據給瀏覽器，數據與展示分離。
界面開發人員提供瀏覽器插件形式的，適合用戶喜好的本體編輯器用於向遠程伺服器提交數據，提供插件形式的分面篩選器用於找到想要的信息。
可能根本沒有 Web 前端這個職位，因為運營人員可以直接用適合他們的編輯器製作 linked data，直接公布到互聯網。互聯網上的數據由大量爬蟲腳本提供流動性，最終推送到需要它們的用戶的瀏覽器上，被用戶安裝的插件渲染出來。
有的用戶可能喜歡 GUI，他們將聊天組裡的文章組合成瀑布流的形式，將評分功能映射到點贊按鈕。有的用戶喜歡 CUI，他們的瀏覽器為他們朗讀其他用戶的帖子，並能利用帖子的語義信息回答用戶的問題。將數據和界面綁定，其實不僅麻煩了前端，也麻煩了用戶。所以我們要把網站和 Web 編程兩個概念分離開來，網站提供數據，而 Web 編程指的是設計用戶使用的各種和具體網站無關或松耦合的界面。沒有如果
一個跑題的回答：從Web誕生開始，到目前這個階段，做Web相關的開發者在這個期間不斷去抹平語言、瀏覽器、平台直接的差異所浪費的時間和精力相信遠比其他語言編程要多N倍。
首先把前端編程看成一個bandle, 然後讓前端看起來更像後端或者平台編程。如HTML 是bandle 的interface，CSS 作為其中一個字典調用，js 用於controller，和helper class， 並且規範JavaScript的代碼方式，讓JavaScript更加OOP。
html會被*xml替換
flash這個東西不會存在了
也不會有坑爹的jsp了
哦哦哦哦哦哦哦
java也不會拿來寫web如果一切重新來過，但是所有人都不帶著現有的記憶，或許，歷史還是照舊的吧....
如果從從頭開始，web很有可能是變成ieScript，foxScript ，chromeScript等等各種互相不兼容的語言。。。變得和後端一樣複雜
還將是現在這樣子，
因為並沒有多少血性的開發者，
敢和老闆說 」我不兼容IE」。
惡魔就是這樣養大的唄。Javascript 或改名Applescript
肯定沒有傻缺的尖括弧.
spec一個 webOS，實現裡面的syscall就算符合標準（誤
...................................................................................................................................................................................................................................................................................................................................................................................................................................
埃里森：「不準叫javascript，不然等著收律師函！」
希望寫js的那個大佬 多花點時間 好好寫不要7天寫出來 折磨這麼多人
推薦閱讀：
TAG:Web開發 | 前端開發 | JavaScript |