Less React, more JS

Sebastian Wallace
Apr 22, 2016 · 2 min read

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.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store