Passer au contenu principal

5 articles tagués avec « wails »

Voir tous les tags

· 9 minutes de lecture
Lea Anthony

Introduction

Wails est un projet qui simplifie la possibilité d'écrire des applications de bureau inter-plateformes en utilisant 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.

La version 2 a été publiée le 22 septembre 2022 et a apporté de nombreuses améliorations y compris :

  • 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.

Où en sommes-nous actuellement?

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.

Problèmes actuels

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 was 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.

Le 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.

Résumé

  • 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.

Cordialement,

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.

· 9 minutes de lecture
Lea Anthony

C'est là!

Aujourd'hui marque la sortie de Wails v2. Il y a environ 18 mois depuis la première version alpha de la v2 et environ un an depuis la première version bêta. Je suis vraiment reconnaissant à toutes les personnes impliquées dans l'évolution du projet.

Une partie de la raison pour laquelle il a fallu aussi longtemps était dû à la volonté d'obtenir une version bien stable et complète avant de l'appeler officiellement v2. La vérité est qu'il n'y a jamais un moment parfait pour taguer une version - il y a toujours des problèmes en suspens ou une fonctionnalité de plus pour y ajouter. Taguer une version majeure imparfaite ça arrive, cependant, ça permet de fournir un peu de stabilité pour les utilisateurs du projet, ainsi qu'un peu de réinitialisation pour les développeurs.

Cette version contient bien plus que ce à quoi je m'attendais. J'espère qu'il vous donnera autant de plaisir qu'il nous en a donné de le développer.

Qu'est-ce Wails?

Si vous n'êtes pas familier avec Wails, c'est un projet qui permet aux programmeurs Go de fournir des interfaces pour leurs programmes Go en utilisant des technologies web. C'est une alternative Go à Electron. Beaucoup plus d'informations peuvent être trouvées sur le site officiel.

Quelles sont les nouveautés ?

La version v2 est un énorme bond en avant pour le projet, en abordant la plupart des points douloureux de la v1. Si vous n'avez lu aucun des articles de blog sur la version bêta pour macOS, Windows ou Linux, alors je vous encourage à le faire car il couvre tous les changements majeurs plus en détail. En Résumé:

  • Le composant Webview2 pour Windows qui prend en charge les standards Web modernes et les capacités de débogage.
  • Thème sombre / clair + thème personnalisé sur Windows.
  • Windows n'a plus besoin de CGO.
  • Prise en charge des modèles de projet Svelte, Vue, React, Preact, Lit & Vanilla.
  • Intégration de Vite fournissant un environnement de développement de rechargement à chaud pour votre application.
  • Support des menus et boites de dialogues natifs.
  • Effets de transparence de fenêtre native pour Windows et macOS. Prise en charge des fonds Mica & Acrylic.
  • Générez facilement un installateur NSIS pour les déploiements Windows.
  • Une riche bibliothèque runtime fournissant des méthodes utilitaires pour la manipulation de fenêtres, évènements, les boites de dialogues, les menus et les logs.
  • Prise en charge pour le masquage de votre application en utilisant garble.
  • Prise en charge de la compression de votre application en utilisant UPX.
  • Génération automatique en TypeScript de structures Go. Plus d'infos ici.
  • Aucune autre bibliothèque ou DLL ne doit être fournie avec votre application. Pour n'importe quelle plateforme.
  • Pas d'obligation de regrouper les actifs en frontend. Il vous suffit de développer votre application comme toute autre application web.

Crédits & Remerciements

Le passage à la v2 a été un effort énorme. Il y a eu ~2.2K commits par 89 contributeurs entre l'alpha initial et la publication aujourd'hui, et plusieurs, beaucoup d'autres qui ont fourni des traductions, des tests, des commentaires et de l'aide sur les forums de discussion ainsi que le suivi des problèmes. Je suis si incroyablement reconnaissant de chacun de vous. Je voudrais également remercier tout particulièrement tous les commanditaires du projet qui ont fourni des conseils, des conseils et des commentaires. Tout ce que vous faites est grandement apprécié.

Il y a quelques personnes auxquelles je voudrais donner une mention spéciale à:

Tout d'abord, un grand merci à @stffabi qui a fourni tant de contributions dont nous bénéficions tous, en plus de fournir un grand soutien sur de nombreuses questions. Il a fourni quelques fonctionnalités clés comme le support du serveur de développement externe qui a transformé notre offre de mode de développement en nous permettant de nous brancher sur les superpouvoirs de Vite. Il est juste de dire que Wails v2 serait une version beaucoup moins excitante sans ses contributions incroyables. Merci beaucoup @stffabi!

Je voudrais également adresser un cri énorme à @misitebao qui a inlassablement maintenu le site web en plus de fournir des traductions chinoises, de gérer Crowdin et d'aider les nouveaux traducteurs à se mettre à la hauteur. C'est une tâche extrêmement importante, et je suis extrêmement reconnaissant pour tout le temps et les efforts consentis dans cette tâche! Tu assures !

Enfin, et surtout, un grand merci à Mat Ryer qui a fourni des conseils et du soutien pendant le développement de la v2. Écrire xBar ensemble en utilisant une Alpha de v2 était utile pour façonner la direction de v2, en plus de me donner une compréhension de certains défauts de conception dans les premières versions. Je suis heureux de vous annoncer qu'à partir d'aujourd'hui, nous allons commencer à porter xBar sur Wails v2, et il deviendra l'application phare du projet. Bravo Mat!

Leçons apprises

Il y a un certain nombre de leçons apprises à se rendre à la version 2 qui façonneront les futurs développements.

Des versions plus petites, plus rapides et ciblées

Au cours du développement de la version 2, de nombreuses fonctionnalités et corrections de bogues ont été développées sur une base ad-hoc. Cela a entraîné des cycles de publication plus longs et a été plus difficile à déboger. Dans le futur, nous allons créer des versions plus souvent qui incluront un nombre réduit de fonctionnalités. Une version implique des mises à jour de la documentation ainsi que des tests approfondis. Espérons que ces versions plus petites, plus rapides et ciblées conduiront à moins de régressions et à une meilleure qualité de la documentation.

Encourager l'engagement

Lors du lancement de ce projet, je voulais aider immédiatement tous ceux qui avaient un problème. Les problèmes étaient "personnels" et je voulais les résoudre le plus rapidement possible. Ceci n'est pas durable et va finalement à l'encontre de la longévité du projet. En avançant, je donnerai plus de place aux gens pour s'impliquer dans la réponse aux questions et vis à vis du triage. Il serait bon d'obtenir des outils pour aider à cela, donc si vous avez des suggestions, veuillez vous joindre à la discussion ici.

Apprendre à dire non

Plus il y a de personnes qui s'engagent dans un projet Open Source, plus il y aura de requêtes pour des fonctionnalités supplémentaires qui peuvent ou non être utiles à la majorité des personnes. Ces fonctionnalités prendront un temps initial de développement et de débogage, et entraîneront un coût de maintenance continu à partir de ce moment. Je suis moi-même coupable de cela, souvent vouloir "remuer terre et mer" plutôt que de fournir la caractéristique minimale viable. Dorénavant, nous devrons dire "Non" un peu plus pour ajouter des fonctionnalités de base et concentrer nos énergies sur un moyen de permettre aux développeurs de fournir eux-mêmes cette fonctionnalité. Nous examinons sérieusement les plugins pour ce scénario. Cela permettra à tous de prolonger le projet comme bon leur semble, tout en fournissant un moyen facile de contribuer au projet.

Un regard tourné vers l'avenir

Il y a tant de fonctionnalités fondamentales que nous envisageons d'ajouter à Wails dans le prochain cycle de développement majeur. La feuille de route est pleine d'idées intéressantes, et je suis impatient de commencer à y travailler. Une des grandes demandes a été le support de plusieurs fenêtres. C'est délicat et pour le faire correctement, et nous pourrions avoir besoin d'envisager de fournir une API alternative, car la version courante n'a pas été conçue en gardant cela à l'esprit. Sur la base de quelques idées préliminaires et de commentaires, je pense que vous aimerez où nous allons aller.

Personnellement, je suis très excité à l'idée de faire fonctionner des applications Wails sur mobile. Nous avons déjà un projet de démo qui montre qu'il est possible d'exécuter une application Wails sur Android, donc je suis vraiment impatient d'explorer où nous pouvons aller avec ceci!

Un dernier point que je voudrais soulever est celui de la parité des fonctionnalités. Cela fait longtemps que nous n'ajouterions rien au projet sans un support cross-plateforme complet. Bien que cela se soit avéré (principalement) réalisable jusqu'à présent, il a vraiment repoussé le projet dans la publication de nouvelles fonctionnalités. A présent, nous adopterons une approche légèrement différente : toute nouvelle fonctionnalité qui ne peut pas être publiée immédiatement pour toutes les plates-formes sera publiée sous une configuration expérimentale ou une API. Cela permet aux adopteurs précoces sur certaines plates-formes d'essayer la fonctionnalité et de fournir des commentaires qui alimenteront la conception finale de la fonctionnalité. Ceci, bien sûr, signifie qu'il n'y a aucune garantie de stabilité de l'API tant qu'il n'est pas entièrement supporté par toutes les plateformes sur lesquelles il peut être supporté, mais au moins cela débloquera le développement.

Derniers Mots

Je suis vraiment fier de ce que nous avons pu réaliser avec la version V2. C'est incroyable de voir ce que les gens ont déjà pu construire en utilisant les versions bêta jusqu'à présent. Applications de qualité comme Varly, Surge et October. Je vous encourage à aller voir ces projets.

Cette version a été obtenue grâce au travail acharné de nombreux contributeurs. Bien qu'il soit gratuit à télécharger et à utiliser, il n'a pas rien coûté. Ne vous y trompez pas, ce projet a eu un coût considérable. Ce n'est pas seulement mon temps et le temps de chaque contributeur, mais aussi le coût de l'absence des amis et des familles de chacune de ces personnes aussi. C'est pourquoi je suis extrêmement reconnaissant pour chaque seconde qui a été consacré à faire de ce projet se produire. Plus nous avons de contributeurs, plus cet effort peut être réparti et le plus nous pourrons faire ensemble. Je voudrais vous encourager tous à choisir une chose que vous pouvez contribuer, si elle confirme le bogue de quelqu'un, suggérer un correctif, faire un changement de documentation ou aider quelqu'un qui en a besoin. Toutes ces petites choses ont un impact énorme! Ça serait si génial si vous aussi faisiez aussi parti de l'histoire de la v3.

Profitez bien!

Lea

PS : Si vous ou votre entreprise trouvez Wails utile, veuillez envisager de parrainer le projet. Merci !

· 6 minutes de lecture
Lea Anthony

J'ai le plaisir d'annoncer enfin que Wails v2 est maintenant en version bêta pour Linux ! Il est quelque peu ironique que les toutes premières expériences avec v2 aient été sous Linux et pourtant elles ont fini comme la dernière version. Cela dit, la v2 que nous avons aujourd'hui est très différente de ces premières expériences. Donc, sans perdre plus de temps, passons en revue les nouvelles fonctionnalités :

Nouvelles fonctionnalités


Il y avait beaucoup de demandes pour le support des menus natifs. Wails a enfin ce qu'il vous faut. Les menus des applications sont maintenant disponibles et incluent la prise en charge de la plupart des fonctions natives de menu. Cela inclut les éléments de menu standard, les cases à cocher, les groupes radio, les sous-menus et les séparateurs.

Il y avait un grand nombre de demandes dans la v1 pour avoir un plus grand contrôle de la fenêtre elle-même. Je suis heureux d'annoncer qu'il y a de nouvelles API runtime spécifiquement pour cela. Il est riche en fonctionnalités et supporte les configurations multi-moniteurs. Il y a aussi une API de boite de dialogues améliorée : maintenant, vous pouvez avoir des boites de dialogues modernes et natives avec une configuration enrichie pour répondre à tous vos besoins.

Pas d'obligation de regrouper les ressources

Un énorme point de douleur de v1 était le besoin de condenser toute votre application en un seul fichier JS & CSS. Je suis heureux d'annoncer que, pour la v2, il n'y a pas d'obligation de regrouper des ressources, de quelque manière que ce soit. Vous voulez charger une image locale? Utilisez un tag <img> avec un chemin src local. Vous voulez utiliser une police de caractères cool ? Copiez-la et ajoutez le chemin d'accès dans votre CSS.

Wow, ça ressemble à un serveur web...

Oui, il fonctionne comme un serveur web, sauf que ce n'est pas le cas.

Comment puis-je inclure mes ressources ?

Vous passez simplement un seul embed.FS qui contient tous vos actifs dans la configuration de votre application. Ils n'ont même pas besoin d'être dans le répertoire racine du projet - Wails s'assurera de le faire fonctionner pour vous.

Nouvelle expérience de développement

Maintenant que les actifs n'ont pas besoin d'être regroupés, cela permet de vivre une toute nouvelle expérience de développement. La nouvelle commande wails dev construira et exécutera votre application, mais au lieu d'utiliser les ressources embarquées dans embed.FS, il les charge directement à partir du disque.

Il fournit également les fonctionnalités supplémentaires :

  • Rechargement à chaud - Toutes les modifications apportées aux ressources du frontend déclencheront le rechargement automatique du frontend de l'application
  • Reconstruction automatique - Toutes les modifications apportées à votre code Go déclencheront une reconstruction automatique avant de relancer votre application

En plus de cela, un serveur web démarrera sur le port 34115. Cela servira votre application à n'importe quel navigateur qui s'y connecte. Tous les navigateurs Web connectés recevront les événements du système tels que le rechargement chaud en cas de modification.

Avec Go, nous sommes habitués à traiter avec des structs dans nos applications. Il est souvent utile d'envoyer des structs sur notre site et de les utiliser dans notre application. Dans la v1, c'était un processus manuel et un peu lourd pour le développeur. Je suis heureux de vous annoncer qu'en v2, toute application exécutée en mode dev générera automatiquement des modèles TypeScript pour tous les structs qui sont des paramètres d'entrée ou de sortie aux méthodes Go liées au frontend. Cela permet un échange transparent de modèles de données entre les deux mondes.

En plus de cela, un autre module JS est généré dynamiquement en enveloppant toutes vos méthodes liées. Cela fournit la JSDoc pour vos méthodes, en fournissant la complétion de code et des suggestions dans votre IDE. C'est vraiment cool quand vous obtenez des modèles de données auto-importés en appuyant sur la touche tab dans un module généré automatiquement à partir de votre code Go !

Modèles distants


La mise en place rapide d'une application a toujours été un objectif clé pour le projet Wails. Quand nous avons lancé le projet, nous avons essayé de couvrir beaucoup de frameworks modernes à l'époque : react, vue et angular. Le monde du développement du frontend évolue très vite et est difficile à garder à jour ! En conséquence, nous avons trouvé que nos modèles de base étaient obsolètes rapidement et cela a causé des maux de tête de maintenance. Cela signifie également que nous n'avons pas de modèles modernes et cool pour les dernières grandes technologies.

Avec la v2, je voulais donner à la communauté la possibilité de créer et d'héberger des modèles vous-même, plutôt que que de compter sur le projet Wails. Maintenant vous pouvez créer des projets en utilisant des modèles supportés par la communauté! J'espère que cela inspirera les développeurs à créer un écosystème de modèles de projet. Je suis vraiment très excité par ce que notre communauté de développeurs peut créer !

Cross Compilation sur Windows

Parce que Wails v2 pour Windows est pur Go, vous pouvez cibler les versions Windows sans docker.


En conclusion

Comme je l'ai dit dans les notes de version de Windows, Wails v2 représente une nouvelle base pour le projet. Le but de cette version est d'obtenir des commentaires sur la nouvelle approche et d'éliminer tout bug avant une version complète. Vos commentaires sont les bienvenus! Veuillez diriger tout commentaire vers le forum de discussion v2 Bêta .

Linux est difficile à supporter. Nous espérons qu'il y aura un certain nombre de bizarreries avec la bêta. Veuillez nous aider à vous aider en remplissant des rapports de bogue détaillés !

Enfin J'aimerais remercier tout particulièrement tous les sponsors du projet dont le soutien propulse le projet de plusieurs manières en coulisses.

J'ai hâte de voir ce que les gens construisent avec Wails dans cette prochaine phase excitante du projet!

Lea.

PS: La sortie de la version v2 n'est plus pour très longtemps.

PPS : Si vous ou votre entreprise trouvez Wails utile, veuillez envisager de parrainer le projet. Merci !

· 7 minutes de lecture
Lea Anthony

Aujourd'hui marque la première version bêta de Wails v2 pour Mac! Il a fallu un certain temps pour arriver à ce point et j'espère que la version d'aujourd'hui vous donnera quelque chose de raisonnablement utile. Il y a eu un certain nombre de virages et détours pour atteindre ce point et j'espère, avec votre aide, pour aplanir les croupes et faire polir le portage sur Mac pour la version définitive de la v2.

Vous voulez dire que ce n'est pas prêt pour la production ? Pour votre cas d'utilisation, il peut être prêt, mais il y a encore un certain nombre de problèmes connus donc gardez votre œil sur ce tableau de projet et si vous souhaitez contribuer, vous serez les bienvenus !

Alors quoi de neuf pour Wails v2 pour Mac vs v1 ? Indice : C'est assez similaire à la bêta de Windows 😉

Nouvelles fonctionnalités


Il y avait beaucoup de demandes pour le support des menus natifs. Wails a enfin ce qu'il vous faut. Les menus des applications sont maintenant disponibles et incluent la prise en charge de la plupart des fonctions natives de menu. Cela inclut les éléments de menu standard, les cases à cocher, les groupes radio, les sous-menus et les séparateurs.

Il y avait un grand nombre de demandes dans la v1 pour avoir un plus grand contrôle de la fenêtre elle-même. Je suis heureux d'annoncer qu'il y a de nouvelles API runtime spécifiquement pour cela. Il est riche en fonctionnalités et supporte les configurations multi-moniteurs. Il y a aussi une API de boite de dialogues améliorée : maintenant, vous pouvez avoir des boites de dialogues modernes et natives avec une configuration enrichie pour répondre à tous vos besoins.

Options spécifiques à Mac

En plus des options d'application normales, Wails v2 pour Mac apporte également quelques options supplémentaires pour Mac :

  • Faites de votre fenêtre une fenêtre funky et transparente, comme toutes les applications assez rapides !
  • Barre de titre hautement personnalisable
  • Nous prenons en charge les options NSAppearance pour l'application
  • Configuration simple pour créer automatiquement un menu "À propos"

Pas d'obligation de regrouper les ressources

Un énorme point de douleur de v1 était le besoin de condenser toute votre application en un seul fichier JS & CSS. Je suis heureux d'annoncer que, pour la v2, il n'y a pas d'obligation de regrouper des ressources, de quelque manière que ce soit. Vous voulez charger une image locale? Utilisez un tag <img> avec un chemin src local. Vous voulez utiliser une police de caractères cool ? Copiez-la et ajoutez le chemin d'accès dans votre CSS.

Wow, ça ressemble à un serveur web...

Oui, il fonctionne comme un serveur web, sauf que ce n'est pas le cas.

Comment puis-je inclure mes ressources ?

Vous passez simplement un seul embed.FS qui contient tous vos actifs dans la configuration de votre application. Ils n'ont même pas besoin d'être dans le répertoire racine du projet - Wails s'assurera de le faire fonctionner pour vous.

Nouvelle expérience de développement

Maintenant que les actifs n'ont pas besoin d'être regroupés, cela permet de vivre une toute nouvelle expérience de développement. La nouvelle commande wails dev construira et exécutera votre application, mais au lieu d'utiliser les ressources embarquées dans embed.FS, il les charge directement à partir du disque.

Il fournit également les fonctionnalités supplémentaires :

  • Rechargement à chaud - Toutes les modifications apportées aux ressources du frontend déclencheront le rechargement automatique du frontend de l'application
  • Reconstruction automatique - Toutes les modifications apportées à votre code Go déclencheront une reconstruction automatique avant de relancer votre application

En plus de cela, un serveur web démarrera sur le port 34115. Cela servira votre application à n'importe quel navigateur qui s'y connecte. Tous les navigateurs Web connectés recevront les événements du système tels que le rechargement chaud en cas de modification.

Avec Go, nous sommes habitués à traiter avec des structs dans nos applications. Il est souvent utile d'envoyer des structs sur notre site et de les utiliser dans notre application. Dans la v1, c'était un processus manuel et un peu lourd pour le développeur. Je suis heureux de vous annoncer qu'en v2, toute application exécutée en mode dev générera automatiquement des modèles TypeScript pour tous les structs qui sont des paramètres d'entrée ou de sortie aux méthodes Go liées au frontend. Cela permet un échange transparent de modèles de données entre les deux mondes.

En plus de cela, un autre module JS est généré dynamiquement en enveloppant toutes vos méthodes liées. Cela fournit la JSDoc pour vos méthodes, en fournissant la complétion de code et des suggestions dans votre IDE. C'est vraiment cool quand vous obtenez des modèles de données auto-importés en appuyant sur la touche tab dans un module généré automatiquement à partir de votre code Go !

Modèles distants


La mise en place rapide d'une application a toujours été un objectif clé pour le projet Wails. Quand nous avons lancé le projet, nous avons essayé de couvrir beaucoup de frameworks modernes à l'époque : react, vue et angular. Le monde du développement du frontend évolue très vite et est difficile à garder à jour ! En conséquence, nous avons trouvé que nos modèles de base étaient obsolètes rapidement et cela a causé des maux de tête de maintenance. Cela signifie également que nous n'avons pas de modèles modernes et cool pour les dernières grandes technologies.

Avec la v2, je voulais donner à la communauté la possibilité de créer et d'héberger des modèles vous-même, plutôt que que de compter sur le projet Wails. Maintenant vous pouvez créer des projets en utilisant des modèles supportés par la communauté! J'espère que cela inspirera les développeurs à créer un écosystème de modèles de projet. Je suis vraiment très excité par ce que notre communauté de développeurs peut créer !

Prise en charge native de M1

Grâce au support incroyable de Mat Ryer, le projet Wails prend maintenant en charge les versions natives de M1 :


Vous pouvez également spécifier darwin/amd64 comme cible :


Oh, j'ai presque oublié.... vous pouvez aussi faire darwin/universal.... 😉


Cross Compilation sur Windows

Parce que Wails v2 pour Windows est pur Go, vous pouvez cibler les versions Windows sans docker.


WKWebView Renderer

V1 s'est appuyé sur un composant WebView (maintenant obsolète). V2 utilise le composant WKWebKit le plus récent, donc attendez-vous au meilleur d'Apple.

En conclusion

Comme je l'ai dit dans les notes de version de Windows, Wails v2 représente une nouvelle base pour le projet. Le but de cette version est d'obtenir des commentaires sur la nouvelle approche et d'éliminer tout bug avant une version complète. Vos commentaires sont les bienvenus! Veuillez diriger tout commentaire vers le forum de discussion v2 Bêta .

Enfin, je voudrais remercier tout particulièrement tous les sponsors du projet, y compris JetBrains, dont le soutien anime le projet de plusieurs manières en coulisses.

J'ai hâte de voir ce que les gens construisent avec Wails dans cette prochaine phase excitante du projet!

Lea.

PS: Les utilisateurs de Linux, vous êtes les prochains !

PPS : Si vous ou votre entreprise trouvez Wails utile, veuillez envisager de parrainer le projet. Merci !

· 10 minutes de lecture
Lea Anthony

Quand j'ai annoncé Wails pour la première fois sur Reddit, il y a deux ans depuis un train à Sydney, je n'espérais pas autant d'attention. Quelques jours plus tard, un tech vlogger populaire a publié un tutoriel vidéo, a effectué une revue positive et à partir de ça, l'intérêt du projet n'a fait que croître.

Il était clair que des gens étaient excités au fait de pouvoir ajouter des frontends web à leurs projets en Go, et presque immédiatement ça a poussé le projet bien plus loin que la preuve de concept que j'avais créé. A ce moment, Wails utilisait le projet webview pour gérer le frontend, et la seule option pour Windows était le moteur de rendu IE11. Beaucoup de bugs ont été ouverts à cause de cette limitation : support faible du JavaScript/CSS et accès à aucun outil de développement pour le déboguer. C'était une expérience de développement frustrante, mais il n'y avait pas grand-chose qui pouvait être fait pour le rectifier.

Durant un long moment, je croyais fermement que Microsoft allait devoir faire quelque chose pour améliorer la situation de leur navigateur. Le monde avançait, le développement frontend était en plein boom, mais IE n'était pas à la hauteur. Lorsque Microsoft a annoncé le passage à l'utilisation de Chromium comme nouvelle base pour leur navigateur, je savais que ce n'était qu'une question de de temps avant que Wails ne puisse l'utiliser, et que l'expérience du développeur Windows ne passe au niveau supérieur.

Aujourd'hui, j'ai le plaisir d'annoncer : Wails v2 Beta pour Windows! Il y a énormément de stock dans cette version, donc attrape une boisson, prend un siège et nous allons commencer...

Pas de dépendance CGO !

Non, je ne plaisante pas : Pas de dépendance CGO 🤯! La chose à propos de Windows est que, contrairement à MacOS et Linux, il n'est pas livré avec un compilateur par défaut. De plus, CGO a besoin d'un compilateur mingw et il y a une tonne d'options d'installation différentes. La suppression de CGO comme prérequis a simplifié considérablement la configuration et facilite grandement le débogage. Pendant que j'ai fait un effort raisonnable pour que cela fonctionne, la majorité du crédit devrait aller à John Chadwick pour non seulement démarrer quelques projets pour rendre ceci possible, mais aussi être ouvert à quelqu'un qui prend ces projets et qui en crée d'autres à partir des siens. Crédit également à Tad Vizbaras dont le projet winc m'a lancé dans cette direction.

Moteur de rendu WebView2 Chromium


Enfin, les développeurs de Windows obtiennent un moteur de rendu de première classe pour leurs applications ! Les jours à tordre votre code frontend pour le faire fonctionner sur Windows sont terminés. En plus de cela, vous obtenez une expérience avec des outils de développement de première classe !

Le composant WebView2 a toutefois besoin d'avoir le WebView2Loader.dll de présent avec le binaire. Cela rend la distribution juste un peu plus douloureuse que ce à quoi nous sommes habitués. Toutes les solutions et bibliothèques (que je connais) qui utilisent WebView2 ont cette dépendance.

Cependant, je suis vraiment heureuse d'annoncer que les applications Wails n'ont pas de telles exigences! Merci à la sorcellerie de John Chadwick, grâce à qui nous sommes en mesure de regrouper cette dll à l'intérieur du binaire et d'obtenir que Windows la charge comme si elle était présente sur le disque.

Les Gophers se réjouissent! Le rêve d'un binaire unique vit !

Nouvelles fonctionnalités


Il y avait beaucoup de demandes pour le support des menus natifs. Wails a enfin ce qu'il vous faut. Les menus des applications sont maintenant disponibles et incluent la prise en charge de la plupart des fonctions natives de menu. Cela inclut les éléments de menu standard, les cases à cocher, les groupes radio, les sous-menus et les séparateurs.

Il y avait un grand nombre de demandes dans la v1 pour avoir un plus grand contrôle de la fenêtre elle-même. Je suis heureux d'annoncer qu'il y a de nouvelles API runtime spécifiquement pour cela. Il est riche en fonctionnalités et supporte les configurations multi-moniteurs. Il y a aussi une API de boite de dialogues améliorée : maintenant, vous pouvez avoir des boites de dialogues modernes et natives avec une configuration enrichie pour répondre à tous vos besoins.

Il y a maintenant la possibilité de générer la configuration dee votre IDE avec votre projet. Cela signifie que si vous ouvrez votre projet dans un IDE pris en charge, il sera déjà configuré pour construire et déboguer votre application. Actuellement, VSCode est supporté mais nous espérons bientôt pouvoir prendre en charge d'autres IDE comme Goland.


Pas d'obligation de regrouper les ressources

Un énorme point de douleur de v1 était le besoin de condenser toute votre application en un seul fichier JS & CSS. Je suis heureux d'annoncer que, pour la v2, il n'y a pas d'obligation de regrouper des actifs, de quelque manière que ce soit. Vous voulez charger une image locale? Utilisez un tag <img> avec un chemin src local. Vous voulez utiliser une police de caractères cool ? Copiez-la et ajoutez le chemin d'accès dans votre CSS.

Wow, ça ressemble à un serveur web...

Oui, il fonctionne comme un serveur web, sauf que ce n'est pas le cas.

Comment puis-je inclure mes ressources ?

Vous passez simplement un seul embed.FS qui contient tous vos actifs dans la configuration de votre application. Ils n'ont même pas besoin d'être dans le répertoire racine du projet - Wails s'assurera de le faire fonctionner pour vous.

Nouvelle expérience de développement


Maintenant que les actifs n'ont pas besoin d'être regroupés, cela permet de vivre une toute nouvelle expérience de développement. La nouvelle commande wails dev construira et exécutera votre application, mais au lieu d'utiliser les ressources embarquées dans embed.FS, il les charge directement à partir du disque.

Il fournit également les fonctionnalités supplémentaires :

  • Rechargement à chaud - Toutes les modifications apportées aux ressources du frontend déclencheront le rechargement automatique du frontend de l'application
  • Reconstruction automatique - Toutes les modifications apportées à votre code Go déclencheront une reconstruction automatique avant de relancer votre application

En plus de cela, un serveur web démarrera sur le port 34115. Cela servira votre application à n'importe quel navigateur qui s'y connecte. Tous les navigateurs Web connectés recevront les événements du système tels que le rechargement chaud en cas de modification.

Avec Go, nous sommes habitués à traiter les structs dans nos applications. Il est souvent utile d'envoyer des structs sur notre site et de les utiliser dans notre application. Dans la v1, c'était un processus manuel et un peu lourd pour le développeur. Je suis heureux de vous annoncer qu'en v2, toute application exécutée en mode dev générera automatiquement des modèles TypeScript pour tous les structs qui sont des paramètres d'entrée ou de sortie aux méthodes Go liées au frontend. Cela permet un échange transparent de modèles de données entre les deux mondes.

En plus de cela, un autre module JS est généré dynamiquement en enveloppant toutes vos méthodes liées. Cela fournit la JSDoc pour vos méthodes, en fournissant la complétion de code et des suggestions dans votre IDE. C'est vraiment cool quand vous obtenez des modèles de données auto-importés en appuyant sur la touche tab dans un module généré automatiquement à partir de votre code Go !

Modèles distants


La mise en place rapide d'une application a toujours été un objectif clé pour le projet Wails. Quand nous avons lancé le projet, nous avons essayé de couvrir beaucoup de frameworks modernes à l'époque : react, vue et angular. Le monde du développement du frontend est rapide et difficile à garder à jour ! En conséquence, nous avons trouvé que nos modèles de base étaient obsolètes rapidement et cela a causé des maux de tête de maintenance. Cela signifie également que nous n'avons pas de modèles modernes et cool pour les dernières grandes technologies.

Avec la v2, je voulais donner à la communauté la possibilité de créer et d'héberger des modèles vous-même, plutôt que que de compter sur le projet Wails. Maintenant vous pouvez créer des projets en utilisant des modèles supportés par la communauté! J'espère que cela inspirera les développeurs à créer un écosystème dynamique de modèles de projet. Je suis vraiment très excité par ce que notre communauté de développeurs peut créer !

En conclusion

Wails v2 représente une nouvelle fondation pour le projet. Le but de cette version est d'obtenir des commentaires sur la nouvelle approche et d'éliminer tout bug avant une version complète. Vos commentaires sont les bienvenus. Veuillez diriger tout commentaire vers le forum de discussion v2 Bêta .

Il y a eu beaucoup de détours, de virages et de retournements de situation pour atteindre ce but. Cela est dû en partie à des décisions techniques précoces qui devaient être modifiées, et en partie parce que certains problèmes de base pour lesquels nous avions passé du temps à construire des solutions de contournement ont été corrigés en amont : L'intégration de Go est un bon exemple. Heureusement, tout s'est réuni au bon moment, et aujourd'hui nous avons la meilleure solution que nous puissions avoir. Je pense que l'attente en valait la peine, cela n'aurait pas été possible il y a même 2 mois .

J'ai également besoin de remercier énormément les personnes suivantes 🙏 parce que sans elles, cette version n'existerait tout simplement pas:

  • Misite Bao - Un bourreau de travail absolu sur les traductions chinoises et un chercheur de bugs incroyable.
  • John Chadwick - Pour son travail incroyable sur go-webview2 et go-winloader qui a permis aujourd'hui d'avoir une version Windows.
  • Tad Vizbaras - Expérimenter avec son projet winc a été le premier pas vers un pur Wails en Go.
  • Mat Ryer - Son soutien, ses encouragements et ses commentaires ont vraiment contribué à faire avancer le projet.

Enfin, je voudrais remercier tout particulièrement tous les sponsors du projet, y compris JetBrains, dont le soutien anime le projet de plusieurs manières en coulisses.

J'ai hâte de voir ce que les gens construisent avec Wails dans cette prochaine phase excitante du projet!

Lea.

PS: Les utilisateurs de MacOS et de Linux n'ont pas besoin de se sentir laissés de côté. Le portage vers ces OS est en cours et la majeure partie du travail a déjà été faite. Tenez bon !

PPS : Si vous ou votre entreprise trouvez Wails utile, veuillez envisager de parrainer le projet. Merci !