90 DAY ADVICE ON USING REACT.JS AND RELATED TECH (revised and expanded) #react #

90 DAY ADVICE ON USING REACT.JS AND RELATED TECH

(revised and expanded) #react #mobx #javascript

I’m using React, Mobx, my own Event manager. I’ve been at it for 90 days. I chose it after spending about 90 days testing the alternatives. I have found it terribly slow, painful, and fragile technology, but technology that DOES deliver on the promised performance at large scale.

FINDINGS

1) React is immature. It is poorly architected. The documentation must have been written by an Asian for whom english is a second language, that never wrote documentation before, and for whom the concept of passive voice and low context definitions was never learned in school. The support community is immature and all but useless. BUT … React is fast. That’s it. It’s simple. And the fundamental concept of the DOM as a database for rendering UI’s, and only rendering the DOM elements that change by use of diff-ing from an intermediary database is genius. This is not a novel concept. It has been in the spec for browsers for a long time. But FB actually did it.

But (and it is a big but) for some reason it appears that the ‘chipmunks’ (kids) at Facebook have never written a text, 2d,or 3d game engine, whether single, multi, or massively multiplayer, or they would have understood that this is the architectural pattern that they are wrestling with: Containers (spaces, or components, or forms, or documents), Nouns(things), Verbs(events, actions), States(Measures that are testable), Transformations (or operations), Render-sequencers, and Renderers(Display for Human Beings). If that was the case, we would not write our react applications as elaborate and tragically fragile pseudocode in javascript (like they force us to), but merely define containers, nous, verbs, states, and renderers, and let React (the engine) make use of that information. In other words, we would define data, and program very little but transformations and renders.

And then we could write web apps like any of the tens of thousands of other apps that use this architectural pattern do. (It is, after all, what I recommend as the universal application pattern — and is what our product Oversing is based upon. Oversing is an enormous ERP platform, but fundamentally, architecturally, it’s a game engine — which is why you don’t need to code to replace the previous generation of Enterprise Platforms. )

So, deterministically, I would see React either migrating to the standard game pattern over time, or being replaced by a framework that employs this standard patter over the top of react. React’s primary value is its construction of an alternate DOM, and its diff-ing algorithms. The rest of the architecture is clearly invented by a product of postmodern educational system and totally ignorant of history. If I wasn’t reforming western philosophy, and trying to ship the next generation of business platform software at the same time, I would maybe take up this little project — but I don’t have the juice or time.

2) Javascript is an inherently fragile language, and an especially, a syntactically fragile language. Most of my recommendations originate in circumventing the many errors that arise in javascript code due to the need to infer developer intentions from the use of syntactical variation within that fragility rather than explicit declarations of intent.

For some reason there is a bit of a cult in javasccript and functional programming like there was in C, Lisp, and Perl, and too weak of a community to compete with it like there was in Smalltalk and C++ and the eventual scale of object oriented programming. Not that there aren’t uses for both, but the primary difference is in the readability of code. I do like that in javascript you can program in Pascal style (functions within functions). But I don’t like that we can’t choose strong typing, scope, and object declarations so that the compilers can take the place of three testers per developer, or halving the productivity of developers because of the fragility of the language.

That said, Javascript is now the intermediary language and the future looks certain: various languages complile to javascript with a variety of options, and basic javascript will replace bytecode as a more human readable pre-execution language. What does this mean? it means that you won’t see javascript in a few years, because it will be replaced by more stable languages that improve your productivity. And today’s Babel and Webpack will take the place of compilers of yesteryear. (This is obvious but for newbies I think it might be helpful in career planning.)

There is no reason that if we use Babel and Webpack today and Hot loading we do not produce javascript as the output of that ‘process of compiling’. We are just compiling to javascript the way we have always compiled software — with the virtue that compiling to javascript is machine independent like byte-code, but even better, it’s largely human-readable.

There is a lot of babble in the javascript community over the future of the language, and huffing and puffing over the features coming down the line — and I think this is going to result in hot air. No one writes in assembler any more (I used to write my graphics and AI routines in assembler), and I see javascript going the way of assembly language. When? As soon as we see a framework that solves all its problems AND uses the underlying strategy of React.

Why? Because what we are all spending billions of dollars and millions of hours on writing today in order to circumvent an archaic set of technologies: The MS operating system imported from Digital Equipment and designed to run continuous processes on expensive hardware, the superiority of the whatever-nix operating systems at running temporary processes on cheaper hardware; the (finally) arrival of node.js and the many variations it’s generating to overcome this archaic operating system limitation; the archaic browser architecture based on the dom, the archaic language we call javascript that the browsers depend upon, the means of circumventing those archaic technologies we call diff-ing the virtual DOM, (and its now many kin), and the postmodern (OMG) reinvention of the wheel (text adventure games) we call react and its imitators (Angular2 and others.)

So why am I investing in a technology that I see as intermediary and not ready for prime time? Because the underlying solution will mature, and our product needs the performance that comes from the diff-ing of the react-dom, and the browser dom.

3) I don’t see any reason to use any state solution other than Mobx for state management. Everything else is a waste of time, and adds fragility to your code. React’s state management is relatively incompetent at complex changes in state. So ignore it and simply rely on Mobx. I prefer using decorators for Mobx to keep the syntax very simple and clear, as well as keep the declarations of what is under state management in Mobx or not very clear. it isn’t inferred. it’s declarative.

4) Binding is a catastrophe for maintenance in javascript, vastly increases boilerplate, and dramatically compounds the opportunity for error. So far it has been the source of almost every error I have found in my code. Javascript offers a range of syntactic solutions to binding, and others have written translators (compilers) that attempt to solve this problem. Having surveyed all of them, the most flexible declarative and maintainable is to use autobind in the constructor. So that all methods of an object are automatically bound unless you state otherwise using an exception parameter.

5) There are many ways of constructing components and all are eventually reduced by the ‘compilers’ to javascript. However, some of these methods are implied, and some of them are declarative. I recommend using only two classes of components: (a) constants for anything that renders only using static parameters passed to it. and classes for anything that uses references (binding) or state (variables).

6) There are many ways of constructing ‘stores’ (models that manage data), but only one of them is reliable, and that is using the Provider functionality, so that all stores (models) are instantiated as single instances, and are accessible by injection into any component that requires them.

CLOSING

So we have an archaic operating system (the browser and the DOM)

We have an archaic intermediary language (javascript)

We have a childishly postmodern positioning statement around an ancient textual game engine design pattern (React).

And we are currently in the process of developing compilers to this intermediary archaic language (javascript)

And we have yet to see a language or framework that eliminates the fragility of these layers of archaic technologies so that they are anywhere near the equivalent of their archaic counterparts (text adventure games), or their current equivalents (3d adventure games).

So that’s what I’ve learned (painfully).

Cheers