redbar0n

Local-First vs. Offline-First vs. Offline-Second vs. Online

The terms "offline-first" and "local-first" have become more established and distinct concepts in the developer community for referring to various classes of apps, since my original Reddit post in 2023 where I introduced the concept of "offline-second" to clear up some misclassifications. Since there is still frequent cross-talk (mixing of terms) on this topic, I've included the clearest current definitions here, sorted from their most-to-least requirement for internet/server access:

Online / Cloud apps (always requires internet/server access to be used). Most webapps.
Offline-Second apps (Cloud-First + Local Cache + Queued writes): The app is built assuming it will most frequently be used with an internet connection. Developers add caching layers (like Service Workers, IndexedDB, or local SQLite) after the core features are built so the app does not crash when the network drop

Portable Background Jobs in TS/JS

An idea I had, intended for JS fullstack/backend frameworks, worked out together with AI, and this FIRST DRAFT is stored here for future reference and discussion.

Our Use Case

We are building an application on serverless edge infrastructure (Cloudflare Workers, Durable Objects, SQLite, and Drizzle ORM), with a hard requirement that the codebase must remain portable to a self-hosted Node.js server (using SQLite or PostgreSQL) without rewriting application logic.

Like Solid Queue in Rails 8.1, our background job system needs to:

Some of my ecosystem contributions

Nov 2026 - I designed "Portable Background Jobs in TS/JS with Drizzle (as an ~80 line module)". Using my knowledge of serverless environments, SQL databases, distributed systems and message queues (Redis, Kafka, SQS, Upstash's QStash, etc.). https://gist.github.com/redbar0n/cac6b0cc420011e2b48ecba0896f4bdc

Oct 2026 - I helped design how the One.js framework handles searchParams. One is a framework that unifies React + React Native, so you can build crossplatform apps from a single codebase without code duplication or needing multiple frameworks (like Next + Expo).

A new front-end architecture for React apps, with simple decentralized stores and explicit rendering control.

This is an idea that I devised through working with AI through many revisions.

As an experiment (worked out together with Gemini AI), this should be a practical and very performant realization of the Functional Core, Imperative Shell (FCIS) architecture for a TypeScript front-end in React:

We avoid using most React hooks (aka. side-effects), such as useState, useReducer, useContext, useMemo / useCallback, and useEffect.
We let React be strictly and only responsible for the View layer (the Functional Core), and for the Imperative Shell we use decoupled Stores (aka. ModelControllers: state + logic) colocated alongside the view Components. Our API becomes a simple useStore (to wire it up, so we can use React's component tree for structure, and don't have to replicate it in

Functional Core, Imperative Shell (FCIS) architecture in a TypeScript/JavaScript backend

Intro to FCIS for those unfamiliar with it: https://www.youtube.com/watch?v=P1vES9AgfC4 FCIS favors using very simple and intuitive FP instead of OOP, and the architecture follows from that.

I worked with Grok AI through many revisions to devise how exactly a FCIS architecture could look in a TypeScript/JavaScript backend. It is similar to the Onion architecture, but more pure (no mocks), and doesn't have the interface boilerplate of Hexagonal (Ports & Adapters), while being more robust and testable (pure functions). This is the result of that work.

Here's a revised version where the functional core is kept completely pure — no Effect, no Task, no monads of any kind inside the core business logic. We still follow Functional Core / Imperative Shell, but the core now returns plain values + Either-like results (using simple discriminated unions).

How to get TypeScript as close as possible to a fully sound static type system?

Like in ReScript, PureScript, OCaml, Elm etc.

To get more sound type inference. To avoid type errors slipping through to production in spite of the type checking.

A sound type system guarantees that if a program passes type checking, it will not produce runtime type errors (no false negatives), ensuring reliability. It is one of the main benefits of using ReScript over TypeScript, which has a superior type system inference (due to it's OCaml roots).

-- Gemini's answer to my queries:

What if you could have vertically sliced MVC-widgets, that looked something like this?

Using React and XState.

//  A vertically sliced "MVC-widget"

//  VIEW:

export default function Users() {

Routing ideas for JS

A thread where we can discuss some crazy routing ideas a bit out in the open branching out from the previous discussion on filesystem routes over at: https://discord.com/channels/815937377888632913/1014946079965454366

For new JS frameworks, or custom setups.

So, first of all, it seems there is a close alignment between how vite-plugin-ssr and router5 handles routing:

vps: (view === 'overview') @ https://vite-plugin-ssr.com/layouts#nested-layouts
router5 (route === 'dashboard') @ https://youtu.be/hblXdstrAg0?t=197

	// The following is an example from the language Kitten, but generalizes to other languages.
	// It should be useful for language design and choosing naming conventions for variables and functions.

	// TL;DR: camelCase is most readable/discernable when used in context, as per this simple example extract:

	`n bottles-of-beer on-the-wall` // kebab-case
	`n bottles_of_beer on_the_wall` // snake_case
	`n bottlesOfBeer onTheWall` // camelCase

	// To more fully see the effect yourself, in context, do the following:

	// "Mutable borrows" is where the Rust ownership/borrowing model became too complex for it's own good...


	// A function that mutates a value, but does not return the value. So it only performs an effect, often called a side-effect.
	fn mutate_value(s: &mut String) {
	s.push_str(", world"); // we can mutate the borrowed value. In Rust, push_str returns the unit value, aka. void, so the function does not return the string.
	}

	fn main() {
	let mut hello = String::from("hello");