简介

Wails是一个使用 Go 简化编写跨平台桌面应用程序的能力的项目。 它使用原生 webview 组件作为前端(而不是嵌入式浏览器)，将世界上最流行的 UI 系统的强大功能引入Go，同时保持轻量级。

第二版于 2022年9月22日 发布，并带来了很多增强功能包括：

• 实时开发，利用流行的Vite项目
• 管理窗口和创建菜单的丰富功能
• 微软的 WebView2 组件
• 生成对应 Go 结构体的 TypeScript 模型
• 创建 NSIS 安装程序
• 混淆构建

现在，Wails v2 提供了强大的工具来创建丰富的跨平台桌面应用程序。

这篇博文的目的是看看这个项目现在处于什么阶段，以及我们可以在后续中改进什么。

我们现在在哪里？

看到 Wails 自 v2 发布以来的受欢迎程度上升是令人难以置信的。 我经常对社区的创造力和用它建造的美好事物感到惊讶。 随着越来越受欢迎，更多的目光投向了这个项目。 随之而来的是更多的功能请求和错误报告。

随着时间的推移，我已经能够确定该项目面临的一些最紧迫的问题。 我也已经能够识别出一些阻碍该项目的因素。

当前问题​

我确定了以下我认为阻碍该项目的领域：

• API
• 绑定生成
• 构建系统

接口​

构建 Wails 应用程序的 API 目前由两部分组成：

• 应用程序 API
• 运行时 API

著名的应用程序 API 只有一个函数：Run()，它需要一堆 控制应用程序如何工作的选项。 虽然这使用起来非常简单，但这也非常有限。 这是一种“声明式”的方法，隐藏了很多潜在的复杂性。 例如，主窗口没有句柄，所以你不能直接与之互动。 为此，您需要使用运行时 API。 这是个问题当您开始想要做更复杂的事情时，例如创建多个窗口。

运行时 API 为开发者提供了许多实用功能。 其中包括：

• 窗口管理
• 对话框
• 菜单
• 事件
• 日志

我对运行时 API 有很多不满意的地方。 第一个是它需要传递一个“context”。 对于传入上下文然后出现运行时错误的新开发人员来说，这既令人沮丧又令人困惑。

运行时 API 的最大问题是它是为只使用单个窗口的应用程序设计的。 随着时间的推移，对多窗口的需求不断增长，API 不太适合这种情况。

关于 v3 API 的想法​

如果我们能做这样的事情不是很好吗？

func main() {
    app := wails.NewApplication(options.App{})
    myWindow := app.NewWindow(options.Window{})
    myWindow.SetTitle("My Window")
    myWindow.On(events.Window.Close, func() {
        app.Quit()
    })
    app.Run()
}

这种编程方法更加直观，允许开发人员直接与应用程序元素交互。 所有当前的窗口运行时方法都只是窗口对象上的方法。 对于其他运行时方法，我们可以像这样移动他们到应用程序对象：

app := wails.NewApplication(options.App{})
app.NewInfoDialog(options.InfoDialog{})
app.Log.Info("Hello World")

这是一个更强大的 API，可以构建更复杂的应用程序。 它还允许创建多个窗口，这是 GitHub 上投票最多的功能：

func main() {
    app := wails.NewApplication(options.App{})
    myWindow := app.NewWindow(options.Window{})
    myWindow.SetTitle("My Window")
    myWindow.On(events.Window.Close, func() {
        app.Quit()
    })
    myWindow2 := app.NewWindow(options.Window{})
    myWindow2.SetTitle("My Window 2")
    myWindow2.On(events.Window.Close, func() {
        app.Quit()
    })
    app.Run()
}

绑定生成​

Wails 的关键特性之一是为您的 Go 方法生成绑定，因此它们可能从 JavaScript 调用。 当前执行此操作的方法有点 hack。 它涉及使用特殊标志构建应用程序，然后运行生成的二进制文件，该二进制文件使用反射来确定已绑定的内容。 这导致了先有鸡还是先有蛋的情况：没有绑定就无法构建应用程序，没有构建应用程序就无法生成绑定。 有很多方法可以解决这个问题，但最好的一个根本不会使用这种方法。

曾多次尝试为 Wails 项目编写策略分析器，但收效甚微。 最近，随着有关该主题的更多可用资料，这样做变得稍微容易一些。

与反射相比，AST 方法要快得多，但要复杂得多。 首先，我们可能需要对如何在代码中指定绑定施加某些约束。 目标是支持最常见的用例，然后在以后扩展它。

构建系统​

与 API 的声明性方法一样，创建构建系统是为了隐藏构建桌面应用程序的复杂性。 当你运行 wails build 时，它会在幕后做很多事情：

• 为绑定构建后端二进制文件并生成绑定
• 安装前端依赖项
• 构建前端资产
• 确定应用程序图标是否存在，如果存在，则嵌入它
• 构建最终二进制文件
• 如果构建是针对 darwin/universal 的，它会构建 2 个二进制文件，一个用于 darwin/amd64，一个用于 darwin/arm64，然后使用 lipo 创建一个大的二进制文件
• 如果需要压缩，它会使用 UPX 压缩二进制文件
• 确定是否要打包此二进制文件，如果是：
  • 确保将图标和应用程序清单（manifest）编译成二进制文件 (Windows)
  • 构建应用程序包，生成图标包并将二进制文件和 info.plist 复制到应用程序包 (Mac)
• 如果需要 NSIS 安装程序，它会构建它

整个过程虽然非常强大，但也非常不透明。 定制起来非常困难，调试也非常困难。

为了在 v3 中解决这个问题，我想转移到一个存在于 Wails 之外的构建系统。 在使用 Task 一段时间后，我非常喜欢它。 它是配置构建系统的绝佳工具，任何使用过 Makefile 的人都应该相当熟悉。

构建系统将使用 Taskfile.yml 文件进行配置，该文件默认使用任意受支持的模板生成。 这将具有完成所有当前任务所需的所有步骤，例如构建或打包应用程序，从而实现轻松定制。

这个工具将没有外部要求，因为它将构成 Wails CLI 的一部分。 这意味着您仍然可以使用 wails build，它会完成它今天所做的所有事情。 但是，如果您想自定义构建过程，可以通过编辑 Taskfile.yml 文件来实现。 这也意味着您可以轻松理解构建步骤并根据需要使用自己的构建系统。

构建难题中缺少的部分是构建过程中的原子操作，例如图标生成、压缩和打包。 需要一堆外部工具对开发人员来说不是很好的体验。 为了解决这个问题，Wails CLI 将提供所有这些功能作为 CLI 的一部分。 这意味着构建仍然按预期工作，没有额外的外部工具，但是您可以用您喜欢的任何工具替换构建的任何步骤。

这将是一个更加透明的构建系统，可以更轻松地进行定制并解决围绕它提出的许多问题。

好处​

这些积极的变化将为项目带来巨大的好处：

• 新的 API 将更加直观，并允许构建更复杂的应用程序。
• 使用静态分析生成绑定会更快，并且会降低当前流程的复杂性。
• 使用已建立的外部构建系统将使构建过程完全透明，从而实现强大的定制。

对项目维护者的好处是：

• 新的 API 将更容易维护和适应新功能和平台。
• 新的构建系统将更容易维护和扩展。 我希望这将导致社区驱动构建管道的新生态系统。
• 更好地分离项目中的关注点。 这将使添加新功能和平台变得更加容易。

计划​

很多这方面的实验已经完成，而且看起来不错。 这项工作目前没有时间表，但我希望到 2023 年第一季度末，将有一个 Mac 的 alpha 版本，允许社区进行测试、试验并提供反馈。

总结​

• v2 API 是声明式的，对开发人员隐藏了很多，不适合多窗口等功能。 将创建一个更简单、直观且功能更强大的新 API。
• 构建系统不透明且难以定制，因此我们将转向外部构建系统，它将全部开放。
• 绑定生成缓慢且复杂，因此我们将转向静态分析，这将消除当前方法的许多复杂性。

我们在 v2 的内部做了很多工作，它是可靠的。 现在是时候解决它上面的瓶颈并为开发人员提供更好的体验了。

我希望你和我一样对此感到兴奋。 我期待听到您的想法和反馈。

此致，

‐ Lea

PS: 如果您或您的公司发现 Wails 有用, 请考虑 赞助项目。 谢谢！

PPS：是的，这是一个用 Wails 构建的多窗口应用程序的真实截图。 它不是一个模型。 这是真实的。 太棒了。 即将到来。

终于发布了！

今天标志着 Wails v2 的发布。 距离发布第一个 v2 alpha 版本大约 18 个月，距离发布第一个 beta 版本大约一年。 我非常感谢参与项目发展的每一个人。

花了这么长时间的部分原因是想要在正式将其称为 v2 之前对其进行一些完整性的定义。 事实是，从来没有一个完美的时间来标记一个版本 - 总是有突出的问题或 “只是一个” 功能要加进去。 然而，标记一个不完美的主要版本的确是为项目的用户提供一些稳定性，并为开发人员提供了一些重置。

这此发布超出了我的预期。 我希望它给您带来的乐趣与开发它给我们带来的乐趣一样多。

什么 是 Wails?

如果你对 Wails 不熟悉，它是一个让 Go 程序员能够使用熟悉的 Web 技术为其 Go 程序提供丰富的前端的项目。 它是 Electron 的轻量级 Go 替代品。 更多信息可以在 官方网站 上找到。

有哪些新东西？

V2 版本是该项目的巨大飞跃，解决了 v1 的许多痛点。 如果您尚未阅读任何有关 macOS、Windows 或 Linux Beta 版本的博客文章，那么我鼓励您阅读，因为它更详细地涵盖了所有主要变更。 总结起来就是：

• 适用于 Windows 的 Webview2 组件，支持现代 Web 标准和调试功能。
• Windows 上的 深色/浅色主题 和 自定义主题。
• Windows 现在没有 CGO 要求。
• 支持对 Svelte、Vue、React、Preact、Lit 和 Vanilla 项目模板的开箱即用。
• 集成 Vite 为您的应用程序提供热重载开发环境。
• 原生应用的 菜单 和 对话框。
• 适用于 Windows 和 macOS 的原生窗口半透明效果。 支持 Mica 和 亚克力 背景。
• 为 Windows 部署轻松生成 NSIS 安装程序。
• 一个为窗口操作、事件、对话框、菜单和日志记录提供实用方法的丰富的 运行时库。
• 支持使用 garble 混淆 您的应用程序。
• 支持使用 UPX 压缩您的应用程序。
• 自动为 Go 结构体的生成 TypeScript。 更多信息在 这里。
• 您的应用程序不需要附带额外的库或 DLL。 适用于任何平台。
• 无需打包前端资产。 只需像开发任何其他 Web 应用程序一样开发您的应用程序。

致敬和感谢

到达 v2 是一项巨大的努力。 从最初的 alpha 版本到今天的发布，已经有 89 位贡献者提交了大约 2200 次提交，还有很多很多的贡献者在讨论论坛和 Issue 跟踪器上提供了翻译、测试、反馈和帮助。 我非常感谢你们每一个人。 我还要特别感谢所有提供指导、建议和反馈的项目赞助商。 非常感谢您所做的一切。

我想特别提及以下几个人：

首先， 非常 感谢 @stffabi，他提供了许多我们都从中受益的贡献，并在许多 Issue 上提供了很多支持。 他提供了一些关键功能，例如外部开发服务器的支持，这改变了我们的开发模式，允许我们与 Vite 的超级能力挂钩。 客观地说，如果没有他令人 难以置信的贡献，Wails v2 将是一个不那么令人兴奋的版本。 非常感谢 @stffabi！

我还想对 @misitebao 表示热烈的祝贺，他一直不懈地维护网站、提供中文翻译、管理 Crowdin 并帮助新的翻译人员跟上进度。 这是一项非常重要的任务，我非常感谢为此付出的所有时间和精力！ 你太棒了！

最后但同样重要的是，非常感谢 Mat Ryer，他在 v2 的开发过程中提供了建议和支持。 使用 v2 的早期 Alpha 一起编写 xBar 有助于塑造 v2 的方向，并让我了解早期版本中的一些设计缺陷。 我很高兴地宣布，从今天开始，我们将开始将 xBar 移植到 Wails v2，它将成为该项目的旗舰应用。 干杯！

吸取的教训

在到达 v2 的过程中吸取了许多经验教训，这些经验教训将影响未来的发展。

更小、更快、更聚焦的发布​

在开发 v2 的过程中，有许多特性和错误修复是在临时基础上开发的。 这导致了更长的发布周期并且更难调试。 未来，我们将更频繁地创建包含较少数量功能的发布。 发布一个版本将包括文档的更新和完全的测试。 希望这些更小、更快、更集中的发布将导致更少的回归和更好的文档质量。

鼓励参与​

在开始这个项目时，我想立即帮助每个有问题的人。 问题是“个人的”，我希望它们尽快得到解决。 这是不可持续的，最终会影响项目的寿命。 未来，我将为人们提供更多空间来参与回答问题和对问题进行分类。 通过一些工具来帮助解决这个问题会很好，所以如果您有任何建议，请在 此处 加入讨论。

学会说不​

参与开源项目的人越多，对大多数人可能有用也可能没用的附加功能的请求就越多。 这些特性的开发和调试需要一段初始的时间，并从那时起产生持续的维护成本。 我本人对此负有最大责任，往往想要 “好高骛远”，而不是提供最小的可行功能。 未来，我们需要对添加核心功能多说一些 “不”，并将我们的精力集中在授权开发人员自己提供该功能的方式上。 我们正在认真研究这种情景的插件。 这将使任何人都能够按照他们认为合适的方式扩展该项目，并提供一种为项目做出贡献的简单方法。

展望未来

在下一个主要开发周期中，我们正在考虑将许多核心功能添加到 Wails 中。 路线图 充满了令人感兴趣的想法，我非常希望着手处理这些想法。 最多的要求之一是多窗口支持。 这是一个棘手的问题，并且要正确执行，我们可能需要考虑提供替代 API，因为当前的 API 在设计时并未考虑到这一点。 根据一些初步的想法和反馈，我想你会喜欢我们的预期。

我个人对在移动设备上运行 Wails 应用程序的前景非常感兴趣。 我们已经有一个演示项目表明可以在 Android 上运行 Wails 应用程序，所以我真的很想探索我们可以用它做到什么地步！

我想提出的最后一点是功能均等性。 长期以来，我们不会在项目中添加任何东西，除非有完整的跨平台支持，这一直是一个核心原则。 虽然到目前为止这已被证明（主要）是可以实现的，但它确实阻碍了项目发布新功能。 未来，我们将采用稍微不同的方法：任何无法立即为所有平台发布的新功能都将在实验配置或 API 下发布。 这允许某些平台上的早期采用者尝试该功能并提供反馈，这些反馈将反馈到该功能的最终设计中。 当然，这意味着在所有可以支持它的平台完全支持之前，不能保证 API 的稳定性，但至少它会解除对开发的阻碍。

最后想说的

我真的为我们在 V2 版本中所取得的成就感到自豪。 看到人们已经能够使用 beta 版本构建的东西真是太神奇了。 像 Varly、Surge 和 October 等优质的应用程序。 我鼓励你们去看看。

这个版本是通过许多贡献者的辛勤工作实现的。 虽然它可以免费下载和使用，但它并不是通过零成本实现的。 毫无疑问，这个项目的成本很大。 这不仅是我的时间和每一个贡献者的时间，也是这些人的朋友和家人缺席的代价。 这就是为什么我非常感谢为实现这个项目而付出的每一秒。 我们拥有的贡献者越多，这种努力就可以分散得越多，我们可以共同实现的目标就越多。 我想鼓励大家选择一件可以贡献的东西，无论是确认某人的错误、提出修复建议、更改文档还是帮助需要它的人。 所有这些小事都有如此巨大的影响！ 如果你也能成为 v3 故事的一部分那就太棒了。

请尽情享用！

‐ Lea

PPS：如果您或您的公司发现 Wails 有用，可以考虑 赞助该项目。 谢谢！

我很高兴终于宣布，Wails v2 现在处于 Linux 测试版中！ 有点讽刺的是，v2 的第一次实验是在 Linux 上进行的，但它最终成为了最后一个版本。 话虽如此，我们今天拥有的 v2 与最初的实验非常不同。 因此，事不宜迟，让我们回顾一下新功能：

新功能​

有很多对原生菜单支持的请求。 Wails 终于帮您搞定了。 应用程序菜单现已可用，并且包括对大多数原生菜单功能的支持。 这包括标准菜单项、复选框、单选组、子菜单和分隔符。

在 v1 中有大量的请求，要求能够更好地控制窗口本身。 我很高兴地宣布，有专门用于此的新运行时 API。 它功能丰富，支持多显示器配置。 还有一个改进的对话框 API：现在，您可以拥有具有丰富配置的现代原生对话框，以满足您的所有对话框需求。

无需打包资源​

v1 的一个巨大痛点是需要将整个应用程序压缩为单个 JS 和 CSS 文件。 我很高兴地宣布，对于 v2，不需要以任何形式打包资源。 想要加载本地图片？ 使用带有本地src路径的<img>标签。 想使用很酷的字体吗？ 复制它并在你的 CSS 中添加它的路径。

哇，这听起来像一个网络服务器......

是的，它就像一个网络服务器一样工作，但它不是。

那么我如何包含我的资源？

您只需将embed.FS包含所有资源的单个文件传递到您的应用程序配置中。 他们甚至不需要在顶级目录中——Wails 会为你解决这个问题。

全新的开发体验​

现在不需要打包资源，它启用了全新的开发体验。 新wails dev命令将构建并运行您的应用程序，但它不使用embed.FS中的资源，而是直接从磁盘加载它们。

它还提供了附加功能：

• 热重载 - 对前端资源的任何更改都将触发并自动重载应用程序前端
• 自动重新构建 - 对 Go 代码的任何更改都将重新构建并重新启动您的应用程序

除此之外，网络服务器将在端口 34115 上启动。 所有连接的 Web 浏览器都会响应系统事件，例如资源更改时的热重载。 所有连接的 Web 浏览器都会响应系统事件，例如资源更改时的热重载。

在 Go 中，我们习惯于在应用程序中处理结构。 将结构发送到我们的前端并将它们用作我们应用程序中的状态通常很有用。 在 v1 中，这是一个非常需要手动的过程，对开发人员来说有点负担。 我很高兴地宣布，在 v2 中，任何以开发模式运行的应用程序都会自动生成 TypeScript 作为绑定方法的输入或输出参数的所有结构的模型。 这实现了两个世界之间数据模型的无缝交换。

除此之外，还会动态生成另一个 JS 模块来包装您的所有绑定方法。 这为您的方法提供了 JSDoc，在您的 IDE 中提供代码完成和提示。 当您在自动生成的包含 Go 代码的模块中点击 Tab 时自动导入数据模型，这真的很酷！

远程模板​

让应用程序快速启动并运行一直是 Wails 项目的一个关键目标。 当我们推出时，我们试图涵盖当时的很多现代框架：react、vue 和 angular。 前端开发的世界非常固执己见，发展迅速，很难保持领先地位！ 这也意味着，我们没有为最新和最伟大的技术栈提供酷炫的现代模板。 这也意味着，我们没有为最新和最伟大的技术栈提供酷炫的现代模板。

在 v2 中，我希望通过让您能够自己创建和托管模板来增强社区的能力，而不是依赖于 Wails 项目。 所以现在您可以使用社区支持的模板创建项目！ 我希望这将激励开发人员创建一个充满活力的项目模板生态系统。 我对我们的开发者社区可以创造的东西感到非常兴奋！

交叉编译到 Windows​

因为 Windows 的 Wails v2 是纯 Go，所以你可以在没有 docker 的情况下针对 Windows 构建。

结语​

正如我在 Windows 发行说明中所说，Wails v2 代表了该项目的新起点。 此版本的目的是获得有关新方式的反馈，并在完整版本发布之前解决所有错误。 非常欢迎您的意见！ 请直接反馈到 v2 测试版讨论板。

Linux很难支持。 我们预计测试版会有一些小毛病。 请通过提交详细的错误报告来帮助我们帮助您！

最后，我还要特别感谢所有项目赞助商，他们的幕后支持以多种方式推动了该项目。

我期待看到在项目的下一个激动人心的阶段人们用 Wails 构建什么！

Lea.

PS: 距离 v2 正式版发布不远了！

PPS：如果您或您的公司发现 Wails 有用，可以考虑赞助该项目。 谢谢！

今天是 Mac 版 Wails v2 的第一个测试版！ 花了很长时间才走到这一步，我希望今天的版本会给你一些相当有用的东西。 为了达到这一点，经历了许多曲折，我希望在您的帮助下，消除问题并为最终的 v2 版本完善 Mac 端口。

你的意思是这还没有准备好生产？ 对于您的用例，它可能已经准备就绪，但仍然存在许多已知问题，因此请密切关注此项目板，如果您愿意做出贡献，我们将非常欢迎您！

那么 Mac 版 Wails v2 与 v1 有哪些新变化？ 提示：它与 Windows Beta 非常相似 😉

新功能​

有很多对原生菜单支持的请求。 Wails 终于帮您搞定了。 应用程序菜单现已可用，并且包括对大多数原生菜单功能的支持。 这包括标准菜单项、复选框、单选组、子菜单和分隔符。

在 v1 中有大量的请求，要求能够更好地控制窗口本身。 我很高兴地宣布，有专门用于此的新运行时 API。 它功能丰富，支持多显示器配置。 还有一个改进的对话框 API：现在，您可以拥有具有丰富配置的现代原生对话框，以满足您的所有对话框需求。

Mac 特定选项​

除了普通的应用程序选项，Wails v2 for Mac 还带来了一些 Mac 附加功能：

• 让你的窗口变得时髦和半透明，就像所有 Swift 应用程序一样！
• 高度可定制的标题栏
• 我们支持应用程序的 NSAppearance 选项
• 自动创建“关于”菜单的简单配置

无需打包资产​

v1 的一个巨大痛点是需要将整个应用程序压缩为单个 JS 和 CSS 文件。 我很高兴地宣布，对于 v2，不需要以任何形式打包资源。 想要加载本地图片？ 使用带有本地src路径的<img>标签。 想使用很酷的字体吗？ 复制它并在你的 CSS 中添加它的路径。

哇，这听起来像一个网络服务器......

是的，它就像一个网络服务器一样工作，但它不是。

那么我如何包含我的资源？

您只需将embed.FS包含所有资源的单个文件传递到您的应用程序配置中。 他们甚至不需要在顶级目录中——Wails 会为你解决这个问题。

全新的开发体验​

现在不需要打包资源，它启用了全新的开发体验。 新wails dev命令将构建并运行您的应用程序，但它不使用embed.FS中的资源，而是直接从磁盘加载它们。

它还提供了附加功能：

• 热重载 - 对前端资源的任何更改都将触发并自动重载应用程序前端
• 自动重新构建 - 对 Go 代码的任何更改都将重新构建并重新启动您的应用程序

除此之外，网络服务器将在端口 34115 上启动。 所有连接的 Web 浏览器都会响应系统事件，例如资源更改时的热重载。 所有连接的 Web 浏览器都会响应系统事件，例如资源更改时的热重载。

在 Go 中，我们习惯于在应用程序中处理结构。 将结构发送到我们的前端并将它们用作我们应用程序中的状态通常很有用。 在 v1 中，这是一个非常需要手动的过程，对开发人员来说有点负担。 我很高兴地宣布，在 v2 中，任何以开发模式运行的应用程序都会自动生成 TypeScript 作为绑定方法的输入或输出参数的所有结构的模型。 这实现了两个世界之间数据模型的无缝交换。

除此之外，还会动态生成另一个 JS 模块来包装您的所有绑定方法。 这为您的方法提供了 JSDoc，在您的 IDE 中提供代码完成和提示。 当您在自动生成的包含 Go 代码的模块中点击 Tab 时自动导入数据模型，这真的很酷！

远程模板​

让应用程序快速启动并运行一直是 Wails 项目的一个关键目标。 当我们推出时，我们试图涵盖当时的很多现代框架：react、vue 和 angular。 前端开发的世界非常固执己见，发展迅速，很难保持领先地位！ 这也意味着，我们没有为最新和最伟大的技术栈提供酷炫的现代模板。 这也意味着，我们没有为最新和最伟大的技术栈提供酷炫的现代模板。

在 v2 中，我希望通过让您能够自己创建和托管模板来增强社区的能力，而不是依赖于 Wails 项目。 所以现在您可以使用社区支持的模板创建项目！ 我希望这将激励开发人员创建一个充满活力的项目模板生态系统。 我对我们的开发者社区可以创造的东西感到非常兴奋！

原生 M1 支持​

感谢Mat Ryer的惊人支持，Wails 项目现在支持 M1 原生构建：

您也可以指定 darwin/amd64 为目标：

哦，我差点忘了....你也可以做 darwin/universal....😉

交叉编译到 Windows​

因为 Windows 的 Wails v2 是纯 Go，所以你可以在没有 docker 的情况下针对 Windows 构建。

WKWebView 渲染器​

V1 依赖于 WebView（现已弃用）组件。 V2 使用最新的 WKWebKit 组件，所以期待 Apple 的最新和最棒的组件。

总结​

正如我在 Windows 发行说明中所说，Wails v2 代表了该项目的新起点。 此版本的目的是获得有关新方式的反馈，并在完整版本发布之前解决所有错误。 非常欢迎您的意见！ 请直接反馈到 v2 测试版讨论板。

最后，我还要特别感谢包括JetBrains在内的所有项目赞助商，他们的幕后支持以多种方式推动了该项目。

我期待看到在项目的下一个激动人心的阶段人们用 Wails 构建什么！

Lea.

PS: Linux 用户们，你们将是下一个！

PPS：如果您或您的公司发现 Wails 有用，可以考虑赞助该项目。 谢谢！

两年多前，在悉尼的火车上，当我第一次在 Reddit 上宣布 Wails 时，我没想到它会引起太多关注。 几天后，一位多产的科技视频博主发布了一个教程视频，并给予了正面评价，从那时起，人们对该项目的兴趣猛增。

很明显，人们对将 Web 前端添加到他们的 Go 项目感到兴奋，几乎立即将项目推动到超出我创建这个项目的设想。 当时，Wails 使用 webview 项目来处理前端， Windows 的唯一选择是 IE11 渲染器。 许多错误报告都因为受到它的限制：糟糕的 JavaScript/CSS 支持并且没有开发工具来调试它。 这是一段令人沮丧的开发经历，但我们也没有采取什么措施去纠正它。

很长一段时间以来，我一直坚信微软最终会解决他们的浏览器问题。 世界在不断进步，前端开发正在蓬勃发展，而 IE 并没有做到这一点。 当微软宣布将 Chromium 作为其新浏览器方向的基础时， 我知道 Wails 能够使用它并将 Windows 开发者的体验提升到下一个水平只是时间问题。

今天，我很高兴地宣布：Windows 的 Wails v2 公测啦！ 此版本中有大量内容需要展开来说，所以，请倒一杯茶，咱们坐下来慢慢讲......

没有 CGO 依赖​

不，我不是在开玩笑：没有 CGO 依赖🤯！ Windows 的问题在于，与 MacOS 和 Linux 不同，它没有默认编译器。 此外，CGO 需要一个 mingw 编译器，并且有大量不同的安装选项。 删除 CGO 的要求大大简化了设置，并使调试变得非常容易。 虽然我已经付出了相当多的努力来完成这项工作，但大部分功劳应该归功于John Chadwick，他不仅启动了几个项目使这成为可能， 而且还对接受这些项目并以此为基础的人持开放态度。 还要感谢Tad Vizbaras，他的winc项目让我走上了这条道路。

WebView2 Chromium 渲染引擎​

最终，Windows 开发人员为他们的应用程序获得了一流的渲染引擎！ 扭曲前端代码以在 Windows 上工作的日子已经一去不复返了。 最重要的是，您将获得一流的开发者工具体验！

但是，WebView2 组件确实需要将其放置WebView2Loader.dll在二进制文件旁边。 这使得分发比我们 gophers 习惯的更痛苦。 所有使用 WebView2 的解决方案和库（我知道的）都具有这种依赖性。

然而，我真的很高兴地宣布，Wails 应用程序没有这样的要求！ 感谢John Chadwick的魔法，我们能够将这个 dll 打包在二进制文件中，并让 Windows 加载它，就像它存在于磁盘上一样。

Gophers 欢呼吧！ 单个二进制文件的构想依然存在！

新功能​

有很多对原生菜单支持的需求。 Wails 终于帮您搞定了。 应用程序菜单现已可用，并且包括对大多数原生菜单功能的支持。 这包括标准菜单项、复选框、单选组、子菜单和分隔符。

在 v1 中有大量的需求，要求能够更好地控制窗口本身。 我很高兴地宣布，有专门用于此的新运行时 API。 它功能丰富，支持多显示器配置。 还有一个改进的对话框 API：现在，您可以拥有具有丰富配置的现代原生对话框，以满足您所有的对话框需求。

现在可以选择随项目生成 IDE 配置。 这意味着如果您在受支持的 IDE 中打开您的项目，它已经被配置为构建和调试您的应用程序。 目前支持 VSCode，但我们希望尽快支持其他 IDE，例如 Goland。

无需打包资产​

v1 的一个巨大痛点是需要将整个应用程序压缩为单个 JS 和 CSS 文件。 我很高兴地宣布，对于 v2，不需要以任何形式打包资源。 想要加载本地图片？ 使用带有本地src路径的<img>标签。 想使用很酷的字体吗？ 复制它并在你的 CSS 中添加它的路径。

哇，这听起来像一个网络服务器......

是的，它就像一个网络服务器一样工作，但它不是。

那么我如何包含我的资源？

您只需将embed.FS包含所有资源的单个文件传递到您的应用程序配置中。 他们甚至不需要在顶级目录中——Wails 会为你解决这个问题。

全新的开发体验​

现在不需要打包资源，它启用了全新的开发体验。 新wails dev命令将构建并运行您的应用程序，但它不使用embed.FS中的资源，而是直接从磁盘加载它们。

它还提供了附加功能：

• 热重载 - 对前端资源的任何更改都将触发并自动重载应用程序前端
• 自动重新构建 - 对 Go 代码的任何更改都将重新构建并重新启动您的应用程序

除此之外，网络服务器将在端口 34115 上启动。 所有连接的 Web 浏览器都会响应系统事件，例如资源更改时的热重载。 所有连接的 Web 浏览器都会响应系统事件，例如资源更改时的热重载。

在 Go 中，我们习惯于在应用程序中处理结构。 将结构发送到我们的前端并将它们用作我们应用程序中的状态通常很有用。 在 v1 中，这是一个非常需要手动的过程，对开发人员来说有点负担。 我很高兴地宣布，在 v2 中，任何以开发模式运行的应用程序都会自动生成 TypeScript 作为绑定方法的输入或输出参数的所有结构的模型。 这实现了两个世界之间数据模型的无缝交换。

除此之外，还会动态生成另一个 JS 模块来包装您的所有绑定方法。 这为您的方法提供了 JSDoc，在您的 IDE 中提供代码完成和提示。 当您在自动生成的包含 Go 代码的模块中点击 Tab 时自动导入数据模型，这真的很酷！

远程模板​

让应用程序快速启动并运行一直是 Wails 项目的一个关键目标。 当我们推出时，我们试图涵盖当时的很多现代框架：react、vue 和 angular。 前端开发的世界非常固执己见，发展迅速，很难保持领先地位！ 这也意味着，我们没有为最新和最伟大的技术栈提供酷炫的现代模板。 这也意味着，我们没有为最新和最伟大的技术栈提供酷炫的现代模板。

在 v2 中，我希望通过让您能够自己创建和托管模板来增强社区的能力，而不是依赖于 Wails 项目。 所以现在您可以使用社区支持的模板创建项目！ 我希望这将激励开发人员创建一个充满活力的项目模板生态系统。 我对我们的开发者社区可以创造的东西感到非常兴奋！

总结​

Wails v2 代表了该项目的新起点。 此版本的目的是获得有关新方式的反馈，并在完整版本发布之前解决所有错误。 欢迎提出您的意见。 请直接反馈到 v2 测试版讨论板。

为了达到这一点，经历了许多曲折和坎坷。 部分原因是早期的技术决策需要改变，另一部分原因是我们花时间构建的一些核心问题的变通方式已经在上游得到了解决：Go 的 embed 特性就是一个很好的例子。 幸运的是，一切都刚刚好，今天我们有了我们所能拥有的最好的解决方案。 我相信等待是值得的 - 这在两个月前是完全不可能的。

我还需要特别感谢 🙏 以下人员，因为没有他们，这个版本就不会存在：

• Misite Bao - 中文翻译的主要人员和和令人难以置信的漏洞发现者。
• John Chadwick - 他在 go-webview2 和 go-winloader 方面的出色工作使 Windows 版本成为可能。
• Tad Vizbaras - 他的winc项目是走向纯粹的 Go Wails 的第一步。
• Mat Ryer - 他的支持、鼓励和反馈确实推动了项目向前发展。

最后，我还要特别感谢包括JetBrains在内的所有项目赞助商，他们的幕后支持以多种方式推动了该项目。

我期待看到在项目的下一个激动人心的阶段人们用 Wails 构建什么！

Lea.

PS：MacOS 和 Linux 用户不必感到被忽略了——移植到这个新基础上的工作正在积极进行中，大部分复杂的工作已经完成。 坚持下去...

PPS：如果您或您的公司发现 Wails 有用，可以考虑赞助该项目。 谢谢！