前端框架带来的疑惑与是非

说到框架，行业间的人都无数在争执前后端分离的Vue和React，跨平台软件开发的Qt 和Electron，快速搭建整站的高性能解决方案并可满足全栈需求的Nextjs和Gatsby，它们都有各自的职责和特色，整体上都是为了解决一些共同的问题。那作为用户到底怎么去看待？涉及到业务领域，那么相对应的产品的业务框架，到底又是什么？有没有现成的"框架"以供使用？这些问题总是在各种社区充满了战火。

感觉“框架”这个词其实比较泛，它可以是基于Node的工具，可以是一个开发轮子，可以是UI组件的架构，可以是软件架构，也可以是达成业务的一套系统，可以是测试的一套方案。就好比Scrum敏捷开发框架，其实它不是代码层面的开发框架，而是一种遍布生活每个角落的方法论+思维方式+其它影响的综合体。

用敏捷开发的一个重要观点来说，就是永远不可能有“最佳实践”，这是一个不断改进，不断探索，不断尝试，不断革新的过程，只有更好更合适，没有最好最合适。这里的最佳实践其实是一个“上限”，框架也一样，是没有上限的。

同样的，“前端业务框架”，这个框架可以是代码层面的，可以是一种工作流程，可以是一套现成的开发架构，可以是代码层面和工作流的组合，也可以是纯方法论。

譬如Vue和React只是工具，一种手段，不要把它当成是目的。通常处理大型的业务体系，大厂都有自己的微前端架构，从前中后台、前后端分离、组件化、团队协作、不同的编程语言的兼容、发布测试集成部署一条线，这是一个庞大的体系，它并不一定单纯就是业务框架化，当然也可以绑定一些常用业务功能(注册登录、JWT验证、分页、SEO等)，很大程度能给业务提速提效。需求不同，一定程度上来说业务代码还是需要去手写的，但是工具、组件和软件架构是可以重复利用的。比如WordPress也是属于一个工具，通过它提供的接口可以实现不同的业务需求，它也可以CD/CI化，也可以vue/react化，使用RESTful API，也可以用于Java环境，也可以直接开发小程序，App。

如果要做套框架，必要的封装肯定是需要的，但是软件设计模式的运用好坏，几乎直接影响了框架的好坏。关乎耦合、维护、迭代、目的、业务实现等方面。

如果你进一家非常规范的大公司，会需要去适应他们的研发体系，使用他们已经成熟的框架，也许你也只需要负责业务代码。如果项目独立性较强，也不是很庞大，完全可以自己构建工具，或者使用现成的第三方工具完成开发部署。

其实说了那么多，无非就是：萝卜各有所爱，在什么地方用什么工具，达成目的即可。

同样的原理，细微的差别，换一个人，换一个公司，可能就是另一套“框架”了。无需较真。我觉得真正要在意的，还是底层的技术和基础知识，任何框架都脱离不了他们，基础上去了，学什么框架都只是看看文档快速上手的问题，当然英语要尽量跟上，因为大多实时文档都是英文的。

如今框架已经非常卷了，开发框架亦是如此，那么设计框架呢？下次再思考一下这个问题。