在知乎上看到这么一个问题，觉得很有意思，以下是原提问者的见解
过去五年前端的发展过程基本上是一个工程化的过程,框架和工程化工具层出不穷。
近两年其实发展已经比较迟滞了。
框架方面:基本就是三大框架鼎立的局面,三大框架都在相互借鉴吸收,而且方向各有侧重,未来短时间内我看格局不可能有什么大变化.
工程化工具:基本上是 webpack 一统江湖的趋势,虽然有 parcel 等来小打小闹,但是生态一旦形成,没有革命性的项目是无法取代 webpack 的,而且 webpack 也在进化.
个人认为前面五年是前端生产力提高的五年,工程化使得前端的生产力得到了极大提升,但是现在也基本上是在已有的格局中修修补补了
我谈谈我对前端未来几年的发展方向的看法。
看未来的发展方向，无非就是看现在的解决方案所存在的痛点。
1. 浏览器的性能问题
做 web 前端的同学都知道，和原生的 App 相比，性能一直一个致命的痛点，如果要追求性能，肯定得用原生 App。那么在性能上，未来几年可能是一个方向。
①前端代码编译为字节码
浏览器这几年在 Chrome 的带动下，性能飞速发展，但毕竟其核心原理没有变化，性能始终难以达到原生 App 的水平，这部分是很有可能出现大的变化的，一个可能的方向就是浏览器变成虚拟机，前端代码编译为字节码，通过这种方式来将性能提升一个等级，虽然还是难以达到原生App的水平，但已经能够满足绝大部分应用的性能需求，类似于Java对比C/C++一样。 —李运华
因为 js 是边解释边执行的，这肯定是要比编译型语言要慢，为了解决解释器的低效问题，大概在 2008 年的时候，提出了 JIT 的概念，它是使 JavaScript 运行更快的一种手段（JIT，内联缓存和隐藏类）之一，通过监视代码的运行状态，把 hot 代码（重复执行多次的代码）进行优化。通过这种方式，可以使 JavaScript 应用的性能提升很多倍。
但是时至今日，还是觉得不够快，所以各大浏览器厂商开始支持 WebAssembly。WebAssembly 是一种新的字节码格式，主流浏览器都已经支持 WebAssembly。
和 JS 需要解释执行不同的是，WebAssembly 字节码和底层机器码很相似可快速装载运行，因此性能相对于 JS 解释执行大大提升。
也就是说 WebAssembly 并不是一门编程语言，而是一份字节码标准，需要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行.
他的优点就是：
- 体积小：由于浏览器运行时只加载编译成的字节码，一样的逻辑比用字符串描述的 JS 文件体积要小很多；
- 加载快：由于文件体积小，再加上无需解释执行，WebAssembly 能更快的加载并实例化，减少运行前的等待时间；
目前可以编译成为 WebAssembly 字节码有 ：AssemblyScript(语法跟 TS 差不多，)、c\c++、Rust、Kotlin。
②统一的DOM树限制了单线程的渲染
理论上来说，一个页面某个时间变化的部分只是集中在一小块区域，没有必要将整个DOM树锁住。因此，一个可能的方向是分区渲染，即将页面划分为几个不同的区域，每个区域有独立的DOM树，独立渲染，那么性能会高很多，类似于 App 开发中的组件，组件类的运行不影响其它组件，如果需要依赖其它组件，通过组件间消息进行通信。
原生 App 不同平台重新开发的痛点
现在的 web 有两大优势，一个是浏览完毕直接走人，另外一个是跨平台，只要有浏览器，一切都好说。
所以现在有很多 hybrid 解决方案，某些页面通过 h5 的方式来展现。
想解决的无非就是少花点成本，写一份代码，可以在 ios 和 Android 上都可以用，进而也出来了想 RN、weex、NativeScript 这类 Learn Once, Write Anywhere(RN提出来的) ，但是他们最终都会翻译成原生代码。
但是用过这些的人都知道，还有很多坑，经常调侃 rn 的就是 write once ，debug anywhere。
Learn Once, Write Anywhere 的理念，背后就是跨端的思想，所以也诞生出来 electron、PWA 为代表的案例。
而且现在出现了 Taro 、mpvue 这些 h5 与小程序的统一的方案，所以未来在突破写一份代码在 h5 ，原生 app、小程序，甚至桌面应用都有可能。
另外提醒
- 我很早就跟星球里的朋友们说过，TS 一定会在火的，现在用 TS 的感觉，让我感觉跟 vim 很像，刚开始用的时候很难受，一旦习惯了就离不开了。未来项目会越来越复杂，用了 TS 项目的风险会可控很多。
- 多注重框架原理，现在对于前端工程化，个人认为差不多到了瓶颈期，很难有新的突破，注重原理才能很好的应对未来的发展。
- 眼界放宽、拓宽自己知识的广度。