The Vision

This is really just a peice of the vision. But I'll put it here until there's another place for the vision as a whole.

Re-frame and Derived Data All The Way Down

Stop right now and go do two things: Read the re-frame README, then watch the video the author keeps going on about (Turning the database inside out with apache samsa).

From the re-frame README (discussing the qualification of describing re-frame as FRP-like in nature):

But, these days, FRP seems to have become a "big tent" (a broad church?). Broad enough perhaps that re-frame can be in the far, top, left paddock of the tent, via a series of qualifications: re-frame has "discrete, dynamic, asynchronous, push FRP-ish-nature" without "glitch free" guarantees. (Surprisingly, "glitch" has specific meaning in FRP).

This application architecture is based around these ideas.

It picks up where they left off and says:

• If we like servers and database architectures that look like one distributed persistent log structure being streamed into materialized views of the data (al a Samsa)
• And we like mimicking this in a FRP-ish "Reactive-Atom Component Event Subscription" (RACES, to quote re-frame again) framework on the front end (al a re-frame)

Then we like systems that look like this "all the way down"

Enter Datalog (Dat(aScript|omic))

In this paradigm of FRP that has emerged here (and elsewhere actually), there is the recurring theme of looking at a centralized state store on the client as a database. This way, everything in the UI is transactional, which is good.

However, when we do this we sort of wave our hands and say "think of the atom as a db!" But an atom is sort of an ad-hoc db. It has (limited but sufficient) transaction semantics, but doesn't care about the data inside. If we have complex data, being able to draw relations between the data becomes hugely advantageous. And this has to do with the structure of the data we put inside.

But DataScript is an actual database. The structure of the (DataScript) database value we put in a DataScript conn object (which is really just a gussied (read: listener-metadata-laden) up atom) has the semantics we'd want from thinking relationally about a database of datoms. So why mess with cursors and lenses into ad hoc databases (which is error prone and performance troubled) when we can ... Re-frame gets around cursors and lenses with an event log and reactions. We just make things more direct by making the log queryable with Datalog. And we can still trigger things reactively based on queries with posh (look it up, it's so good), giving us the best of both worlds.

The Web After Tomorrow

http://tonsky.me/blog/the-web-after-tomorrow/

Is this the thing?

I don't know. Maybe.

I know other smart people have thought about this problem. I think I just happened to be able to build out the basic building blocks in such a way that we have something to work from, in dialogue, idea and implementation.