迁移一个中等规模的React应用到Janet + Urn，最初源于对重复渲染逻辑的厌倦。这个后台管理系统有大量列表页、筛选表单和详情抽屉，每个页面都在重复useState、useEffect、useMemo的组合，自定义Hook越来越多，但业务逻辑仍然散落在各处。开始探索Lisp方言之后发现，Janet和Urn处理这类场景的方式与React完全不同：Janet作为后端语言用宏消除重复的CRUD接口，Urn在前端把组件抽象成可以像函数一样组合的表达式。整个过程不是一键式迁移，而是先保留React的构建产物，逐步用Urn替换交互密集的组件，再把API层从Node切换到Janet。
这次迁移的目标不是追求新潮，而是验证Lisp方言在真实业务中的可维护性。Janet是一门小巧的Lisp方言，内置了协程、模式匹配和宏系统，运行在服务端非常轻量。Urn则是另一门Lisp方言，编译目标为JavaScript，能够直接操作DOM，也能调用React的底层API。两者配合时，Janet负责数据建模和接口逻辑，Urn负责视图层和用户交互。最大的吸引力在于，前后端可以使用同一套函数式编程思维，宏在两端都能减少样板代码。
迁移前的技术判断：Janet与Urn能替代React的哪些部分
React本身并不是一个完整框架，它解决的是视图层声明式渲染和组件状态管理。一个典型React项目还会引入Redux或Zustand做全局状态、React Router做路由、Axios做请求、自定义Hook封装副作用。迁移到Janet + Urn时，需要逐项判断这些职责如何重新分配。Urn编译出的JavaScript可以直接挂载到DOM节点，也可以用其虚拟节点表达式生成类似JSX的结构，所以React的渲染层可以被Urn的表达式替代。状态管理方面，Urn的不可变数据结构和Janet的原子操作可以覆盖大部分Redux场景，而且不需要专门的中间件处理异步。
真正需要谨慎对待的是生态依赖。如果项目重度使用Ant Design或Material UI，迁移成本会非常高，因为Urn没有现成的组件库封装，必须自己用宏包一层DOM操作。但对表单、表格、筛选这类业务组件，反而可以借迁移机会重新设计一套更贴合领域模型的组件表达方式。服务端的迁移相对简单，Janet有HTTP服务器库和数据库驱动，可以像Express一样处理路由和中间件，而且宏可以生成参数校验代码，减少大量重复的请求处理逻辑。
一个关键判断是：React项目里哪些代码是纯渲染，哪些代码是副作用和状态流转。纯渲染部分迁移到Urn非常直接，几乎是一一对应的表达式转换；副作用部分需要重新设计，因为React的useEffect模式在Lisp方言里更倾向于显式的生命周期函数或响应式信号。经过梳理，这个项目大约70%的组件属于纯渲染和简单状态，迁移后代码量减少一半；剩下30%涉及复杂异步和拖拽交互，需要重新实现，但借助宏可以控制复杂度。
环境搭建与项目结构调整
Janet的安装比较直接，下载预编译二进制或通过包管理器安装，然后使用jpm管理依赖。Urn则需要通过npm安装，因为它的编译器运行在Node环境，输出也是JavaScript。项目结构调整为两个目录：server/存放Janet源码，client/存放Urn源码。构建时先编译Urn到静态JS文件，再由Janet的HTTP服务器托管这些静态资源。开发环境中可以使用文件监听工具，在Urn文件变化时触发编译，Janet端则用热重载监听源码变更。
Janet的依赖管理用project.janet文件声明，类似package.json。下面是一个基础的Janet服务器入口，展示路由和静态文件服务的组织方式：
(import http)
(import json)
(defn handle-api [req]
(match (req :method)
"GET" (json/encode {:status "ok" :data []})
"POST" (let [body (json/decode (req :body))]
(json/encode {:created (body :id)}))))
(defn main [& args]
(http/server
(fn [req]
(match (req :path)
"/api/todos" (handle-api req)
_ (http/serve-static req "public")))))
Urn侧的项目结构类似ClojureScript，使用urn.json配置编译入口和输出目标。一个简单的Urn组件定义如下，它直接生成虚拟DOM节点，不需要React.createElement：
(defn todo-item [todo]
(let [done (:done todo)]
(html
[:li {:class (if done "done" "pending")}
(:text todo)])))
这种写法与JSX的差异在于，标签名和数据都以Lisp数据结构表达，宏可以在编译期遍历这个结构，注入额外的属性或优化渲染。编译后的JavaScript体积比同等React代码小很多，因为Urn的运行时非常精简，不需要React Fiber的调度机制。迁移过程中，旧的React组件可以暂时保留，通过一个桥接文件逐步替换，新旧组件共存不会冲突。
组件重写：从JSX到Urn的Lisp表达式
JSX本质上是JavaScript函数调用的语法糖，而Urn的表达式就是函数调用的直接体现。一个React函数组件接收props返回JSX，在Urn中对应一个接收参数并返回节点表达式的函数。不同之处在于，Urn的节点表达式是纯数据，可以像操作列表一样进行遍历、修改和组合。这意味着高阶组件、render props这些React模式都可以用简单的函数组合替代。例如，一个带权限控制的按钮组件，在React中需要包一层高阶组件或者使用context，在Urn里只需要一个宏：
(defmacro with-permission [perm & body]
`(if (has-permission? ~perm)
(do ~@body)
(empty-node)))
(component admin-button [label]
(with-permission :admin
(html [:button {:class "btn"} label])))
这个宏在编译期展开成条件判断，不需要额外的组件包裹层。事件处理方面，Urn使用普通的函数绑定，没有合成事件系统。对于受控组件，需要自己维护输入状态，但可以用一个通用的状态容器来简化。下面的例子展示了一个带本地状态的计数器组件：
(defcomponent counter []
(let [count (atom 0)]
(fn []
(html
[:div
[:span (str "Count: " @count)]
[:button {:onclick (fn [_] (swap! count inc))} "Inc"]]))))
这里使用atom来持有可变状态，swap!更新状态并触发重新渲染。这个模式直接对应React的useState，但更显式，没有Hook的调用顺序规则。对于复杂表单，可以将所有输入值放在一个atom中，用统一的更新函数处理，减少重复的事件处理代码。迁移时先列出所有组件的状态依赖关系，然后按依赖粒度拆分为多个atom，避免大而全的全局状态。
样式处理是另一个迁移重点。React项目常用CSS Modules或styled-components，Urn生态没有这些工具，但可以直接使用CSS类名和行内样式。一种做法是保留现有CSS文件，在Urn节点中通过class属性引用类名；另一种做法是用宏生成样式对象，编译为CSS-in-JS字符串。实践中推荐前者，因为迁移阶段不需要改变样式加载方式，降低回归风险。
状态管理与宏驱动的优化
React项目里的状态管理通常分为服务端状态和客户端状态。服务端状态来自API请求，需要处理加载、错误、缓存和失效；客户端状态是表单输入、UI开关等。迁移到Janet + Urn后，服务端状态可以交给一个统一的请求缓存模块，客户端状态使用atom和响应式更新。Urn没有内置的响应式系统，但可以利用atom的监听机制实现类似MobX的自动追踪。定义一个reactive宏，在组件渲染时记录依赖的atom，当atom变化时自动重新渲染组件：
(defmacro reactive [component]
`(let [deps (make-dependency-tracker)]
(fn [& args]
(track-render deps #(apply ~component args)))))
这个宏封装了依赖收集和订阅逻辑，业务组件不需要关心重渲染的触发细节。对于服务端状态，Janet端可以提供RESTful或GraphQL接口，Urn端用统一的fetch封装。由于两者都是Lisp方言，请求和响应的数据格式可以约定为EDN风格的JSON结构，减少序列化负担。Janet内置的数据结构如数组和字典可以无缝映射为JSON。
宏的最大价值在于消除跨切面的重复代码。例如，列表页通常有分页参数、排序字段、筛选条件，这些参数在React中需要写到每个useState和请求函数里。在Urn中，可以定义一个list-page宏，自动生成分页状态、加载状态和筛选表单的渲染逻辑：
(defmacro list-page [name fetch-fn columns]
`(component ~name []
(let [page (atom 1)
filters (atom {})
data (atom nil)]
(fetch-data fetch-fn @page @filters)
(html
[:div
(filter-form filters)
(data-table @data columns)
(pagination page)]))))
这个宏将散落在多个组件中的模式集中到一处，业务页面只需传入数据获取函数和列定义。迁移过程中，原先三个列表页共约400行React代码被压缩到不到100行的Urn表达式。宏虽然强大，但也要避免过度使用，否则生成的可读性会下降。建议只在重复出现三次以上的模式中引入宏，并且给宏配上清晰的文档字符串。
调试、测试与部署的实战经验
Janet和Urn的调试工具不如React生态成熟。Urn编译后的JavaScript带有源映射，可以在浏览器开发者工具中定位到Urn源码，但断点调试体验不如原生JavaScript。一个有效的方式是在Urn代码中使用console.log宏，自动打印表达式和值，类似Clojure的prn。服务端Janet可以使用内置的pp函数打印复杂结构，也可以启动REPL连接正在运行的进程进行交互式排查。
测试方面，Urn没有现成的测试框架，但可以用Janet的测试宏来验证编译后的JavaScript模块。做法是将Urn组件编译为Node可加载的模块，在Janet测试代码中通过子进程调用Node运行断言。这种跨语言测试流程有一定维护成本，但对核心业务逻辑值得投入。服务端Janet的测试比较直接，使用内置的test模块即可覆盖路由和数据库访问。
部署时，Janet应用可以打包成单个可执行文件，Urn编译后的静态资源直接由Janet服务器托管。整个迁移后的应用运行时占用内存比原React + Node栈低约40%，冷启动时间从数百毫秒降到几十毫秒。不过需要接受一个现实：Urn的编译速度较慢，大型文件的增量编译可能需要数秒，与React的HMR相比有明显差距。因此建议在开发过程中将Urn文件拆分为较小的模块，只编译变更的部分，同时利用缓存加快构建速度。
总体来看，从React迁移到Janet + Urn是一项有风险但回报明确的技术投入。它不适合所有团队，尤其是那些依赖大量React生态组件和工具链的项目。但对于熟悉函数式编程、希望减少样板代码并愿意投入时间自建部分工具的团队，Lisp方言栈提供了一种更简洁、可组合性更高的开发方式。迁移不是推翻重来，而是一次重新审视代码结构和抽象边界的机会。