We’re going to be doing a bit with the Wails project this year, so let’s start off nice and slow with a small project to get our feet wet before diving in head first.
Wails is a project that enables you to write desktop applications using Go and web technologies. It’s a lightweight and fast Electron alternative for Go, allowing you to build applications with the flexibility and power of Go, combined with a rich, modern frontend. Wails uses a purpose-built library for handling native elements such as Window, Menus, Dialogs, etc., so you can build good-looking, feature-rich desktop applications.
The amount of Go and JavaScript required is minimal, at first, and you can 100% get by with Kagi, Perplexity, or just some keen internet searches (and poking through the Drop history for Go and JavaScript resources). I’ll prove this with the app you’re going to modify.
Wails use of these technologies means you can (for the most part) turn any web app you make into something that you can distribute as an actual app to folks. While I’m more of a fan of native apps, this can save a ton of time and reduce cognitive load…something I think we’ll all need this year.
app.go contains the Go back end functions we’ll be exposing to the JavaScript front end
frontend/index.html is the entry point for the app
my-element.js is the Lit web component that handles the interactivity (we’ll be renaming this).
In the default app, Greet in app.go is called by my-element.js. Here’s what that function looks like:
func (a *App) Greet(name string) string { return fmt.Sprintf("Hello %s, It's show time!", name)}
The func (a *App) Greet(name string) string is a function signature the Wails dev tools looks for. It will automagically generate glue code for the JavaScript parts, and you can use complex function parameters and return values. This one takes in a string, surrounds it with some basic text, then returns it.
You should take some time to change what’s in the Sprintf, rename Greet (and use the new imported name in the my-element.js) and tweak what the render() returns in my-element.js before continuing. It might also be a good idea to read through the official walkthrough.
I added some printing in there so you can see messages appear in the terminal console while the app is running.
When you run wails dev the glue code is, again, automagically generated so the JavaScript side can call that function via:
async fetchOG() { let thisURL = this.shadowRoot.querySelector('input#url').value console.log("fetchOG") FetchOpenGraphTags(thisURL).then(result => { console.log('fetch opengraph tags:', result) this.tags = result; this.requestUpdate(); });}// I’m showing this here, but we’ll talk about it in the next WPEasync connectedCallback() { super.connectedCallback();}
The fetchOG function is called in render() when the button is pressed:
You can use Developer Tools from the running app to watch the console messages go by (very useful for debugging).
Your Mission
Your goal is to (a) successfully get this modified app running and (b) utilize more OG tag fields and display the entire set of OG tags in a much nicer way. Extra points for adding another Golang back end function that you need to call from the JS side.
FIN
Today’s WPE sets a solid foundation for future ones, and we’ll be having tons of fun with it as we layer in DuckDB, SQLite, WebR, Pyodide, and more over the coming weeks/months. Give a shout-out or reply to this post if you have any questions/issues.
The first Bonus Drop goes out this weekend to paid subscribers! (The refunds from the transition from Nazistack should be out soon…I keep checking on the status and will follow up next week if there’s a delay.)
Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev ☮️
"in a way you can think of a lit element is like a computed effect of a signals although our system kinda works like a push system instead of signals that often have a pull system" ~ @justinfagnani
@jaredwhite’s personal thoughts on a great entry by @collinsworth into the growing body of work which details why greenfield #WebDev projects are better served by other frameworks…or none at all.