NOTE! This is an article I published on my blog back in April 2016

In the world of web applications it is not enough to just write code. We also need a well thought out interface for our users to interact with the application. The web has changed a lot the last few years as we have moved from building static websites to full fledged complex applications. The workflow of writing code, collaborating with designers and push great products out the door is still changing as we explore this brave new world. …

How do you build a user interface? Do you always start with a component? Do you do styling before you implement state? What about data required from the server? Do you use fetch directly in your components or do you put that responsibility somewhere else? How we approach these challenges probably varies a lot. In this article we are going to take on a different perspective building user interfaces… by not building them at all.

The ingredients of an application

To create a web application you need the following ingredients:

  • State that describes the current state of the application
  • Effects to talk to the outside…

When I write applications I want to spend as much time as possible doing three things:

  1. Define state and the domains of that state
  2. Write logic to change the state
  3. Consume the state in components to produce a UI for the users

When my line of code expresses one of these points I produce actual value for the customer/company. This is where I write the actual application.

In the last few years working with different state management solutions I find myself spending less time writing code covering these three points and more time writing code orchestrating the relationship between them. You might argue that this orchestration creates value in the long run, but there is a threshold. …

I saw this tweet from Dan Abramov highlighting the approaches of React compared to Vue:


As a library author I have explored implementing application state management from the perspective of value comparison and mutation tracking. In this article I will explain how these two approaches work and why I personally think one is better than the other for keeping UIs in sync with your application state.


In this article we are going to compare how two different approaches to detecting state changes affects how you structure that state, how you write logic to change that state and ultimately how it affects UI performance. … is an online code editor that allows you to write and share code for modern JavaScript and popular frameworks. The project was originally written by Ives van Hoorne. When the project was conceived in late 2016 Redux had taken a strong foothold in the JavaScript community. With an ambitious project like Codesandbox, Redux was an obvious choice. A year later the project has grown larger in contributions, features and lines of code. To keep the project growing at a steady pace it was necessary to make changes to the stack and refactor. …

Over one year ago I published this video on YouTube explaining how I was able to pass code from the client to a custom Webpack bundling server and show the result in an Iframe. The idea was to create a bin tool that would simulate how we actually write code, using a bundler.

The hardcoded React example gave high hopes, but there were still huge challenges to overcome.

  • How would the Webpack server perform with many sessions?
  • How would I get the users to install NPM packages to be bundled with the bin code?
  • How could I make Webpack loaders configurable? …

If you are not familiar with how Cerebral does its routing we can start off by telling you that it is different than traditional routing. Traditional routers map url changes to views/components. The Cerebral router maps urls to signals. So, why change the behaviour?

Every event in your application triggers a signal that normally leads to one or multiple state changes. This is not special to Cerebral, this is how all applications work. A url change is also an event in your application, just like a button click or a websocket message. In Cerebral you treat URL changes the same way as any other event in your application, with a signal. The router does not affect your view/components layer at all. The benefit of this approach is consistency and flexibility. …

The javascript framework Cerebral is about to get out of its infant stage. The last two years has truly been an amazing ride. Running open source projects with several contributors, creating a tool that is actually used in real life applications… it has been the best experience of my career. So I wanted to share the story of Cerebral this far and why you would want to consider using it.

TL;DR — Cerebral is a JavaScript framework with a debugger that gives you great insight into how your application works. We often label applications as complex when it is hard to build a mental image of what is going on. …


Christian Alfoni

Open source enthusiast. Author of Cerebral and try to contribute where I can

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store