React

User interfaces allows humans to interact with machines programmed to fulfill some of their needs. And that willy-nilly includes some state UI has to reflect.

Let’s use Trello for an example, as it is highly reactive app — whatever happens on server every affected client is updated in near realtime.

Here are couple of facts that are part of the state:

Which board is the user looking at?

Is the search box focused?

Are tickets filtered?

To whom is the ticket assigned?

Every time any of the facts changes, UI has to be updated. We could rerender whole page just to be safe, but that’s a big no-no as it is a costly operation and we loose some benefits browsers provide us (eg. maintaining the focused state on an input field, while something else is modified). On the other end, we could update only the affected elements.

Traditionally, if we decided to go fully optimal, we would maintain all the mutator handlers to carefully take all of the facts, not just the changed one, into the account and deal with DOM accordingly. The amount of code and, inherently, the cost spirals out of the control easily, as for each fact we have to write a handler which references every other handler — that’s exponential code growth in worst case. Unacceptable.

React solves this problem really good — you get hooked on it the first time you try it. It’s so intuitive because it combines simplicity of a full page rendering with the optimality of minimal DOM updates.

The core of the solution lies in the virtual DOM React provides and uses. Briefly, the app developer writes down how does the whole page render given the state, and the React maintains the browser DOM by:

rendering the whole page into a virtual DOM on each state change (with couple of optimizations here and there),

making the diff between virtual and browser DOM, and ultimately

applying a set of minimal changes to the browser DOM.

Incredible.

Akka

To support epic (interactive and timely as a video game) interfaces, there has to be reactive solution on the backend too.

Such apps often have plenty of events to pass around multiple affected clients and disposable derived data that has to be incrementally computed. And that is solved and maintained with ease using actors and message passing.

In short, we wrap all mutable data kept in memory inside actors. That way, access to that data is synchronous and all mutations are easy to trace because only that actor can change it.

We’ve had (and are still having) a great time crafting well designed and highly dynamic solutions using this approach.

That being said, if you are an exceptional individual and like (or even strongly dislike) what you’re seeing on our blog, you’re invited to stop by our office and say hi — we’d love to meet you.

Read next

Software engineering today is all about building better, [value-driven digital products](https://spicefactory.co/blog/2017/04/27/building-user-value-into-digital-products/) more efficiently. This 'mantra of efficiency' is especially present in the...