对于 Web 项目,我一般会将其分为“页面”和“应用”两大类,页面是指博客、企业官网等展示类的网页,应用是指中后台、在线文档编辑等用户交互较多的项目。对于“页面”而言,偏重的是数据获取,比如获取一篇文章的内容再把它渲染成页面,对“应用”而言,偏重的是数据修改,需要把用户在页面上交互产生的数据提交给服务端。
前些年国外比较流行的前端框架大多都是倾向于数据获取,然后变着花样地实现生成页面的方式,如 SSR、SSG 等,好像他们的业务中不需要做中后台之类的应用,而最近这些框架又在折腾数据修改,试图把原生表单带回到前端应用中,但对于比较复杂的交互,这种方式挺难用的。
比较典型的代表就是 Next.js,前几年在折腾 getStaticProps、getServerSideProps 等用于获取数据的 API,而现在又在搞 Server Actions 之类的 API 用于数据修改,整得挺不伦不类的,社区对 Next.js 的抱怨也越来越多。
这里就不得不推荐一下 Astro 了,它是一个专注于内容型站点的框架,虽然现在没有很火,但绝对值得一试。这里简单介绍一下它的几个主要特性。
默认无 JS:Astro 渲染的页面可以做到无 JS,比如一个博客页面只是纯文本的展示,本来就不需要 JS,而其他框架无论如何都需要加载一大堆 JS 文件以及比较耗费性能的 hydrate 操作。
岛屿架构:无 JS 是一种比较理想的情况,有时候我们的静态页面上也是需要一些交互的,比如轮播图等。岛屿架构是把整个静态的页面比做海洋,而可交互的部分则比做是一个岛屿,一个页面上也可以有多个岛屿,并且每个岛屿之间互不影响,可以独自进行 hydrate,不会阻塞整个页面的渲染。
另外 Astro 虽然定义了自己的 .astro
文件格式,但是也支持多种框架,如 React、Vue 等,并且官方文档也有完整的中文版本,对于“页面”类型的项目可以尝试一下。
技术
The Two Reacts
Dan 的最新文章,文中提到了 React 中的两种范式,一是 UI = f(state)
,其中 state
来自客户端,二是 UI = f(data)
,其中 data
来自于服务端,有点类似于 Next.js 中的客户端组件和服务端组件,在实际情况中会是两种范式的结合,即 UI = f(data, state)
,怎么对两种范式的组件进行划分就是一个问题,等他下篇文章来讲。
技术极简主义:一切皆用 Postgres
原文是一篇 Hacker News 上的帖子,作者提倡使用 Postgres 来替代 Kafka、RabbitMQ、ElasticSearch 和 Redis 等,来降低系统的复杂度。得益于 Postgres 的高性能和可扩展性,这确实是个不错的方案,尤其是对个人开发者或小团队的项目来说。
Open sourcing Pingora
Cloudflare 开源了他们的网络框架 Pingora,使用 Rust 编写,可以理解为 Rust 版的 Nginx,本文对 Pingora 做了简单的介绍。
开源
zbpack
zbpack 是一个自动分析代码所使用的语言、框架等信息,并自动将其打包成可部署产物(如静态文件、云函数、容器等形式)的工具,由 Zeabur 开源,并运用在 Zeabur 平台上。
Tiny RDM
一个轻量级、跨平台的 Redis 客户端,支持 macOS、Windows 和 Linux,基于 Wails 和 Vue 开发。
设计
Mobbin
世界上最大的手机 App 和 Web 设计库,收集了大量应用的设计案例和截图,与 Dribbble 类似,但这里面的都是实际案例。