HomeAuthorContactSearch

静态页面开发新姿势

到目前为止,前端开发方法有以下几种:

  1. 传统静态页面:不使用框架,手撸DOM;
  2. 传统服务端渲染:HTMl作为模板,由服务端渲染完成;
  3. 单页应用:使用MVVM框架前端渲染;

项目特点

所谓静态页面项目,只项目中大多数为无交互逻辑的展示型页面。如产品介绍,官方网站,内容发布等项目,都属于静态页面项目。

结合业务,静态页面的项目需要满足以下特性

『静态』页面

顾名思义,这类项目绝大多数内容都是静态的,是写死在项目里的。

SEO友好

因为此类项目往往用于宣传,所以一般依赖搜索引擎引流,SEO是必不可少的。

快速打开

此类项目的用户往往没有明确的目标,抱着随便看看的心态。如果网站首屏加载速度较慢,会损失一部分弱网环境的用户。

单页可拆分

此类项目页面不多,但内容很丰富,我们需要将大页面中的解耦元素进行拆分,独立开发, 这样做的好处就不再赘述了。

最佳实践

为了满足上面的特性,我们需要综合考虑不同开发方法的优劣,得出最优解。以下是几种开发方法的对比:

方法 首屏打开速度 体验 开发效率 可维护性 SEO 成本
传统静态页面 极快 极低 极低 一般
传统服务端渲染 一般 极高
单页应用 极高

通过对比可以看出:

  1. 在不考虑开发成本和硬件成本的情况下,比较符合我们预期的是传统服务端渲染;
  2. 单页应用虽然成本低,效率高但首屏打开速度过慢,SEO几乎不支持,这不符合项目的要求,所以不考虑;
  3. 针对一些流量较大,逻辑简单,开发时间充裕,不需要长期维护和迭代的项目,传统静态页面比较符合我们的需求。

新想法

我们发现,这几种方法都是优缺点互补的,如果能把这些好的地方集合到一起形成一种新的开发方法,就太好了。

单页应用的预渲染

即编译时将单页应用渲染一次形成多页应用。结合静态页面的「静态」的特点,预渲染的页面首次加载与加载完成几乎没有差别。

单页应用的服务端渲染

即服务端提前将动态加载的数据渲染成为可直接浏览的页面后返回,这可以很好地解决SEO的问题。

结论

  • 使用单页应用的Workflow快速高效开发;
  • 将纯静态页面预渲染,放在CDN上;
  • 使用服务端渲染含有动态数据的页面。

技术栈选择

Next.js (React)Nuxt.js (Vue) 都可以很好的实现需求,但精益求精,还是可以作一些对比出来。

加载速度

Vue 的依赖收集机制在强交互,状态大量改变的场景下表现地很好。但相应的,首次加载或刷新页面时,它需要一些时间来收集依赖。考虑到我们项目各种意义上的「静态」,Next.js胜出。

上手难度

Next.js是从零配置的,需要一些时间来搭建适合业务的项目,Nuxt.js是开箱即用的。作为项目的开发者,Next.js的上手难度要低一些。

开发效率

毫无疑问,Vue的效率要高一些。但此类项目交互逻辑简单,所以开发效率不是我们考虑的重点。

可维护性

JSX 非常适合这种需要频繁拆分组件的场景,而且React对Typescript的支持也更好。

影响力

Next.js坐拥庞大的React社区,由ZEIT开源。有非常多著名的产品站和官网,都是使用Next.js开发。

这里看:https://nextjs.org/showcase

最后选择 Next.js 作为主要技术

工作栈

样式处理

围绕React样式的问题一直以来都是热点。依然是结合业务:我们需要编写很多组件和CSS代码。所以我更偏向于CSS-in-js。这样可以保证这些组件的样式没有命名空间冲突的问题,目录页更好组织。

得益于预渲染的好处,编译时写在Js里的CSS就自动转化为了内联样式,顺手还解决了样式闪烁 (FOUC) 的问题  。

兼容性

使用Typescript与Babel相结合,添加各种腻子保证兼容性。

热重载

Next.js是基于Webpack的

Lint

Eslint配合Prettier,自动修复各种风格差异,保证项目风格一致。

资源文件

  1. 所有资源文件直接从CDN拉取,防止项目过大,项目文件混乱;
  2. 图片提前裁剪至合适尺寸上传至CDN。