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.
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.
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.
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.
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… 😉
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.
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.
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.
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.
Wouldn’t it be great if we could do something like this?
funcmain() {
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:
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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!
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:
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.
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.
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!
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!
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!
Today marks the first beta release of Wails v2 for Mac! It’s taken quite a while
to get to this point and I’m hoping that today’s release will give you something
that’s reasonably useful. There have been a number of twists and turns to get to
this point and I’m hoping, with your help, to iron out the crinkles and get the
Mac port polished for the final v2 release.
You mean this isn’t ready for production? For your use case, it may well be
ready, but there are still a number of known issues so keep your eye on
this project board and if you
would like to contribute, you’d be very welcome!
So what’s new for Wails v2 for Mac vs v1? Hint: It’s pretty similar to the
Windows Beta :wink:
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.
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 <img> 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.
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 and 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!
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!
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.
And finally, I’d like to give a special thank you to all the
project sponsors, including
JetBrains, whose support drive 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: Linux users, you’re next!
PPS: If you or your company find Wails useful, please consider
sponsoring the project. Thanks!
