This is the conclusion of a transition that started more than a year ago, stemming from my frustration with TypeScript and the state of front-end frameworks. Gleam and Lustre were and still are a breath of fresh air and I am glad to have made the move.

This post will detail how those early motivations measure up in hindsight, and what it means (and feels) to maintain tens of thousands of lines of Gleam code.

You could do it too

Nestful is what I call “almost done” software. It’s not quite the completeness that are SQLite or Sublime Text, but is also not as ever-changing as something like Windows, a bastion of agile development these days. This positioning makes Nestful able to survive such a rewrite.

Nestful is valuable to users as is, and so they are more tolerant of features not being a part of every browser refresh. Some are happy with the low amount of jarring changes. Not every app has this luxury, with some pushed by their market segment to chase competition. Thankfully Nestful is a very opinionated tool in a niche without much innovation, so could easily afford the rewrite.

However, a rewrite is not the only avenue. Since Gleam is not a pure language, it’s very easy to interact with existing JavaScript or TypeScript code. New code and much-needed refactors could be done in Gleam with little to no hassle. In fact, this is how Nestful started, with Vue SFCs written in Gleam, and later with Lustre taking over state management while Vue kept on rendering.

You could do the same in your company, implementing carefully and incrementally, and enjoy the benefits described in the blog post for those new sections of code.

Of joy and trouble

Clearly, Nestful does change. “Almost done” is very different from “done”, with improvements added in a calculated manner. As of writing, the next planned big feature is showing items from third party services. This requires a non-trivial amount of architecture to then be able to arbitrarily add tasks from other services and have them bubble up next to one another for the user to compare priorities.

To do that, the code base needed to support changes maintainability-wise, but also the enjoyment of writing them. The thing is — those are intertwined. Yes, there is an aspect of enjoyment that stems solely from the writing, in isolation. But there’s also the mental load that comes from bad maintainability which kills that joy of coding.

In my original post about rewriting in Gleam, I mentioned some of the language specifics that were a joy — simple, exhaustiveness checks, pattern matching, friendly syntax. Those all turned out to be true. A stark contrast to TypeScript’s complexity, where one has to write two programs; one serving logic and the other types. All I wanted was to make sure there aren’t any null references.

Difficulties on the front end most often boil down to managing state. jQuery closures, Angular services, React and Vue hooks and stores and of course, the resurgence of back-end-centric solutions like Phoenix — those are all attempts trying to make sure incrementing a counter won’t turn on the user’s toaster.

Elm and its architecture almost entirely solved state issues like the aforementioned by getting state soundness in exchange for boilerplate. You write more defining your state model, the actions that can be performed on it, and the side effects they may incur and in return you get significantly fewer bugs and, most importantly, developer clarity of how state flows. That is a fine exchange. Boilerplate is much easier to live with than being ever-vigilant about state racing like it’s Daytona.

Along the years I’ve advised companies on how to replicate this architecture with TypeScript, solving issues like the that “spooky actions at a distance”, unpredictable reactivity, and unruly side effects. I’ve done it with Nestful. However, there was always this feeling of trying to fit a square peg in a round hole. It’s well worth the benefits, but could I have done better?

That’s where Lustre — Gleam’s implementation of The Elm Architecture — shines as the true star of the show.

Explicit state handling and not having to fight off reactivity made Nestful much faster. The architecture also avoids over-design by allowing the developer to easily compose and recompose state and its handlers, Gleam and Lustre do make refactors easy and clean, because in the end, it’s all just regular functions with strong type guarantees.

This all concludes to a single word: fun. Programming Gleam is fun, and I do not intend on going back to the old, cold days of TypeScript if I can help it.

Lessons Learned

The following is a short summary of some lessons learned along the way, in no particular order (except for that first one). I hope that they can be useful to you.

The AI Elephant in the Room

I know I’ll get a lot of replies saying how Gleam is too new for AI and therefore productivity is reduced compared to something like React. Well, I’ve been using Opus 4.5 for some of the rewrite and I can tell you two things:

1. It is much better at Gleam even compared to Sonnet 4.5 and Codex 5.2

2. LLMs are very knowledgeable idiots

Given their stupidity as their main weakness and their vast knowledge as their main strength, LLMs need very precise guidance and supervision to crank out what I’d consider acceptable code. In that context, having more knowledge about a specific framework or language results in diminishing returns, especially with tools like Claude Code or OpenCode which give the LLM more information.

Instead, it’s much preferable to guide the LLM to avoid its stupidity. The constraints that are inherent to Gleam and Lustre do that perfectly. Yes, the LLM might try to concatenate a conditional CSS class instead of using attribute.classes, or rename variables weirdly because it has PTSD from JavaScript name collisions. That is much easier to deal with than having it RNG an architecture like we’re playing The Sims.

Forget view hierarchy

This is more of an Elm architecture generality but is useful even if you don’t adopt a framework that follows it. Due to components holding state, React and Vue make it extremely easy to model your state hierarchy identically to your view hierarchy.

This is often not only counterproductive but downright harmful. State should be modeled completely separately from the view. Drawing state encapsulation lines that match view encapsulation will just mean you’ll be ever-busy trying to circumvent your own architecture as you discover state cross-requirements.

Design late

JavaScript and to some extent TypeScript are both landmine languages and therefore incur significant refactor cost, as refactoring doesn’t only mean avoiding pitfalls in the new code, but also breakage that is caused by removing the old code.

This is almost entirely absent in Gleam, which has your back. This makes the drawbacks of designing early — making incorrect assumptions about the future — more harmful than the logic inconsistencies that still can sneak into Gleam code, especially since it’s not pure.

Instead, just build really well for what you have now. The code will tell you when you need to change the design, which will be a mostly painless process.

Accept the boilerplate

Lustre requires you to commit to more boilerplate. It is a fact of its design. Fighting it by being “smart” will come back to bite you down the line.

Consider your FFI boundaries carefully

FFI is by far the most bug-prone area of the code. This is understandable. Be careful when writing it and its glue code to Gleam.

I hope that tooling in the future could detect type inconsistencies between TypeScript types and the types declared in Gleam for the external function.

Have fun

I may be repeating myself — well, I am repeating myself — but remember to have fun. Slight adjustments to the things you do can go a long way in making you enjoy them. Even if you don’t like Gleam or Lustre (how?!) — incorporate what you do like, even if in a small way. I haven’t done my research but I’d bet people who enjoy the work do it more productively.

What more do you need?

Most of you are already aware that the most common way to do this today is Conflict-free Replicated Data Types (CRDTs). As their name suggests, they are replicated data structures that can be combined, with algorithms guaranteeing that the data will eventually converge.

Nestful uses Yjs, a fast JavaScript CRDT. Yjs is truly a magnificent piece of software. Each user has its own Yjs Document where most data is stored. For local persistence that data is synced into IndexedDB, the in-browser database, using y-indexeddb, which is part of Yjs’ provider ecosystem.

Providers are pluggable pieces of code that hook into a Yjs document for added functionality. This is mostly in the form of sync to and from various places, from our local IndexedDB database to a middle ground in the form of y-websocket, to a full-blown solution like y-sweet.

Although I would have been glad to find a ready-made provider and integrate that into Nestful, things were not so easy. Commercial providers like y-sweet were in their infancy, so I didn’t even bother evaluating them. The most battle-tested solution was y-websocket, but that was just the communication layer. I would have had to write a non-negligible amount of backend code, which development (and maintenance) bandwidth did not allow for.

What do we do, then? To understand our options we need to figure out where Nestful was at the time, and what it is that we need to sync.

Nestful’s legacy

Historically Nestful was written as a generic, simple CRUD app using PostgreSQL via Supabase. I thought to myself – it’s a personal-use todo app, why would I need anything else? I’d say that for most todo apps that decision would have been correct (and it surely was correct at the time, for other reasons). The thing is, Nestful has two very important traits that change most of everything:

1. Nestful is offline-first, which now requires constructing a sync mechanism

2. Nestful uses a tree-structure which the traversal of can cause significant recursion

Don’t let anyone tell you otherwise – both are perfectly solvable and maintainable using PostgreSQL, even if they lend themselves better to something like a document-based CRDT.

Nestful’s other circumstances, including the way it was coded and my annoyance with my then local DB (a story for another time about how not to maintain FOSS) pushed me to switch.

So now we know that Nestful is hosted on Supabase, relying on its Auth and its Database, and most important of all – Nestful does not deploy any backend. This means that adding one will not only incur the complexity of the functionality we want to add, but of the expanded codebase, its deployment, and the server maintenance.

Doing that is all well and good, we are a software company after all, but let’s do better.

Update here, update there

That way sync works with Yjs (and most other CRDTs) is by using an update mechanism. Yjs allows the developer to obtain binary updates, representing a data diff, then send those over the wire. There are 3 main ways to do that:

1. Listen to changes

2. Diff against another version of the data

3. Get everything

Those updates can then be consumed in any order and they will converge to the same final state. Now that we know we want to sync updates, the questions are where do we save them and how will they get there.

Remember Nestful using Supabase? Well, Supabase has an S3 equivalent called Supabase Storage. The other side of the coin of provider lock-in is of course, blissful integration. After a minimal setting of permissions, end users would be able to push updates to Storage, and fetch updates that are already there.

Of course, just fetching all the updates all the time can be wasteful (and slow), so we’ll have to do some tweaking.

Almost converged

To not have the client download a humongous amount of files, which is as slow over these “serverless” platforms almost as how stupid the term “serverless” is, we could write a small “serverless” function to consolidate the updates for us.

That function will receive a date from the client, and will send over a single file.

When a client wants to get the latest data, he sends a date to the just-a-function-not-a-server. Upon receiving the combined update, the client diffs its own state against it, and uploads a diff directly to the just-object-storage-not-a-server.

This is called a full sync. At this point, the client and server are fully in sync. Any further update on the client is:

1. Uploaded directly to object storage

2. Broadcasted to peers using Supabase, to avoid a roundtrip

Using this scheme also has the added benefit of being able to restore data to a point in time, even if it was garbage collected by Yjs.

And that’s how Nestful syncs your data. This simple, client-dependent approach serves us well. It works, is stable, low maintenance, but… it’s slow. Nestful does not in fact require fast sync. It is not a real-time collaborative platform like other products using Yjs, and so sync can happen in the background, take a few seconds, and no one would notice.

But… we can’t settle for that, can we?

The future ahead

Even though it is fine for now (and for a long time from now) that a full sync is slow, we may need a bit more performance in the future. Although this may require getting an actual server and setting up an actual backend, the current design will stay mostly the same.

Since end-to-end encryption is planned for Nestful, the server will not be able to consolidate updates. Instead, a client will have to do that periodically and upload an encrypted checkpoint, which will serve as the new starting point for the next consolidation.

For this we’re going to need to cache both the metadata and data since the latest checkpoint for the update files in object storage to be able to quickly and efficiently serve whatever is needed, but that is for the future.

Check out the marvel of CRDT syncing by trying Nestful now, and also try Nestful itself while you’re at it.

Frequent readers will remember Nestful is written using Gleam and will probably wonder how we call Yjs from inside our lovely Gleam code. Here’s a YGleam link for you.

You may also be interested in our latest story about moving to an Elm-like state management.

Subscribe now

As much as you might have heard otherwise, the answer is an astounding yes. Those who fight on the hills pretending it’s all about the code are missing one very crucial point:

Frameworks shape the code you write.

To a certain extent, they define what’s possible, but more important than that – they set a path of least resistance. Yes, frameworks coming and going is one of the most frequent occurrences in nature, but that doesn’t mean it’s wasted effort to choose the right one or invest in it. The waste only appears when the frameworks are of the same kind, and introduce similar tradeoffs.

The clearest example of this is Elm. It’s not a coincidence that Elm manages state differently than how you’d normally do it in JS-land. Even Redux, which is an implementation of The Elm Architecture (also known as Model-View-Update), could not give the same streamlined experiences developers expect from Elm. Even if that experience is better than what’s otherwise available in the JavaScript ecosystem, you have to be fairly disciplined to keep it going.

Alas, there is only so much time in this world for us to try and fit a square into a peg. At this point some would fall back to the usual default: “Elm is great, but it’s too far from JavaScript. And there’s really nothing very different about all the JavaScript options, so I’ll just – ”

But wait. What if I told you there is another option? As robust as Elm, with a familiar syntax, and that you could learn in a day?

Grab yourself some tea, for this is the story of how adopting the Gleam language out of pure disdain for TypeScript led to much better state management for Nestful.

Before we delve into the details, let me bring you up to speed.

About a year since I started experimenting with Gleam, a delightful functional language that compiles to both Javascript and Erlang. I’ve decided to rewrite Nestful in Gleam to alleviate some of the terrible slog that is TypeScript.

The first major part was the introduction of Vleam, a set of tools that allows one to write Gleam inside Vue SFCs. Nestful is written with Vue and incremental adoption is a must when working on such a large-scale rewrite.

In November I launched OmniMessage, an experimental library for client-server communication. OmniMessage, you see, is an extension of Lustre (please bear with the buzzwords), Gleam’s Elm-inspired frontend framework. It allows one to define messages that are common to both the client and the server, thus streamlining communication.

Whether that’s a good idea or not, time will tell. What I do know is that Lustre was a breath of fresh air. But why? What is it about Lustre that’s missing from Redux (except for my strong, deep, unwavering dislike of React, that is)?

The answer is Gleam. Writing MVU-style apps in JavaScript is a bit like driving in a zigzag pattern — possible, but unless you’re 100% diligent, a crash is coming.

Luckily, I try to avoid premature optimization as much as possible and state management was no different. Nestful’s was simply done, by hooking up different kinds of Vue composables and utilizing Yjs’ event system. Some people may gasp at the lack of structure, but hindsight has revealed this to be a good decision. Much better than committing to what some would consider “proper” state management, spreading its tentacles into every corner of Nestful, making change a labor of desperation.

Instead, having a simple, unstructured system allowed it to be promptly removed when the learnings were sufficient and time had come to replace it.

After adopting Gleam for the language it is, Nestful could continue to enjoy its ecosystem, including Elm-inspired Lustre.

Why you should have some TEA

The Elm Architecture (TEA), also known as Model-View-Update (MVU), is a centralized form of state management made popular by —you guessed it —The Elm programming language.

As its alternative name suggests, it involves a centralized model that is sent for rendering to a view function, and is updated by an update function. If it sounds simple, that’s because it is. Here’s the state management diagram straight out of Elm’s docs:

Here’s the counter example from Lustre, Gleam’s frontend framework, which also implements TEA:

type Msg {

  Incr  

  Decr

}



fn update(model, msg) {

  case msg {

    Incr -> model + 1

    Decr -> model - 1

  }

}



fn view(model) {

  let count = int.to_string(model)

  div([], [

    button([on_click(Incr)], [text(" + ")]),

    p([], [text(count)]),

    button([on_click(Decr)], [text(" - ")])

  ])

}

That’s it, kids. For most web applications, you can pack Pinia and Zustand up, thank them for their service, and promptly show them out to the nearest commit.

You see, those popular solutions are popular for good reason. They are a low common denominator that, with all honesty, works quite well. The problem is they’re not as good as it gets. They break at the edges, if you will. A local maxima.

For Nestful, The Elm Architecture has the edge on them in three crucial places.

Preventing state-creep

State creep is the bane of my existence. When components are stateful, one of two things must happen:

1. You must hold constant, unwavering diligence, keeping local state local and global state global.

2. You despair as global and local states are inevitably mixed into a soup of misery.

I personally am not a fan of either constantly looking over my shoulder for the state boogeyman, nor of holding the mental model the size of the Tokyo rail system of how state flows through an application.

Instead, using TEA, I have a lovely, detailed map of all the paths data flows in. That map is an entire overview of the application, caging in the global state, only to be seen — never mutated.

A pure heart

Another great advantage of strictly enforcing TEA is that it makes it very easy to structure an application using “Functional Core, Imperative Shell”, a design pattern in which I/O is separated out to distinct parts at the start and end of a flow, while the center, the business logic processing that I/O, is kept pure. It always returns the same output for a given input, and does not involve side effects.

As it so happens, that is exactly how TEA pushes you to architect your state. Both the update and view functions are pure, and will return the same output for a given model and message.

Side effects are then handled by an effect system, which takes side-effect tasks returned by the update function and executes them out of the update function’s context.

This approach isolates the important bit of the application, the business logic, from the ever-changing, hardly testable, outside world.

Works great with Gleam

Gleam lends itself to this model quite significantly. Being a functional, type-safe language is a great usability gain for TEA, especially thanks to discriminate unions, who allow us to write the apps message type like this:

type Msg {

  Incr

  Decr

}

And the case statement, that allows for exhaustive matching on that message type:

fn update(model, msg) {

  case msg {

    Incr -> model + 1

    Decr -> model - 1

  }

}

Other implementations, like Redux, Dartea, or Vuex to some extent, while admirable, all fall short. After a developer has chosen a paradigm, tools need to not only enforce it, but encourage that paradigm. They need to not only make it the path of least resistance, but make the other paths hard in comparison.

A tool that requires diligence to keep going is failing at its job.

An added bonus from those three advantages is they make it extremely easy to refactor. They allow razing fields of old code to the ground, building skyscrapers above them, exchanging the fear of imminent crumble for the guarantees of type-safety and robust defaults.

But wait, isn’t Nestful a Vue app? How am I going to fit Gleam-written TEA into it? Am I going to have to settle for a TEA-like experience, similar to what I could conjure up using existing TypeScript solutions?

Incrementally adopting a frontend framework

So I’ve adopted Gleam and can now write it inside Vue files instead of TypeScript and look to use it to implement TEA and replace the current haphazardly-managed state.

To do that, two main tasks need to be completed:

1. Construct a runtime capable of executing the TEA state machine.

2. Somehow integrate that runtime into existing Gleam and TypeScript Vue components.

The first one already exists, it’s just Lustre (but without a view).

There are two ways of going about incorporating Lustre incrementally. The first is to carve out portions of Nestful and write those exclusively in Lustre. The second is to launch a Lustre app and render nothing, using just its state management capabilities.

Since the goal here is to have comprehensive state management, the second solution is more appealing, but a closer look will reveal that it’s actually the only solution possible.

Nestful, you see, is a giant item graph that’s traversed for specific views or actions. To enable offline-only capabilities, the entirety of the graph is stored on the client in the form of a single Yjs document, and if enabled, is synced on changes.

This means that not only is there very little local state to manage, the global nature of Nestful’s state will greatly benefit from collecting the static logic into a single, coherent, state machine. For Nestful, it makes much more sense to embed Vue in Lustre rather than Lustre in Vue.

// /src/compositions/useNestful.ts

import { computed, shallowRef, watch } from 'vue';

import { UseNestful } from '../nestful/compositions.gleam';

import { nestful } from '../nestful.gleam';



const modelRef = shallowRef();

const modelComputed = computed(() => modelRef.value);



const [initialModel, dispatch] = nestful((model) => {

  modelRef.value = model;

});



modelRef.value = initialModel;



export function useNestful() {

  return new UseNestful(modelComputed, dispatch);

}





// /src/nestful/compositions.gleampub type UseNestful {

  UseNestful(model: vue.Computed(Model), dispatch: fn(Msg) -> Nil)

}



@external(javascript, "/src/compositions/useNestful", "useNestful")

pub fn use_nestful() -> UseNestful

This is the glue code that allows Vue components, written either in Gleam or TypeScript, to read the model and dispatch messages. It is supported by helper functions in nestful.gleam to avoid having to import the different Gleam types into TypeScript.

Vue components are then treated as functions composing a Lustre app’s view function.

But there’s a catch.

The Elm Architecture’s centrally managed state trades off component composability to the point where Elm’s docs outright discourage them. While I don’t consider this blasphemy like some React folks may, I can see how different parts of an app lose on not being completely separate.

All things considered, it’s not an endemic issue similar to those I am trying to solve with the move to Gleam. That same page on the Elm docs discouraging components lists much more important things right before that that are benefits of TEA.

Which brings us to today.

A fun future

Except for two pending files, no global state is managed outside Lustre. State holding composables have been reduced significantly, and I hope to remove them completely in the following months.

The adoption of TEA has made Nestful faster, more maintainable and easier to develop features for. Most importantly, however, those advantages are now the path of least resistance in Nestful’s development cycle.

I hope that this transition will continue to bear fruit as time passes. By reducing the need for testing, by encouraging better design and architecture, and most importantly — by being fun.

This post was mostly about the technical benefits of Gleam and Lustre, but there’s also an emotional one — programming in them is a much, much, much more enjoyable experience than the TS alternative.

As we put our best foot forward in an attempt to increase value for our customers we sometimes forget about ourselves, and if we can — we can and should enjoy the process. Programming can and should be fun.

Subscribe and stay tuned for more unique takes on personal productivity and novel(-ish) web technologies.

OmniMessage is written in Gleam, a language that compiles to both Erlang and JavaScript, and is an extension of Lustre, Gleam’s major frontend framework.

To understand the benefits of OmniMessage and how it works, we first need we’ll first need explore how Gleam and Lustre provide one of the best developer experiences you can find for the web these days, and how building on top of them can improve that experience even more.

If you’re already familiar with The Elm Architecture and functional languages, you can click here to skip to the OmniMessage part, however going through the Lustre tutorial really puts the problem it solves in perspective.

A Functional C

Gleam’s website says:

Gleam powers the app this blog is for, Nestful. Which I am incrementally rewriting.

That other blog post already covers a lot of Gleam’s advantages and the specific considerations and tradeoffs as they pertain to Nestful. Those still apply, but when we look at frontend development in general, one key trait of Gleam is crucial:

Gleam is a functional language with a C-style syntax.

That is an indispensable advantage on the journey to ecosystem nirvana.

Here’s some for you to bask in. It is a very pleasant language:

We know that frontend developers like functional paradigms. TypeScript functional-like libraries continue to pop up, some developers really like React, and even when they dislike those, they still argue about it on AirBnB’s style guide repository.

Even with all the that functional engagement in mind, however you slice it, frontend development is all in JavaScript-land, and JavaScript has a C-style syntax.

In my opinion, this is a significant part of why previous attempts like Elm, Reason/ReScript and PureScript did not reach the success they should have. It is also why Flutter made such huge strides with frontend developers. Flutter’s developer experience is excellent, and Dart sure does feel a lot like TypeScript.

The fact that Gleam has that kind of syntax will help the most crucial part of going mainstream — ecosystem growth. It’s going to be nice to have a functional language that’s not only simple and type safe, but also has a large ecosystem.

Enter Lustre

If I had to describe Lustre with only a few words, I would say it is Gleam’s Elm and LiveView.

Yes, Elm and LiveView. While not a 1-to-1 match, Lustre is a Model-View-Update framework that can run both as a single-page application, like Elm, on the server like LiveView, and with OmniMessage — well, you’ll see.

I am not going to define Model-View-Update. Instead, I’m going to teach you some Lustre. By the time we’re done you’ll know exactly what it means.

We’ll start with a counter example, which is small and contained, then continue to build a (very, very minimal) chat app. Follow along with the code, it’s nice seeing how the different pieces fall into place.

First, let’s keep our data in a model, and have a function initializing it:

type Model {
  Model(count: Int)
}

fn init(initial_count: Int) -> Model {
  Model(int.max(0, initial_count))
}

A Model type that contains a single integer, which we initialize to a given value, but not lower than zero. Fairly simple.

Next, we’ll define messages that can operate on that model:

import gleam/int

import lustre/effect.{type Effect}

type Msg {
  Increment
  Decrement
}

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    Increment -> #(Model(model.count + 1), effect.none())
    Decrement -> #(Model(int.max(0, model.count - 1)), effect.none())
  }
}

Our update function returns a new count based on the message it receives, adding or substracting from the original. Don’t mind the effect.none() part for now — we’ll get to that later.

Finally, we’ll have a function for displaying a user interface. It’s important to note that all the view functions in this post use lustre_pipes, which is an extension of Lustre’s view utilities that I consider easier to read:

import lustre_pipes/attribute
import lustre_pipes/element.{type Element}
import lustre_pipes/element/html
import lustre_pipes/event

fn view(model: Model) -> Element(Msg) {
  let count = int.to_string(model.count)

  html.div()
  |> attribute.class("h-full w-full flex justify-center items-center")
  |> element.children([
    html.button()
      |> event.on_click(Decrement)
      |> element.text_content("-"),
    html.p()
      |> element.text_content(count),
    html.button()
      |> event.on_click(Increment)
      |> element.text_content("+"),
  ])
}

When we hand the init, update, and view functions to Lustre starts a runtime that:

1. Calls init with an initial value

2. Uses the resulting model to render a view

3. Listens to events and calls update with any dispatched messages, then back to #2

Model, view, update.

Because views are pure functions, meaning they do not perform any side-effects, they can be used anywhere. Every time we’ll hand the same model into that function, we’re going to get the same view. Every. Single Time.

This makes features like hydration very simple. Since this is a deterministic state machine, all we need is the current state. In Lustre, hydration means simply sending the model alongside the rendered HTML. Lustre will use that model to create a view of its own and compare it to the prerendered HTML. If they match, the app is “hydrated”.

But I digress. We’re here to talk about client-server state management, so let’s continue, building a small chat app.

A LiveView Single Page Application

Our app should be able to:

1. Send chat messages

2. Display chat messages and their status (sending, sent, received, etc)

3. Have a button that scrolls down to the latest chat message

4. Show the amount of active users in the chat room

We’re missing some key features such as receiving messages, chat room creation and user authentication. It doesn’t matter. Even this confined use case of a single room with a single user will show us the benefits of managing state with Lustre.

We’re going to build a single page application first, then use the fundamentals for the server as well. The conversion will be trivial.

First, our model:

// For date handling
import birl

pub type Model {
  Model(
    messages: List(ChatMessage),
    draft_content: String,
  )
}

pub type ChatMessage {
  ChatMessage(
    id: String,
    content: String,
    status: ChatMessageStatus,
    sent_at: birl.Time,
  )
}

pub type ChatMessageStatus {
  ClientError
  ServerError
  Sent
  Received
  Sending
}

Note that to avoid confusing chat messages and Lustre messages, the former will be strictly called a chat message.

We’ll initialize our model with an empty draft and empty chat messages.

fn init(_) -> #(Model, effect.Effect(Msg)) {
  #(Model([], draft_content: ""), effect.none())
}

Again, don’t worry about that effect.none() for now.

To define our Msg type, first let’s think through what we need to do. Lustre suggests using a SubjectVerbObject (SVO) structure:

1. UserUpdateDraftContent

2. UserSendChatMessage

3. UserScrollToLatest

4. ServerSentChatMessages

Number 4 is for getting back messages we sent to the server, not for other user’s messages, which is out of scope. This is more of a bring-your-own-refresh kind of app.

Having those messages written in SVO not only makes it easy to reason about how the app works, but also makes it easier to debug later, if and when needed.

Here is an update function that takes care of all the simple bits:

// For uuid generation
import gluid


pub type Msg {
  UserUpdateDraftContent(String)
  UserSendChatMessage
  UserScrollToLatest
  ServerSentChatMessages(List(ChatMessage))
}

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    UserUpdateDraftContent(draft_content) -> #(
      Model(..model, draft_content:),
      effect.none(),
    )
    UserSendChatMessage -> {
      let chat_msg =
        Message(
          id: gluid.guidv4() |> string.lowercase(),
          content: model.draft_message,
          status: shared.Sending,
          sent_at: birl.utc_now(),
        )

      let chat_msgs = [chat_msg, ..model.chat_msgs]

      #(Model(..model, chat_msgs:), effect.none())
    }
  }
}

How lovely is that case, which the Gleam compiler should mark as an error. Gleam makes sure case is exhaustive — it has our back in guaranteeing we address all of the different messages that the update function should be able to handle.

But wait! There’s a design problem. We need to clean the draft after sending it, but that doesn’t make sense to do in the UserSendChatMessage branch — chat messages can come from other places. A “scheduled messages” queue, for example. We need another message, UserSendDraft:

pub type Msg {
  UserSendDraft
  UserUpdateDraftContent(String)
  UserSendChatMessage(String)
  UserScrollToLatest
  ServerSentChatMessages(List(ChatMessage))
}

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    UserUpdateDraftContent(content) -> #(
      Model(..model, draft_content: content),
      effect.none(),
    )
    UserSendChatMessage(chat_msg) -> {
      let chat_msgs = [chat_msg, ..model.chat_msgs]

      #(Model(..model, chat_msgs:), effect.none())
    }
    UserSendDraft -> #(
      Model(..model, draft_content: ""),
      effect.from(fn(dispatch) {
        Message(
          id: gluid.guidv4() |> string.lowercase(),
          content: model.draft_content,
          status: shared.Sending,
          sent_at: birl.utc_now(),
        )
        |> UserSendChatMessage
        |> dispatch
      }),
    )
  }
}

UserSendDraft returns not only the model, but also something called an Effect.

An effect is a type that instructs Lustre’s runtime to perform tasks on our behalf. In this case we ask Lustre to dispatch UserSendChatMessage with the message, by returning that effect alongside our model. effect.none() simply tells Lustre that there’s nothing to do, which is the case for the rest of our case branches.

Side effects are a must in most apps, especially on the web. To be able to use them while keeping our update function pure (meaning, having the same output every time it receives the same input), MVU delegates their execution to the runtime. If we want a side effect to happen, we have to ask the runtime to perform it.

Now that we know effects exist, we’ll use them to implement UserScrollToLatest.

For that we need need a container to scroll. Enter, a view function:

fn status_string(status: ChatMessageStatus) {
  case status {
    ClientError -> "Client Error"
    ServerError -> "Server Error"
    Sent -> "Sent"
    Received -> "Received"
    Sending -> "Sending"
  }
}

fn chat_message_element(chat_msg: ChatMessage) {
  html.div()
  |> element.children([
    html.p()
    |> element.text_content(
      status_string(chat_msg.status) <> ": " <> chat_msg.content,
    ),
  ])
}

fn sort_chat_messages(chat_msgs: List(ChatMessage)) {
  use a, b <- list.sort(chat_msgs)
  birl.compare(a.sent_at, b.sent_at)
}

fn view(model: Model) -> element.Element(Msg) {
  let sorted_chat_msgs =
    model.chat_msgs
    |> sort_chat_messages

  html.div()
  |> attribute.class(
    "h-full flex flex-col justify-center items-center gap-y-5"
  )
  |> element.children([
    html.div()
      |> attribute.id("chat-msgs")
      |> attribute.class(
      "h-80 w-80 overflow-y-auto p-5 border border-gray-400 rounded-xl",
      )
      |> element.keyed({
        use chat_msg <- list.map(sorted_chat_msgs)
        #(chat_msg.id, chat_message_element(chat_msg))
      }),
    html.form()
      |> attribute.class("w-80 flex gap-x-4")
      |> event.on_submit(UserSendDraft)
      |> element.children([
        html.input()
          |> event.on_input(UserUpdateDraftContent)
          |> attribute.type_("text")
          |> attribute.value(model.draft_content)
          |> attribute.class(
            "flex-1 border border-gray-400 rounded-lg p-1.5")
          |> element.empty(),
        html.input()
          |> attribute.type_("submit")
          |> attribute.value("Send")
          |> attribute.class(
      "border border-gray-400 rounded-lg p-1.5 text-gray-700 font-bold",
          )
          |> element.empty(),
      ]),
  ])
}

Note how event handlers must return a Msg for our update function to handle.

event_onsubmit accepts a straight up Msg, so we just put UserSendDraft.

on_input accepts a function of the type fn(String) → Msg, which is exactly what UserUpdateDraftContent is. The following is identical:

|> event.on_input(fn(value: String) {
  UserUpdateDraftContent(value)
})

If you know HTML, the rest is fairly straightforward except for two parts: use and element.keyed.

use is syntactic sugar for a final-argument callback. Everything before the arrow is the callback’s arguments, lines below the use are the callback’s body.

This means these two are equivalent:

fn sort_chat_messages(chat_msgs: List(ChatMessage)) {
  use a, b <- list.sort(chat_msgs)
  birl.compare(a.sent_at, b.sent_at)
}

fn sort_chat_messages(chat_msgs: List(ChatMessage)) {
  chat_msgs
  |> list.sort(fn(a, b) {
    birl.compare(a.sent_at, b.sent_at)
  })
}

You know a language is simple when use is its most “complicated” part.

element.keyed creates an element whose children have a unique identifier (the key) attached to them such that when Lustre has to re-render the list itself, it knows which elements changed and which didn’t. This is similar to React’s or Vue’s key property and is done in Lustre by giving the element.keyed() function a list of tuples in the form of #(key, Element).

Now that we have our view, we can handle UserScrollToLatest:

# for handling possible errors
import gleam/result
# for interacting with the DOM
import plinth/browser/element as plinth_element

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    // other handlers omitted for brevity
    UserScrollToLatest -> #(model, scroll_to_latest_message())
  }
}

const msgs_container_id = "chat-msgs"

fn scroll_to_latest_message() {
  effect.from(fn(_dispatch) {
    let _ =
      document.get_element_by_id(msgs_container_id)
      |> result.then(fn(container) {
        plinth_element.scroll_height(container)
        |> plinth_element.set_scroll_top(container, _)
        Ok(Nil)
      })

    Nil
  })
}

This code uses plinth, an library to interact with browser APIs, to first find the container by its id (get_element_by_id), and if found (result.then), scroll.

By extracting this effect to a separate function, we can include it in other places, like automatically scrolling on UserSendChatMessage.

By now you should experience how Gleam and Lustre make for this very structured, harmonious development experience, where everything has a place in the render loop.

Now that we have the client side taken care of, let’s address the server. As you’ve probably guessed, talking to the server is a side effect, meaning we’ll instruct Lustre to make the talking on our behalf. Luckily there is a package that does just that:

import lustre_http as http

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    // other handlers omitted for brevity
    ClientMessage(shared.UserSendChatMessage(chat_msg)) -> {
      let chat_msgs = [chat_msg, ..model.chat_msgs]

      #(
        Model(..model, chat_msgs:),
        effect.batch([
          scroll_to_latest_message(),
          http.post(
            "/chat-message",
            [chat_msg] |> chat_msgs_to_json,
            http.expect_json(
              chat_msgs_from_json,
              ServerSentChatMessages,
            ),
          ),
        ]
      )
    }
  }
}

This takes care of creating the message on the server. We still update the model with the new chat message in Sending state, and we continue with effect.batch.

effect.batch takes several effects and combines them to a single one for our update function. The first one is our scroll effect that’ll happen after sending a message. The second will HTTP POST that message to the path /chat_message.

That effect is from the lustre_http library (that we import as http), that can create effects of HTTP requests. The arguments for creating the POST effect are:

1. The path to POST to, in our case /chat-message

2. The body of the post request, in our case a JSON.stringify-ed chat message

3. A description of the result, (JSON) and its handler (ServerSentChatMessages).

In a production chat app it would have been better to use websockets. The websocket effect works very similarly but requires more setup due to the nature of websockets. Since boilerplate does not add to our learning, we demonstrate using regular HTTP.

When Lustre will execute this effect, the following will happen:

1. It will post our encoded chat message to /chat-message

2. It will try parsing it as JSON using chat_msgs_from_json

3. On success, it will dispatch ServerSendChatMessages(Ok(messages))

4. On error, it will dispatch ServerSendChatMessages(Error(error))

Gleam, you see, has errors as values. That means that except for problematic FFI, functions never throw. You must deal with errors as they come or consciously defer their handling. This pairs fantastically with case’s exhaustiveness checks:

pub type Msg {
  // accepts a `Result` from `lustre_http`'s effect:
  ServerSentChatMessages(Result(List(ChatMessage), http.HttpError))
}

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    // Gleam will make sure both variants are present. Lovely.
    ServerSentChatMessage(Ok(List(ChatMessage)) -> todo
    ServerSentChatMessage(Error(error)) -> todo
  }
}

Again, we have a design problem. The server is the source of truth for chat messages, so we’d like it to override our local copies (that’s how a Sending chat message will become a Sent chat message). However doing that for a list can be quite costly.

Let’s change our state to hold chat messages in a dictionary, instead:

pub type Model {
  Model(
    messages: Dict(String, ChatMessage),
    draft_content: String,
  )
}

And implement ServerSendChatMessage:

fn update(model: Model, msg: Msg) -> #(Model, Effect(Msg)) {
  case msg {
    ServerSentChatMessage(Ok(server_chat_msgs)) -> {
      let chat_msgs =
        model.chat_msgs
        |> dict.merge(server_chat_msgs)

      #(Model(..model, chat_msgs:), effect.none())
    }
    ServerSentChatMessage(Error(error)) -> {
      // this is where you'd show, say, an error toast
      #(model, effect.none())
    }
    // changes to other branches available in the full code below
  }
}

As with any project, the more time we spend writing its code, the more we learn about it and about the solutions it demands. With MVU, those changes are easy to adapt to since the state mechanism stays the same. By keeping the state handling mechanism completely separate from our project’s design choices, we avoid having to change it when we inevitably discover we made poor ones.

To complete our server-communication portion for chat messages, let’s fetch on init:

fn init(_) -> #(Model, effect.Effect(Msg)) {
  #(
    Model(dict.new(), draft_content: ""),
    http.get(
      "/chat-message",
      http.expect_json(
        chat_msgs_from_json,
        ServerSentChatMessages,
      ),
    ),
  )
}

So far this should have been a relatively pleasant experience of writing a very regular app, with all the pros and cons that come with it. Our state handling approach forever puts us on alert, having to make sure our local copy of the chat is up to date with the server’s copy — the source of truth. This is a very common SPA issue.

I can hear the LiveView gang collectively yelling into the past as I’m typing. “Keep everything on the server”, they say. Well, we’re about to. — “and get rid of that REST mess!”. Ok, I heard you, we’re about to.

Our first step of evolution will be to implement our final missing feature:

Show the amount of active users in the chat room

I sneakily did not include a Msg for handling this when we built our update function. This information is strictly server-side, with no interaction, and most importantly — it is meaningless when we’re offline.

It’s a no-brainer to run it exclusively on the server. This is where the LiveView part of “Elm and LiveView” comes in. We can take this Lustre component:

type Model {
  Model(user_count: Option(Int))
}

fn init(count_listener: fn(fn(Int) -> Nil) -> Nil) {
  #(
    Model(None),
    effect.from(fn(dispatch) {
      listen(fn(new_count) { 
        dispatch(GotNewCount(new_count))
      })
    })
  )
}

type Msg {
  GotNewCount(Int)
}

fn update(model: Model, msg: Msg) {
  case msg {
    GotNewCount(new_count) -> #(Model(new_count), effect.none())
  }
}

fn view(model: Model) {
  let count_message =
    model.user_count
    |> option.map(int.to_string)
    |> option.unwrap("Getting user count...")

  html.p()
    |> element.text_content(count_message)
}

Run it on the server, serve it via websockets on /user-count, then add the following to our client’s view function:

server_component.component()
  |> server_component.route("/user-count")
  |> element.children([
    html.p()
      |> element.text_content("Getting user count...") 
  ])

Lustre will make it happen so that our user count will travel from the server into the client, accurately rendered. No need to sync state, everything comes from the source.

In my opinion, even after considering all the good that is Gleam, MVU, and Lustre’s implementation of it, this is the biggest advantage of them all.

Whenever you use HTMX or LiveView, there always comes a time when you need to “sprinkle some JavaScript”. While sprinkling some JavaScirpt is much better than writing everything in JavaScript, writing none is best.

This is the power of Gleam’s Lustre. You have all the advantages of a single page application, and of server side components. You pick the right approach, and use the same exact tool to fulfill it.

I hear you, HTMX people calling into the past: “make the chat messages server side too”. Nope. Not going to happen. At least not the way you think it will.

You see, the chat is meaningful even when the user is offline. Even if you make it online-only, there’s a problem moving the chat messages functionality to the server. How will we handle a chat message that was just sent? The server can’t render a Sending state because it’s still sending — it doesn’t know it exists!

“Sprinkle some JavaScript!”

Yes, the current solution is to have some mix of client and server side code, and do the syncing manually, just for that one bit.

Or is it?

Introducing OmniMessage

OmniMessage is a library created to answer this exact problem. It is composed of a Lustre extension on the client side, and server utilities (including another, optional, Lustre extension) on the server side.

After you set those two up a subset of messages, at your discretion, will dispatch in both the client and the server. You can think of this as a more blissful RPC.

Here’s the boilerplate:

import omnimessage_lustre as omniclient

// This just converts to/from JSON
let encoder_decoder =
  omniclient.EncoderDecoder(
    // this converts TO JSON
    fn(msg) {
      case msg {
        // Encode a certain subset of messages
        ClientMessage(message) -> Ok(shared.encode_client_message(message))
        // Return Error(Nil) for messages you don't want to send out
        _ -> Error(Nil)
      }
    },
    // this converts FROM JSON
    fn(encoded_msg) {
      shared.decode_server_message(encoded_msg)
      |> result.map(ServerMessage)
    },
  )

// This creates an extended Lustre component
omniclient.component(
  init,
  update,
  view,
  dict.new(),
  encoder_decoder,
  transports.http("http://localhost:8000/omni-http", option.None, dict.new()),
  TransportState,
)

The “biggest” chunk of work is encoding and decoding, but that’s something you need to do anyway. Even pure server components eventually need to save to a database.

If we setup OmniMessage like that, our original Lustre app could reuse all the client-side messages we wrote at the beginning of this post, and the server will reply and override our Sending chat messages when they are received.

Yes, yes, I know you want to see the code, but it really is the same. Here, look:

// MODEL ---------------------------------------------------------------

pub type Model {
  Model(chat_msgs: dict.Dict(String, ChatMessage), draft_content: String)
}

fn init(_initial_model: Option(Model)) -> #(Model, effect.Effect(Msg)) {
  #(Model(dict.new(), draft_content: ""), effect.none())
}

// UPDATE --------------------------------------------------------------

pub type Msg {
  UserSendDraft
  UserScrollToLatest
  UserUpdateDraftContent(String)
  ClientMessage(ClientMessage)
  ServerMessage(ServerMessage)
  TransportState(transports.TransportState(json.DecodeError))
}

fn update(model: Model, msg: Msg) -> #(Model, effect.Effect(Msg)) {
  case msg {
    // Good old UI
    UserUpdateDraftContent(content) -> #(
      Model(..model, draft_content: content),
      effect.none(),
    )
    UserSendDraft -> {
      #(
        Model(..model, draft_content: ""),
        effect.from(fn(dispatch) {
          shared.new_chat_msg(model.draft_content, shared.Sending)
          |> shared.UserSendChatMessage
          |> ClientMessage
          |> dispatch
        }),
      )
    }
    UserScrollToLatest -> #(model, scroll_to_latest_message())
    // Shared messages
    ClientMessage(shared.UserSendChatMessage(chat_msg)) -> {
      let chat_msgs =
        model.chat_msgs
        |> dict.insert(chat_msg.id, chat_msg)

      #(Model(..model, chat_msgs:), scroll_to_latest_message())
    }
    // The rest of the ClientMessages are exlusively handled by the server
    ClientMessage(_) -> {
      #(model, effect.none())
    }
    // Merge strategy
    ServerMessage(shared.ServerUpsertChatMessages(server_messages)) -> {
      let chat_msgs =
        model.chat_msgs
        // Omnimessage shines when you're OK with server being source of truth
        |> dict.merge(server_messages)

      #(Model(..model, chat_msgs:), effect.none())
    }
    // State handlers - use for initialization, debug, online/offline indicator
    TransportState(transports.TransportUp) -> {
      #(
        model,
        effect.from(fn(dispatch) {
          dispatch(ClientMessage(shared.FetchChatMessages))
        }),
      )
    }
    TransportState(transports.TransportDown(_, _)) -> {
      // Use this for debugging, online/offline indicator
      #(model, effect.none())
    }
    TransportState(transports.TransportError(_)) -> {
      // Use this for debugging, online/offline indicator
      #(model, effect.none())
    }
  }
}

See? Same logic. The only differences are that some types are wrapped so we could share them with the server, and instead of handling network errors directly we now handle them through a TransportState variant.

Other than that, you dispatch messages and the server replies as if it’s the same app.

You decide how to encode the messages, and what transport to send them through. As long as the server can understand those, you can use whatever server, in any language. Currently we have transports for HTTP and websockets, but any transport is possible. For example, you could write one to communicate with an Electron or Tauri backend.

Here are some examples utilizing omnimessage_server, meant for Gleam servers. Say you have this simple handler:

fn handle(ctx: Context, msg: Msg) -> Msg {
  case msg {
    ClientMessage(shared.UserSendMessage(message)) -> {
      ctx |> context.add_message(message)

      context.get_chat_messages(ctx)
      |> shared.ServerUpsertMessages
      |> ServerMessage
    }
    ClientMessage(shared.UserDeleteMessage(message_id)) -> {
      ctx |> context.delete_message(message_id)

      context.get_chat_messages(ctx)
      |> shared.ServerUpsertMessages
      |> ServerMessage
    }
    ClientMessage(shared.FetchMessages) -> {
      context.get_chat_messages(ctx)
      |> shared.ServerUpsertMessages
      |> ServerMessage
    }
    ServerMessage(_) | Noop -> Noop
  }
}

Here’s how you’d use it in a Gleam HTTP server:

use <- omniserver.wisp_http_middleware(
  req,
  "/omni-http",
  encoder_decoder(),
  handle(ctx, _),
)

Just give it the request, the path it should handle, the messages encoder/decoder and the handler from above, and it will:

1. Decode incoming messages

2. Run them through the handler

3. Encode the result

4. Generate an HTTP response with it

Need to send messages without the client initiating a request? Use websockets:

["omni-pipe-ws"], http.Get ->
  omniserver.mist_websocket_pipe(
    req,
    encoder_decoder(), // this is the same encoder_decoer
    handle(ctx, _), // the same message handler
    logger, // error handler
  )

Have a more complex app and you need structure? Use a Lustre server component!

["omni-app-ws"], http.Get ->
  omniserver.mist_websocket_application(
    req,
    chat.app(), // lustre server component
    ctx, // flags for its init
    logger // error handler
  )

This is how the server component will look like:

// MODEL ---------------------------------------------------------------
pub type Model {
  Model(messages: dict.Dict(String, shared.ChatMessage), ctx: Context)
}

fn init(ctx: Context) -> #(Model, effect.Effect(Msg)) {
  #(Model(messages: ctx |> context.get_chat_msgs, ctx:), effect.none())
}

// UPDATE --------------------------------------------------------------

pub type Msg {
  ClientMessage(ClientMessage)
  ServerMessage(ServerMessage)
}

pub fn update(model: Model, msg: Msg) {
  case msg {
    ClientMessage(shared.UserSendMessage(message)) -> #(
      model,
      effect.from(fn(dispatch) {
        model.ctx |> context.add_message(message)

        ctx
        |> context.get_chat_msgs
        |> shared.ServerUpsertMessages
        |> ServerMessage
        |> dispatch
      }),
    )
    ClientMessage(shared.UserDeleteMessage(message_id)) -> #(
      model,
      effect.from(fn(dispatch) {
        model.ctx |> context.delete_message(message_id)

        ctx
        |> context.get_chat_msgs
        |> shared.ServerUpsertMessages
        |> ServerMessage
        |> dispatch
      }),
    )
    ClientMessage(shared.FetchMessages) -> #(
      model,
      effect.from(fn(dispatch) {
        get_messages(model.ctx)
        |> shared.ServerUpsertMessages
        |> ServerMessage
        |> dispatch
      }),
    )
    ServerMessage(shared.ServerUpsertMessages(messages)) -> #(
      Model(..model, messages:),
      effect.none(),
    )
  }
}

It’s like having the same app spread across two different files.

OmniMessage is still very young and is missing some important features, but the vision is clear — it is the last piece in the trifecta that is zen state management:

1. Client state — solved by MVU

2. Server state — solved by server components/LiveView approach

3. Hybrid state — solved by OmniState

The hybrid state OmniMessage represents is a very sharp sword that can be tricky to wield without a clear separation of concerns. This is why OmniMessage shines when a single party is the source of truth, since we can simply override the other party’s state every time a message arrives. This gives us all the benefits of OmniMessage without the beehive hornets nest that is carefully merging state.1

This is why Lustre is the end game of frontend development. It collected all of the right solutions and wrapped them up in the nicest, gleamy package.

Full, working, code is available in the OmniMessage repository.

Here is the OmniMessage documentation:

https://hex.pm/packages/omnimessage_server

https://hex.pm/packages/omnimessage_lustre

And don’t forget to check out Nestful! Not only is Nestful written in Gleam (the new “written in Rust”), but it actually has novel ways to manage your time:

https://nestful.app

Share

This post tells the story of why I wanted to leave TypeScript behind, and why I chose Gleam to replace it.

A Need Rises

Nestful is a list-taking app with the promise to consolidate all of the different things competing for its users’ time. Those things (work, chores, musings, etc) would usually be stored in siloes —GitHub for personal projects, Trello for house chores, notes on life in a notes app, and so on. That’s great for prioritizing within a project, but how do you prioritize the projects themselves?

Nestful was born to solve this problem for me. The premise is simple: Nestful is a list of items, and items can be inside other items. That way I could have a list of my projects, prioritize them, and when it’s time to prioritize the project itself, I click the project’s item and inside there’s its own specific items, relating to its completion.

These were my main requirements from Nestful:

1. Work completely offline, with composable sync (more on that later)

2. Fast iteration so I could dogfood it quickly

3. Work on all my devices

Web it was.

I chose Vue + TypeScript because I was the most fluent with it, but it could easily have been any other client-side web technology and this post would have stayed mostly the same.

TypeScript Frustrations

As with every clean-slate project, the beginning was a breeze. I got started relatively quickly, but as I progressed and Nestful grew, problems started popping up.

A Language Within a Language

The types part of TypeScript is a language in and of itself. First you program the actual business logic, then you have to spend 10% of the time that took to wrangle types to be correct. The worst part of it?

When you’re done, you still don’t have confidence that it’s correct.

I did not delve deep enough into the typing system of TypeScript to know if it’s psychological. Maybe it is mathematically proven that once TypeScript compiles without any `any`s, it’s safe.

Maybe. I don’t care.

The way I see it, a language has to justify a learning curve. Learning to navigate Rust’s convoluted (at times) syntax is rewarded by very impressive compile time guarantees.

What does TypeScript give you that is worth the time it demands, in learning and maintenance?

Inherited Difficulties

Those problems with TypeScript are inherited and compounded when using a library. I used to spend 2-3 days when upgrading the client-side database I used at the time because for some reason, may it be TypeScript itself or the library’s author investment, the type system did not supply enough guarantees.

This is compounded when there’s a bug in a 3rd party library, or that I need to understand the inner-workings of one. I have become fairly adept in understanding other people’s code, especially in TypeScript, yet it is still more intensive of a task compared to a nicer, simple language like Gleam.

Error Handling

After Rust exposed me to the concept of errors as values, I could not go back. It was so much more ergonomic and resulted in such a better end product that I started sorely missing it. Although this is a Javascript problem first and foremost, its supersets can solve it, and some did try.

There are several attempts to make “Functional TypeScript”, but I did not like them. First, there was no nice solution to handle those returned errors, with the glaring lack of pattern matching. More than that, though — eventually, when the kitchen sink is full enough, the tools are too suffocated to be useful.

TypeScript is No Fun

Anything I do should be as enjoyable as possible, and when it comes down to it, TypeScript is just not fun.

Some things are just destined to suck, like the recent clearing up of a clogged sewer at the house. Programming Nestful is not one of them.

This is also important to its success as an application — as Nestful grew and will grow, refactors were and will be needed. Every TypeScript refactor resulted in more bugs. Gleam refactors resulted in less. More on that below.

“Compiled to WASM”

I am a relatively thorough person. As I got more frustrated with the stack I had, I began going one by one over the possible alternatives. There’s a lovely repository on GitHub tracking languages that compile to WebAssembly, so I started looking at each, one by one.

They all had one problem in common, though. Although WASM runs in the browser, it will demand a practically complete rewrite of Nestful, due to interoperability issues that will inevitably arise.

The solution is then to strictly compile to JavaScript.

I can’t remember which list I looked at at the time (maybe the one on the CoffeScript wiki?), but in the end I have narrowed it down to:

• Dart

• F#

• OCaml

Dart was easy to pass on, even though it’s one I already knew, and on paper — the most fitting replacement — especially when adding a lot of the functional-style features I was looking for. However, it suffers from the crowded kitchen sink problem, and… Google makes it. I like using Flutter a fair bit, but I would rather split my eggs over multiple baskets, thank you very much.

F# and OCaml were pretty close. F# looked more approachable to me, but the ecosystem was fairly slow going, and I don’t paticularly enjoy working with Microsoft tools. OCaml seems to be back on track, and used in some major production codebases, but the syntax was not as familiar to me, and I got mixed signals about the rejuvenation they claim they have.

I have a soft-rule that says that in every new project I start, I must learn something new to the extent my bandwidth allows. Even though I decided not to go with either F# or OCaml this time, I’ll be happy if they turn out to be a good fit in a future project.

Then Gleam hit 1.0, which I discovered when YouTube recommended me a Primeagen video. Before, I probably skimmed over Gleam and passed for it being too young. Having it reach stability with the community momentum to compensate for being young relaxed my ecosystem worries (a little), and I took it for a spin.

Star of the Show

Gleam has quickly turned out to be an excellent choice made at the right time. It streamlined my development even though I had to write a lot of (FFI) boilerplate to get going.

As Simple as it Gets

Gleam has a simple-language philosophy. This means that the language itself is fairly small and contained (there’s no `if`!), which in turn makes it very easy to learn, and most importantly, extremely easy to understand 3rd party code.

Even with a language this young and some things that are not fully ready, I had a much better time than doing the same task with TypeScript.

Easy Refactor

As Nestful grows refactors are going to be needed. “Composable sync”, mentioned in the requirements, is an example of that.

If Nestful promises to be a place that hosts all the different things competing for my time, it better do that for things that need more than a list to be managed. Some projects do need the likes of Linear or GitHub, and I would like to be able to pull items from there and transparently display them to the user to be prioritized. They don’t need all of GitHub’s features to prioritize between fixing bug #233 and putting the car in the garage. When they actually reach fixing that bug they can click the item and Nestful will lead them right to GitHub.

The data layer is abstracted enough to achieve this, but you don’t really know what you need until you need it, especially if you avoid premature optimization like I do.

I am confident with Gleam having my back when it’s time to modify the data layer, helping me refactor correctly, even when it’s tricky. For example, Nestful has a feature that “bubbles up” items. It’s currently only used to show use deeply-nested due items in a single view (to prioritize between "bug #233 somewhere inside a project and “Put car in garage” somewhere inside house chores). Expanding this to more use cases is not trivial, and Gleam is here to help.

Fluffy and Cozy

Gleam is fun to write in. It’s a calming language if there ever was one. It’s soft to read and write (you’ll get it when you try it) and is overall a relaxing experience. That’s mostly thanks to its syntax choices.

Beyond that, it supplies the usual functional/immutable features you’d expect from a first release of such a language. Namely, to my liking, no nulls, errors as values, and pattern matching.

Enter Vleam

The cherry on the top is that I could adopt Gleam incrementally. I could add it piece by piece, replacing the TypeScript in my services, composables, and components. For that last one to be easy, I wrote Vleam.

Vleam is a set of tools (Vite plugin, Vue FFI, and LSP) that allows the usage of Gleam in Vue single-file components with full LSP and hot-reload support. Give it a try if you’re looking for a change and running Vue yourself. Easily done one component at a time.

Not Perfect Yet, But Overall Right

Gleam doesn’t have everything nailed quite yet. Some LSP features are sorely lacking (it’s rename for me), and the language could use a bit of introspection and reflection so I could avoid a neverending unwrapping of types and the chore of serialization.

Even with those rough spots, though, Gleam is still a great choice. It’s a breath of fresh air over the chore that is TypeScript, and is making big strides with every release.

Next, I’ll give it a shot on the backend.