Wails General API

[leaanthony]

Hi everyone!

When Wails was first created, there were a number of design decisions that were made based on speculation and assumption. Now we have a fair number of people using it, I was hoping for some feedback on the way it works from an API perspective. The main areas for discussion are:

1. WailsInit / WailsShutdown - These methods were added because the frontend gets created in an Asyncronous fashion, so there needs to be a hook back to your code. An alternative approach might be to have a method like app.Ready(callback) that is invoked when the frontend is ready to run.

2. Menus - There's a lot of work in v2 that's been done around menus (application, context and system tray). Currently, these may be defined in the application config. The issue with this is how the callback mechanism should work. If there's a method on the menu items for the callback, then the code being executed is actually in the context of the application config, not any of your structs. This may be ok as you can create those structs in the main() function before the config and call on them. The alternative is that you define the callbacks in your structs using a runtime method, eg runtime.Menu.On('menuid', callback). This then opens up the discussion around would menuids be unique globally or unique to the context they are made for (eg context menus).

I'm keen to discuss anything related to this topic so feel free to raise further points! How do you use Wails? What could be better from an API/Workflow perspective? Thanks!

[GeekStocks]

Re: menus, your quandary reminds me so much of other frameworks and their design decisions, and I'm sorry but you'll have people liking both ways LOL.

eg, people who LOVE JavaScript love React, because its "just JavaScript". On the converse, users of Vue appreciate the ease of development offered by the single file approach that merges HTML/CSS/JS (which drives purists crazy). Sometimes there is no good answer and you must use artistic license. Which method appeals to you?

For me, I try to think things out until I find a clear winner, even if that win is marginal. In your case, if I understand your choices correctly, it seems like creating structs in the main() will help locate bugs at compile time, while setting things up at runtime opens you up to uncaught runtime bugs the compiler could not see. Do you concur?

---

Your second question is what I was digging around for today. "How do I use Wails?" Answer: I don't, or rather I can't. I need Windows support, and your well documented MSHTML issue is blocking Wails development for now (I need to demo a working EXE to stakeholders to achieve buy-in). I am heartened to see that a Webview upgrade will solve this in v2. Are you able to predict which quarter of 2021 v2 might drop in?

[leaanthony]

Thanks for taking the time to write a detailed reply. Much appreciated! I agree with your take on the startup/shutdown issue and have already implemented them as simple callbacks. There is significant speedup in both startup and shutdown (much less to do) and it also had the side-effect of fixing a rather annoying shutdown bug. Yay! I'm also thinking this principle applies to the binding of structs and am looking to move that to the config too.

Regarding MSHTML, is this really a blocker for you? How so? Many projects have worked well with it, though it is way harder than it should be. Regarding which quarter v2 windows support will drop, I would guess q2 at the earliest. I'm firming up v2 Mac right now which entails the hard part of making sure the internals and API are right. The other platforms is merely a port of the windowing library + a bit extra for packaging specifics.

[GeekStocks]

I wouldn't take up a maintainer's time with a deeper explanation of that which is why I skimmed over the issue, but perhaps I accidentally opened a Pandora's Box here LOL. Let me try to close it!

I influence the architecture & tooling for my workplace. My first choice for frontend would be option *[5] Vue Full which has the asterisk:

(* means unsupported on current platform):

It would pretty much be "career limiting" if I recommended technologies with build messages like:

WARNING: This project is unsupported on windows - it probably won't work!
Windows builds use mshtml which is only compatible with IE11.

Now, those messages are quite helpful of course so I'm glad they are there. They explain why building the out-of-the-box demo (Vue Full template --->wails build) produces an EXE with a script error in my win10/amd64 environment. But of course I cannot recommend Vue Full until that is addressed.

For personal projects I see that 2: React JS builds just fine (only a 10MB binary too!) but professionally we are a Vue shop which is why I stated I was blocked. I'm NOT blocked personally (JavaScript lover == React lol). Hope that answers your question; the block is more Vue than Wails I guess.

[leaanthony]

Thanks for taking the time to write this. Vue3 isn't supported on IE11 so we can't support it until they do! 👍