一点思考

整篇文章的思路是这样子的:重新思考前端开发过程,有不少让人觉得不痛快的地方。如果没有这些束缚的话,理想中的开发部署又是怎样的?理想有点远,眼下我们又能做些什么呢?

现状与问题

最近在重新思考前端构建与部署,不过上次写的文章根本没有讲清楚。没有讲清楚为什么要这么做。现在我们来重新审视下目前流行的前端技术栈与发布方式,以我熟悉的技术栈为例。

  1. 项目启动:一般团队都会有自己的脚手架,再不济也可以 copy 现有项目,迅速搭建开发环境。
  2. 开发与调试:集团内比较常见的或许是 React + Redux,集团外或许是 Vue
  3. 构建与部署:云构建发布到 CDN 上,修改后端维护的版本号。构建工具基于 webpack。

我们再来看看问题:

  1. 脚手架的问题之前也提到过,没有一个像样的更新工具,用 generator 生成之后只能手工升级。
  2. 开发中的问题很多,与技术栈关联也比较大。我觉得有个问题值得反思一下,现在很多的框架号称半小时搞定增删改查,为啥前端还是忙的没时间,甚至有些觉得开发速度不比 jQuery 来的快。
  3. 计算资源的浪费。以 React 应用为例,对于纯静态的内容,每次重新渲染这不是纯粹浪费么,不管在服务端还是客户端这些浪费都是不能容忍的。前后的资源消耗统一来看的话,怎么看都是服务端模板渲染更为节约。
  4. 带宽的浪费。每个项目都用到了那么多的公共库,webpack 一并打进去,每个应用每个版本都有大量的请求都是非必须的。而且集团很多的变更,都是一个版本的粗粒度的控制,每次版本变更,所有的资源又重新拉取一次。
  5. 构建的问题。webpack 取代 gulp,改变了我们管理资源的方式。webpack 很复杂,它的配置我们应该关心吗?我们把构建理解为一个黑盒,源文件作为输入,目标代码作为输出。我多希望我什么都不用关心,构建就能正常运行起来。
  6. 部署优化。pagespeed 已经提供了一个性能诊断,甚至可以给出一个优化方案,为什么我们还要自己上手来搞这些。

大胆思考

上次也接着贺老的思路 YY 了一番,这儿再啰嗦一遍:

  1. 资源云化。所有可以公用的资源都在云上,可以说是公用 CDN 资源的高级形式。这个可以解决问题4。
  2. 几乎不需要配置,构建可以自动完成,并且它可以做些分析,还可以做些优化。
  3. 现成的部署和监控方案,根据请求响应不同内容。比如首屏的关键路径样式优化,预加载,这些由服务器自动优化。

上面的 2 和 3 听上去都有些智能的感觉。还有一个问题是:我们进行了太多重复不必要的运算,就像上面的问题3,每次重新运行 webpack 我都觉得是种浪费。

脚踏实地

步子迈的太大,有点不切实际。我们先利用好手上可用的工具来解决性能和资源问题。不对现有技术体系做大的调整下,利用新的技术做些优化。

对上面的问题3,我们还有服务端渲染嘛,只是服务端渲染的机会成本略高。退一步我们可以考虑,数据直出,预渲染。create-react-app没有引入服务端渲染的特性,倒是提到了预渲染 React Snapshot 。这个库的思路是:服务端渲染太麻烦,不如生成静态页面。react-snapshot 提前渲染这些页面,重新生成一个静态页面。

增强构建。PWA 很诱人,无需大的改动,我们可以使用webpack 插件 可以帮助生成 servicework.js 文件。若有必要我们可以使用 http2-aggressive-splitting 分割文件来加快 HTTP2 网络下的资源加载速度。还有 preload-webpack-plugin 插件帮助做预加载的脚本。

后记

追随框架与工具变革却看不清未来发展趋势,整理下最近的想法。