你們覺得前端需要什麼樣的平台支持開發起來會很爽？

更新幾點

1. 提前說句：我們公司的產品可以限定用戶使用的瀏覽器，另外我們的產品是內部平台，不是對公眾開放的產品，所以我們可以這麼做。 @郁也風 的評論是準確的。Web Components 現在暫時不適合在公開產品的生產環境里使用，再過半年可能會好一點。
2. 要 GitHub 的很遺憾，沒開源啊我們，而且公司的項目代碼是放 BitBucket 的。我自己去年做業餘項目的事後寫了個數據框架練手，使用的就是純 Web Components，代碼結構和我們公司的組件基本一樣：tingting-io/avalon-data-framework ，至於吐槽這玩意的就不必了，Web Components 的實現直到去年還是限制一大堆，練練手而已。
3. 重複發明輪子的問題，我很贊同評論區的說法，很蠢。但我更認為，平台的遷移比重複造輪子是更重要的決定因素。因為有更好地基礎平台而重複造輪子是值得的。
4. 對各位關心的實際瀏覽器實現問題：基本上 Chrome 和 Safari 目前已經全面支持了 Template、Custom Elements 和 Shadow DOM，雖然有一些小 bug。FF 對 Custom Elements 的開發進度一天平均解決兩個 bug，正式上線指日可待；微軟家的 Edge 負責人估計已經死了，所以我們也直接告訴客戶不用 Edge。另外 HTML Import 比較特殊。跟過 Blink 組郵件的可能知道，之前 HTML Import 的次級 CSS 樣式渲染對主文檔的影響導致了幾個史無前例的麻煩，並且除了 Chrome 外沒有任何瀏覽器有計劃支持它，所以目前 Blink 那邊負責 HTML Import 的人表示這個標準會在未來被廢除，並且以更好的新方案替代。這很不幸，但是對於前端工程化來說，WC 剩下的三個標準也已經可以起步了。

正因為這些原因，我們公司才會在實現不成熟的 2015 年底就毅然決然地上 Web Components，因為我們認為第一方慢歸慢，標準可能也因為扯皮而無法完美（比如當時 V0 到 V1 的標準大變動），但第一方更簡約、更基礎、更堅實、也更不受制於人。選用第一方的 Web Components 標準的好處是長遠的，我們願意為之付出代價，而情況也會隨著實現改善而不斷變好。因此選用 WC 是一個長遠決策。

原答案

我們公司開發前端連前端庫都不用，直接上 Web Components，各種組件自己寫成 Custom Elements 扔 GitHub，前端包管理用 NPM 直接拖 GitHub。代碼層面零編譯，純 HTML5 + CSS + JavaScript，後期壓縮醜化等等一系列工作全部扔給第三方流水線。這一系列棧用下來，前端什麼支持平台都不用。每個程序員不管是桌面機還是筆記本，不管是 MacOS 還是 Windows 還是 Linux，不管用 Sublime 還是 Atome 還是 Vim，開發的時候零依賴。

反正從我個人角度來講，我覺得前端開發起來最爽的平台支持就是零編譯零依賴。WC 實現之前由於 Web 平台自己太落後，要用大廠的第三方庫這算沒辦法。WC 原生支持紛紛上馬以後，前端其實事實上擁有了第一方工程化的條件，因此逐步削弱對平台和庫的依賴其實是很重要的。

當然，要這麼玩也得犧牲很多東西，比如說零編譯就不存在資源打包了，那我們的單頁應用里的依賴很多是寫死的，所以得上 HTTP/2，否則一個頁面幾十個外鏈會很慢；另外你得有耐心等瀏覽器的實現慢慢跟上，比如說還在開發中的 FF 和我們已經覺得相關負責人已經死掉的 Edge —— 這會倒是 Chrome 和 Safafri 支持完備了，可你知道當年只有 Chrome 支持個 V0 的時候我們是怎麼熬過來的……

回到問題本身，我們公司是願意犧牲哪怕用戶群來維持開發效率和開發潛力的思路，所以我們會為了一個簡潔、優雅、清晰和易上手的前端體系付出很大代價。換來的好處是：再也沒有第三方大庫了，再也沒有代碼編譯了，新人進來除了基礎的 HTML/CSS/JavaScript 以外再也不需要經歷一層疊加在上的 React/Webpack/Vue/Babel/Angular……了。這就是我個人最喜歡的前端平台支持：回歸根本，讓 W3C 標準本身來完成支持。

內置 webview 調試的 debugger 平台。能夠眾多 APP 提供其內置的 webview 調試工具。也就是將 微信開發者工具 那一套遷到雲上。如果有，我覺得花多少錢都值。每次調試的時候，真的要死。。。

問題看的不明白，「什麼樣的平台支持」是指要開發環境還是運行環境 ？

對於開發環境來說，好用就很爽；

對於運行環境，除了 IE 其他都還好