怎样看待， 前端框架的竞争是否已经变成生态系统的竞争？其他框架生存空间太小?

jQuery 的护城河不深吗？曾有人评价柯达：“在破产之前，柯达生产的胶卷依然是世界最好的。只是我们不再需要它了”。也曾有人这么评价过诺基亚。

作为一个不知名框架的作者，我表示这件事是真的。

每次在别人吐槽起react太麻烦，angular太重，vue不想用因为懒得学的时候，我说那你们来试试ef啊，5分钟上手，啥架子都不用搭，性能还显著优于三大框架，这些人立刻又跳出来说不了不了没生态不用，甚至还有因为写不了jsx而拒绝使用的。。。。

然而想一想就会发现，这种说法真的是无稽之谈。我也演示过ef可以随意搭配任何UI框架使用，想要路由有page.js，想要状态管理的话ef自己就能做到，坐拥整个js社区的所有资源，你还嫌没生态 （捂脸）

我认为靠所谓的生态来当自己的护城河真的是一言难尽，缺点大于优点吧。。。把人圈进自己的地盘并牢牢拴住大概是最大的缺点，因为在方便开发者的同时，真的培养了很多很多的不良习惯。比如滥用所谓的“函数式编程”，自以为没有副作用，其实最大的副作用就是极大地增加了性能开销（antd尤其严重）。我一直在喷react过度设计，每次搞些新花样出来其实都是在填之前设计上带来的坑点，却搞得好像解决了整个前端开发中的老大难问题一样。而这些“生态”其实情况也很类似，有了这些生态的高层封装以后，便没有人在意这底下的实现是什么，性能反正也不是硬指标，一把梭乱用就好了。

不过，在离职几个月后，为了还有人会来用ef的希望，基于ef的UI库我一个人啃馒头喝稀饭吃榨菜也要造出来。。。。大概还有一个月左右会有相对能用的demo放出吧 。。JSX支持也在0.9版本的时候加入了。不是我要建立护城河，而是你们逼我这么干的啊23333

补充：

题主在评论区力推jsx的行为其实也可以看作是护城河的一种表现。众所周知，jsx的诞生就是为了给react服务的，其他框架再怎么实现jsx支持都免不了一股react味——我称之为react税。而非jsx不用或者看两眼其他设计就认为不如jsx直观好用的开发者其实也早已被这种“护城河”所围困。

殊不知我开发ef.js的初衷之一就是为了避免使用jsx，避免使用带有大量无效计算的virtualdom。而后来ef决定支持jsx有两个方面的因素：第一是因为我可以用非常少量的代码做到用jsx的语法生成页面内容，尽管这不能完全替代模版；第二则是为了吸引那些非jsx不用或者不看的人能来看两眼。很讽刺对不对？但我也非常无奈，因为现实就是如此。

1. 生态系统的形成，是社区认同上。而这个过程并不是一蹴而就的，react vue也是从零做起，但是它们一开始都有一个明确的设计意图，mvvm以及组件化开发应用。
2. 业务的发展促使了react的出现，试想下facebook的前端应用复杂度达到一定两级的时候，他必然会去寻找合适技术来解决，找不到那就自己做一个。
3. 所以，我觉得任何一个框架要想得到发展首先立意要清除，也就是解决问题的场景要明确。剩下就是耐心的迭代自己的产品，兼容并蓄好的想法，又不失本心的做好自己的特色。比如，我们所坚持的lugia。

谢邀。

前端框架的竞争是否已经变成生态系统的竞争？

是，无论Vue、React和Angular哪个不是有巨大开发者社区，哪个不是养活了一个生态系统，哪一个不是雄霸一方(Angular可能不是）。

其他框架生存空间太小?

是，咋了？不服？

虽然科技的进步来自于不断重复发明轮子，但是，各位开发者们，这么多框架，你们学得过来吗？与其搞出一大堆没人用生态系统都建不起来的“框架”，还不如好好建设完善现有的框架。

假如谁要发明一个新的轮子，带来革命性思想，横扫三大前端框架，解决开发者们的更大的痛点，那到时候生态肯定自然建立起来了。

我知道我知道，是会有人想要再造一个超级牛逼的轮子以名垂千史的，如果能做到最好，但是，不能因此怪React、Vue和Angular已经占领阵地了，就好比，你不能怪牛顿已经开创了经典力学让你没机会来发明经典力学吧，你要是真牛逼，就别怪牛顿创造“经典力学的生态系统”不给后来人扬名立万的机会，你要做的是去开创量子力学啊，当然，量子力学也已经被人开创了，那你要青史留名那就去开创更前沿的东西啊，踩着前人的肩膀接着上啊。

我个人觉得，对于前端应用开发者来说，技术方案在一定多样化下趋于收敛最好，需要学的东西少，可以更集中精力在应用开发上。现在有三个前端框架差不多了，数量刚刚好，三国演义嘛，那是传奇，五胡乱华，那就是一团浆糊。

只要大神不走, 核心开发不放弃, 框架就会有人维护, 大神用啥我用啥

emmm谢邀

我个人认为前端框架的竞争，并不是生态的竞争

我好像之前有说过，一个【新】框架的出现，它代表的是一个新的【机制/思想】的出现

本质上是前端没有革命性的东西出现罢了

至于生态，看看就行了，现在的时间点，就算写了 router，写了 store，写了组件库，小程序框架

仍然也火不起来

就好像我写了 fre，写了 use-routes 写了 smox 写了 fard，没什么卵用的

肯定火不起来啊，因为没有新东西，就没什么搞头，就没有人前来研究

分久必合合久必分！刚开始三大框架多样性，现在不也在趋于一致性。只是前端场景太丰富了，才有各家存在的价值。

那么多编程语言以及相关生态，为何不给新语言生存空间？

那么多操作系统以及相关生态，为何不给新操作系统生存空间？

都是为了应付不同的场景吧，所以现在前端这个职业也在细化，不同的公司招前端也有偏向。人类世界大的系统发展越来越精细。瞧瞧文化大融合的米国，不同的技术框架只是代表不同的设计理念和思想，如果都是双向绑定那就没意思了。所以在“造轮子”方面，我是觉得挺好，不过得有自己的创新点。希望能有一些创意的框架脱颖而出，给这个端技术带来新的思考维度。

至于生存空间？你只要理念新颖，有创新点，最重要能解决开发痛点和问题，生态那都不是事儿，哪个框架都是这么过来的。你把环境造好，不怕没有人来生存繁衍。

在现有web技术不发生巨变的条件下，是很难再出现第四大框架了。但这不是坏事。

遇到问题或痛点应该先在已有框架内想办法解决，解决不了再考虑能否通过修改或改良框架解决，最后没办法才去自己造框架。这种情况下做出的新框架也没必要去考虑能不能搞得过三大框架，遇到相同问题或痛点的人自然就会选择你的框架了。

不要为了做框架而做框架，重复造轮子对个人成长有益，对开源社区无益，如果你还有资源有背景去推广你的轮子，通过一些方法强迫开发者使用，那就真是谋财害命了。

做框架应该专注考虑技术上的优势和差异化，以及如何对开发者更友好。移动端框架那么多，为什么react-native能火？因为大大降低了web端的react框架使用者开发移动端应用的难度，做一些简单的跨平台需求不再需要js - java/kotlin - swift/object-c三种语言三种框架来回切换；为什么flutter又火了？因为解决了跨平台应用的性能痛点，有大厂保障维护，还有望扩展到桌面和web端。

对于开发者来说，也没必要为了学框架而学框架，什么精通三大框架纯粹是浪费时间，专精一套，能解决问题就够了。

谢邀，我不得不说，题主是太闲了吗，问这种问题其实毫无意义，你爱用什么框架就用什么框架，自己觉得好用就行。就像我不爱用三大框架，就算它生态强到变态我也只能说抱歉。

框架之争，真的没什么意思，就我这两个月的观察来看，此类争执，多数都是徒劳。

是呀，这个跟市场一样；只要你进场的早，技术能力还可以，就可以占领一定的空间；

越晚来，越要有特色，否则，只是打水漂而已

1．前端框架的竞争

前端框架之争，并不是生态系统的竞争，比的是谁能提供更大的价值。

VAR或其他框架基于原生的Javascript或者Typescript编写的，还到不了生态系统那个层面。

2．第二个问题：其他框架的生存空间是不是太小？

看起来是生存空间大小的问题，其实是框架提供价值大小不一样：

JQuery解决了浏览器兼容性问题，使用class选择器、插件，创造了一个前端的时代；

VAR三大框架解决了组件化，数据驱动（告别复杂的DOM操作），跨平台（使用web相关技术，开发小程序，安卓，IOS，PC应用），工程化（系统系解决性能，兼容，开发体验，测试等）这些问题，成为当下流行的框架。

未来也可能有新的框架、库诞生，假如它能够让开发人员的效率进一步提高，更加满足项目需求，那么它提供的价值更高，“生存空间”会更大。

3．身为一个前端，面对这种情况，该怎么办呢？

根据自身优势和项目需求，综合考虑，如果习惯了一切都用Js来写，那么学习react是个好选择；

如果喜欢轻量模板化，vue更适合；

如果有ts基础，并且开发大型，类型银行，事业单位大型，复杂系统，可以选择angular。

如果想要在前端走的更远，在熟练使用框架以后，可以了解ssh，http，性能优化（代码层面，网络层面）相关的知识，以便我们深层次理解各种技术栈之间的差异。