自从angular/react/vue的出现颠覆了前端开发者开发模式以来，虽然新的前端框架依然不断涌现，但是迟迟没有一个新的前端框架进入广大前端开发者的视野。本文会从近两年越来越火的lowcode/微前端出发，探讨在传统前端领域，下一代前端工程/框架的可能方向。
一、lowcode
lowcode 其实一点也不新，通过 GUI、配置化的方式代替传统的手写代码编程，从sql语句到dreamweaver,基于模型驱动的可视化的编程工具层出不穷。而近两年lowcode的兴起，笔者认为主要有以下原因：1.前端技术体系及工程化体系成熟，许多有追求的工程师渴望用新的轮子追求变革式的生产效率突破；
2.前端开发者依旧稀缺；
3.B端业务兴起，大厂提前布局，希望在未来能够商业化从中获利；而和历史上诸多尝试相比，这次前端lowcode平台的兴起最大的不同: 大多数平台的目的是为了解决普通人的编程问题，而不再是开发者的编程效率问题。
1.1 国内lowcode平台
目前应用比较广泛的：
易企秀、淘宝天马 这样的基于页面模板搭建，开发人员开发模板（或者开发人员开发模块和模板），运营人员配置页面；阿里云凤蝶、百度爱速搭这样的组件配置平台（可以通过配置组件实现模板功能）。这些平台都一定程度满足了用户快速建站的需求，特别是时间紧、没有开发人力时。
1.2 lowcode可以解决所有问题吗？
lowcode平台是为了提升一部分交互简单的前端开发场景开发效率的，这也就是说对于使用者来说最大的问题在于使用场景及时机的判断上：谁来判断使用哪个lowcode的平台，研发还是产品经理？找到平台后，谁来判断哪些业务可以使用平台搭建？谁来搭建？当平台只能满足99%需求时怎么办？所以很多时候，我们找到了平台，配置了页面，最后发现某个需求完成不了而不了了之。当然，许多平台支持开发人员开发定制模板或者自定义组件，但是，当你有了自定义组件需求时，基于平台开发还会比自行开发效率高吗？
1.3 场景举例
我们孵化了一款新的APP，希望配置一个简单宣传页，页面内容就是一张背景图，一个下载按钮。
我们使用平台配置好了页面，也配置好了按钮的下载链接，此时PM提出了新需求，当用户已经安装了APP时不再下载而是直接打开APP，我应该基于平台开发一个自定义的action还是自己线下开发下呢？？？
1.4 serverless
当然，lowcode平台也提供了一些serverless的功能，但还是那个问题，谁来评估要不要用serverless？谁来使用？遇到不支持的问题该怎么办？
二、微前端要解决什么问题
微前端是一种从后端微服务借鉴过来的架构方式。市面上微前端的方案层出不穷，我就不列了，我们只需要明确下，微前端、前端微服务到底要解决什么问题：利用服务化、微服务的概念，有效的拆分应用，实现敏捷开发和部署，解决大型项目的管理问题。
2.1 场景举例
两个不同团队的业务，需要合成一个：电商平台、视频PC发布平台，需要统一到同一个站点，让用户实现发布视频、挂接商品一条路径走通。
当业务简单时，可以让两个团队协助工作，但是当各自业务越来越复杂，会有越来多的问题出现：技术栈必须统一开发、部署耦合运行时一个业务的BUG可能带崩整个系统
2.2 为什么提到微前端
微前端的兴起，说明前端工程复杂度的提升，越来越多的人遇到类似的架构问题，说明我们需要一个更上层的应用框架来帮助我们解决类似应用拆分隔离这样的架构问题。
三、前端框架及前端工程化
3.1 前端框架
我们思考 jQuery/React/Vue 这几个划时代框架/类库的共性，会发现他们都是为了解决视图层的问题而诞生的。
这不难理解，传统前端的核心就是视图，如何更快的帮助前端开发者更好的完成视图开发工作，是大部分前端框架要解决的核心问题。
jQuery简化了视图层开发的DOM API，React/Vue 更是绕开了API，颠覆了页面的开发模式。这个过程中，随着前端技术的发展，工程化在框架应用中所占比重越来越大，大多数vue使用者创建项目都是通过vue cli创建。
3.2 什么是前端工程化？
工程化是一种思想，主要目的是为了提效，即提高开发效率，减少不必要的重复工作。工程化常见的方向有模块化、组件化、规范化、自动化4个方面。
回顾前端框架的发展，会发现前端框架的发展其实和工程化发展相辅相成，绕开DOM API、通过工程化实现更低的上手成本 是vue/react成功的根本，而vue/react在代码运行侧已经解决了足够多的问题，前端框架后续的发展焦点需要更多的偏向工程化。
四、下一代前端应用框架
使用高度工程化的应用框架进一步推动组件化发展，再度重塑开发模式，这是我认为下一代前端应用框架需要做的事！
换句话说，它需要更容易的让开发者解决组件化、自动化、规范化等工程化的问题，可以快速让开发者实现一个lowcode、procode、微
