Energy picks between LCL, system webview and CEF per window

Three engines, and the choice is the architecture

Energy is a framework written in Go for building cross platform desktop applications, and it sits on top of three component libraries. LCL is the native UI component library from the Lazarus project, CEF is the Chromium Embedded Framework, and the webview options are WebView2 on Windows and Webkit2Gtk or WKWebView on macOS and Linux.

The three rendering modes are described as usable together or independently, and each carries a different cost. LCL native controls are lightweight with a system look. The system webview runtime needs no extra dependencies because it uses what the operating system already ships. CEF gives complete browser capabilities because it embeds a full Chromium.

That distinction runs through the whole framework. The LCL path gives you 100 or more system native GUI components, including buttons, grids, tree views, list views, dialogs and code editors. The webview path gives you a Go backend handling window management, system calls, file I/O and encryption, with an HTML, CSS and JavaScript frontend handling UI rendering, and it supports Vue, React, Angular and other mainstream frontend frameworks.

The IPC layer is what makes the hybrid mode work. The documentation describes bidirectional, event-driven IPC letting Go and the web side call each other and exchange data, with callback support and automatic type conversion. Local resource loading is handled by a custom protocol scheme so files or embedded Go resources can be loaded directly without an HTTP server, though HTTP server loading is supported as well.

The cross platform claim is specific: Windows 7 and later, macOS on Intel and Apple Silicon, and Linux on x86 and ARM. The optional no-CGO mode is the other headline, since developing in pure Go removes the C toolchain requirement that normally makes cross platform Go GUI work painful.

The LCL quick start is a struct, a form and a callback

The native mode example is small enough to read in one pass. It starts with the package declaration and the two imports it needs:

package main

import (
	"github.com/energye/lcl/api"
	"github.com/energye/lcl/lcl"
)

The window type embeds lcl.TEngForm, and the entry point initialises the library and runs the application:

type TMainForm struct {
	lcl.TEngForm
}

var MainForm TMainForm

func main() {
	lcl.Init()
	lcl.RunApp(&MainForm)
}

The form create handler sets the caption and size, centres the window, and attaches a button with a click handler:

func (m *TMainForm) FormCreate(sender lcl.IObject) {
	m.SetCaption("Hello Energy")
	m.SetWidth(400)
	m.SetHeight(300)
	m.WorkAreaCenter()

	btn := lcl.NewButton(m)
	btn.SetParent(m)
	btn.SetCaption("Click Me")
	btn.SetLeft(50)
	btn.SetTop(50)
	btn.SetOnClick(func(sender lcl.IObject) {
		api.ShowMessage("Hello from Go!")
	})
}

This is a familiar shape for anyone from the Delphi or Pascal world, since the component model with a parent, a caption, absolute positions and an event handler maps directly onto the LCL. The naming convention, with the T prefix and the FormCreate method, follows that tradition rather than Go idiom, which is a deliberate choice to keep the Lazarus audience in mind.

The webview hybrid has an ordering contract you cannot ignore

The webview example shows a different structure, with the window type embedding window.TWindow and holding a webview control. The imports pull from three separate modules, application, window and wv from the energy module itself, plus lcl and lcl/types:

package main

import (
	"github.com/energye/energy/v3/application"
	"github.com/energye/energy/v3/window"
	"github.com/energye/energy/v3/wv"
	"github.com/energye/lcl/lcl"
	"github.com/energye/lcl/types"
)

The form create handler contains the part that trips people up. There are two calls that have to happen in a specific order, and the comments in the example say so explicitly. The window has to be created before the call:

func (m *TForm1) FormCreate(sender lcl.IObject) {
	m.TWindow.InternalBeforeFormCreate() // window create before call
	m.SetCaption("Hello Energy")
	m.SetWidth(800)
	m.SetHeight(600)

	m.Webview1 = wv.NewWebview(m)
	m.Webview1.SetAlign(types.AlClient)
	m.Webview1.SetParent(m)

	m.TWindow.FormCreate(sender) // window widget create after call

	m.Webview1.SetWindow(m)
}

So the sequence is InternalBeforeFormCreate, then you build and attach the webview, then FormCreate, then SetWindow to hand the webview its native window handle. Getting this wrong tends to produce a blank or broken surface rather than a clean error, which is why it is worth reading the generated code rather than approximating it.

The main function initialises the webview application and points it at a URL:

func main() {
	wvApp := wv.Init()
	wvApp.SetOptions(application.Options{
		DefaultURL: "https://energye.github.io",
	})
	wv.Run(&Form1)
}

The URL here is the project's own site, which is a placeholder rather than a real target. The types.AlClient alignment is what makes the webview fill the window.

The designer generates Go, so you still have to read Go

Energy Designer is the visual side of the project, and it is a separate repository with its own releases. The workflow is four steps: launch the designer, create a new project, drag components onto the canvas, configure properties and events, then click Run to preview.

What it produces is maintainable Go source code, and that phrase is doing real work in the documentation. The output is not a data file that only the designer can read, and it is not a web view of a design. It is Go code that you can open in an editor, review in a pull request, and hand to a colleague who does not use the designer at all.

That is the right choice for a framework whose whole premise is that you write Go, and it comes with a real trade-off. The designer removes the tedium of laying out components, but it does not remove the need to understand the API. Anyone maintaining the output later is reading Go code, so the designer accelerates the first draft rather than replacing the programming.

The environment requirements line up with this. You need Golang 1.20 or newer and an Energy development environment, described as either the CEF or System Runtime option plus the libenergy runtime. The documented setup sequence is to install Golang, then create a project from the Energy Designer releases. The examples repository is linked separately, so the fastest way to see a working application beyond the two snippets above is to read one of those instead.

Choosing an engine is choosing a distribution model

The three modes differ most in what you ship to the user, and the documentation makes the system runtime point explicit. WebView2 and Webkit2 use the system runtime, so no extra dependencies are bundled. CEF is a full Chromium, which means a large binary and an engine you fully control, at the cost of size.

The repository layout mirrors the split. Top-level directories include cef, wv, lcl, window, application, ipc, platform and logger, so the CEF path and the webview path are separate trees that share the LCL layer and the IPC implementation.

The dependency versions in go.mod show how thin this core is. The module path is github.com/energye/energy/v3, it declares go 1.20, and it requires three sibling projects: energye/cef at v1.0.5, energye/lcl at v1.0.9 and energye/wv at v1.0.10. Below that sit ebitengine/purego, godbus/dbus, google/uuid and golang.org/x/sys. purego is what makes the no-CGO path possible, since it calls into native libraries without requiring a C compiler at build time, and dbus is there for Linux desktop integration.

The honest framing is that Energy is a family of related frameworks sharing a common component model, not one framework with a setting. A project that mixes native dialogs and a web dashboard will use both trees, and the release engineering for each engine stays a separate concern.

Apache 2.0, an active repository, and a version gap to check

The licence is Apache 2.0, linked from the README badge and stored in the LICENSE file at the repository root. That is the permissive case with an explicit patent grant, and it is what you would expect for a framework intended for commercial desktop applications.

Upkeep looks real but has a wrinkle worth checking. The last push was on 2026-07-12 and the repository is not archived. The release tags, however, are v2.5.6 from 2025-06-17, v2.5.5 from 2025-06-06 and v2.5.4 from 2025-02-27, and the README header carries a large 3.0 version marker while the badges still point at the v2 module paths for the Go reference and the Go Report Card. The go.mod declares the v3 module path, and the quick start examples import from energy/v3.

So the source tree is on the third generation of the module path while the tagged releases visible in the listing are from the second. That may simply mean the 3.0 tags exist and are not reflected in the excerpt, or it may mean the 3.0 line is published without the same tagging discipline. Either way, the practical instruction is to check the release list before pinning a version, and to match your imports to the module path you actually get.

A 2.x application and a 3.x application are not interchangeable, because the import paths differ, so an upgrade is a migration rather than a version bump.

Editorial conclusion

Energy fits a Go team that wants a desktop application for Windows, macOS and Linux from a single codebase and is prepared to commit to one rendering strategy per window, whether native controls for a utility, a system webview for a hybrid, or CEF when a full browser is required. It is the wrong choice for a small utility that a single Go binary could handle, since CEF ships a full Chromium and the hybrid path adds a web layer, and it is the wrong choice if you need to build the UI visually without learning the Go API, since the designer generates code you still have to read. Before committing, run both quick start examples, the LCL form and the webview hybrid, on each target platform, and confirm the CEF distribution size is acceptable if you plan to ship that engine, since CEF bundles a full Chromium runtime while the webview modes use the system runtime.

Frequently asked questions

Official sources

1. energye/energy on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases