cogentcore/core: one Go codebase, six platforms, and exactly one release tag

One tag, cut in 2024, titled as a first release

The release history contains a single entry. It is version zero point three, dated the middle of 2024, and the release note consists of two words: initial release.

That tag is still the only one. The last commit to the default branch is dated 2026-09-26, so the project is not dormant. It is receiving changes, and the dependency file shows a version of the module manifest and a Go toolchain floor that are both far newer than the tag.

So the situation is a project with more than two years of continuous development and no published version past its first one. For a library that is used as a dependency, that has two consequences and both of them are awkward.

The first is that you cannot pin. If you depend on this and something breaks, the commit you were on is a commit, not a version, and there is no way for a colleague to ask which one you meant other than by hash. The version badge at the top of the readme points at the tags page, which contains one entry, which is at best not useful and at worst actively misleading because it implies a versioned release exists.

The second is that fixes are indistinguishable from changes. If the project ships a security fix in a dependency and also merges forty unrelated commits in the same week, there is no way for a downstream user to take the first without the second. A tag at least gives you a boundary even if the boundary moves slowly, and a minor version increment at least tells you something about whether to expect breakage.

The reason is probably ordinary. A GUI framework with a large dependency surface, a pre-release graphics binding, and mobile build targets is a project where every release is a decision to freeze a matrix of platforms, and freezing one is expensive. The readme is also not trying to sell you a version. It links to documentation on a website, it states the toolchain requirement, and it thanks its sponsors. There is no install command, no quick start, and no mention of a release cadence anywhere in it, which is consistent with a project that is not yet ready to promise one.

For a reader, the practical guidance is short. Depend on a specific commit, record the hash, and expect to update by hand. Do not put this in a shared dependency file that other people also write to.

Three dependencies are forks the project maintains itself

The module manifest lists around forty direct dependencies, and three of them are forks maintained by the same organisation as the framework itself. That is unusual enough to be worth examining, because a fork is a maintenance commitment that outlives any single feature.

The first is an embedded interpreter for Go, forked and pinned to a specific commit from January 2026. There is a matching top-level package in the repository whose name is that interpreter's, which is the confirmation: this framework embeds a scripting language, and that language is the one the framework itself is written in.

That is the largest architectural statement in the dependency list, and it deserves a moment. A GUI framework with an embedded interpreter is a framework whose applications are scriptable at runtime. A user can type Go at the application, a script can reach the same widget tree the compiled code built, and the debugging and build tooling is the one the developer already has. It also means the framework's scene graph is reflectively inspectable from inside the running program, which is what makes a scripting layer possible at all.

The cost is real. An interpreter is a large, security-sensitive dependency that has to track the language it implements, and the fork exists presumably because upstream was not keeping up with what the framework needed. Every language release the project wants to support becomes a merge into the fork.

The second fork is a TeX typesetting engine, pinned to a pseudo-version from mid-2026, and the repository has a text package alongside it. So the framework can typeset mathematics. That is a surprising thing to find in a graphics toolkit and it is a strong signal about who uses it: an application that renders a technical document and a chart in the same window, with correct maths, is a scientific computing tool, and the dependency list is full of other things that only make sense in that context.

The third fork is a web engine pinned to a commit from 2024, and the oldest of the three by a wide margin. Given the framework runs on the web, that one is load bearing for every browser deployment.

Three forks is three ongoing upstream merges. That is a real cost that a user inherits: the framework's maintenance burden includes three other projects, and any of them can become the reason a release is delayed.

One renderer for every platform, pinned to a pre-release

The claim at the top of the readme is that a single Go codebase runs on desktop three operating systems, two mobile platforms, and the web. Making that true is usually done by having several backends and a conditional build, and the interesting question is what this project did instead.

The dependency list answers it. There is a single graphics binding, for a browser graphics API, pinned to a pseudo-version from May 2026, and there is a dedicated graphics package in the repository. There is a windowing binding, pinned to a pre-release version, and it is the only windowing layer in the list. There is no separate native graphics abstraction, no OpenGL binding, no Direct3D binding, no Metal binding, no Android canvas, no native view toolkit for either mobile platform.

So the architecture is one renderer everywhere. That is a much bolder position than a multi-backend toolkit, and the reason it works is the same reason it is risky. A browser graphics API is implemented by the browser, and the same abstraction is now implemented on desktop and mobile by the platform vendor. Rather than writing three backends, this project writes one and depends on all six platforms having converged on it.

The risk is visible in the pins. The windowing binding is at a pre-release version, which means the framework depends on unreleased upstream code for its window creation on every desktop platform. The graphics binding is at a pseudo-version, which in Go convention means a specific commit rather than a tag. And the toolchain floor is not just a major version: the module manifest and the readme both name a specific patch release of Go, which is stricter than almost any project and means a contributor on a slightly older patch cannot build at all.

There is a second cost that the dependency list makes visible. The repository has a paint package, a vector graphics package, a styling package and a content package. A two-dimensional interface built on a three-dimensional graphics API is not free: every rounded corner, every shadow and every text baseline is a shader or a mesh rather than a platform drawing call. That is the correct choice if you want one codebase and pixel-identical output everywhere, and it is the wrong choice if you want the native look of each platform, which is the thing users usually notice first.

The documentation is a build of the framework

There is a sentence in the readme that is easy to skim and that is the strongest claim in the document: the documentation itself is an application built with this framework, running on the web through WebAssembly, with interactive examples that you can edit and run in place.

That is complete dogfooding, and it is more informative than a feature list. Every claim in the documentation is a claim the author has verified by shipping it. If the documentation shows a layout working, then the layout works in a WebAssembly build in a browser, which is the hardest target in the list. The examples being editable means the framework is not just capable of rendering a fixed scene, it is capable of compiling and running new code at runtime, which is a much stronger requirement and a much better test of the scene graph.

It also has a cost that nobody mentions in projects like this, which is that the documentation is now a build artefact. If the WebAssembly build breaks, the documentation goes with it, and the documentation is the only place the install instructions live. So a regression in the browser target does not degrade the docs, it removes them, and the people who most need them are the people trying to install the thing that broke.

That is a genuine circularity and it is worth naming before you rely on it. A reader who cannot build the project, or whose browser cannot run the WebAssembly module, is dependent on a page that is itself a WebAssembly module. The repository does contain a documentation directory, so there is likely static source underneath, but the readme points only at the website.

There is one more detail in that sentence that says something about the project. The tagline is a code once, run everywhere phrase, and the word is immediately parenthesised with the project's own name. That is a small piece of wordplay that only makes sense if the framework genuinely runs on all six platforms today, because otherwise the tagline is a roadmap and the joke would be embarrassing. Its presence is weak evidence that the claim is real, and it is the kind of evidence that is easy to include and impossible to verify from a readme.

No install command, and a toolchain floor that includes a patch number

The entire setup instruction in this readme is a sentence telling you to go to a web page and complete the installation instructions there before you can develop with the framework on your system.

There is no install command. There is no list of system packages. There is no note about which C compiler you need, or which windowing libraries have to be present, or which mobile toolchains have to be installed to build for a phone. All of that is on a website, and the website is a WebAssembly build of the framework.

Some of this is unavoidable. A framework that creates real windows on three desktop systems needs a C toolchain and the platform's development headers, and no amount of documentation changes that. A framework that targets two mobile platforms needs those platforms' build tools. A framework that targets the web needs a WebAssembly toolchain. The dependency list confirms the scale of it: there is a C binding for windowing, a binding for the graphics API, a font library with a Latin modern family, an audio library, a video dependency, image processing, and a text typesetting engine.

But the choice to put it all on a website rather than in the repository has a cost. A person evaluating the project from the readme learns nothing about what they will have to install. A person on a locked-down machine learns it at the worst possible moment. And a person whose browser cannot run the module, which is the failure mode described in the previous section, has no path forward at all.

The toolchain requirement deserves its own note because it is unusual. Both the readme and the module manifest name a specific patch release of Go as the minimum, rather than a language version. That is a stricter requirement than almost any project states, and it has a defensible reason: the framework uses features from the current language and probably recent standard library additions, and a patch floor is how you express that in the module system. The cost is that contributors and CI images have to be current to the patch, which for a project that already depends on a pre-release windowing binding is a coherent level of strictness rather than an accident.

One more small thing: there is a command line package and a command entry point in the repository, so the framework ships a tool as well as a library, and a project manifest file at the root describing it. That manifest is probably how the tool knows what to build, and it is worth looking at first if you want to understand the build without following the website.

The dependency list describes an application toolkit, not a widget library

Here is the honest way to categorise this project, and it is worth doing before you estimate the cost of adopting it.

The stated purpose is a framework for two and three dimensional applications. The dependency list is for an application toolkit. Both statements are true and the gap between them is where the surprises live.

There is an HTML rendering package in the repository, and the dependencies include a CSS parser, a second CSS implementation, an HTML tag stripper and a full HTML parser. There is a syntax highlighter. There is a markdown renderer. There is a text typesetting engine and a mathematics typesetter. There is a video package and an audio library. There is a file tree widget backed by an in-memory filesystem and a file system watching library. There is an undo package. There is a terminal environment library and a shell word splitter, which is what a built-in terminal or a command palette would need. There is a font family and a text shaping library. There is a keymap package and a cursor package and an icon format library for macOS.

There is also single sign-on. An OpenID Connect client and an OAuth library are direct dependencies of a desktop and mobile graphics framework, which is genuinely surprising until you notice what it implies: the framework has a concept of an account and an authenticated service, and can obtain a token. That is a hosted-application concern, and it is not in the feature description.

The pattern across the list is that these are not dependencies a widget library would have. A widget library needs a window, a renderer, fonts and events. This list needs a web engine, a content pipeline, a version manager, a scripting host, a typesetting system, a terminal, a file system abstraction and an identity provider.

The practical consequence is twofold. The dependency surface is large, and every one of them is a thing that can have a security advisory, so the framework's effective update cadence is the slowest of forty projects rather than its own. And the feature set is much broader than the description suggests, which is good news if you were worried it would be too small and a warning if you were expecting to understand it in an afternoon.

There is a good sign buried in the list as well. A test assertion library and a coverage badge. Whatever else this is, it is tested, and the coverage is published as a wiki page rather than kept private.

Editorial conclusion

Cogent Core is worth trying if you write Go and want a desktop, mobile and web application from one tree, and if you are the kind of person who is willing to be an early adopter of a framework that has never published a second release. It is a poor fit if you need version pinning, because there is one tag from 2024 and the default branch is the only addressable version, which means a security or regression fix is indistinguishable from an unrelated change in your dependency lock. Before you start, follow the installation page on the project website rather than the readme, because the native windowing dependencies are not described in the repository, and expect the build to be heavy, since the dependency list is large enough that three of its entries are forks the project carries itself.

Frequently asked questions

Official sources

1. cogentcore/core on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases