jeffhui.net

Datastar Basics

Thu, 19 Mar 2026 18:10:19 -0700

Datastar is an HTMX-like framework that attempts to minimize the amount of Javascript you write using a few concepts:

Use html attributes for dynamism prefixed with data-
Easy in-document updates similar to Turbo
Real-time updating via SSE
Signals for client-side state

If we compare it to other approaches, we can understand some of the tradeoffs:

Unlike React, signals are global to a page and are expected to have less state than a full SPA. Complex UI elements are recommended to be web components with Datastar.
Real-time updating via SSE for compression and automatic reconnects provided by the browser (instead of WebSockets which LiveView uses)
Unlike HTMX, it uses mostly just plain Javascript so you don’t have to include hyperscript, Alpinejs or another supplementary library for more complex logic.
HTML content is swapped via dom morph swaps instead of innerHTML replacement by default in an attempt to better preserve the DOM state.

Datastar is explicitly NOT a Single Page Application framework. Whenever something should be another page, it should be a separate server-rendered page. As a default, complexity should be pushed towards the server:

Algebraic Data Types: Product & Sum Types

Sun, 17 Aug 2025 13:22:03 -0700

ADTs is a fancy term for a type composed from other types. There are two kinds of Algebraic Data Types.

Product Types

Product types are structs and tuples, which contain a sequence of types.

Most programming languages have product types, so ADTs are often seen as shorthand for sum types, but that’s technically inaccurate.

Sum Types

Sum types are unions plus enums. They contain one of the specified underlying types:

Object Oriented Programming

Thu, 24 Jul 2025 01:51:17 -0700

Object Oriented Programming is really two different ideas: message-passing and compile-time hierarchies. The former informs modern distributed systems and the latter is the basis of popular modern programming architectures.

Problem	Small-talk / Message Passing Lineage	Modern / Compile-Time Lineage
Encourages everything to be solved with …	Message passing	Classes
Integrating two existing pieces of code	Proxy Objects, Dynamic Dispatch	Adapters
Extending code without modifying original code …	Delegation	Inheritance
Calling a method implementation is …	Asynchronous and knowable only at runtime	Synchronous and compile-time known
Iterating on Program Development by …	Updating one object at a time while preserving state, Limited type checking	Compile-time, Static type checking, Update full program by reseting state

While both are technically about objects, one focuses on using mechanisms of messages to solve problems, while the other focuses on using classes and inheritance to solve problems.

Event Sourcing

Sun, 06 Jul 2025 10:47:39 -0700

Event Sourcing departs from traditional state-centric data management. Instead of treating the current state of entities as the primary source of truth, Event Sourcing recognizes that the sequence of changes—the events—contains richer, more complete information about what actually happened in your system.

Consider the difference between a bank account balance and a bank statement. Traditional CRUD systems store the equivalent of just the current balance:

Account 12345 has $1,247.83.

Event Sourcing stores the complete statement:

Monads: Are they worth it?

Sat, 10 May 2025 12:59:43 -0700

Monads are interfaces for sequencing behaviors related to a data type.

Monads are similar to Unix pipes. They transform input and return the same output type. While pipes describe the function, Monads describe the data type flowing through pipes.

Let’s look at pseudocode defining a monad:

// Java: one of the best languages for defining interfaces...
interface Monad<M, T> {
 // Return is a class method: static isn't legal java
 static Monad<M, T> Return(value T)
 Monad<M, U> Bind<U>(f Function<T, U>) // f = func(T) -> U
}

We define the Monad as a generic interface. M is the data type implementing the monad interface and T is the input type for pipeline functions. M is the output value and T is the input type. In the simplest case, both can be the same type, like Text in Unix pipes.

Typescript Retrospective

Tue, 01 Oct 2024 20:37:50 -0700

As part of trying out Svelte, I’ve also stepped into the modern web development ecosystem. I previously worked primarily in Clojurescript, so my reference point is based on being away from conventional web dev for many years.

The Good Parts

Getting Started is Easy

Not having to build anything yourself can be nice if you want to deliver something quickly. This is doubly true when Svelte allows you to pull a library that doesn’t have explicit view framework support (eg - ReactJS). Need auth? Use AuthJS. Everything is so easy.

Svelte 5 for ReactJS Users

Mon, 23 Sep 2024 22:17:00 -0700

Disclaimer: I didn’t learn Svelte before v5, so this is an experience report on translating Svelte 4 code to 5.

This is a blind jump into Svelte.

The Basics

Svelte components end in .svelte like .jsx or .tsx. They look more HTML-like than JavaScript. In comparison, ReactJS is more JavaScript-like than HTML.

<script>
 let { name } = $props();
</script>

<h1>Hello, {name}!</h1>

Typescript

To use TypeScript, add lang=”ts” to the script tag:

Toml Crash Course

Thu, 19 Sep 2024 16:28:34 -0700

Background

Since migrating this site to Hugo, I felt like it was finally time to avoid learning TOML.

This assumes you don’t know TOML but know other data formats? Time to speedrun through.

The 30-second Start

You can think of toml as key value file format with namespace prefixes that translate to JSON:

# this is a comment
key = "value"

[my-key-prefix]
key2 = "value2"

person.name = "John"

Conceptually produces

{
 "key": "value",
 "my-key-prefix": {
 "key2": "value2"
 },
 "person": {
 "name": "John"
 }
}

Dot-notation indicates a nested object. In the spec, TOML calls objects tables.

check.statem: Generating Test Programs

Sun, 05 Jan 2020 00:00:00 +0000

One of the most interesting parts of generative testing (aka QuickCheck) is state machine testing. The original purpose I built Fox was to explore state machine testing. In particular, the talk from John Hughes video was inspirational to exploring this further:

In short, John makes a case: dynamically generating state machines to detect errors that is more effective and economical than traditional example based tests. There’s lots of work managing example based tests that can be better solved with generative testing.

Reading Code – Assertions & Assumptions

Wed, 31 Aug 2016 00:00:00 +0000

I’m fascinated by how engineers read and interpret code that they work on a daily basis. It’s no doubt different for everyone, but few explain how they go about and understand an unfamiliar codebase.

For me, being comfortable in a codebase usually means two things:

Being able to jump to relevant, related parts of the code.
Understand the implications of changing a piece of code
- Inside the system – impact of code quality. How does the code influence code in the same project?
- Outside the system – implications for human and program collaborators. How does the code influence other projects, teams, or users?

Both can be addressed by following the data flow of the code. I refer to my strategy as assertions and assumptions. Take this arbitrary code snippet from Django:

What's Your Engineering Culture?

Sun, 31 Jul 2016 00:00:00 +0000

When evaluating companies, it’s of utmost importance to learn about the engineering culture. Culture for a company is similar to scope for code – culture provides a context for getting work done.

Companies advertise their culture, but note that each company has a different culture. There’s plenty of articles about culture, so I won’t bother covering that. Just remember they aren’t necessarily the same. Companies tend not to be explicit about making sure their process matches what you expect. Be suspicious for a company that can’t explain its culture because that just means they’re not actively trying to cultivate one. And that means it’s implicitly defined by the leaders of the company. Even if they choose not to define it.

TLDR Programming Concepts

Thu, 30 Jun 2016 00:00:00 +0000

Trying to concisely describe concepts is an interesting exercise. The ideal goal is to build upon existing concepts, but as you add more concepts you run the risk of being inconsistent.

So with at most two sentences, I present a list of common programming concepts. This goes without saying that lossy compression is inevitable.

Data: Ones and zeros.
Values: Meaningful data.
Types / Encodings: Interpretations of values.
State: A value that changes over time. Usually also considered a Value.
Variables: Names for values over time.
Collections: A value that’s a group of values of same type.
Structs: A value that’s a group of values with possibly differing types.
Classes: Structs with functions that have itself as the first argument.
Inheritance: A concise way to implement a class by referring to part of its implementation from one class.
Multiple Inheritance: A class that inherits from multiple other classes.
Extensions: Adding methods to a previously defined type.
Mixins: Adding (Multiple) Inheritance to a previously defined type.
Interface / Protocols: Inheritance of a class that has only functions that should be implemented by the class that inherits it.
Traits: Interfaces that may have function implementations.
Generics: Treating a type as a variable. Allows algorithms independent of specific types.
Type Classes: Generic Interfaces.
Monad: An interface defining the expected behavior for map.
Functor: An interface defining the expected behavior for apply.
Pointers: A value that indicates where to find another value. A home address is a pointer to a home.
Big-O Notation: A method to estimate the number of main-memory operations
Slice: A value that is a pointer and length into an existing collection
Value Objects: A struct / class with equality and hashCode semantics.
Object-Oriented Programming: The concept of classes talking to each other using value objects.
Procedure: A sequence of operations to execute. Most programming languages mean procedure when they say function.
Function: Vaguely defined / blurred by current norms. See Procedure.
Pure Function: A procedure that returns the same output for the same inputs.
Side Effects: Any observable state that occurs besides a return value.
Functional Programming: The practice of using less state and more pure functions.
Code: A value that is a series of operations
AST (Abstract Syntax Tree): Hierarchy of typed code
Program: A collection of code that a computer that can execute.
Compiler: Program that takes code and produce programs.
Interpreter: A program that executes code without producing a program.
Emulator: A program that mimics the behavior of hardware.
Virtual Machine: A computer emulator where the hardware may not actually exist (eg - Java Virtual Machine).
Static: Known at compile-time.
Dynamic: Known at execution-time.
Type Checker: A program that validates what types flowing through your code.
Type Inference: A compiler or interpreter feature that can deduce types without always explicitly specifying it in code.
Optimization: Writing code for the computer first, instead of humans.
Performance: Turning memory operations for lower frequency, and higher throughput.
Reference Counting: Counting number of owners of a piece of memory to know when to free it.
Garbage Collection: An embedded program that frees another program’s memory that is no longer being used.
Reflection: Code that can inspect and/or modify itself as it’s executing.
Macros: An operation that can be translated to a sequence of operations before program execution.
JIT (Just-In-Time) Compilation: A feature of interpreters or emulators that compiles code during its execution.

The last concept pushes the limits of definitions this concise. Some interesting implications result from these definitions:

Two Kinds of Abstractions

Tue, 31 May 2016 00:00:00 +0000

When someone talks about abstractions, they’re usually trying to make the software more flexible. But that’s usually one of two kinds of abstractions.

Build an abstraction to hide an implementation

Abstractions that hide implementations are more commonly touted as good designs. Ruby’s Faraday abstracts the specific HTTP library implementation. Rails’ ActiveRecord abstracts the SQL you need to write to interface with a relational database. The Data Mapper Pattern abstracts the persistent storage from your application.

Design of Software Solutions

Sat, 30 Apr 2016 00:00:00 +0000

What’s the best way to model a solution? In software, there’s several common ways of building solutions that solve specific problems. It’s worth trying to identify their characteristics and the tradeoffs they make.

Architect the Software After the Current Problem

The easiest is way to model software. There’s no need to take into consideration of future solutions the user may want.

Sometimes this is what you need. If you’re writing a throw-away program, the fastest possible way to implement it is to codify for the exact problem you’re trying to solve. An example are most shell scripts. They tend to not be abstracted and usually automate a very specific task.

Editing Text (Basics)

Thu, 31 Mar 2016 00:00:00 +0000

Background

The problem seems simple: open, edit, and save text files. This can range from JSON files to source code like every other editor.

Turns out, this is a relatively difficult problem. The rise of javascript text editors surfaces the performance problem of editing large text. It’s a non-trivial problem. There are several desirable characteristics that editors want:

Editors need to optimize for edits. Having immediate feedback for changes is paramount to text editing. This includes editing large files.
Editors need to optimize for reads. This is implied for optimized edits so that users can see immediate feedback to their edit. This also includes support for large files.
Editors should minimize memory usage. Reduced overhead for storage of text leaves more memory for more text buffers. This is useful for developers editing multiple projects at once (eg - microservices).

Different data structures support these requirements in varying degrees of success. For the sake of this article, I’m ignoring many other features editors usually have:

Observation

Mon, 29 Feb 2016 00:00:00 +0000

The more you learn, the more this skill seems to be necessary. When missing a bug or a refactor opportunity, I wonder how did I miss this? Sure, everyone wants to learn from their mistakes. But noticing the little details gives you the opportunity to adapt. Massive function definitions start off looking like a common pattern for code that needs to be refactored. Those dozen one-letter variables names probably should be better named. Shadowing a variable is prone to introduce errors in the future. All those mental notes form from being able to observe it.

Modeling the Domain

Sun, 31 Jan 2016 00:00:00 +0000

Let’s mentally build an API for an e-commerce site. Let’s say we’re tasked with building the cart & checkout portion of the API. Building a RESTful API seems like the natural choice. At first, a Cart seems like any other model entity in the system. But what about a multi-page checkout step?

Allow partial updating of the Cart model (sounds like a job for PATCH). We need to preserve as much information as possible on the server to allow the user to pick up where they left off.
Each update needs to be validated against the current known state of the world. Store credit may not fully cover an order that has an upgraded shipping method specified later on.
The final cart has to be “committed” where final validations need to be performed before committed.
And finally, the committed cart requires taking to third party APIs all along the way (shipping, credit card processing, tax calculations) as well as at the commit point.

REST doesn’t provide an easy way to model this.

Daily Processes Check-In

Mon, 30 Nov 2015 00:00:00 +0000

Instead of sounding prescriptive, this article is much more descriptive.

I’m describing my regular workflows: what is working; what isn’t working. I’m documenting this for completely selfish reasons since it’s useful to track progression (if any). It happens to be a great inflection point since a recent illness has thrown me off my routine in the past week.

Like most people, there’s a need to regularly do:

Respond to messages (twitter, facebook, texts)
Respond to mail (physical, email)
Attend events (birthdays, social gatherings, meetups)
Capture ideas (they tend to come up in the most random places)
Living (rent, bills, taxes, laundry, cleaning)

All while (attempting) to achieve other goals:

Going Fast by Going Slow

Sat, 31 Oct 2015 00:00:00 +0000

People always ask about how did you learn this or work so quickly doing that? It’s a tough question to answer elegantly. And it’s a cop-out to vaguely say I spent my free time looking into that particular topic. It’s a socially-acceptable excuse.

But no doubt that this requires time. The time spent learning comes from somewhere, since we all only have 24 hours in a day for this. In our field, there’s always time you must dedicate to learning to keep up to date.

Process is King

Wed, 30 Sep 2015 00:00:00 +0000

There’s a process behind every result.

If you say, “we have no process, there’s no meetings”, then that’s your process. Admitting to no process simply indicates that you don’t have it formalized. A poorly defined process hurts. Processes enable efficiency and consistency. They can also act like a communication protocol among team members, teams, and organizations. Process can improve your quality.

Let’s think about how you deploy an application. What does that process look like? A poorly defined deployment process is inconsistent – something undesirable for a deployment. At minimum, a quick checklist works:

Communicating as an Engineer

Mon, 31 Aug 2015 00:00:00 +0000

As an engineer, one of the most valuable skills you can have is to communicate effectively. This applies both to your fellow engineers as well as non-engineers (PMs, designers, business). Obviously, this advice is generally applicable, but many engineers don’t craft their communication to the business well. Common problems are:

Talking too much about technical implementation.
Talking too little about technical implementation.

Too much technical implementation drowns out the important details that businesses are concerned about. It drags on discussions and meetings unnecessarily. Imagine if a designer talked for hours about how they picked the correct border radius value and color for their buttons in a meeting. That’s a waste of time for business stakeholders and engineers in that meeting. Getting far into the weeds like that quickly wastes discussions or meetings1.

Mental Schemas

Thu, 30 Jul 2015 00:00:00 +0000

It is difficult to always be improving in the software industry. In creative fields, many artists talk about churn. When starting out, there’s an enormous amount of work to produce to get better. If you’re new, there’s a massive amount of bad code you need to write. That’s OK, it’s necessary. But the rate of improvement decays as time progresses. As your notoriety grows, you can no longer just crank out code to get better, how can you preserve some rate of improvement? It feels like the rate of learning looks like this:

Software as Bridges

Mon, 29 Jun 2015 00:00:00 +0000

Software is always challenging to explain to non-engineers and having a metaphor is valuable to explain complex concepts. Bridges happen to be a good analogy to software. But the devil is always in the details.

Any piece of software provides a benefit to its users. It’s similar to people using bridges to cross rivers. As with bridges, many kinds of software can solve the same problems.

Some bridges support many cars and pedestrians which is analogous to a high-throughput like a server that can support many users. Others are very nice walkways with trees, a highly usable piece of software that supports only a few users. Most of the time, users only see the bridge from the top. Like seeing only the tip of an iceberg.

Seeking Simplicity

Sun, 03 May 2015 00:00:00 +0000

What is simple?

Rich Hickey makes a good abstract definition, but it can be difficult to translate to everyday code. I encourage you to watch that before returning to this. I’ll still be here.

Ok, let’s start at that definition. Hickey’s simplicity is the disentangling of concerns. It’s easy to convolute from what seems like straight-forward statement.

For example, a high-level example would be what domain-driven design proponents argue for. Separate solving your problem domain from the machinery that you use to solve it. Separate How from What or When.

Moving On

Wed, 15 Apr 2015 00:00:00 +0000

It’s a bittersweet end to a chapter. I’ve thoroughly enjoyed my time at Pivotal Labs. I met a lot of great friends. I paired and talked with geniuses and newcomers alike. And I’d recommend anyone with an opportunity to work at Labs to take it immediately.

I look back with great memories, shared turmoil, and personal growth. As an introvert, it was a boundary-expanded endeavor: pair programming every day. I learned the value of tests which is evident to most of the major open source work I’ve contributed to. I’ve sharpened my mind by the discussions I’ve had there.

Generative Testing

Sat, 31 Jan 2015 00:00:00 +0000

It’s no secret that I’ve been interested in testing. Most of the work I’ve done are around example-based testing. While useful, it’s interesting to look at other communities for inspiration. I’m specifically fascinated in the functional programming community. Generative testing in particular. It was popularized in the early 2000s by a famous implementation in Haskell, QuickCheck.

In short, generative testing allows you to specify properties your software should have. Then the testing library generates test cases. It’s an alternative path the functional community has taken when it comes to testing. This becomes evident since testing functional code becomes mostly boilerplate management:

Parsing JSON in Objective-C - Part 2

Sat, 08 Nov 2014 00:00:00 +0000

Note: This previously was on Pivotal Labs blog.

In the previous article, we used TDD to parse JSON into our Person model and refactored the code under test. In part 2, we’re going to refactor the code further to be more reusable and extendable. All the code in this article will also be in the same repository.

Redesign

The refactorings in the previous article were fairly straightforward and mechanical. Ultimately, we’ll need to break apart different concerns of this code. One approach would be to start with some questions:

Parsing JSON in Objective-C - Part 1

Fri, 24 Oct 2014 00:00:00 -0700

This post was originally written on the Pivotal Labs Blog.

JSON parsing is a frequent task for clients interfacing with any recent web API. Those web services frequently vary in quality:

Is the API following a RESTful design pattern?
Is it providing an object graph or just a single/collection of objects in the JSON response?
What are the data types of the fields being returned? Can they be relied upon?
How much work are clients duplicating to work around the server (e.g. - Performance, Business Logic, etc.)?

If you have full control of the resulting API endpoints, then it is easy to build or fix the API to your client’s specific needs. Controlling the incidental complexity can be challenging for APIs you do not control, or which have to support a variety of clients.

Reverse Engineering Objective-C

Sat, 26 Jul 2014 00:00:00 -0700

Languages that have dynamic introspection provide powerful meta-programming capabilities. This is generally done at runtime with additional memory used for storing metadata - such as types and method signatures. But they also provide the same power for people reverse engineering your code.

Let’s look at Objective-C, a simple code snippet:

@interface MyObject : NSObject
@end

@implementation MyObject {
 NSInteger _number;
}
- (void)doSomething
{
 _number++;
 NSLog(@"The %@", [self _doSomethingSpecial:_number]);
}
- (NSString *)_doSomethingSpecial:(NSInteger)number
{
 return [NSString stringWithFormat:@"Number: %d", number];
}
@end

Simple enough, but what if we don’t have the source? Let’s step back to how Objective-C works…

Adapting Binary Search

Fri, 25 Jul 2014 00:00:00 -0700

It’s great to use classic algorithms to solve problems at hand. Take this problem of ellipsis:

For a given text. Fit the maximum number of words that fits in the given size, append “… More” if there was truncation.

No, NSLineBreakModeTailTruncation will not work. We need different text.

The näive solution would simply to cut a word one-by-one until it fits with a custom ellipsis text:

@implementation NSString (CustomEllipsis)
- (NSString *)textThatFitsSize:(CGSize)size ellipsisText:(NSString *)text
{
 CGSize infiniteSize = CGSizeMake(size.width, INFINITY);
 CGSize fullSize = [text boundingRectWithSize:infiniteSize options:NSStringDrawingUsesFontLeading|NSStringDrawingUsesLineFragmentOrigin
 context:nil].size;

 // if text fits
 if (fullSize.height <= size.height) {
 return text;
 }

 NSString *finalString = nil;
 // if text doesn't fit
 NSMutableArray *words = [[text componentsSeparatedByString:@" "] mutableCopy];
 while (fullSize.height > size.height) {
 [words removeLastObject];
 finalString = [words componentsJoinByString:@" "];
 finalString = [finalString stringByAppendString:@"... MORE"];
 fullSize = [modifiedString boundingRectWithSize:infiniteSize options:NSStringDrawingUsesFontLeading|NSStringDrawingUsesLineFragmentOrigin context:nil].size;
 }
 return finalString;
}
@end

Run that in a table cell and you’ve got performance problems!

Evaluating New Techonologies

Thu, 24 Jul 2014 00:00:00 -0700

Every time you look at a new (or familiar) technology, you should ask: What are the tradeoffs?

It’s obvious to see the benefits of something - it’s generally advertised everywhere. Everyone is always shouting the pros of X.

“X does Y easier”
“X does Y faster”
“X integrates with Y”

Pros tend to flood the internet way more than cons:

X makes Z harder
X makes Z slower
X locks you into Y
X does Y, at the expense of Z

These are harder to find. Especially when the library is relatively new. But you can imagine based on how critical it is on your software stack.

Objective-C: Lazy Sequences

Mon, 07 Jul 2014 00:00:00 -0700

Lazy data structures are a powerful abstraction can increase the readability of your program while encouraging separation of concerns.

What are they? Simply put, they are data structures that “realize” what they contain when they’re needed (or right before they’re needed).

What can you do with lazy data structures? How about a page-scraper that paginates as needed:

# pseudocode
seed_url = "http://example.com/page/"
# generate a lazy list of urls:
# - http://example.com/page/1
# - http://example.com/page/2
# - etc.
urls = lazy {
 for (i = 0; i < 100; i++) {
 yield seed_url + string(i)
 }
}
# a lazy list of html pages
pages = map(urls, fetchURLPageContents)
# a lazy list of list of links
links_per_page = map(pages, extractLinksFromHTML)
# flatten to just a lazy list of links
links = join(links_per_page)
# do stuff with links
for link in links {
 record(link)
}

This creates a powerful abstraction that separates tasks your program needs to get done behind an implicit interface. The ending for loop doesn’t need to know that those links came from multiple page fetches or the file system. If the loop short-circuited, then it minimizes the number of unnecessary fetches.

Hi there, I'm Jeff!

Mon, 01 Jan 0001 00:00:00 +0000

I’m a software engineer passionate about software engineering - which is the never-ending challenge of balance of perfection and shipping.

In the past, I was a consultant working on iOS applications using the C-family of languages and Swift. Clients ranged from early stealth startups to Fortune 500 companies. In iOS, I’m probably best known for work on Nimble or Cedar or giving some talks in the early days of Swift. Although, I’ve personally learned the most while making Hydrant.

Resume

Mon, 01 Jan 0001 00:00:00 +0000

There’s also a PDF version of my resume. Engineers may be interested in my Github profile.

Goals

My professional goal is continuous growth and learning. This can be as broad as handling financial audits. Or as narrow as using a new technology. I revel in collaborating with my peers or other roles. Communicating is not just enunciating one’s intent, but to make sure terminology used by different professions are aligned.

Note: I’m not looking for a managerial role at this time. I want to refocus based on technical skills.