Live data from Hacker News

Wails: Build cross-platform applications using Go

wails.io

11–20 of 48 posts

Re: Wails: Build cross-platform applications using Go

#11
post #7
post #6

Earlier quoted context omitted.

Just have the application start the browser like daemons used to 20 years ago. Nowadays they can even send the PWA manifest to hide the browser appearance.

Are we really arguing why someone might want to have a "native" app instead of a browser window? There's many reasons why someone might want to have that.

Yes we are, Web technologies belong in the browser.

I wasn't impressed with MSHTML when it came up as Active Desktop, nor I am impressed with anything that followed suit.

Re: Wails: Build cross-platform applications using Go

#12
I played with this a few days ago and it is still early days with rough edges but at the same time encouraging. I used the latest beta which supports Linux (the banner on the main site still says just Mac and Windows but the blog announces Linux support). The default app built after I increased the max file watcher system parameter and the dev mode reloaded quickly on changes after that. There was a flash of white as the app view loaded but I remember early Electron apps doing the same. Kudos to the devs for working on this - I’m hoping it brings some competition for Electron as it matures.

Re: Wails: Build cross-platform applications using Go

#13
post #11
post #7

Earlier quoted context omitted.

Are we really arguing why someone might want to have a "native" app instead of a browser window? There's many reasons why someone might want to have that.

Yes we are, Web technologies belong in the browser. I wasn't impressed with MSHTML when it came up as Active Desktop, nor I am impressed with anything that followed suit.

> Web technologies belong in the browser

That ship has sailed a long time ago. These days sometimes whole operating systems are based on HTML based interfaces (LGs TV OS would be one example).

Re: Wails: Build cross-platform applications using Go

#14
post #2

I don't get these projects. If you're going to write an html/js app, why not just launch the web browser against the local url of your app?

This way you know exactly which browser people are using and you don't have to deal with idiosyncrasies.

Re: Wails: Build cross-platform applications using Go

#15
post #2

I don't get these projects. If you're going to write an html/js app, why not just launch the web browser against the local url of your app?

Using the the apps I have built in this style as an example (not this library in particular though) - starting a whole browser comes with a lot of baggage you may not need - plug-ins as a small example. It’s easier to target 3 OSs than some random permutation.

Also, doing it this way, you can extend the Javascript to add custom callback functions - if that is something you need.

Also, it’s all in one process so there is less fiddly bits (request / response and all that)

You do bring up a good point though, and I hadn’t thought of the PWA angle. It would be an easy way to add a cli interface (just curl I guess)… I might try that next time.

Re: Wails: Build cross-platform applications using Go

#18
post #13
post #11

Earlier quoted context omitted.

Yes we are, Web technologies belong in the browser. I wasn't impressed with MSHTML when it came up as Active Desktop, nor I am impressed with anything that followed suit.

> Web technologies belong in the browser That ship has sailed a long time ago. These days sometimes whole operating systems are based on HTML based interfaces (LGs TV OS would be one example).

WebOS applications don't ship a browser alongside them, they use what is already installed.

Doing Web development alongside native since Web exists, hasn't made me like shipping browsers with applications (or Web views) any better during the last 20 years.

Re: Wails: Build cross-platform applications using Go

#20
post #2

I don't get these projects. If you're going to write an html/js app, why not just launch the web browser against the local url of your app?

An embedded webview gives you more control over the browser chrome (as in UI), extensions, cookies, etc. It also gives you a shim into some filesystem/OS APIs that a regular sandboxed browser page wouldn't have. It gives you a predictable HTML/JS renderer that you control, instead of blindly hoping that your user will happen to have a compatible browser.

Still, webview UIs are a lazy alternative to actual native apps. I don't like them either, but not every org can afford to hire native devs and write 3x-4x the UI code.

Post reply on HN