Watched this old YouTube classic recently: Brian Will's Object-Oriented Programming is Bad.

And was recently looking through this codebase https://github.com/tinyplex/tinybase and realized there is not a single class keyword used.

Interested in people's thoughts/drawbacks on no-classes vs classes in general, and perhaps using the TinyBase's codebase as a basis for evaluating/reviewing the no-classes approach on a real-world project. Would this codebase be easier to read/document/visualize if classes were used.

I also included a short example of the different approaches:

Function variable version

main.ts

const store: Store = createStore('foo')
store.foo()

store.ts

import {createStore as createStoreDecl} from './store.d.ts'

// export function createStore(foo: string): Store { <- alternative form
export async const createStore: createStoreDecl = (foo: string): Store {
  const bar = 1
  await initStuff()
  function printFoo() {
    console.log(foo, bar)
  }
  return {
    foo() { printFoo() },
  }
}

store.d.ts

/** Some docs */ 
export async function createStore(foo: string): Store;

export interface Store {
  foo()
}

Function version with exports

This version extracts a pure function and exports it.

export function printFoo(foo, bar) { console.log(foo, bar) }

export async function createStore(foo: string): Store {
  const bar = 1
  await initStuff()
  return {
    foo() { printFoo(foo, bar) },
  }
}

// Potentially export private stuff in a private variable like so:
// export const private = {printFoo}

Class version

main.ts

const store: Store = new Store('foo')
await store.init()
store.foo()

store.ts

class Store {
  #foo: string
  static #bar = 1
  constructor(foo: string) { this.foo = foo; }
  async init() { await initStuff() }
  /** Some docs */
  foo() { this.#printFoo() }
  #printFoo() { 
    const Clazz = <typeof Store>this.constructor
    const bar = Clazz.bar
    console.log(this.foo, bar) 
  }
}

My thoughts on no-classes:

Pros

• Async constructors are nice.

• new keyword is awkward and doesn't chain well.

• Documentation/typing in a separate file doesn't clutter code. This is also possible for classes though.

Cons

• Typedef for function version must be separate to method definition. Can be positive and negative.

• Commas in object definitions are not as clean.

• Instance vars are not accessible ever. For example const foo can never be accessed, compared to #private in classes which I think you can do with reflection. There have been several times I wanted to read or monkey-patch one of these variables when desparately debugging some third-party library.

• Duplication of factory type definition when using const foo = createFoo() form and its messy needed to assign type to the variable and the function.

• Classes make it easier to see all fields and methods and their visibility (private, static, etc.)

• Functions declared in the factory body (i.e. printFoo) can name-clash with factory params.

• Harder to test private factory-scope functions.

• Inheritance is harder to document/visualize. In TinyBase they support custom Persisters via createCustomPersister, which could neatly be implemented using inheritance which would also allow automatic documentation. Would be interested to know pro/cons of this approach.

On the function version with exported functions:

Pros

Testable

The function's data dependencies are explicit in the params. In the previous example, it's not clear until examining the entire method, which fields it depends on.

Easier to extract out generic/reusable utility functions, which helps keep the custom business logic clear. We want as many pure functions (i.e. not touching shared state) as possible.

Tends to be closer to what my code looks like on my first-attempt, before refactoring to allow configuration and additional features. This makes it easy to understand.

A lot of this can still be done with classes though - you can always just create a function instead of a static.

Cons

Cannot enforce private visibility.

Can be verbose and repetitive having to write the same arguments and parameters for each call and definition.

Developer may end up passing in a "context" object as a single param to avoid the previous issue which ends up defeating the purpose, and we are back to potentially depending on all the fields in a class.