文章分享了作者作为非专业应用开发者的探索经历。作者长期从事计算机相关工作但从未开发过应用，希望通过实践了解当前各平台的原生开发体验，而非依赖Electron等网页技术。这源于他之前对网页技术发展的思考，现在想亲身体验应用开发的现状。

标题：探索跨平台应用开发：一位开发者的实践与反思

作者：ArcaneNibble 发布日期：2025年5月21日

文章概述： 本文记录了作者尝试在不同平台开发简单骰子应用的全过程，通过七个平台的实践对比，揭示了现代应用开发的现状与挑战。

核心内容：

1. 实验背景

• 作者作为有数十年经验的开发者，但缺乏现代应用开发经验
• 选择开发一个简单的骰子生成器应用（支持指定骰子面数）
• 增加两个额外需求：持久化设置和多语言支持

2. 测试平台及评价 (按开发顺序排列)

1) 标准C语言 - 优点：代码简洁，跨平台兼容性极佳 - 评价："最抗过时的方案" - 示例代码展示了基本的随机数生成逻辑

2) C/POSIX命令行 - 遵循Unix工具规范 - 问题：POSIX标准存在局限性（如随机数生成器质量） - 评价："最无用的标准"

3) GNOME/GTK（Linux） - 优点：完善的开发者引导页面 - 问题：文档缺乏系统性，调试困难 - 评价："潜力最大但最被浪费的平台"

4) KDE/Qt（Linux） - 优点：Qt框架文档完善，开发体验流畅 - 问题：CMake配置复杂 - 评价："最受平台拖累的方案"

5) WinUI 3（Windows） - 优点：XAML布局系统改进明显 - 问题：微软技术栈混乱，构建流程冗长 - 评价："最缺乏新意的方案"

6) SwiftUI（macOS/iOS） - 优点：开发体验愉悦，文档优秀 - 问题：苹果生态封闭，兼容性差 - 评价："最有趣的消遣方式"

7) Jetpack Compose（Android） - 问题：文档混乱，开发工具不稳定 - 评价："最赤裸裸的垄断产物"

3. 关键发现

• 跨平台开发仍面临巨大挑战
• 文档质量直接影响开发体验
• 标准化进程滞后于技术发展
• 商业平台与开源生态各有优劣

4. 作者建议

• 推荐Qt作为跨平台开发首选（但建议避免CMake）
• 强调开发者需要持续学习不同平台特性

5. 反思

• 虽然体验不尽如人意，但获得了宝贵经验
• 未来将更关注多语言支持等长期忽视的领域

（注：原文中的代码示例、图片链接及部分技术细节在此摘要中已简化处理，完整内容可查看原文）

评论总结：

1. 关于开发工具选择：

• 有评论认为开发者体验应关注功能而非界面稳定性（sublinear："I care more about the specs and not the stuff on the dashboard"）
• 多位开发者分享个人选择：Python（analog31）、Lazarus（dvh）、C# WinForms（NetMageSCW）、Flutter（satvikpendem）、Tcl/Tk（jrapdx3）

2. 关于跨平台开发：

• Flutter被推荐为最佳跨平台方案（satvikpendem："hard to find a competitor that's as 'write once, run everywhere'"）
• 有开发者质疑为何不尝试React Native（stackedinserter）

3. 关于Web vs 原生应用：

• 强烈支持Web技术的观点认为其具有分发优势（judah列举12项Web优势如"Universal distribution"、"No download and install process"）
• 反对观点认为Electron等Web技术盛行是标准化的胜利（sublinear："that's precisely why everything is now a web app"）

4. 技术细节讨论：

• Jetpack Compose的响应式编程范例获得详细辩护（olcay_用代码示例说明Flow和Coroutines的使用）
• 有评论指出POSIX标准在Linux环境的重要性（casey2列举多个系统文档对POSIX的引用）

关键分歧点： - 工具选择标准：功能能力（sublinear）vs 开发体验（原文作者） - 技术路线：Web优先（judah）vs 原生/跨平台框架（satvikpendem等）

注：所有评论均无评分数据，无法评估社区认可度。技术讨论中Web优势论和Flutter推荐获得较详细论证，Jetpack Compose的辩护最具技术深度。