Using the native API, (Go bindings of the native winAPI) is possible, but in most cases this is more verbose, as you are working directly with a low-level API. Coding in this way can't make use of standard metrics or configurations that are handled by the higher-level declarative API, designed to better suit a modern programming language. To illustrate the difference, here is what the preceding example would look like if we only used the native API:

package main

import (
   "log"

   "github.com/lxn/walk"
)

var marginSize = 9

func buildWindow() (*walk.MainWindow, error) {
   win, err := walk.NewMainWindowWithName("Hello")
   if err != nil {
      return nil, err
   }
   layout := walk.NewVBoxLayout()
   layout.SetMargins(walk.Margins{marginSize, marginSize, marginSize, marginSize})
   layout.SetSpacing(marginSize)
   win.SetLayout(layout)

   label, err := walk.NewLabel(win)
   if err != nil {
      return win, err
   }
   label.SetText("Hello World!")

   button, err := walk.NewPushButton(win)
   if err != nil {
      return win, err
   }
   button.SetText("Quit")
   button.Clicked().Attach(func() {
      walk.App().Exit(0)
   })

   return win, nil
}

func main() {
   win, err := buildWindow()
   if err != nil {
      log.Fatalln(err)
   }

   win.SetVisible(true)
   win.Run()
}

This code can be compiled in the same way as the previous example, and when run, it will look exactly the same. Clearly, this is a lot more code to obtain the same result and it is a lot harder to read with no particular gain. The error handling that clutters this alternative example is handled implicitly when using the declarative API. Putting aside the differences in the Go syntax, it should be clear that the native API calls used in this example are directly manipulating widgets from the WinAPI. In fact, each of the objects created (through NewLabel(), NewPushButton(), and NewMainWindowWithName()) is a lightweight wrapper for Go the bindings of the WinAPI (provided by github.com/lxn/win).

There are many times where usage of this native API can be useful; most commonly, when you need control of fine details or are dealing with changes to existing widgets, for example within event-handling code. The declarative API is designed for easy definition of an application user interface, but it isn't normally enough to manage the workflow of a complex GUI. Therefore, it's common to use both of these APIs together—using the power of each at the right time.