创刊 Vol与第一份硬件实证发出之后的一周。Signal的质地有了变化——如果说之前是「这真能行吗」，本周更多的是「那我们的情况呢?」
本周Signal
「我们这个行业也能行吗」开始进来了。 在面板厂商 30 分钟把 HMI 装上画面的文章之后，最多的反应不是称赞，而是代入。「我们做的是仪表」「我们是传感器模组」「我们是自助终端——同样的方式行得通吗?」这是个好Signal。实证的目的不是赞叹，而是让对方用自己的处境重新去想。这也是这个连载一个行业一个行业往下做的原因。
有人把第一个画面跑起来了。 跟着编程文章立起一个画面的读者，发来简短的反馈。共同点很有意思——几乎所有人都说「最不习惯的是没有等待构建的那一步」。当熟悉的成本消失，那块空白反而显得别扭。那份别扭，正是这场转变最诚实的证据。
「服务器定义画面会不会慢」的误解。 这是本周纠正最多的一个误解。这种担心来自「每时每刻都在呼叫服务器」的想象，而实际上往返的只是画面的定义——不是沉重的代码包，而是「一个按钮、一段文字」这样轻的规格。何况收到一次后定义就会被缓存。真正沉重的渲染引擎，早已以原生形态在设备上。体感性能就是原生的。
工具·包·备忘
本周的备忘是关于状态。把值绑定到画面时，新手最常卡住的地方是「值变了，画面却没变」。原因几乎总是同一个——他们想去直接改画面。在服务器定义的模式里，你不是改画面，而是改状态。状态一变，绑定其上的位置自会跟随。你从不命令「重绘」。本 Vol第二篇编程文章正是处理这一点。
一点想法
关于「30 分钟」这个数字。它的一大半，是因为不必等待构建而省出来的余裕。我们随口称作「开发时间」的，相当一部分其实是等待时间——编译、烧录、审核、发布。不是制造这一行为本身，而是等待造好的东西抵达的时间。当这份等待趋近于零，同一个人用同一双手能走得远得多。变快的不是打字速度，而是尝试与查看之间的那口气。
来自现场
一位读者发来的一行字，久久留在心里。「我改了按钮颜色保存，另一个房间里的平板画面就那样变了。我什么都没做。」这本杂志长篇解释的事，他用一句话就概括了。
本周提问
在你的工作里，哪一个画面不是「做一次就完事」，而是「得不断打磨」?价目表、菜单、状态看板、设置画面这类经常变动的东西。越是这样的地方，定义而非烧录的方式收益越大。下周，我们会聊一个围绕这些「经常变动的画面」展开的领域案例。
makemind.dev 「动态」— 一月第三周。用数字回答「我们这行也行吗」。