最新

大家好！我是FlutterJS的创始人。 问题：Flutter Web非常适合构建应用程序，但对于网站来说却很糟糕。它将所有内容渲染到Canvas/WASM，这意味着： - 2-5 MB的包（在移动设备上加载缓慢） - 零SEO——谷歌无法索引Canvas像素 - 较差的可访问性（没有语义化的HTML供屏幕阅读器使用） - 初始加载时间为3-8秒 如果你曾尝试使用Flutter Web构建营销网站或博客，你一定遇到过这个问题。 解决方案：FlutterJS将你的Flutter/Dart代码编译为语义化的HTML + CSS + JavaScript，而不是Canvas。使用的语法与Flutter相同，但输出为： - ~50-100 KB的包（小50倍） - 完全支持SEO（真实的HTML元素） - 首次渲染时间少于1秒 - 默认可访问 工作原理： 1. 你编写普通的Flutter/Dart代码 2. 我们的Dart CLI分析你的AST并生成中间表示（IR） 3. IR被转译为JavaScript，并使用轻量级运行时 4. 输出为搜索引擎可以索引的语义化HTML 当前状态：测试版（v0.9.x）。我们支持最常见的Material组件（Scaffold、AppBar、Text、Button、Row、Column、StatefulWidget等）。动画支持和完整的Material 3在开发计划中。 已知限制： - 目前并非所有Flutter组件都已实现（请参见README中的兼容性矩阵） - 方法的拆分目前需要用lambda包裹 - 复杂的动画尚不支持 - 这更适合内容丰富的网站，而不是图形密集型应用 我为什么要构建这个：我遇到了许多客户，他们喜欢Flutter的开发体验，但需要他们的网站在谷歌上排名。Flutter Web无法做到这一点。我希望能够兼得两者的优点。 我非常希望听到你的反馈，特别是： - 你是否在使用Flutter Web时遇到了这个SEO问题？ - 你在使用场景中需要哪些组件？ - 对这种方法有任何顾虑吗？ 欢迎提出关于架构、性能声明或开发计划的问题！

我是一名二年级学生，正在开发 ReTraced——一个分布式作业调度器，它将重试行为视为一等数据，而不是隐藏在日志或配置标志中。 大多数调度器只告诉你某个作业重试了 3 次，而 ReTraced 则告诉你： - 每次重试发生的时间（带时间戳） - 重试的原因（暂时性故障与永久性故障） - 是自动重试还是手动触发？ - 在进入死信队列（DLQ）之前的完整审计记录 我之所以构建这个系统，是因为在压力测试时，我发现了一个回退定时的错误，只有在我能够将重试尝试以结构化数据的形式“看到”时才会显现。预期的指数延迟（5秒 → 10秒 → 20秒），但实际时间戳显示约为 6 秒的平稳期。这种可见性使调试变得简单。 *核心理念：* - 将重试尝试存储为可查询的记录（不仅仅是计数） - 针对每个作业的重试策略（固定、线性、指数 + 抖动） - DLQ 是一等公民，带有完整的失败上下文 - 基于 Redis，至少一次的语义 *当前状态：* v1.0.0——核心模型稳定，可用于内部工具和实验。目标是在一年内实现生产就绪的自托管。 我正在积极寻求反馈，特别是在以下方面： - DLQ 重放策略 - Redis 协调模式与 Postgres 的比较 - 我遗漏的重试策略边缘案例 GitHub: [https://github.com/Anshikakalpana/ReTraced](https://github.com/Anshikakalpana/ReTraced) 文档: [https://re-trace-five.vercel.app/](https://re-trace-five.vercel.app/) 我非常希望听到大家的想法，特别是那些在生产环境中构建或操作调度器的人。