CLOG: Common Lisp applications through a browser interface

Why CLOG places Common Lisp behind a browser UI

CLOG addresses a specific split in application development: the application can run as Common Lisp code while its interface is rendered by a browser or a browser control compiled into a native application. The intended users are Common Lisp developers building local tools, remote services, business applications, reports, monitoring interfaces, or other software that benefits from a graphical interface without requiring a separate native widget implementation for each platform.

The README positions CLOG as a possible replacement for or companion to cross-platform GUI and website frameworks. That claim is most concrete when an application already accepts browser delivery. CLOG supports local browser windows and remote access over the web, while the README also lists native Windows, macOS, Linux, Android, and iOS targets. Those platform statements do not mean that every deployment path is identical. The repository provides platform-specific files such as LINUX.md, MACOS.md, WINDOWS.md, ANDROID-TERMUX.md, OCICL.md, and NATIVE.md, so an adopter still needs platform-specific setup instructions.

CLOG is also aimed at developers learning Common Lisp. Its LEARN.md and numbered tutorials provide a path from loading the framework to running an interactive demonstration. The builder is described as a portable Common Lisp IDE that can work with CLOG, Common Lisp, JavaScript, and HTML, including a CLOG GUI builder. That makes the project broader than a thin interface library, although the core adoption decision still depends on whether server-side application logic and browser rendering are appropriate for the product.

WebSockets, browser rendering, and server-side event handling

CLOG connects a Common Lisp application to a browser window or native browser control through WebSockets. The browser renders the GUI, while CLOG maintains an active soft real-time connection for application events and state changes. According to the README, most CLOG applications keep programming logic, event handling, and decisions on the server. That server can be on the same machine as the interface or reachable remotely.

This arrangement differs from a conventional server-rendered website whose main request cycle consists of loading a page and sending form submissions. CLOG is built around a continuing connection and server-controlled interaction. Its examples create interface elements and modify properties from Lisp code. The REPL example opens a page at http://127.0.0.1:8080/repl, creates a division in `*body*`, and changes the page background:

CL-USER> (in-package clog-user)
CLOG-USER> (clog-repl)
CLOG-USER> (setf (background-color *body*) "beige")
CLOG-USER> (create-div *body* :content "Hello World!")

The page and REPL are available together so that interface construction can be tried interactively. The README also states that `*body*` refers to the most recently accessed body element at that URL. Applications move beyond demonstrations by defining a handler for new browser windows. The smallest documented application initializes a connection handler that adds a `div` to the supplied body, as covered in the first-use tutorial below.

Because the browser is the renderer, CLOG inherits browser concerns rather than removing them. A deployment must support its WebSocket connection, static assets, and the relevant CLOG server behavior. The repository includes WEBSERVER.md and entries such as `templates/`, `static-files/`, and `clogframe/`, but the README does not provide a complete production deployment matrix. It therefore supports the architecture, not a universal claim that every host configuration is interchangeable.

QuickLisp installation and the first CLOG application

The README distinguishes CLOG 1 from CLOG 2. It says CLOG 1 is in QuickLisp and directs CLOG 2 users to add the UltraLisp distribution or use Git. The following commands reproduce the documented distribution setup. After loading the tools, the command starts CLOG Builder. The README says the distribution systems must then be updated often.

(ql-dist:install-dist "http://dist.ultralisp.org/"
                      :prompt nil)
(ql:update-all-dists)

A user who already has QuickLisp can start SBCL, load `:clog/tools`, and launch the builder with the documented command:

sbcl --eval "(ql:quickload :clog/tools)" --eval "(clog-tools:clog-builder)"

The README also gives a direct REPL route for a first application. This sequence loads CLOG, changes the current package, and initializes a connection handler:

(ql:quickload :clog)
(in-package :clog-user)
(initialize (lambda (body) (create-div body :content "Hello World")))

After initialization, the application is available at the documented local URL. The reader should expect the browser page to contain a `Hello World` division when the application and its browser connection are functioning:

http://127.0.0.1:8080/

CLOG also exposes `(open-browser)` for launching a browser from Lisp. Before that step, `http://127.0.0.1:8080/` can be opened directly. For a guided check, the README offers `(clog:run-tutorial 1)` from CLOG Builder or a Lisp REPL. Demo 1 is available through `(clog:run-demo 1)`. These paths are useful for seeing the documented connection behavior, but they do not substitute for defining an application callback and testing its deployment environment.

OCICL, standalone packages, and platform delivery

OCICL is the repository's documented route for distributable or advanced installations. The README links OCICL.md and describes it as usable across platforms. Its minimal CLOG setup creates a project directory, initializes OCICL configuration, and installs CLOG:

mkdkir helloworld
cd helloworld
ocicl setup > init
ocicl install clog

The README lists `helloworld.lisp` as the file to edit and `run-ocicl` as the run command. It notes `edit-ocicl` for editing and provides `run-ocicl.bat` and `edit-ocicl.bat` for Windows. A Windows installation also needs the open-source DLLs from the linked `clogframe.zip`. This qualification matters because the basic OCICL sequence is not sufficient by itself on that platform.

Separate standalone releases exist for Windows, Linux x86-64, Linux ARM, and macOS. Their documented update procedure uses `update.bat` or `./update`. The README says the standalone packages are intended for newcomers and quick use of the builder. It does not document their exact contents, release cadence, rollback behavior, or production support policy, so those details should be checked before selecting one as an application distribution format.

For Windows users running CLOG in WSL, the README gives two specific configuration steps. The WSL environment needs `xdg-open` and `wslu`, while `.wslconfig` is set to mirrored networking:

sudo apt install xdg-utils wslu

[wsl2]
networkingMode=mirrored

These instructions show that local browser launching can require host integration. CLOG's shared abstraction does not make operating-system configuration irrelevant.

CLOG Builder scope and upgrade implications

CLOG Builder is a separate working environment packaged with the CLOG project. The README describes it as a general-purpose IDE written entirely in portable Common Lisp using the CLOG Framework. Its stated feature set includes editing and working with Common Lisp, JavaScript, HTML, and a CLOG GUI builder. It can also update CLOG Builder itself, which the README says performs the distribution updates described earlier.

This breadth can reduce the number of separate tools needed for a Common Lisp web project, but it also raises adoption questions. The README does not document editor responsiveness, memory use, debugging behavior, project migration, or compatibility with every external tool. It also does not establish that Builder is required to build a CLOG application. The direct ASDF example depends only on `clog`, which indicates that the framework can be used without treating Builder as an application runtime dependency.

Maintenance evidence is concrete but should be stated narrowly. The repository is not archived, and its last push was on 2026-09-08. Releases named CLOG and CLOG Builder 2.4, 2.3, and 2.2 were published on 2025-11-27, 2024-07-11, and 2024-06-18. The README says the CLOG API has been stable for four years and labels 2.3 as released, although the release list also contains 2.4. That mismatch is minor documentation drift, but it means version-specific behavior should be checked against the actual release rather than inferred from the status paragraph.

Upgrade cost depends on whether an application relies on documented stable APIs or on surrounding tooling. The repository does not document a formal migration guide, compatibility matrix, rollback process, or long-term support policy. The stated stability reduces one concern, but it does not answer how applications should be upgraded or how breaking changes are communicated.

License ambiguity and the browser-based design boundary

The README identifies the project as using the BSD 3-Clause License and includes that text under its license heading. GitHub classifies the repository license as Other and points to LICENSE as a custom license it cannot classify. Those sources do not align cleanly. This is not a basis for legal advice, and no interpretation of the actual obligations is possible without reviewing the repository's current LICENSE file.

An organization considering CLOG should compare that file with the README statement before distributing an application or integrating CLOG into a product. Dependency scanners may also report a nonstandard classification. This is an administrative issue that can affect approval workflows even when the application code itself is straightforward.

CLOG is the wrong tool when a browser cannot be part of the user experience and native controls must be compiled as part of the application without a browser renderer. It is also a poor fit when a permanently connected WebSocket model conflicts with network policy or when the target environment cannot run the required browser control. A separate native widget toolkit is better suited to products whose interface contract is entirely independent of web standards.

A real alternative is a conventional HTML plus server framework architecture, such as an application framework that renders HTML and handles HTTP requests. The practical difference is the connection model. CLOG keeps Common Lisp application logic connected to the rendered interface through WebSockets and browser-based rendering. A conventional web framework usually organizes interaction around HTTP requests, HTML responses, and browser behavior delivered through page loads or APIs. CLOG favors a continuing connection and shared interface construction model. The conventional approach may fit organizations with established HTTP deployment, request-level observability, and browser asset pipelines. The README does not compare CLOG directly with a named framework, so the distinction should be evaluated against the architecture already required by the project.

Editorial conclusion

Common Lisp developers should consider CLOG when business logic belongs on the server and a browser-based interface is acceptable for both desktop and web distribution. Projects requiring a self-contained native widget toolchain, undocumented deployment behavior, or a clearly classified standard license should look elsewhere or verify those requirements first. The first checks should be the actual LICENSE file, the target platform instructions, and whether a browser-based event model fits the application.

Frequently asked questions

Official sources

1. Issues
2. rabbibotton/clog on GitHub
3. README
4. Releases