vanilla

A collection of different ways of structuring vanilla JavaScript components.

Features common to of all flavors

• Isomorphic. Works on both the server (Node.js) and in the browser’s main thread.
• Observable. Provides a way to listen to state changes.
• Immutable state. The state is never mutated in place, which makes the components compatible with other paradigms that depend on immutability (such as optimized React components).

Flavors

Flavor 1 – inspired by @eirikbacker

Pros	Cons
• Few lines of code. One function handles “everything” – initialization, state management, and DOM patching – resulting in little code. • Few abstractions. • Close to the DOM.	• Magic. One function that does “everything” complicates things and is hard to reason about. • Requires use of expandos. Since WeakMap is not available in IE9.

Flavor 2 – inspired by Elm, React and Redux

Pros	Cons
—	—

Flavor 3 – inspired by React’s Component class

Pros	Cons
• Familiar when used to React.	• Requires being aware of method bindings. Using the this keyword can cause problems when combined with functional paradigms. • Inheritance. Can cause unexpected behavior, and requires being familiar with base classes.

Flavor 4 – inspired by MVC

Pros	Cons
• Familiar and well-discussed.	• Old and unattractive. Hard to bring on new developers who want to try shinier things. • Open to interpretation. Developers interpret MVC in many different ways, leading to inconsistencies and “spaghetti” code. • Many abstractions.

Flavor 5 – using functional reactive programming

Pros	Cons
• Expressive. Declarative state management makes asynchronous dataflows easier to reason about. • Fully reactive. • Relatively few lines of code.	• Learning curve. Functional reactive programming is a relatively new paradigm, which takes time to learn.

NOTE: In the not-so-far future the Observable might become a part of the DOM’s Event API.