Halogen 7.1.0 for Type-Safe PureScript Interfaces

Why Halogen Targets PureScript UI Development

Halogen addresses the need to build stateful web interfaces while keeping application code in PureScript. Its intended users are developers who want types to constrain UI definitions and component communication, especially teams already using Spago and PureScript modules. The README describes Halogen as declarative: a developer writes views for application states, and the library determines which components need updating before rendering the interface.

The library offers two broad composition styles. Developers can create encapsulated components that manage their own state and combine them into a larger interface. Alternatively, one component can own the application structure and follow an Elm-like architecture. That choice matters because Halogen does not impose only one state distribution pattern. A small interface may use several local components, while a data-heavy application may keep its state and effects in a root component.

Halogen also includes its virtual DOM implementation in PureScript. This matters for teams that want the UI abstraction and renderer to fit the same language boundary as their business logic. The README compares Halogen's performance and bundle sizes roughly with React and Angular, but it does not publish the workloads, versions, measurement method, or numerical results behind that statement. That comparison is a project claim, not sufficient evidence for an application-specific performance decision.

Halogen's Component and Rendering Model

Halogen's central unit is a component that owns its state and can be composed with other components. Views are defined for states rather than assembled through imperative mutation. When state changes, Halogen can update the relevant components and re-render the interface. The repository's `examples/components`, `examples/components-inputs`, and `examples/components-multitype` directories indicate separate examples for basic composition, input handling, and components with different input types.

The example layout also exposes the library's broader integration surface. There are dedicated directories for effects with `Aff` and AJAX, lifecycle handling, routing through `driver-routing`, websocket control through `driver-websockets`, keyboard input, higher-order components, interpretation, memoization, and lazy components. These names come from the repository layout rather than from an asserted list of stable public APIs, but they show the concerns that the project expects application developers to address.

Halogen can support a single-component, Elm-like design or a tree of state-owning components. Neither style is free. Splitting state across components requires deliberate decisions about ownership and communication. Keeping too much state in one root component can simplify coordination but may produce a large component with many responsibilities. The README does not document a prescribed folder structure, rollback mechanism, or state-debugging workflow, so those architectural conventions must be established from the guides and examples rather than assumed from the installation.

Installing Halogen and Building the Basic Example

The README identifies Spago as the supported installation route for adding Halogen to a PureScript project. Run this in the project environment that already uses Spago:

spago install halogen

The repository also provides a `purescript-halogen-template`, which the README presents as the alternative for creating a new Halogen application. This distinction matters: `spago install halogen` adds the library to an existing project, while the template supplies a new application starting point.

For a first repository-based use, the `package.json` defines an `example-basic` script that bundles `Example.Basic.Main` to `dist/example.js`. From the repository root, the exact command is:

spago bundle -p example-basic --module Example.Basic.Main --outfile dist/example.js

That command is the first executable path documented by the repository's package configuration. The source application is under `examples/basic`, and the configured output path is `dist/example.js`. The README does not provide a browser launch command or describe what the example should display, so it would be inaccurate to promise a particular rendered result. Reviewing `examples/basic` before bundling gives the developer a concrete source file to trace from component definition to generated JavaScript.

For library-wide checks, the package configuration defines separate strict commands:

spago build -p halogen --strict
spago test -p halogen --strict

The first invokes a strict build for the `halogen` package. The second invokes its strict test command. These are repository maintenance commands rather than an end-user deployment recipe.

Effects, Inputs, Routing, and External Control

Halogen's repository includes examples for several boundaries commonly found in web applications. `effects-aff-ajax` addresses effects using `Aff` and AJAX. `driver-io` covers controlling external components, while `driver-websockets` represents websocket integration. These directories suggest that Halogen does not stop at static presentation: application logic can connect components to effects and external events.

The distinction between a pure view definition and an effectful event path is important. A declarative UI can still need to perform an asynchronous request, open communication with a server, or coordinate an external resource. Halogen provides examples for those cases, but the README does not explain their APIs, cancellation model, error representation, or lifecycle guarantees. Developers should therefore inspect the relevant example and the guide rather than infer runtime semantics from the directory names.

Input handling also receives dedicated treatment through `components-inputs` and `keyboard-input`. Higher-order components appear in `higher-order-components`, while `memoized-lazy` points to rendering and loading concerns. This makes the repository useful as a map of implementation patterns. It does not, however, establish that every pattern is appropriate for production. In particular, the README does not document server rendering, progressive enhancement, accessibility testing, localization, or automated browser coverage. Those are material omissions for teams evaluating a general web UI foundation.

Halogen's Constraints Compared With JavaScript UI Stacks

Halogen's most concrete constraint is its language and tooling boundary. The README states that Halogen and its virtual DOM implementation are written entirely in PureScript. This is attractive for a PureScript codebase because the UI library remains within the same typed language, but it also means developers cannot assume that a JavaScript component or package will be directly reusable. Interoperability may still be possible through JavaScript Foreign Function Interface mechanisms, but the README does not document Halogen-specific procedures for that integration.

The project offers a genuine alternative for teams choosing between Halogen and a component library centered on another ecosystem. Halogen instead keeps those definitions in PureScript and uses its own virtual DOM implementation. A team already standardized on React components cannot switch by changing only a dependency name; its component code, build assumptions, and ecosystem dependencies differ.

Halogen is also the wrong tool when its extra component abstraction is unnecessary for a small static page. Introducing typed state, effects, and component composition for a limited interface can add conceptual work without a clear benefit. Conversely, teams whose application logic is already PureScript may gain more from that shared type boundary than teams whose primary concern is access to a large JavaScript package collection. The README lists support channels and community resources, but it does not document a formal compatibility matrix for external components or a migration path from another UI library.

Release, License, and Maintenance Considerations for Halogen

Halogen is not archived, and the repository's last push was on 2026-10-11. Version `v7.1.0` was also released on 2026-10-11, while the preceding listed major release, `v7.0.0`, dates from 2022-05-02. The recent release means the project currently has a visible update after the earlier 7.0 release, but release frequency alone does not answer compatibility questions for an application.

The repository provides a major version changelog under `docs/changelog`, plus guide documentation under `docs/guide`. Those are the relevant files for checking behavior changes before moving from Halogen 6 to 7 or adopting `v7.1.0`. The README does not summarize individual migration changes, so an upgrade should not be treated as a drop-in package replacement until the changelog and strict build have been checked in the target project.

Halogen is licensed under Apache License 2.0. That identifies the project's declared license and provides a standardized permission and notice framework, including conditions around modification and distribution. The repository includes a `LICENSE` file. Teams still need to review that text and their own compliance obligations, especially for bundled dependencies, notices, and distribution. This is a licensing boundary, not legal advice.

The package configuration also defines formatting commands:

purs-tidy check src test examples

That command checks formatting across the source, test, and example directories. It is relevant for contributors, while application adopters are more likely to care about `spago build -p halogen --strict`, `spago test -p halogen --strict`, and the changelog during upgrades.

Editorial conclusion

Halogen is a sensible fit for PureScript teams that value typed component boundaries and can accept a PureScript-specific rendering model. It is a weaker choice for teams requiring a JavaScript-first ecosystem or expecting the README's broad comparison with React and Angular to substitute for application-specific measurements. Before adoption, verify `spago build -p halogen --strict` in the intended PureScript toolchain, inspect the `examples/basic` structure, and confirm that the team's preferred effects, routing, and integration patterns are covered.

Frequently asked questions

Official sources

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