# 前端发展与思考

# 方向

# 跨端

  • Flutter
  • Web
  • Mobile

# Node

  • cli 相关
  • BFF + TS 相关
  • 公共组件、npm 包

# 工程化

  • cli 工具
  • 发布一体化
  • Node 相关

# 后端

  • Node
  • Go
  • Dart/Flutter
  • Java

# 可视化

  • svg
  • canvas

# 前端的部署

静态化

# Serverless

# 组件库

组件库、中后台前端的解决方案之类的。

# 微前端

# 大前端的方向

# 1. 企业中后台

  • 标准化: 数据接口协议、编译统一
  • 智能化: low code, 搭建服务

# 2. 开发者服务

  • 从端到云一体化应用的解决方案

# 3. 泛 Nodejs

  • Node 应用治理
  • ssr, bff 规范

# 4. 端技术

# 5. 图形

可视化 + 互动能力

  • 互动: 容器、引擎、框架、平台
  • 可视化: 智能化、数据联动

# 业务专注

# 敏捷

工程

  1. 研发模式优化
  2. 动态化 + 组件化
  3. 新工程能力: 动态部署,开发者服务

# 性能

  1. 性能专项治理: 内存、帧率,启动时间
  2. 基础体验三要素: 定位、容器、内容
  3. 互动能力:AR、语音、线下结合

# 稳定性

  1. 数据质量: 监控 + 预警
  2. 稳定性能力: Monkey, Hotpatch, 灰度
  3. 文化生根:零容忍稳定性文化

# 技术人成长的三个关键词

做、思考、发声

  • 做: 有目标的做,分阶段的做,做到极致
  • 思考:思考是核心:why 有时候比 how 更重要
  • 发声:执行的总结,思考的传达

# 关于思考

#

思考自己:

  1. 我擅长做什么?
  2. 我需要提升的地方?
  3. 老板对我的要求是?

思考团队

  1. 这个团队的问题是什么?
  2. 我能帮助团队解决什么?
  3. 我在团队中的角色是?

#

业务节奏

  1. 过去三个月的项目解决什么?
  2. 未来三个月业务要解决什么?
  3. “最痛”和“最重要”的关系

技术拆解

  1. 团队问题和业务问题作为输入?
  2. 如果只能做一件事?三件事?
  3. 目标、方案、节奏

# 关于做

why > 目标 > 方案 > 节奏 (按照顺序)

大家往往一接到事情就埋头扎到怎么做这个维度上,可是比方案更重要的是 why 和 目标。

# 关于发声

发声的本质:

  1. 思考的传达
  2. 帮助自我梳理和总结

# 前端的核心竞争力

  • 框架
  • 可视化
  • Hybrid
  • IOT
  • 工程能力
  • Node.js
  • JS
  • CSS
  • 3D
  • 算法
  • 基于上面所有知识和技能,对于业务和团队问题的拆解并输出解决方案且落地的综合能力

# 大前端时代下的前端进阶之路

作为一名合格的前端开发人员,我相信你一定会有一个很明显的感觉:前端并没有想象的那么简单。前端的职责越来越重要,战场越来越多样,应用也越来越复杂。但是从目前的实际情况来看,很多人对前端的认识还是停留在网页开发的阶段。

# 前端发展

最早期,所有人对前端的认知:就是用 HTML + CSS + JavaScript 完成网页切图。当时的前端只是 Web 开发的附属品,绝大多数情况都是处于被后端开发人员驱动的状态。而现如今,前端主导整个应用的开发已经成为常态。伴随着这种状态的变迁,前端技术在这些年也发生了翻天覆地的变化,核心技术不再局限于 HTML、CSS、JavaScript 本身。

现阶段的前端已经不再是往页面上引入几个库、调用几个函数就能满足应用开发需求的状态。如今,前端都拥有自己的工程,独立的发挥空间。不仅如此,从传统的前端发展到现在的大前端,前端的边界正在变得越来越宽泛,前端开发也慢慢趋向于泛客户端开发。

现如今,当我们聊起前端,听到的大多是各种框架、Node.js、Serverless、泛客户端之类的话题。我把这些内容总结了一下,大致分为以下这几点:

  • 层出不穷的框架和工具;
  • 各式各样的载体(客户端),泛客户端指的是各种各样的客户端载体,例如移动 App、H5、公众号、小程序等等。;
  • 蓄势待发的云开发(Serverless);
  • 无所不能的全栈;
  • 开发岗位的周边软技能。

# 热点趋势盘点

# TypeScript

JavaScript 是一门弱类型而且还是动态类型的语言,语言本身的类型系统是非常薄弱的,甚至可以说 JavaScript 根本就没有类型系统。

这样的特征就决定了 JavaScript 并不适合开发大型企业级应用,因为在大型应用开发过程中,我们的代码会非常复杂,开发周期也会特别长。这种情况下没有一个强大的类型系统,我们的开发成本和维护成本都会非常高。

TypeScript 是一门基于 JavaScript 基础之上的编程语言,是一个 JavaScript 的超集(扩展集),弥补 JavaScript 类型系统的不足。

所谓超集,其实就是在 JavaScript 原有的基础之上多了一些扩展特性。多出来的主要就是:

  • 一套更强大的类型系统;
  • 对 ECMAScript 新特性的支持;

这也就是说,使用 TypeScript 过后,我们开发者在开发过程中可以直接使用 TypeScript 所提供的新特性,以及 TypeScript 中更强大的类型系统去完成开发工作。然后将其编译为能在生产环境中直接运行的 JavaScript 代码。

那 TypeScript 的意义也就很明显了:

  • 类型系统可以帮我们避免开发过程中有可能出现的类型异常,提高编码的效率,以及代码的可靠程度。
  • ECMAScript 几年迭代了很多非常有用的新功能,但是在很多陈旧的环境中都会出现兼容问题。TypeScript 支持自动转换这些新特性,所以我们可以立即去使用它们。

即便我们不需要类型系统,通过 TypeScript 去使用 ECMAScript 的新特性也是一个很好的选择。因为 TypeScript 最终可以选择编译到最低 ES3 版本的代码,所以兼容性非常好。

因为 TypeScript 最终都是编译为 JavaScript。所以任何一种使用 JavaScript 开发的应用程序,都可以使用 TypeScript 开发。例如浏览器应用,Node.js 应用,React Native,或者是 Electron 桌面应用。

目前很多大型开源项目都已经开始采用 TypeScript 开发,最知名的自然是 Google 的 Angular 框架。另外,Vue.js 从 3.0 版本开始,也会使用 TypeScript 取代之前的 JavaScript + Flow。

慢慢地你会发现 TypeScript 已经成为前端领域中的第二语言。如果你开发的是小项目需要灵活自由,那么自然选择 JavaScript。相反如果你开发的是长周期的大型项目,所有人都会建议你选择 TypeScript。

当然,再美好的东西也都会有缺点,TypeScript 最大的缺点就是语言本身多了很多概念,例如接口、泛型、枚举等等,这些概念会增加我们的学习成本。不过好在 TypeScript 属于渐进式的语言,即便我们什么特性都不知道,也可以立马按照 JavaScript 标准语法去编写 TypeScript 代码,然后了解一个特性再使用一个特性。

再者就是对于周期短的小型项目,TypeScript 可能会增加一些开发成本,因为我们要额外编写很多的类型声明。但是如果是一个长期维护的大型项目,这些成本不算什么。纵观全局,TypeScript 整体带来的优势足以抵消它的劣势。

# 服务端渲染

目前主流的前端框架都是采用客户端渲染(CSR)的模式工作的,所谓客户端渲染,指的就是从服务器发回来的 HTML 中并没有页面内容,所有的内容都是等到页面中的 JavaScript 代码执行完成过后,动态创建出来的。大体过程我们可以参考下图:

这种客户端渲染模式的弊端显而易见:

  • 页面的“白屏”时间更长,用户体验不好;
  • HTML 中无内容,SEO 不友好。

针对客户端渲染模式的问题,服务端渲染(SSR)就能够很好地加以解决。SSR 大体过程可以参考下图:

相比于客户端渲染,服务端渲染就是在服务端多做了一些额外的工作:传统客户端渲染模式,在服务端接收到请求过后,只需要找到对应的 HTML 静态文件返回给客户端即可;而服务端渲染模式下,服务端接收到请求过后,会先执行一遍对应的 JavaScript,让页面在服务端先渲染一遍,然后将渲染的结果发送给客户端。所以客户端接收到的就是渲染过后的 HTML,自然也就没有上述问题。

目前主流的前端框架,比如 React、Vue.js、Angular 都有对应的服务端渲染方案,不过如果直接原生实现服务端渲染,那么需要你掌握的内容会比较多,也比较杂,其中的很多概念也会比较难理解。很多时候我们会选择直接使用一些集成式的服务端渲染框架,比如 Next.js 或者 Nuxt.js。

# Serverless

Serverless 是一种架构模式,翻译过来应该叫作无服务器架构。近几年被推向了风口浪尖,背后的原因除了一些人的 “盲从”,更为重要的是 Serverless 确实带来了一种全新的开发体验:对于使用 Serverless 架构进行开发的项目,开发者最明显的感受就是更关注应用的业务本身,不必再去过多关心服务器和运行平台的一系列问题。

传统情况下,我们开发一个 Web 应用,除了需要考虑业务本身,还需要考虑很多其他方面的东西,比如:服务器的操作系统、虚拟机、硬件资源配置、运行环境版本等等。如果你经历过这种模式下的应用初次部署,一定会头皮发麻。而且不仅初次配置麻烦,后期维护成本也很高,比如定期更新环境、清理缓存之类的。这让我想起了以前的一句玩笑话:一天 8 小时,6 小时折腾服务器。

再到后来,我们的服务逐渐切换到了云服务器上,在这种情况下,基本上不用关心太多的服务器底层维护问题,我们更多地是考虑运行环境的维护,这使得维护成本大大降低。

再到以后,我们可能会逐渐切换到 Serverless 架构上。无服务器,并不是真的没有服务器,只是开发人员眼中不需要关注服务器。开发人员只需要按照一定的要求完成开发工作,剩下的所有事情全部交给 Serverless 容器完成。

可能你会好奇:Serverless 真的有这么神奇吗?没有服务器,如何将应用运行起来呢?

其实也没有特别神奇,你仔细想想,我们的应用主要由两大块组成,分别是逻辑与存储。Serverless 中就通过两种方式解决了这两块的需求,分别是:

  • 函数即服务,Function as a Service,FaaS;
  • 后端即服务,Backend as a Service,BaaS。

其中 FaaS 中的函数指的就是计算函数,通俗一点描述,你可以理解为,你写了一个实现业务的函数,然后把这个函数丢给容器,容器就会自动把这个函数映射到一个服务上面,然后你就可以直接通过 HTTP 调用这个服务接口,也就是调用这个函数了。

而 BaaS 相对综合一点,它提供了一系列后端常用服务,比如数据或文件的存储、消息推送、账户系统等等。

结合这两点完全就可覆盖我们应用中绝大多数业务功能的开发,这就是 Serverless。它的优势十分明显:

  • 不需要再考虑什么物理机/虚拟机,结合工作流的情况下,代码提交自动部署,直接运行;
  • 没有服务器,维护成本自然大大降低,安全性稳定性更高;
  • 都是弹性伸缩云,硬件资源需要多少分配多少,不用担心性能问题;
  • 大多数 Serverless 服务商的计价方式都是按使用情况(如流量、CPU 占用)来收费;

总之,Serverless 必将大势所趋。

# Flutter 移动 App 开发

Flutter 是 Google 2018  年公开发布的一个移动 App 开发方案,通过 Flutter 前端开发者就能够开发出真正意义上的原生 App。

在此之前,前端面对移动 App 开发需求都是通过 H5 + WebView + JsBridge 的方式,或者 React Native 框架实现。这些方式虽说都能够实现移动 App 开发,但是都存在这样或者那样的问题,最明显的表现就是体验还是达不到原生实现的效果,性能上有所欠缺。

H5 的性能问题不用多说,始终是 Web 平台,相比于原生根本不在一条起跑线。而像 RN 这种方案,性能上最大的弊端在于 RN 项目最终打包的结构还是一个 JS bundle,也就是说还是需要到运行阶段才能够去解析 JavaScript(JIT)。

Flutter 就是一个纯原生的开发方案,采用的是静态编译(AOT),也可以叫作提前编译。一个 Flutter 项目编译后的结果就是原生应用,相比于即时编译(JIT)性能自然有显著提升。

Flutter 甚至还是一个跨平台方案,因为在 2019 年 Flutter 宣布支持 Web 平台,这标志着 Flutter 已经全面支持所有平台。详细内容可以参考 Flutter 官网

当然,Flutter 的缺点同样明显:Flutter 平台采用的编程语言是 Google 推出的 Dart,而非 JavaScript 或者 TypeScript,所以学习成本相对高一点。我个人认为没有选择 JavaScript 或者 TypeScript 的原因有两点:

  • JavaScript 类型系统的不足;
  • 吃了 Java 的亏,涨了个教训。

# 多端统一开发方案

随着这两年各种各样小程序或者快应用平台的诞生,互联网应用的载体种类(客户端形式)越来越多。由于这些不同平台的开发方式类似而又不完全相同,所以就产生了一个新的问题:开发人员要为不同的平台单独维护一个项目,这对于开发者而言需要关注的内容就会更多,学习成本也就更高。

目前前端行业中已经出现了一些很成熟的多端统一开发方案,例如 Tarouni-app。在这类方案下,开发者只需要编写一套代码,就可以直接发布在 iOS、Android 或是各类小程序平台中,大大降低了开发和维护的成本。

对于这类方案,一来我们应该掌握它们,以此应对层出不穷的客户端形式;二来我们也应该尝试去理解它们的实现原理,这会帮助我们更好地应对以后的开发工作。

# 写在最后

总之,不要给自己的学习设立边界,顺着主线,趁年轻多学习一点东西总是好的。

古人有一句老话 :“ 学源于思”,意思是说,学问是从思考中得来的。所以除了学习,还有一点也是我经常强调的,就是多思考为什么,这也是我成长过程中最大的收获,正是因为养成了勤于思考的习惯,我才能看到更多别人没有关注到的细节,才能解决别人解决不了的问题。

# 主要的方向

  • 前端工程化;
  • 核心框架的原理与进阶;
  • Node.js 开发;
  • 泛客户端开发;
  • 大量行业技术和解决方案。