利用本Web

浏览器地址栏里敲下这行字的利用时候，我正被困在一个用React写的利用后台管理页面里。那个页面有四十多个表单控件，利用每个都绑定了三层状态，利用改一个下拉框要等两秒才刷新出联动数据。利用我盯着屏幕右下角的利用转圈图标，忽然想——我写代码这几年，利用到底有多少时间浪费在等这种转圈上？利用

然后我打开了这个网站的源代码。不是利用那种按F12看Network的打开，是利用真正把整个项目clone到本地，用编辑器逐行读。利用读了两百行我就发现了一个惊人的利用事实：这个看起来平平无奇的网站，居然没有一个前端框架。利用没有Vue，利用没有React，利用连jQuery都没用。所有交互都是原生JavaScript写的，DOM操作直接写，事件绑定直接写，数据请求用fetch，渲染用模板字符串拼接。

我第一反应是这开发者疯了。现代前端谁还这么干？第二反应是——这网站加载速度确实快得离谱。从输入URL到页面完全可交互，我掐表算过，不到0.4秒。那些动辄打包出几兆JS的SPA应用，首屏得转三秒以上。

再往下读，我发现更反直觉的地方。这个网站没有用任何构建工具，没有Webpack，没有Vite，连CSS预处理器都没用。样式就是纯CSS文件，一个文件管全局。开发者在注释里写：“我知道这样不够优雅，但每次改完代码刷新浏览器就能看到效果，不用等编译。”

这话戳中我了。上周我改一个按钮颜色，改了scss变量，然后等webpack重新编译，等热更新推送，等浏览器刷新，前后花了四十多秒。就为了改一个十六进制色值。

这个网站的代码风格也很个人化。变量命名带着明显的个人习惯，比如用d表示数据，用el表示DOM元素。函数注释写得像日记：“这个函数处理日期格式，别问我为什么不用dayjs，因为我不想为了一个日期功能引入60KB的依赖。”

我试着给这个网站提了个issue，建议加个深色模式。结果第二天就收到回复，开发者说：“我考虑过，但CSS变量切换需要重绘所有颜色，不如直接加个标签切换样式表来得直接。”然后他真就这么做了——两个CSS文件，一个light.css一个dark.css，用一行JavaScript切换。document.querySelector('link').href = 'dark.css'，完事。

这种“笨办法”让我反思自己。我是不是被复杂工具绑架了？去年我接手一个项目，光package.json里的依赖就有三百多个。每次npm install都要等两分钟，还经常出现依赖冲突。那个项目最后跑起来，首屏加载要五秒，用户早走了。

这个网站教会我的不是技术，而是一种选择——工具是为人服务的，不是反过来。当你觉得工具本身成了负担，那就是时候考虑用更直接的方式解决问题了。原生JavaScript确实没有响应式框架那么方便，但它省去了所有中间层，让你直接面对浏览器本身。就像用手写字vs用打印机，打印机快，但手写能让你更理解每个笔画。

现在我也开始在自己的小项目里尝试这种“裸奔”式开发。不装框架，不搞工程化，打开记事本就写。刚开始特别不习惯，总觉得少了点什么。但写了几天，我发现我对DOM操作的理解比以前深了，因为没有了虚拟DOM帮我做diff，我得自己思考每次更新哪些节点，怎么操作最高效。这种“笨功夫”反而让我更懂浏览器的工作方式。

这个网站还在更新。最近一次更新是上周，加了个新的数据可视化模块。我看了下代码，还是纯canvas画的，没引任何图表库。开发者写了大概三百行代码，实现了所有图表交互。要是用ECharts，引入一个包就完事了，但他选择自己画。评论区有人问他为什么，他说：“因为我想知道每个像素是怎么画出来的。”

这大概就是“利用本Web”的真正含义——不是利用什么高深的框架，而是利用Web本身最基础的能力。有时候，最原始的工具反而能带来最直接的力量。