- runs a shop

- programmer 20+ years

 

 

- makes music / art / games

 

 

 

- <3's Ada, Dorian, Amanda

- eats his vegetables.

 

the-simian

( ↑ new track! ↑)

For decades, developers have heard the call of madness.....

Less surface area

Improved Velocity

Better DX

Higher Quality

"Full Stack Developers"

Bones of the past

Decades of trial and error...

But maybe?

Monorepos

Transpilation

ORMS

DSLs..

We can try... again...

A Product Owner Appears

Hey, I need a website

And uh, mobile app...

And I need a consistent style system

And I need it to integrate with other companies systems

Oh right, and there's gonna be like real time communication

And search.

 And there's more than on kind of user...

(Roar !!)

And be fassst!! (ROAR)!

And. AI.

And one small team will do it all.

Lots of AI. I think.

Creation Is An Act Of Sheer Will! 

This Time It'll Be Flawless!

We'll need the....

  • Mobile and Web
  • Access Control
  • Data Federation
  • RTC
  • Simple build and deploy
  • Durable: Tests / TypeSafe
  • High Platform Transposability
  • Performant
  • Documentation? (yes)
  • Please, not a monorepo.
  • Performant.
  • Design Consistency

Ok, lets break it down, what we both want...

is...

One Team. One Codebase.

 is for 

TypeScript

( Foundation )

Early Js

(late 90s)

  • For better or worse, I wrote the stuff...
  • Basically dead in 2025, but you still find fossils 

Coffescript

(2010s -2015)

  • extincted by es6
  • early attempt to unify syntax
  • no typing benefits

 

Dart

 

(2015)

  • Needs its own runtime or compile step
  • Lacks large traction outside Flutter, despite Google
  • Still around...

TS v1

(~2012)

  • Protoorganism
  • Widely rejected, misunderstood its compile target.
  • ES6 wasn't finalized, complexity was premature

Elm

(2012)

  • Purely functional approach is cool, but niche
  • Harder to integrate with standard js libs

TS v2-5

(2016-2025)

  • Widely adopted
  • Strong support
  • Still rolling out features

ReasonML

 

(2017-18)

  • compile chain feels very different from JS
  • Not enough critical-mass tooling and lib support outside Facebook ecosystem

  • ☠️ LiveScript [1995]
    Briefly the name for JavaScript before it was rebranded.
    Extinction: Quickly replaced by “JavaScript” in late 1995.

  • ☠️ Flash (ActionScript) [1996–2020]
    Powered interactive web animations and games.
    Extinction: Ended by Adobe in 2020; browsers dropped support.

  • ☠️ VBScript (for Web) [1996–~2010s]
    Microsoft’s scripting for Internet Explorer.
    Extinction: Never widely supported; died with IE’s decline.

  • ☠️ GWT (Google Web Toolkit) [2006–~2015]
    Compiled Java to JavaScript for enterprise apps.
    Extinction: Overshadowed by React/Angular.

  • ☠️ CoffeeScript [2009–2015]
    Influenced many ES6 features (e.g., arrow functions).
    Extinction: ES6 adoption replaced its core benefits.

  • 🧟 Dart (Early Versions) [2011–2018]
    Google’s “JS replacement,” now mainly for Flutter.
    "Un-deadness": Modern Dart thrives; the browser-replacement vision faded.

  • ☠️ PogoScript [2012–2015]
    Tiny compile-to-JS language.
    Extinction: Never gained traction; final commits years ago.

  • 🧟 TypeScript v1 [2012–2015]
    Early typed JS from Microsoft.
    "Un-deadness": Paved the way for today’s popular TS.

  • 🧟 ArnoldC [2014–Present?]
    Esoteric language using Arnold quotes as keywords.
    "Un-deadness": Pure novelty; still amuses devs occasionally.

Haxe

  • JavaScript
  • C++
  • C#
  • Java
  • Python
  • Lua
  • PHP
  • Neko (an older Haxe virtual machine)
  • SWF (Flash, supported historically, though Flash is now deprecated)
  • HashLink (a newer virtual machine target often called “HL”)
  • Technically does mobile bit OpenFL and NME

Clever, but....
Clever isn't always the most surviveable

  • Structure
    • (2016) Lerna
    • (2017) Yarn Workpaces
    • (2018-ish) Pnpm
    • (2021) Turborepo

 

  • Style
    • (2002) JS Lint (extinct)
    • (2011) Js Hint (same)
    • (2015) TS Lint
    • (2015) Standard 
    • (2020) Rome (Extinct already!)
    • (Doesn't Xist yet) Void(0)

 

Less Moving Parts

 

Offset Speed Cost of Transpilation

 

Plz, No Monorepos

 is for 

Bun

Biome

 and

Bun 1.2

  • 🔥 BLAZING SPEED 🔥 – Impressively fast runtime and server response times.
  • Node-Compatible – Near drop-in replacement for many Node.js projects.
  • Expo-Friendly – Works smoothly with React Native-based Expo apps.
  • Built-In Test Runner – No need for Jest or Mocha; reduces tooling complexity.
  • Static Server Option – Quick local previews without extra packages.
  • Native S3 Support – Direct AWS integrations for file uploads/storage.
  • Postgres Support – Built-in DB integrations if needed.
  • Dependency Updater – Automatically spots outdated packages.
  • Bun Patch – Replaces patch-package for library tweaks.
  • Solid TypeScript Integration – TS support out of the box.
  • Active Development – Rapidly evolving features and community momentum.

Biome

  • 🔥 BLAZING SPEED 🔥 – Rust-based tool that runs significantly faster than separate lint/format pipelines.
  • All-in-One Solution – Replaces ESLint, Prettier, and other code-quality tools in a single package.
  • Unified Config – Less overhead managing multiple configs for linting, formatting, and code checks.
  • Strong TypeScript Support – Built with modern TS workflows in mind.
  • Minimal Setup – No need to juggle separate plugin ecosystems; just install Biome.
  • Active Development – Rapid iteration, evolving to meet full-stack needs.
  • Even does CSS now.

〞

Our scientists have done things which nobody's ever done before...

– Next and Remix

(describing their routers and DX)

 is for 

Expo

( rowr ~! )

Expo 52

  • 🔥 BLAZING SPEED & NEW ARCHITECTURE 🔥 – Version 52 significantly reduces overhead, improving app performance and build times.
  • File-Based Router – Inspired by Next.js and Remix, making navigation and routing both easier and more familiar to web devs.
  • Expo Application Services (EAS) – Simplified builds and over-the-air updates for complex mobile projects, delivering great DX without the usual native headaches.
  • Unified Platform – Deploy iOS, Android, and web from one codebase—no need for separate monorepos.
  • Improved Configuration – Fewer weird JSON settings, more developer-friendly defaults.
  • Enhanced Community Support – Growing ecosystem of stable libraries, docs, and active maintainers.
  • Dev-First Experience – Hot reloading, easy asset handling, and robust CLI tools let you focus on features, not bundling or environment setup.
  • Better Dev tools
  • Easy to QA

〞

Our scientists have done things which nobody's ever done before...

– Tailwind and Shad CN Enjoyers

(describing their components and DX)

But why?

 is for 

Nativewind

React Native Reuseables

Create Expo Stack

React Native Reanimated

 is for 

Storybook

Hibernate

90s-2000s

Used Pojo objects; minimized direct SQL

Active Record

mid 00s

Convention over configuration

'Model' in MVC

.Net EF

05-08

It was basically Hibernate but worse. Also super XML heavy.

nHibernate

07-07

Like Hibernate. Used Pojo, heavily abstracted SQL. needed tools like nHibernate profiler to use effectively

Subsonic

07-2010

scaffolding/microorm

Focused more on scaffolding. all this is C#-land

"less abstraction"

Scaffol.io/Graphcool

2015ish

Extinct, and misguided approaches to a GQL based ORM

Prisma

2017

Rose from the ashes of Graphcool, a modern ORM, used DSL for defining Models, and transpilation to make a client

Listen. 

I need More *and less*

SQL

in the same way that

I need More *and less*

Dinosaurs

 is for 

Drizzle

(not you)

(thanks AI)

RAWR?

  • TypeScript-first: Ensures robust type safety.
  • Minimal Abstraction: Balances ORM benefits with direct SQL access.
  • SQL Escape Hatches: Flexibility for complex queries.
  • Zod Integration: Enhances data validation.
  • Simplified Migrations: Streamlines database updates.
  • Actively Developed: Regularly updated to meet modern needs.

 is for 

SST

( the second )

And. AI.

Lots of AI. I think.

We have....

  • Postgres
  • Graphql
  • Netlify
  • Blob Storage
  • Zoom

at home

(not you)

 is for 

Apollo

  • 📦 Normalized Caching: Automatically caches and updates query results to minimize server requests.
  • 🧠 Client-side State Management: Manages local and server data in one place using GraphQL.
  • 🛡️ Type-Safe Operations: Generates type-safe operations for TypeScript integration, enhancing code reliability.
  • 📋 Declarative Data Fetching: Fetch and update data directly in UI components declaratively.
  • 🚀 Subscriptions Support: Supports real-time updates via GraphQL subscriptions.
  • 🔄 Error and Loading States: Manages loading and error states automatically.
  • ⚙️ Extensible Architecture: Customizable with plugins for specific needs.
  • Ideal for mobile
    • Extremely Efficient fetching, caching
  • Great for integrations
    • Data federation
    • Type saftey
  • Not *remotely* hard to set up with SST
  • Security
    • Good if you follow best practices
    • Can enforce query complexity, rate limiting, etc...
    • Read their Auth/Security pages.
    • Enforce Access on the server....

Yes. GQL Still slaps in 2025. 

Makes Schema the 'rosetta stone' for types; truth

 is for 

Access Control

( the second )

import { Ability, AbilityBuilder } from '@casl/ability';

// define abilities
const { can, cannot, rules } = new AbilityBuilder();

can('read', ['Post', 'Comment']);
can('manage', 'Post', { author: 'me' });
can('create', 'Comment');

// check abilities
const ability = new Ability(rules);

ability.can('read', 'Post') // true

Putting it Together in a

A New Frontend Component

Putting it Together in a

Backend Feature

with RTC

Your app will run fast

Your build will run slow

Metro: it ain't Vite 😭

Direct communication between JavaScript and native code reduces latency and improves performance, making your app feel faster and more responsive.

You get to use React

You don't get every last new feature (yet)

  • vanguard of ui advancements
  • huge support network
  • lots of options for libraries
  • Still the 👑 in 2025.
  • NO RSC's (yet)
  • You're stuck using react 18 ( for now)
  • There's plans to adopt these things, but you'll get them second

"Spared No Expense! " 

"React! Our Lives Are In Your Hands, And You Have Butterfingers? " 

You get to use CSS


You don't get all of the CSS

  • Same theme, colors; cross platform!
  • Easily map existing web knowledge
  • real-and-actual tailwind, not just CSS in js.

"We have CSS at home  😿" 

  • CSS behavior diverges heavily from web at times
  • Mobile and web friction (pseudostates, cursor)
  • NO GRID. (oof)

"Just swap the <div>'s for <Views> Bruh" 

You can use React Compiler

(now!)

Its moderately cursed.

  web: {
    bundler: 'metro',
    output: 'single',
  },
  experiments: {
    typedRoutes: true,
    reactCompiler: true,
  },

(not the compiler's fault tho...)

still worth it?

Despite the tradeoffs, is the

(it depends)

You will accept a more challenging web dx for an improved mobile dx

You will enjoy a lower code surface area, in exchange for some build complexity

You will enjoy a more consistent, but more limited component model

You will get the flexibility of AWS, in exchange for less white-glove DX

You will get the utility of SQL and Postgres, but its a bit off-flavor

You will still get new features; but often in a spartan state initially.

Code 'compartmentalization' is harder; but we're not here for microservices

A smaller team can do more but the individual members need more experience.

You will accept more product QA-per-feature in exchange for cross-cutting velocity.

the-simian

info@simiancraft.com

the-simian.bsky.social

The Dream of a Single Codebase

By Jesse Harlin

The Dream of a Single Codebase

  • 187

More from Jesse Harlin