# Seaside gives Smalltalk callbacks instead of servlet handlers, and a page as a tree of components

> Seaside is an MIT licensed Smalltalk web framework that layers abstractions over HTTP and HTML, with programmatic HTML generation, callback based request handling, embedded stateful components, and a modal session model where a multi page workflow is one method with linear control flow. It suits a Smalltalk team that wants a rich interactive application rather than a template, and its Squeak port is documented as unmaintained.

**SeasideSt/Seaside** — The framework for developing sophisticated web applications in Smalltalk.

- Repository: https://github.com/SeasideSt/Seaside
- Stars: 564 · Forks: 80
- Language: Smalltalk
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/seasidest-seaside

## Four abstractions over HTTP and HTML, and why they exist

Seaside is described as the framework for developing sophisticated web applications in Smalltalk, and it provides a layered set of abstractions over HTTP and HTML that let you build highly interactive web applications quickly, reusably and maintainably.

The four abstractions in the documentation are each there to remove a specific kind of tedium, and each explains the problem it solves in the same way the framework documentation does.

Programmatic HTML generation addresses the fact that a lot of markup is boilerplate: the same patterns of lists, links, forms and tables show up on page after page. Seaside has a rich API for generating HTML that lets you abstract these patterns into convenient methods rather than pasting the same sequence of tags into templates every time.

Callback-based request handling asks why you should have to come up with a unique name for every link and form input on your page, only to extract them from the URL and request fields later. Seaside automates this by letting you associate blocks, not names, with inputs and links, so you can think about objects and methods instead of ids and strings.

Embedded components let you stop thinking a whole page at a time. Seaside lets you build your UI as a tree of individual, stateful component objects, each encapsulating a small part of a page, and these can be used over and over again within and between applications. The documentation gives the example that nearly every application needs a way to present a batched list of search results, or a table with sortable columns, and Seaside includes components for these out of the box.

Modal session management is the one that changes how you write a workflow. Seaside models an entire user session as a continuous piece of code with natural, linear control flow, so components can call and return to each other like subroutines. String a few of those calls together in a method and you have a workflow, and the back button still works.

## Loading the framework into a Pharo image

Seaside is composed of different parts, allowing you to only load the parts you need for your project, and the documentation advises new users to load the default set of packages by following the load instructions. There is a separate page listing groups and packages if you want to be selective.

The Pharo path goes through Metacello, and the latest stable version is loaded from the master branch of the repository.

```Smalltalk
Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:master/repository';
 load
```

A particular version is the same code with a tag in place of the branch, so the difference is one string.

```Smalltalk
Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:v3.4.5/repository';
 load
```

After the load, the Welcome package is present and a default server adaptor has been started on port 8080. Open a browser on http://localhost:8080 and you should see the Seaside Welcome page, and the documentation also points you at the Seaside Control Panel in the Library menu of the Pharo top toolbar, which is the development tooling for the running application.

That is a fast first run in the sense that matters: you get a server and a page to look at without writing a line of application code, so any problem you hit later is a problem with your application rather than with the framework install.

## Gemstone and VAST load the same baseline through different tools

The other Smalltalk platforms load the same Seaside3 baseline, but the tooling around it differs, and the differences are worth knowing before you pick a platform.

On Gemstone, the documentation starts with an upgrade step, because the deployment tool itself has to be current: you load GsUpgrader-Core from the vendor's site and upgrade Grease.

```Smalltalk
  Gofer new
    package: 'GsUpgrader-Core';
    url: 'http://ss3.gemtalksystems.com/ss/gsUpgrader';
    load.
  (Smalltalk at: #GsUpgrader) upgradeGrease.
```

Seaside itself is then deployed with GsDeployer, wrapping the same Metacello baseline.

```Smalltalk
  GsDeployer deploy: [
    Metacello new
      baseline: 'Seaside3';
      repository: 'github://SeasideSt/Seaside:master/repository';
      onLock: [:ex | ex honor];
      load ].
```

For a specific version you can also list the groups to load, with the example using Development, Examples and Zinc.

```Smalltalk
  GsDeployer deploy: [
    Metacello new
      baseline: 'Seaside3';
      repository: 'github://SeasideSt/Seaside:v3.2.0/repository';
      onLock: [:ex | ex honor];
      load: #('Development' 'Examples' 'Zinc') ].
```

That last argument is the group selection the load groups page describes, and on Gemstone it is how you keep a production image small.

VAST is different again, and the README calls it an official vendor supported framework, with a fork at the instantiations organisation. It installs through VAST's own feature loading tool GUI, or programmatically through the edition map.

```Smalltalk
(EmConfigurationMap editionsFor: 'z.ST: Server Smalltalk (SST) - Seaside')
 first loadWithRequiredMaps
```

Squeak is the outlier and the documentation is honest about it: Seaside for Squeak mostly works but is unmaintained, and the project asks for help keeping it running. For Squeak 5.2 and later you need Metacello first.

```Smalltalk
Installer ensureRecentMetacello.
```

For Squeak below 5.2 you install Metacello by its own older instructions and then follow the Pharo path. The Squeak port is the one platform where you are choosing an unsupported configuration, and it is worth knowing before you build on it.

## What the repository holds beyond the framework

The tree is typical of a mature Smalltalk project, where the distribution is loaded as code rather than installed as a package.

There is a .project file, a .smalltalk.ston file and a .filetree file, which are the Smalltalk world equivalents of a build manifest, a metadata file and a directory listing, and they are how the loading tooling finds the code. The repository/ directory holds the packages themselves, scripts/ holds the maintenance scripts, and tode/ is the TODO file.

There is also a gettext example directory, seaside-gettext-example/, which is a small demonstration of translating an application's strings, and a CONTRIBUTING.md, a LICENSE.md and a .github/ directory for the workflow.

The code of conduct and the contribution guide sit alongside the code rather than in a separate document, which is a small sign of the project's age and institutional maturity. Seaside is old enough to have been ported across four Smalltalk dialects, and the documentation reads like the project it is, a long lived one with an active community rather than a new framework.

The licensing is MIT, in the LICENSE.md file at the root, which for a framework meant to be embedded in commercial applications is about as permissive as it gets.

## The callback model is a real trade, not a free win

The obvious comparison for anyone arriving from another ecosystem is a template driven framework, where a page is a template with placeholders and the controller fills them in.

Seaside inverts that. The markup is code, the request handling is code, and the session is code. That buys you the component tree, where a page is assembled from stateful objects that each own a fragment of it, and the modal session, where a multi step workflow is a method with calls rather than a set of pages wired together with identifiers.

The cost is that your view layer is a program, not a template, and your request layer is a continuation rather than a request router. That is a better fit for an application with a lot of interaction, where the same component appears in several places and the workflow has branches. It is a worse fit for a team that wants designers to edit markup directly, or for a project where the pages are mostly static and the interesting logic is in a service layer anyway.

There is also the Smalltalk question underneath the framework question, which is the real adoption risk. Seaside is a large piece of Smalltalk that needs a Smalltalk toolchain, a Pharo image or a Gemstone deployment, and a team willing to work in a language ecosystem with a much smaller hiring pool than Python or JavaScript. The framework is not the hard part of that decision.

## The workflow model, and the back button that still works

The modal session is the part of Seaside that most often surprises people, so it is worth spelling out how it behaves.

The documentation asks what if you could express a complex, multi-page workflow in a single method, and contrasts it with servlet models which require a separate handler for each page or request. In Seaside, components call and return to each other like subroutines, and stringing a few of those calls together in a method gives you a workflow.

That is a genuine improvement over the alternative. A multi step checkout, a search with filters that can be refined, a wizard that branches, all become one method you can read top to bottom, instead of a set of handlers and a session dictionary full of keys you have to keep in step.

The part that gives most people pause is the back button, and the documentation's answer is that yes, the back button will still work. In a modal model, the browser is not navigating between pages in the classic sense, the session state is on the server, so the history stack is a server side thing. That is exactly why it is worth the mechanism: you get linear code and working history.

The embedded components are the other half of the same idea, and the documentation is concrete about their reuse: they can be used over and over again, within and between applications, and the framework ships components for the two cases almost every application needs, a batched list of search results and a table with sortable columns.

## Conclusion

Seaside fits a Smalltalk team building a highly interactive web application on Pharo or Gemstone, where the callback and component model removes the string identifier plumbing that a servlet or template framework pushes into the application. It does not fit a team that needs a framework with a maintained Squeak port, since the documentation says Seaside for Squeak mostly works but is unmaintained, and it does not fit a project that has decided to leave Smalltalk. Before adopting it, load the baseline in a Pharo image and confirm the Welcome page and the control panel work on your platform, and read the load groups list to load only the parts your project needs rather than the default package set.

## FAQ

### How do I install Seaside in Pharo?

Use Metacello with the Seaside3 baseline and the repository URL pointing at the master branch. After the load, the Welcome package is installed and a default server adaptor starts on port 8080, and you open http://localhost:8080 to see the Seaside Welcome page.

### Which Smalltalk platforms does Seaside run on?

The documentation gives instructions for Pharo, Gemstone, Squeak and the VAST Platform. It notes that Seaside is an official vendor supported framework on VAST, and that Seaside for Squeak mostly works but is unmaintained.

### What is modal session management in Seaside?

It models an entire user session as a continuous piece of code with linear control flow, so components call and return to each other like subroutines and a multi page workflow becomes one method. The documentation also states that the back button will still work.

### Can I install only part of Seaside?

Yes. Seaside is composed of different parts so you can load only what your project needs, and the documentation links a page listing the groups and packages. The default advice for newcomers is to load the default set of packages by following the load instructions.

## Sources

- [Issues](https://github.com/SeasideSt/Seaside/issues)
- [License: MIT](https://github.com/SeasideSt/Seaside/blob/master/LICENSE)
- [README](https://github.com/SeasideSt/Seaside/blob/master/README.md)
- [Releases](https://github.com/SeasideSt/Seaside/releases)
- [SeasideSt/Seaside on GitHub](https://github.com/SeasideSt/Seaside)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/seasidest-seaside