静态页面开发新姿势
到目前为止,前端开发方法有以下几种:
- 传统静态页面:不使用框架,手撸DOM;
- 传统服务端渲染:HTMl作为模板,由服务端渲染完成;
- 单页应用:使用MVVM框架前端渲染;
项目特点
所谓静态页面项目,只项目中大多数为无交互逻辑的展示型页面。如产品介绍,官方网站,内容发布等项目,都属于静态页面项目。
结合业务,静态页面的项目需要满足以下特性
『静态』页面
顾名思义,这类项目绝大多数内容都是静态的,是写死在项目里的。
SEO友好
因为此类项目往往用于宣传,所以一般依赖搜索引擎引流,SEO是必不可少的。
快速打开
此类项目的用户往往没有明确的目标,抱着随便看看的心态。如果网站首屏加载速度较慢,会损失一部分弱网环境的用户。
单页可拆分
此类项目页面不多,但内容很丰富,我们需要将大页面中的解耦元素进行拆分,独立开发, 这样做的好处就不再赘述了。
最佳实践
为了满足上面的特性,我们需要综合考虑不同开发方法的优劣,得出最优解。以下是几种开发方法的对比:
方法 | 首屏打开速度 | 体验 | 开发效率 | 可维护性 | SEO | 成本 |
---|---|---|---|---|---|---|
传统静态页面 | 极快 | 差 | 极低 | 极低 | 一般 | 高 |
传统服务端渲染 | 快 | 一般 | 低 | 高 | 好 | 极高 |
单页应用 | 慢 | 好 | 高 | 极高 | 差 | 低 |
通过对比可以看出:
- 在不考虑开发成本和硬件成本的情况下,比较符合我们预期的是传统服务端渲染;
- 单页应用虽然成本低,效率高但首屏打开速度过慢,SEO几乎不支持,这不符合项目的要求,所以不考虑;
- 针对一些流量较大,逻辑简单,开发时间充裕,不需要长期维护和迭代的项目,传统静态页面比较符合我们的需求。
新想法
我们发现,这几种方法都是优缺点互补的,如果能把这些好的地方集合到一起形成一种新的开发方法,就太好了。
单页应用的预渲染
即编译时将单页应用渲染一次形成多页应用。结合静态页面的「静态」的特点,预渲染的页面首次加载与加载完成几乎没有差别。
单页应用的服务端渲染
即服务端提前将动态加载的数据渲染成为可直接浏览的页面后返回,这可以很好地解决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,自动修复各种风格差异,保证项目风格一致。
资源文件
- 所有资源文件直接从CDN拉取,防止项目过大,项目文件混乱;
- 图片提前裁剪至合适尺寸上传至CDN。