Wails — Session 4: Runtime Architecture & Application Lifecycle

Objectives

• Understand what happens when a Wails application starts.
• Learn the responsibilities of Windows, Go, Wails, and WebView2.
• Understand how JavaScript and Go execute independently.
• Build the mental model required for future desktop application
  development.

---

Application Startup Sequence

User
 │
 ▼
Double-click App.exe
 │
 ▼
Windows Loader
 │
 ▼
Go Runtime
 │
 ▼
main()
 │
 ▼
NewApp()
 │
 ▼
wails.Run()
 │
 ▼
Create Native Window
 │
 ▼
Create WebView2
 │
 ▼
Load Embedded HTML/CSS/JS
 │
 ▼
Initialize Go ↔ JavaScript Bridge
 │
 ▼
Display Window

Key idea: Go starts before any HTML exists because it must create
the environment in which the frontend will run.

---

Responsibilities of Each Layer

Windows
├── Creates process
├── Creates native windows
├── Schedules threads
└── Delivers mouse and keyboard events
 
Go Runtime
├── Executes backend logic
├── Runs goroutines
└── Garbage collection
 
Wails
├── Creates Go ↔ JavaScript bridge
├── Embeds frontend assets
├── Wraps native APIs
└── Coordinates startup
 
WebView2
├── Renders HTML
├── Executes JavaScript
├── Maintains the DOM
└── Loads web content

Wails is primarily the coordinator.

---

Runtime Separation

Go Runtime
│
├── fmt.Println()
├── Business logic
└── Native APIs
 
──────────────────────────────
 
WebView2 JavaScript Runtime
│
├── console.log()
├── HTML
├── CSS
└── JavaScript

• fmt.Println() outputs to the application’s console.
• console.log() appears in WebView2 Developer Tools.

---

The Go ↔ JavaScript Bridge

JavaScript
      │
      ▼
Generated Wails Bridge
      │
      ▼
Go Method
      │
      ▼
Return Value
      │
      ▼
JavaScript

Communication is asynchronous.

---

Why JavaScript Receives a Promise

A Promise means:

“The result is not available yet, but it will become available later.”

JavaScript
      │
Receive Promise
      │
Go performs work
      │
Go returns result
      │
Promise resolves
      │
Update UI

Promises prevent the user interface from freezing while Go performs
long-running work.

---

Native Features

HTML
│
├── Buttons
├── Text boxes
└── Layout
 
↓
 
JavaScript
 
↓
 
Call Go
 
↓
 
Go
 
↓
 
Windows APIs
 
↓
 
Clipboard
Dialogs
Filesystem
Notifications

The frontend requests native operations; Go performs them.

---

Application Lifetime

Not Running
 
↓
 
Process Created
 
↓
 
Go Starts
 
↓
 
Window Created
 
↓
 
WebView2 Initialized
 
↓
 
Frontend Loaded
 
↓
 
User Interaction
 
↓
 
Shutdown
 
↓
 
Process Ends

---

Engineering Lesson

When debugging, first identify which runtime owns the problem:

• Go
• JavaScript
• WebView2
• Wails
• Windows

Separating responsibilities makes debugging much easier.

---

Key Takeaways

• Go starts before the frontend.
• Windows owns the process and native window.
• WebView2 renders HTML and executes JavaScript.
• Go and JavaScript are separate runtimes.
• The Wails bridge connects the two asynchronously.
• Promises keep the UI responsive.
• Native OS features belong in the Go backend.

---

Reflection Questions

1. Why must Go execute before any HTML is displayed?
2. Which component renders HTML?
3. Why do fmt.Println() and console.log() appear in different
   places?
4. What problem does a Promise solve?
5. Which runtime should implement clipboard access or native dialogs,
   and why?

---

Next Session

Wails — Session 5: Native Window, WebView2 Navigation & Event Flow

Topics:

• Native window lifecycle
• WebView2 navigation
• Page loading events
• Keyboard and mouse event propagation
• Window management
• Foundation for tabs and advanced navigation