Less React, more JS

Note: I don’t have anything against React. This article is about exploring ideas of decoupling, regardless of the library or framework.

The rise of the virtual dom in the front-end world has left clumsy imperative dom manipulation in the past. From this new shift comes a flood of new frameworks and libraries, the most popular being React.

What could it look like to write code that is decoupled from React? What if we threw away JSX, createElement, createClass — and instead wrote our applications in simple Javascript? Maybe the only useful thing left over is ReactDOM.render

Without JSX

Without createClass

Consider every component simply renders data to virtual dom nodes. Data in, nodes out. Functionally this seems pure, until state is stored inside. Throw away internal state, throw away createClass.

Any state can just be passed into the function, with no mutation. If state needs to be persisted its better kept in the Model or Store (depending on the paradigm).

Without createElement

This pure function can do without createElement. It can just return an array that can be applied as the arguments for createElement inside ReactDOM.render

This seems nice — pure JS functions and data outside, and all React stuff inside ReactDOM.render. How could this possibly work for nested elements? We’d need to write a small utility function, which may seem tedious for something this small but trivial for larger nested stateless components/functions.

The advantage of using this approach is that coding using plain Javascript decouples the application from React, or any virtual-dom-based framework. I could port this to virtual-dom (for example) just by changing a line or two in prerender. With additional functionality in prerender it could just act as an adapter.

Javascript CSS

Styles are declared as object literals, but they can also be functions that return object literals. This could be recognized as something similar to mixins.

With a small utility function styles can extends others.

With a few utility functions the code became a lot more independent. Most of the code is just Javascript data structures and functions. This lends itself to the idea that if I want to create an encapsulated component ignorant of the consuming framework, I can do so if I just convert the arrays to virtual dom nodes or hyperscript from the outside. In other words, I can create and share framework-agnostic components, all because I am coding to the virtual dom, not to the framework.

It felt good to brain dump these ideas. I’d be interested to hear any other thoughts on this subject.