REACT/FLUX JS AS GAME (STATE) ENGINE (tech stuff) I had the scariest cool tech i

REACT/FLUX JS AS GAME (STATE) ENGINE

(tech stuff)

I had the scariest cool tech idea today, that solves the virtual dom problem.

Just as a hint. When building oversing we realized that we could create a panel in the workspace for creating a 3d game using the tasks lists, the ‘variables'(awards/inventory), and the workflow engine. We even played with it a bit.

That’s because, at least architecturally, Oversing is a game engine that looks like business software.

But while (getting frustrated) with React (or rather, the fad/bullshit language everyone is using), I came to understand that the technology and its designers are is working backwards from the DOM model, to a game engine. Or what most people more primitively refer to as a state engine.

Game (state) engines consist of Nouns(objects), Verbs(messages), Operations(transformations/procedures, and the Renderer just draws the state every time. Meaning that the game engine redraws whats visible to the user, such as the ‘room’ in a text adventure game, or whats within visual range in a 3d adventure game, or in the DOM, the dom elements you can see on the screen that have changed. rendering the DOM is more expensive than rendering polys – a problem I assume will be solved in the future.

React = Rendering Engine (render just diffs)

Virtual Dom(Stores) = Database(es)

Flux = Command Procesor (verb + noun + message)

Events = Command Grammar (verb, noun, message)

The primary issue is that they overuse references instead of following Jquery’s model of sending messages to named entities.

In other words, explicit commands.

This is why the software is unreadable (‘magic’).

In state engines you pass a verb and it’s message to a noun, and then call the procedure(s) listed in the ‘table’.

To create an applicatoin you create a renderer (react components) that react to changes in state.

Then a state table that keeps track of the properties of the objects (many objects can be rendered using the same component) sort of like many trees can be built in a game engine by calling the same tree ‘model’.

Then you code all the verbs that each component (instance of a component) can process.

And you keep track of a ‘win’ state (set of states you’re trying to bring into being).

So to create a react-flux application (a state engine for rendering applications) we have existing design patterns going back to the 1970’s. And the people working on this technology apparently are ignorant of it? Or haven’t made the correlation?

This means it is terribly easy to create a ‘better design’ for working with the a reactive (functional) virtual DOM renderer, and an imperative command processor. Why? there is no value to imperative programming in rendering because it relies too much upon memory allocation for state. There is SOME value in functional programming for recursive / repetitive processing. There is negative value to functional programming and high value to imperative programming for interacting with humans (business and program logic.) But as usual, most idiots want a monopoly rather than a market in which the best of each is available.

BUT WE ARE SPENDING BILLIONS DOING JERKOFF WORK with browser technology that is just antiquated as hell.

Anyway, this make me even more excited about Oversing’s future.

And in the interim it answers my architectural questions about using these technologies. If I build an app as I’m suggesting the “rendering engine” that is stressing me out is readily replaceable.

Thanks for listening to my expurgation of technological frustration.

Curt