LessJS 的哲学不是“少写代码”这么单薄，而是把复杂度放在正确的位置： 平台已经解决的问题交给平台，框架必须解决的问题才由框架承担。
HTTP 使用 Fetch API，UI 使用 Custom Elements 和 Shadow DOM，模块使用 ESM， 服务端使用 Hono 对齐 Web 标准。用户学到的知识应该能离开 LessJS 继续使用。
默认产物应该是静态 HTML、CSS 和必要的 island JavaScript。需要 API、认证、 数据写入或 revalidation 时再显式进入 serverless/fullstack 模式。
页面先是可读、可缓存、可爬取的 HTML。交互组件随后通过 Custom Element upgrade 变成活的组件。框架不把整页状态恢复当成默认成本。
Lit 是当前最现实的作者体验；未来的 .less compiler 是优化路径，不是框架成立的前提。运行时、构建和文档都应该保持 adapter 边界清晰。
文档要写当前行为，而不是愿景口号。能运行的写成指南；还没稳定的写进 Roadmap； 风险和限制写在架构页里，而不是藏到用户踩坑之后。
| 选择 | 原因 | 代价 |
|---|---|---|
| Lit authoring | Web Components 生态成熟，SSR 可行，API 稳定。 | 需要管理安全渲染边界，compiler 优化仍是未来项。 |
| Hono runtime | 足够小，贴近 Fetch，跨运行时迁移成本低。 | 部署适配器和平台能力仍需要逐步补齐。 |
| SSG default | 部署简单，缓存友好，文档/内容站收益最大。 | 动态数据和 ISR 需要额外运行时约定。 |
LessJS 不追求把所有前端范式压进一个框架，也不追求用抽象遮住平台。 如果一个功能必须引入大量专有协议，它需要证明自己能显著降低实际复杂度。