Blog

Wails v3 Beta: a new foundation for Go desktop applications

Aug 2, 2026

Lea Anthony

Maintainer of Wails

Today we are releasing Wails v3 Beta.

Wails lets Go developers build desktop applications with the web frontend tools they already know, using the native WebView on each platform rather than an embedded browser. v3 is a substantial step forward: it gives applications a more direct API, a clearer build model, and a better foundation for the desktop applications people have been asking Wails to support.

This is a beta release, not the final 3.0 release. The desktop API is stable and teams are already using v3 in production, but you should test thoroughly before deploying. We are using the beta period to catch the final compatibility and workflow issues with the community. Wails v2 remains the current stable release and will continue to receive fixes.

Documentation during beta

During beta, we are maintaining the English documentation as the source of truth while the API and workflows receive their final validation. We are not accepting translation PRs at this stage. Translation work will resume before general availability, once the documentation is stable enough for translators to work without repeated churn.

What is in v3

• An explicit application and window API, including first-class multi-window support
• Go services with static source analysis that generates richer TypeScript bindings, preserving comments and meaningful parameter names
• Services that can bundle frontend assets and scripts with their backend API - the foundation for installable, richer plugins
• A visible, Taskfile-based build system you can inspect, extend, and debug
• Server builds for running the same application and services without a native desktop window
• Modern desktop support for macOS, Windows, and Linux on Intel, Apple Silicon, amd64, and arm64 where supported
• Experimental mobile support for iOS and Android, available for exploration but outside the desktop beta compatibility promise

Why v3

Wails v2 made it straightforward to build a Go application with a modern web frontend. It has served the project - and a great many applications - well. But its single-window, context-driven runtime and tightly managed build process made some common desktop work harder than it should have been.

v3 starts from a different model. Applications, windows, services, events, and platform capabilities are explicit objects. That makes the framework easier to reason about as an application grows, and makes features such as multiple windows a normal part of the application model rather than a workaround.

What is new

An application API built for real desktop software

v3 replaces the v2 wails.Run(...) configuration style with an explicit application lifecycle. You create an application, register services, create windows, and interact with the objects that own the behaviour you need.

That removes a great deal of implicit context passing. Window operations belong to windows; application-wide operations belong to the application. It is a more natural model for multi-window applications and a better fit for testing and maintaining larger codebases.

The feedback from people who used v3 during alpha has been overwhelmingly positive. In particular, developers have responded well to the explicit model: it makes the code easier to follow, makes ownership clearer, and gives complex desktop applications room to grow without fighting the framework.

First-class multiple windows

Multiple windows are a core v3 capability. Windows have their own lifecycle and can be created, managed, and closed at runtime. The result is a clearer route to the kind of desktop software that needs editors, inspectors, preferences, tool windows, or several independent pieces of UI.

Services and generated bindings

Go services replace the older binding model. They keep application logic as ordinary Go code and make the boundary to the frontend explicit. Bindings are generated into a structure that reflects the application and its services, making it easier to find and use the API exposed to the frontend.

v3 generates those bindings with static source analysis. That means the generator can retain the information developers put into their code - including comments and meaningful parameter names - rather than discovering an already built program through reflection. The result is a richer, more useful frontend API and a generation process that is easier to understand and maintain.

Services can also mount frontend assets and scripts alongside their Go code. That gives a capability one coherent home: its backend API, the JavaScript or UI it needs, and the integration point for the host application. It opens the door to Wails plugins that deliver rich functionality out of the box - install a plugin, mount its service, and use the feature - rather than assembling a loose collection of bindings and frontend dependencies yourself. A general plugin system is not part of this beta, but v3 makes that direction practical in a way the v2 binding model did not.

A build system you can inspect and adapt

v3 makes the project build structure visible. Rather than hiding every build decision inside a single command, projects have a conventional layout and Taskfile-based build configuration that can be understood, extended, and debugged alongside the application.

A stronger cross-platform desktop baseline

The beta supports Windows on amd64 and arm64, macOS on Intel and Apple Silicon, and Linux on amd64 and arm64. GTK4 with WebKitGTK 6.0 is the default Linux stack; GTK3 remains available as a legacy option throughout the v3.0 series. Mobile support is exciting but remains experimental and is not part of the desktop beta compatibility promise.

This release also includes the work needed to make the day-to-day experience more dependable: improved platform behaviour, a more capable window model, clearer diagnostics, and release artefacts with checksums and provenance.

Moving from v2

v3 is a new major version, and migration is a real port rather than a version number change. The main conceptual shifts are the application and window lifecycle, services instead of context-bound bindings, direct application and window APIs instead of the v2 runtime package, and regenerated frontend bindings.

We have published a v2-to-v3 migration guide that walks through those changes and includes a feature mapping and testing checklist. That manual guide is the supported migration path for this beta. Please do not expect every v2 project to convert without review: test the result, port your runtime calls deliberately, and keep v2 in place until the new application is ready.

The beta CLI also includes an experimental migration assistant: wails3 migrate -d /path/to/v2-project -o /path/to/v3-project. It creates a separate V3 project and a MIGRATION.md checklist, but it does not promise a zero-touch conversion. Review the generated project, port the listed V2 API calls, and report reproducible problems in the issue tracker.

A candid note on the journey

The first v3 alpha tag was published on 18 January 2023. That is a long time to be in alpha, and it deserves more than a vague acknowledgement.

The project has changed enormously during that time. When the first Wails v2 beta shipped for Windows in September 2021, the repository had roughly 4,000 stars. By the v2 release in September 2022, it had roughly 10,300. Today it has more than 35,000. That growth is a privilege, but it also changes what good stewardship looks like: more users depend on release decisions, more contributors need clear routes to participate, and more of the work is about making the project predictable rather than simply adding the next feature.

I have not always adapted our processes as quickly or as clearly as that growth required. I own that. The answer is not to make grand promises or to turn every decision into ceremony; it is to be clearer about what is supported, what is experimental, how decisions are made, and what we are doing next.

That work begins with this beta. We now have explicit beta, release-candidate, and GA milestones; clearer compatibility commitments; an updated security policy; and a WEP (Wails Enhancement Proposal) process for changes to public behaviour and new capabilities. We will continue to improve the roadmap and review the project’s governance as Wails grows. The aim is a project that feels easier to rely on and easier to contribute to - not one that is harder to move.

We are also relaunching the Wails subreddit and will actively maintain it as another place for practical discussion, questions, and feedback as v3 moves toward general availability.

Install and try the beta

Once the release is published, install the latest v3 CLI with:

go install github.com/wailsapp/wails/v3/cmd/wails3@latest

Before creating a project, run the guided setup wizard. It checks your local development environment and helps configure the dependencies Wails needs:

wails3 setup

Create a project

Once you are all set, create a project with:

wails3 init

• Documentation: https://v3.wails.io/
• Migration guide: https://v3.wails.io/migration/v2-to-v3/
• Reddit: https://www.reddit.com/r/wails/
• Release notes: VERSION PLACEHOLDER

If you find a reproducible bug, please report it with the output of wails3 doctor and a minimal example where possible. If you want to propose a new capability or a change to public behaviour, start a draft WEP PR instead of a feature-request issue. Both routes help us respond clearly and keep the beta moving.

Thank you

Wails v3 exists because of the people who tested incomplete builds, reported hard bugs, translated documentation, answered questions, contributed code, and kept asking the project to become better. Thank you.

And a very special, heartfelt thank you to the sponsors who have carried Wails through this long transition. Your support did more than keep the lights on: it gave us the opportunity to spend sustained time on the architecture, tooling, testing, and documentation that let the project accelerate toward v3. Every tester and contributor has helped shape this release, but the sponsors made it possible to give that work the attention it deserved.

The beta is an invitation to help us finish v3 properly. Try it, build with it, tell us where it breaks, and help us make the road to 3.0 a short and careful one.

Tags:

• wails
• v3
• beta

Alpha 10 Released - A New Chapter for Wails

Dec 3, 2024

Lea Anthony

Maintainer of Wails

Alpha 10 Released - A New Chapter for Wails

We’re thrilled to announce the release of Wails v3 Alpha 10 - and it’s big! While our release cadence may have seemed slow recently, there’s been an incredible amount of work happening behind the scenes. Today marks not just another release, but a shift in how we approach the development of Wails.

Why the Wait?

Like many development teams, we fell into the trap of trying to achieve perfection before each release. We wanted to squash every bug, polish every feature, and ensure everything was just right. But here’s the thing - software is never truly bug-free, and waiting for that mythical state only delays getting improvements into your hands.

Our New Release Strategy

Starting today, we’re adopting a daily release strategy. Any new changes merged during the day will be released at the end of that day. This approach will:

• Get bug fixes and features to you faster
• Provide more frequent feedback loops
• Speed up our journey to Beta
• Make the development process more transparent

This means you might see more frequent, smaller releases rather than occasional large ones. We believe this will benefit everyone in the Wails community.

How You Can Help

We’ve been overwhelmed by the number of people wanting to contribute to Wails! To make it easier for contributors to get involved, we’re implementing a new system:

• Firstly, we are opening up bug reporting for alpha releases. The frequent releases allow us to do this.
• Issues marked with “Ready for Work” are open for community contributions
• These issues have clear requirements and are ready to be tackled
• Most importantly, we need people testing PRs - this is one of the most valuable contributions you can make

Testing doesn’t require deep knowledge of the codebase, but it provides immense value by ensuring changes work across different environments and use cases.

What’s Next?

With our new daily release strategy, expect to see rapid progress toward Beta. We’re committed to maintaining momentum and getting Wails v3 to a stable release as quickly as possible without sacrificing quality.

And who knows? There might be a few surprises along the way… 😉

Thank You

To everyone who has contributed code, tested releases, reported bugs, or simply used Wails - thank you. Your support and feedback drive this project forward.

Here’s to more frequent releases, faster iteration, and an exciting journey ahead!

---

Want to get involved? Check out our GitHub repository for issues marked “ready for work”, or join our community to help test the latest changes.

The Road to Wails v3

Jan 17, 2023

Lea Anthony

Maintainer of Wails

Introduction

Wails is a project that simplifies the ability to write cross-platform desktop applications using Go. It uses native webview components for the frontend (not embedded browsers), bringing the power of the world’s most popular UI system to Go, whilst remaining lightweight.

Version 2 was released on the 22nd of September 2022 and brought with it a lot of enhancements including:

• Live development, leveraging the popular Vite project
• Rich functionality for managing windows and creating menus
• Microsoft’s WebView2 component
• Generation of Typescript models that mirror your Go structs
• Creating of NSIS Installer
• Obfuscated builds

Right now, Wails v2 provides powerful tooling for creating rich, cross-platform desktop applications.

This blog post aims to look at where the project is at right now and what we can improve on moving forward.

Where are we now?

It’s been incredible to see the popularity of Wails rising since the v2 release. I’m constantly amazed by the creativity of the community and the wonderful things that are being built with it. With more popularity, comes more eyes on the project. And with that, more feature requests and bug reports.

Over time, I’ve been able to identify some of the most pressing issues facing the project. I’ve also been able to identify some of the things that are holding the project back.

Current issues

I’ve identified the following areas that I feel are holding the project back:

• The API
• Bindings generation
• The Build System

The API

The API to build a Wails application currently consists of 2 parts:

• The Application API
• The Runtime API

The Application API famously has only 1 function: Run() which takes a heap of options which govern how the application will work. Whilst this is very simple to use, it is also very limiting. It is a “declarative” approach which hides a lot of the underlying complexity. For instance, there is no handle to the main window, so you can’t interact with it directly. For that, you need to use the Runtime API. This is a problem when you start to want to do more complex things like create multiple windows.

The Runtime API provides a lot of utility functions for the developer. This includes:

• Window management
• Dialogs
• Menus
• Events
• Logs

There are a number of things I am not happy with the Runtime API. The first is that it requires a “context” to be passed around. This is both frustrating and confusing for new developers who pass in a context and then get a runtime error.

The biggest issue with the Runtime API is that it was designed for applications that only use a single window. Over time, the demand for multiple windows has grown and the API is not well suited to this.

Thoughts on the v3 API

Wouldn’t it be great if we could do something like this?

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()
}

This programmatic approach is far more intuitive and allows the developer to interact with the application elements directly. All current runtime methods for windows would simply be methods on the window object. For the other runtime methods, we could move them to the application object like so:

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

This is a much more powerful API which will allow for more complex applications to be built. It also allows for the creation of multiple windows, the most up-voted feature on 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()
}

Bindings generation

One of the key features of Wails is generating bindings for your Go methods so they may be called from Javascript. The current method for doing this is a bit of a hack. It involves building the application with a special flag and then running the resultant binary which uses reflection to determine what has been bound. This leads to a bit of a chicken and egg situation: You can’t build the application without the bindings and you can’t generate the bindings without building the application. There are many ways around this but the best one would be not to use this approach at all.

There were a number of attempts at writing a static analyser for Wails projects but they didn’t get very far. In more recent times, it has become slightly easier to do this with more material available on the subject.

Compared to reflection, the AST approach is much faster however it is significantly more complicated. To start with, we may need to impose certain constraints on how to specify bindings in the code. The goal is to support the most common use cases and then expand it later on.

The Build System

Like the declarative approach to the API, the build system was created to hide the complexities of building a desktop application. When you run wails build, it does a lot of things behind the scenes:

• Builds the backend binary for bindings and generates the bindings
• Installs the frontend dependencies
• Builds the frontend assets
• Determines if the application icon is present and if so, embeds it
• Builds the final binary
• If the build is for darwin/universal it builds 2 binaries, one for darwin/amd64 and one for darwin/arm64 and then creates a fat binary using lipo
• If compression is required, it compresses the binary with UPX
• Determines if this binary is to be packaged and if so:
  • Ensures the icon and application manifest are compiled into the binary (Windows)
  • Builds out the application bundle, generates the icon bundle and copies it, the binary and Info.plist to the application bundle (Mac)
• If an NSIS installer is required, it builds it

This entire process, whilst very powerful, is also very opaque. It is very difficult to customise it and it is very difficult to debug.

To address this in v3, I would like to move to a build system that exists outside of Wails. After using Task for a while, I am a big fan of it. It is a great tool for configuring build systems and should be reasonably familiar to anyone who has used Makefiles.

The build system would be configured using a Taskfile.yml file which would be generated by default with any of the supported templates. This would have all of the steps required to do all the current tasks, such as building or packaging the application, allowing for easy customisation.

There will be no external requirement for this tooling as it would form part of the Wails CLI. This means that you can still use wails build and it will do all the things it does today. However, if you want to customise the build process, you can do so by editing the Taskfile.yml file. It also means you can easily understand the build steps and use your own build system if you wish.

The missing piece in the build puzzle is the atomic operations in the build process, such as icon generation, compression and packaging. To require a bunch of external tooling would not be a great experience for the developer. To address this, the Wails CLI will provide all these capabilities as part of the CLI. This means that the builds still work as expected, with no extra external tooling, however you can replace any step of the build with any tool you like.

This will be a much more transparent build system which will allow for easier customisation and address a lot of the issues that have been raised around it.

The Payoff

These positive changes will be a huge benefit to the project:

• The new API will be much more intuitive and will allow for more complex applications to be built.
• Using static analysis for bindings generation will be much faster and reduce a lot of the complexity around the current process.
• Using an established, external build system will make the build process completely transparent, allowing for powerful customisation.

Benefits to the project maintainers are:

• The new API will be much easier to maintain and adapt to new features and platforms.
• The new build system will be much easier to maintain and extend. I hope this will lead to a new ecosystem of community driven build pipelines.
• Better separation of concerns within the project. This will make it easier to add new features and platforms.

The Plan

A lot of the experimentation for this has already been done and it’s looking good. There is no current timeline for this work but I’m hoping by the end of Q1 2023, there will be an alpha release for Mac to allow the community to test, experiment with and provide feedback.

Summary

• The v2 API is declarative, hides a lot from the developer and not suitable for features such as multiple windows. A new API will be created which will be simpler, intuitive and more powerful.
• The build system is opaque and difficult to customise so we will move to an external build system which will open it all up.
• The bindings generation is slow and complex so we will move to static analysis which will remove a lot of the complexity the current method has.

There has been a lot of work put into the guts of v2 and it’s solid. It’s now time to address the layer on top of it and make it a much better experience for the developer.

I hope you are as excited about this as I am. I’m looking forward to hearing your thoughts and feedback.

Regards,

‐ Lea

PS: If you or your company find Wails useful, please consider sponsoring the project. Thanks!

PPS: Yes, that’s a genuine screenshot of a multi-window application built with Wails. It’s not a mockup. It’s real. It’s awesome. It’s coming soon.

Tags:

• wails
• v3

Wails v2 Released

Sep 22, 2022

Lea Anthony

Maintainer of Wails

It’s here!

Today marks the release of Wails v2. It’s been about 18 months since the first v2 alpha and about a year from the first beta release. I’m truly grateful to everyone involved in the evolution of the project.

Part of the reason it took that long was due to wanting to get to some definition of completeness before officially calling it v2. The truth is, there’s never a perfect time to tag a release - there’s always outstanding issues or “just one more” feature to squeeze in. What tagging an imperfect major release does do, however, is to provide a bit of stability for users of the project, as well as a bit of a reset for the developers.

This release is more than I’d ever expected it to be. I hope it gives you as much pleasure as it has given us to develop it.

What is Wails?

If you are unfamiliar with Wails, it is a project that enables Go programmers to provide rich frontends for their Go programs using familiar web technologies. It’s a lightweight, Go alternative to Electron. Much more information can be found on the official site.

What’s new?

The v2 release is a huge leap forward for the project, addressing many of the pain points of v1. If you have not read any of the blog posts on the Beta releases for macOS, Windows or Linux, then I encourage you to do so as it covers all the major changes in more detail. In summary:

• Webview2 component for Windows that supports modern web standards and debugging capabilities.
• Dark / Light theme + custom theming on Windows.
• Windows now has no CGO requirements.
• Out-of-the-box support for Svelte, Vue, React, Preact, Lit & Vanilla project templates.
• Vite integration providing a hot-reload development environment for your application.
• Native application menus and dialogs.
• Native window translucency effects for Windows and macOS. Support for Mica & Acrylic backdrops.
• Easily generate an NSIS installer for Windows deployments.
• A rich runtime library providing utility methods for window manipulation, eventing, dialogs, menus and logging.
• Support for obfuscating your application using garble.
• Support for compressing your application using UPX.
• Automatic TypeScript generation of Go structs. More info here.
• No extra libraries or DLLs are required to be shipped with your application. For any platform.
• No requirement to bundle frontend assets. Just develop your application like any other web application.

Credit & Thanks

Getting to v2 has been a huge effort. There have been ~2.2K commits by 89 contributors between the initial alpha and the release today, and many, many more that have provided translations, testing, feedback and help on the discussion forums as well as the issue tracker. I’m so unbelievably grateful to each one of you. I’d also like to give an extra special thank you to all the project sponsors who have provided guidance, advice and feedback. Everything you do is hugely appreciated.

There are a few people I’d like to give special mention to:

Firstly, a huge thank you to @stffabi who has provided so many contributions which we all benefit from, as well as providing a lot of support on many issues. He has provided some key features such as the external dev server support which transformed our dev mode offering by allowing us to hook into Vite’s superpowers. It’s fair to say that Wails v2 would be a far less exciting release without his incredible contributions. Thank you so much @stffabi!

I’d also like to give a huge shout-out to @misitebao who has tirelessly been maintaining the website, as well as providing Chinese translations, managing Crowdin and helping new translators get up to speed. This is a hugely important task, and I’m extremely grateful for all the time and effort put into this! You rock!

Last, but not least, a huge thank you to Mat Ryer who has provided advice and support during the development of v2. Writing xBar together using an early Alpha of v2 was helpful in shaping the direction of v2, as well as give me an understanding of some design flaws in the early releases. I’m happy to announce that as of today, we will start to port xBar to Wails v2, and it will become the flagship application for the project. Cheers Mat!

Lessons Learnt

There are a number of lessons learnt in getting to v2 that will shape development moving forward.

Smaller, Quicker, Focused Releases

In the course of developing v2, there were many features and bug fixes that were developed on an ad-hoc basis. This led to longer release cycles and were harder to debug. Moving forward, we are going to create releases more often that will include a reduced number of features. A release will involve updates to documentation as well as thorough testing. Hopefully, these smaller, quicker, focussed releases will lead to fewer regressions and better quality documentation.

Encourage Engagement

When starting this project, I wanted to immediately help everyone who had a problem. Issues were “personal” and I wanted them resolved as quickly as possible. This is unsustainable and ultimately works against the longevity of the project. Moving forward, I will be giving more space for people to get involved in answering questions and triaging issues. It would be good to get some tooling to help with this so if you have any suggestions, please join in the discussion here.

Learning to say No

The more people that engage with an Open Source project, the more requests there will be for additional features that may or may not be useful to the majority of people. These features will take an initial amount of time to develop and debug, and incur an ongoing maintenance cost from that point on. I myself am the most guilty of this, often wanting to “boil the sea” rather than provide the minimum viable feature. Moving forward, we will need to say “No” a bit more to adding core features and focus our energies on a way to empower developers to provide that functionality themselves. We are looking seriously into plugins for this scenario. This will allow anyone to extend the project as they see fit, as well as providing an easy way to contribute towards the project.

Looking to the Future

There are so many core features we are looking at to add to Wails in the next major development cycle already. The roadmap is full of interesting ideas, and I’m keen to start work on them. One of the big asks has been for multiple window support. It’s a tricky one and to do it right, and we may need to look at providing an alternative API, as the current one was not designed with this in mind. Based on some preliminary ideas and feedback, I think you’ll like where we’re looking to go with it.

I’m personally very excited at the prospect of getting Wails apps running on mobile. We already have a demo project showing that it is possible to run a Wails app on Android, so I’m really keen to explore where we can go with this!

A final point I’d like to raise is that of feature parity. It has long been a core principle that we wouldn’t add anything to the project without there being full cross-platform support for it. Whilst this has proven to be (mainly) achievable so far, it has really held the project back in releasing new features. Moving forward, we will be adopting a slightly different approach: any new feature that cannot be immediately released for all platforms will be released under an experimental configuration or API. This allows early adopters on certain platforms to try the feature and provide feedback that will feed into the final design of the feature. This, of course, means that there are no guarantees of API stability until it is fully supported by all the platforms it can be supported on, but at least it will unblock development.

Final Words

I’m really proud of what we’ve been able to achieve with the V2 release. It’s amazing to see what people have already been able to build using the beta releases so far. Quality applications like Varly, Surge and October. I encourage you to check them out.

This release was achieved through the hard work of many contributors. Whilst it is free to download and use, it has not come about through zero cost. Make no mistakes, this project has come at considerable cost. It has not only been my time and the time of each and every contributor, but also the cost of absence from friends and families of each of those people too. That’s why I’m extremely grateful for every second that has been dedicated to making this project happen. The more contributors we have, the more this effort can be spread out and the more we can achieve together. I’d like to encourage you all to pick one thing that you can contribute, whether it is confirming someone’s bug, suggesting a fix, making a documentation change or helping out someone who needs it. All of these small things have such a huge impact! It would be so awesome if you too were part of the story in getting to v3.

Enjoy!

‐ Lea

PS: If you or your company find Wails useful, please consider sponsoring the project. Thanks!

Tags:

• wails
• v2

Wails v2 Beta for Linux

Feb 22, 2022

Lea Anthony

Maintainer of Wails

I’m pleased to finally announce that Wails v2 is now in beta for Linux! It is somewhat ironic that the very first experiments with v2 was on Linux and yet it has ended up as the last release. That being said, the v2 we have today is very different from those first experiments. So without further ado, let’s go over the new features:

New Features

There were a lot of requests for native menu support. Wails has finally got you covered. Application menus are now available and include support for most native menu features. This includes standard menu items, checkboxes, radio groups, submenus and separators.

There were a huge number of requests in v1 for the ability to have greater control of the window itself. I’m happy to announce that there’s new runtime APIs specifically for this. It’s feature-rich and supports multi-monitor configurations. There is also an improved dialogs API: Now, you can have modern, native dialogs with rich configuration to cater for all your dialog needs.

No requirement to bundle assets

A huge pain-point of v1 was the need to condense your entire application down to single JS & CSS files. I’m happy to announce that for v2, there is no requirement to bundle assets, in any way, shape or form. Want to load a local image? Use an <../../../assets/blog-images> tag with a local src path. Want to use a cool font? Copy it in and add the path to it in your CSS.

Wow, that sounds like a webserver…

Yes, it works just like a webserver, except it isn’t.

So how do I include my assets?

You just pass a single embed.FS that contains all your assets into your application configuration. They don’t even need to be in the top directory - Wails will just work it out for you.

New Development Experience

Now that assets don’t need to be bundled, it’s enabled a whole new development experience. The new wails dev command will build and run your application, but instead of using the assets in the embed.FS, it loads them directly from disk.

It also provides the additional features:

• Hot reload - Any changes to frontend assets will trigger an auto reload of the application frontend
• Auto rebuild - Any changes to your Go code will rebuild and relaunch your application

In addition to this, a webserver will start on port 34115. This will serve your application to any browser that connects to it. All connected web browsers will respond to system events like hot reload on asset change.

In Go, we are used to dealing with structs in our applications. It’s often useful to send structs to our frontend and use them as state in our application. In v1, this was a very manual process and a bit of a burden on the developer. I’m happy to announce that in v2, any application run in dev mode will automatically generate TypeScript models for all structs that are input or output parameters to bound methods. This enables seamless interchange of data models between the two worlds.

In addition to this, another JS module is dynamically generated wrapping all your bound methods. This provides JSDoc for your methods, providing code completion and hinting in your IDE. It’s really cool when you get data models auto-imported when hitting tab in an auto-generated module wrapping your Go code!

Remote Templates

Getting an application up and running quickly was always a key goal for the Wails project. When we launched, we tried to cover a lot of the modern frameworks at the time: react, vue and angular. The world of frontend development is very opinionated, fast moving and hard to keep on top of! As a result, we found our base templates getting out of date pretty quickly and this caused a maintenance headache. It also meant that we didn’t have cool modern templates for the latest and greatest tech stacks.

With v2, I wanted to empower the community by giving you the ability to create and host templates yourselves, rather than rely on the Wails project. So now you can create projects using community supported templates! I hope this will inspire developers to create a vibrant ecosystem of project templates. I’m really quite excited about what our developer community can create!

Cross Compilation to Windows

Because Wails v2 for Windows is pure Go, you can target Windows builds without docker.

In Conclusion

As I’d said in the Windows release notes, Wails v2 represents a new foundation for the project. The aim of this release is to get feedback on the new approach, and to iron out any bugs before a full release. Your input would be most welcome! Please direct any feedback to the v2 Beta discussion board.

Linux is hard to support. We expect there to be a number of quirks with the beta. Please help us to help you by filing detailed bug reports!

Finally, I’d like to give a special thank you to all the project sponsors whose support drives the project in many ways behind the scenes.

I look forward to seeing what people build with Wails in this next exciting phase of the project!

Lea.

PS: The v2 release isn’t far off now!

PPS: If you or your company find Wails useful, please consider sponsoring the project. Thanks!

Tags:

• wails
• v2

Older posts