1樓：龍騰道默默地
custom elements 有全域性汙染問題，怎麼可能成為載體。web components 又不管 MVVM，怎麼可能取代三大框架。換句話說，如果不是為了 MVVM，又有誰會用三大框架？
所以更有可能反過來，三大框架繼續作為載體存在，而它們的每個元件內部都用 web components 中的 shadow DOM 實現 CSS 隔離。
2樓：jun4rui
應該不會，從目前可見的未來看不會，因為你這個思考雖然不錯，但是有個問題。
我先說說目前的Web元件吧，包括樣式、結構和處理邏輯的演算法，其實這種東西不用等到WebComponents就一直存在，為什麼大家不會大量使用？首先，用別人的元件其實挺沒有設計感的，或者說沒法設計，人家咋樣就咋樣了，這種元件用多了無非就是一堆風格亂七八糟的大雜燴，這種玩意誰要用？這就是成熟的元件庫都是成套提供的原因，設計要一致化整體化，零碎的玩意不能叫設計。
所以，react、angular這類框架都不會涉及到UI風格，當WebComponents恰恰不是這種，而是需要提供顯示風格的，兩者其實不是乙個層面上的東西。
這又引申出第二個問題了，可維護可定製性，三大框架外加一大堆的周邊生態大概好幾十號元件，這個你要自己想改改修修，哈哈哈哈你們準備找個什麼級別的前端？
其實還有一些困難，我就不提了，前段其實在工程化的路子上還有大段路要走
3樓：
Web Components 是趨勢，跨框架編譯成Web Components可能不是乙個趨勢。
因為，框架也可以編譯成WebAssembly，它是一種可以促成跨語言開發Web前端的技術。
就現階段的前端框架形勢看，各大框架是存在豎井問題的，你所描繪的那種美好願景（跨框架）是不好實施的，它不僅僅是乙個標準化的工作。
雖然說，社群也有react和vue互轉的實現方案，但說實話，它不適合廣大群眾。因為具體專案比較常見的還是單一框架配合框架生態去開發。從維護和可持續的角度看，更多知識面、關鍵字對團隊協作其實是不利的。
這麼一說，跨框架解決的問題，主要還是融合有不同偏好的開發資源，從而能達到業務開發與框架無關的效果。
框架無關是乙個偏好問題，不是乙個完成業務的必要命題。就跟寫服務端一樣，不同框架都有它適合的場景，比如寫單個領域業務向的、易擴充套件的介面可以試試koa，寫Open API介面的可以試試fastapi，寫完整Web專案可以試試nestjs等。
我覺得，不同框架都有它適合的場景，跨框架可能不是一種趨勢，歷史證明Web的一些標準化總走在了框架的後面。隨著時間推移，框架自己的生態都在發展，會進一步分化，不會是現在這種三足鼎立的局面，也不會是一家獨大的局面。
我覺得，中後台解決方案就是乙個很有前瞻性的方向，比如阿里的雲鳳蝶。這可以促成業務開發與能力無關，會不斷降低開發成本和開發門檻。
就跟遊戲開發的歷史程序差不多。從前去開發遊戲，很難，多端要多語言、靜態資源整合麻煩等很多問題，隨著歷史演進，一系列的類如Unity、Cocos等工具的出現，可以一次開發打包多主機端及移動端，讓遊戲開發變得更加便捷。
是否有能編譯成C 的,同時具有高階語言特性的程式語言
老董 對於C 我也和題主有類似的感覺，所以我現在轉戰Rust了。只是奈何現在的rust的輪子太少，尤其是GUI部分。但這長痛不如短痛，我仍然相信rust是未來系統級程式語言的趨勢。另，題主所說的 必須使用C 情況 但又想有輕鬆的開發體驗，解決方法有3 1.還是用C 但你可以不用指標 陣列這類low ...
Google Polymer是前端元件化的未來！那對於現在當下，又該採用什麼技術實現元件化呢？AngularJs可以勝任嗎？
小芋頭君 大家說的很明白了，只說一句 沒事別瞎折騰，元件化的最大目的是可復用性和團隊開發時候的分工。如果你的頁面沒有特別大的需求，別想著折騰這些，先把前端工程化和表層面的模組化和前端團隊的規範化做好再說吧。普通的web頁面元件化後，如果你的復用很少，基本上的後果就是維護成本陡增，關鍵是並沒有特別大的...
現在開始學前端框架，眾多框架中的優先順序是什麼呢？
楊大錘 優先在網上搜搜怎麼用最快速的方式學會乙個框架的使用。然後按照使用方法選擇乙個框架。這裡推薦學習vue，這個最容易上手。達到會用的標準後，可以再學習angular，因為angular與vue有一些類似的地方，例如資料繫結與事件繫結等。再學習react，感受一下jsx的魅力。這些都學習完後，找到...