Surreal is a bit of a mind bender. It is not a serialization library per-se and yet, when performance is crucial, can act as a drop-in replacement for Transit.

The need for it came about from Roam’s data-intensive frontend app which serializes and deserializes several megabytes of data on every load.

I can easily see how surreal can look like HACK to many. It strongly relies on the unchanging nature of Clojure. If the implementation details of CLJS data-structures change, chances are that surreal will break. On the flip side, if that happens, which is unlikely, breakage should be evident during dev. Your serialization / data-layer will break instantly. Not a bad trade-off if you ask me.

It’s early days for surreal. Thoughts, testers and contributors are very welcome!



Looks like the source hasn’t been touched in 3-4 months.

Yet, I’m curious.

  • Does surreal solve the same problem as transit?
  • Why make surreal when there’s transit?
  • Are you using it internally now?

(thanks for Roam, makes my every day better)

1 Like

Hey @teodorlu!

Thanks for asking!
The only gain of surreal over transit is speed. It does not require serialization at all meaning you can store CLJS data-structures in indexedDB, localstorage or send them over to and from workers as you would with native JS objects.

Even if you send things over the wire you can use JSON.stringify and JSON.parse which will always be faster than transit.

The main purpose of surreal was to alleviate perf issues in roam. But it is a PoC at this point and we never shifted gears to integrate it.

1 Like