迅速发展的前端开发, 在每一年, 都为开发者带来了新的关键词. 2019 年已接近尾声, 2020 年前端发展的关键词将有哪些呢? 发展的方向又会是什么呢? 参考 2019 年大前端的发展, 不出意外, 前端依旧会围绕程序, 超级 App, 跨端开发, 前端程化以及新技术运用等几个方面进行展开(可以参考 2019 年大前端技术趋势深度解读).
小程序
在微信程序, 今年仍然小是程序突然猛进的年, 各大主流的 App 都上线了程序能的持, 各前端团队也都有了专业小的程序开发团队, 以适应更快的程序开发需求. 同时 App 中很多关键的功能都被程序所替代, 甚至有些 App 已经变成 Native 程序壳, 上层的应用实现全部是小程序.
在微信小程序出现以前, 大家在谈 Hybird,ReactNative, 但终归只是技术层面的狂欢, 始终没有业务属性的注入. 小程序的出现, 一方面告诉业界在当前设备上 webview 也没差到哪去, 另外一方面告诉业界如何让有能力的商家在超级 App 上进行私域运营.
另一方面, 从技术角度说, 在上层 DSL 的严格限制下, 超级 App 就可定义符合自己诉求的 Web 标准, 弥补当前 Web 标准的不足, 最后和客户端配合, 结合离线, 预加载, 定制 Webview 能产出类似于 NSR 等各种酷炫的技术模型, 让 Web 在端内低成本达到 Native 版的体验, 端外也不会像 Weex 一样有点小别扭.
不过由于需要依赖超级 App(微信, 支付宝, 百度, 美团, 头条等), 由于各家平台采用的具体方案的差异, 造成目前小程序的落地方案也不一样, 有时候需要开发多套代码.
跨端开发
跨端开发, RN 态已经常成熟, 或者说看不到太多发展前景, 因为目前还停留在 0.61 版本, 似乎 1.0 版本仍然遥遥无期. 因此, 今年很多团队转战歌态的 Flutter, 特别是 Flutter for Web 的第个 Release, 让 Web 前端重燃希望, 跃跃欲试.
同时, 苹果公司也发布了全新的 UI 系统 --SwiftUI, 同时, 开源社区中 SwiftUI for Web 已经在路上了, SwiftUI for Android 还会远吗?
跨端开发, Flutter 仍会快速发展, 并且会有更多的开发者, Flutter on JS,SwiftUIfor Web&Android 也将是开源态值得期待的事情, 毕竟跨端仍没有个完美的解决案.
前端工程化
在前端工程化, 开发者最重要的基本素养就是通过具提升效率, 前端开发者在这会持续迭代和优化.
曾经我们谈 Yoman, 谈 CLI 等系列构建工具, 但在团队大了之后始终觉得差点什么. 反观 Java 同学, 从没听说过 Spring Boot 配置工程师. 今年很多团队都在建设完整的前端 DevOps 流程具集, 些团队之间也开始协作共建, 不管是 Web 还是程序项, 从新建项, 开发, 联调(tiao), 部署, 测试, 发布, 运维到监控统计, 都有完善的具做保障和提效, 今后前端程也会越越标准化.
展望 2020 年前端的发展, 前端工程体系一定会更加闭环, 不再是一个脚手架这么简单, 而是会结合 IDE, 打通业务属性, 从项目初始化, 到编写代码, 到 CI, 到灰度, 到发布 形成一个完成的闭环.
Serverless
Serverless 的爆乎可以归因于前端. 因为 Serverless 能够较完美的持 Node.JS, 使 Serverless 帮助前端开发者解决了使 Node.JS 过程中的诸多问题.
当前的前端工程师大多都是科班出身, 虽不能和正宗的服务端开发同学比, 但也可写很多服务端层的业务逻辑. 当前已经有很多公司在做 BFF 层, 来满足这部分诉求, 但依旧摆脱不掉运维, 机器分配 这条拦路虎. 随着 Serverless 的逐步落地, BFF 这层的代码会摆脱运维, 机器分配等复杂的问题, 同时大概率会由前端同学写这部分代码, 服务端同学专注中台系统的实现. 从业务上说, 业务的试错成本也会大幅度降低.
随着 Node.JS 成为前端开发者必备技能之后, 云计算的不断普及会让 Serverless 触可及. 当越来越多的开发者尝到研发效的甜头之后, Serverless 必将对前端的研发模式产变.
同时, 使用 Serverless 的同学一定会使用 TS. 这也意味着, 2020 不写 TS 可能真的就 Out 了.
WebAssembly
WebAssembly 是一种新的字节码格式, 目前主流浏览器都已经支 WebAssembly. 和 JS 需要解释执行不同的是, WebAssembly 字节码和底层机器码很相似, 可以快速装载运行, 因此性能相对于 JS 解释执行而言有了极大的提升. 也就是说 WebAssembly 并不是一门编程语言, 而是一份字节码标准, 需要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行, 浏览器厂商需要做的就是根据 WebAssembly 规范实现虚拟机.
有了 WebAssembly, 在浏览器上可以跑任何语言. 从 Coffee 到 TypeScript, 到 Babel, 这些都是需要转译为 JS 才能被执行的, 而 WebAssembly 是在浏览器里嵌入 vm, 直接执行, 不需要转译, 执行效率自然高得多.
举个例子, AutoCAD 软件是由美国欧特克有限公司 (Autodesk) 出品的一款自动计算机辅助设计软件, 可以用于绘制二维制图和基本三维设计. 使用它时, 无需懂得编程, 即可自动制图, 因此它在全球被广泛应用于土木建筑, 装饰装潢, 工业制图, 工程制图, 电子工业, 服装加工等诸多领域.
AutoCAD 是由大量 C++ 代码编写的软件, 经历了非常多的技术变革, 从桌面到移动端再到 Web. 之前, InfoQ 上有一个演讲, 题目是《AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web》, 即通过 WebAssembly, 让很多年代久远的 C++ 代码在 Web 上可以运行, 并且保证了执行效率.
hrome 的核心 JavaScript 引擎 V8 目前已包含了 Liftoff 这一新款 WebAssembly baseline 编译器. Liftoff 简单快速的代码生成器极大地提升了 WebAssembly 应用的启动速度. 2019 年, 很多的公司都开始投入人力进行 WebAssembly 的学习个改造, 相信 2020 年 WebAssembly 会经历爆发式期.
5G
2019 年一个绕不开的话题就是 5G. 先, 5G 带宽的幅提升带来传统 Web 复杂度的进步提升, 如同 2G 到 4G 变化过程中从 WAP 的纯本超链接时代化变到 4G 全图视频时代. 5G 对于变的必将是巨大的, 但肯定不会. 因为相应的配套设施也需要逐步完善, 如硬件性能和浏览器的处理速度. 服务端渲染 (SSR) 肯定是其中个捷径, 轻前端重后台, 5G 是桥梁, 把渲染放后台, 不像同构那么简单, 需要关注和优化渲染性能. WebAssembly 或许会在这个机遇下得到快速发展, 因为它可以缝对接后台多种语, 后台渲染的优化也会带来前端研发模式和技术架构的变.
其次, 5G 带来的万物互联, 将带来有别于智能机和普通 PC 的多样化的应场景, VR, 可穿戴设备, 车载系统, 智能投影, 智能交互等会把 Web 带各种各样的垂直领域, 这也意味着前端将有更多阔的空间. 相信随着 5G 的大规模商业, 会诞生一批新的互联网巨头.
来源: http://www.jianshu.com/p/ea35b97979c5