Skip to content

Instantly share code, notes, and snippets.

What would you like to do?

Hello JSConf, before I begin I want to thank all of you for giving me this opportunity.

10 years ago, when I left my hometown in the heart of northwest Argentina, I could not have envisioned that I'd be here today speaking to you all. Thank you.

Earlier this week, I asked other speakers if they had any rituals that they did before speaking, and Laurie Voss suggested that I take a selfie, to help me with stage fright. So if you don't mind, let's take a quick one :)

Alright, for those of you who don't know me, my name is Leandro and I work as a Research Engineer at SRC, the Stockholm Research Center. We are a fully open-source non-profit dedicated to Advance Humanity and our interactions with computers.

Today, I'm here to talk about us, about our history building software for human beings. Hopefully by the end of this brief talk I will have done 2 things:

  1. I will have shown you that while the web today flourishes with incredible ideas, we have a great many lessons to learn from our past, and

  2. I will have compelled some of you to challenge the ways we build web applications, both technically and philosophically.

So let us begin! And in the spirit of fun, let's play a small game. I will describe a program and some of the features it has, and you'll try to guess out loud its name. Sounds good?

Alright. Can you think of a program that lets you draw, freehanded perhaps, and resize your shapes at will? Does this progarm let you set constraints for these shapes, such as "centered" or "parallel to", or "evenly spaced"? Can you make copies of your shapes? And lastly, do those copies update automatically when you update the original?

I hear some people saying Sketch, others Figma. Sketch people you were partially correct. I was describing Sketch...Pad. A program developed by Dr. Ivan Sutherland, back in 1963, so really more than 50 years ago. Let's look at SketchPad...

We can see why it was called that, as he just starts sketching a rough shape of what he wants. It looks like a rivet, and he's drawing a crossbar there to use the intersection as the center of an arc.

He then points to the edges to make them mutually perpendicular, and turns on the constraint solver. As the program solves constraints, it forces the crossbar to change, which forces the arc to change, yielding a perfectly symmetrical rivet.

Then it shows that no matter how you distort it, it comes up with symmetrical solutions. These constraints could have been more complex, for example he could have set ratios between the lines, or even across past drawings.

Another important idea seen here for practically the first time is the idea of "masters" and "instances". He was working before on a master drawing, and now he has an instance of it that is independent from the original.

Nowadays we can relate to this pattern under slightly different names: components and elements, classes and objects. He creates a few more instances of different sizes, that glitching we see is because they didn't have actual displays like we do now, and they are using an oscilloscope to visualize things. Quite ingenous.

Now he goes back to the master to remove the cross bar and lo an dbehold, all of the instances have been updated.

Ivan Sutherland did this development during his master thesis, and when Alan Kay, who studied with him, asked him how did he manage to create the first object-orientated system, and the first graphical interface system, all within one year, Ivan replied that he jus didn't know it was hard!

Ivan really set a high bar and a direction for the likes of Douglas Engelbart, who created the first computer mouse. Engelbart and his team at the Standford Research Institute developed, during the span of 10 years, a system so incredible that I have a hard time grasping it existed.

The oN-Line System was first demoed publicly in 1968, and it's been dubbed "The Mother of All Demos". Let's look at why:

Here we can hear Douglas essentially doing a live-stream of his computer, where he modifies this content-based layout to fit in a video-stream from a different computer altogether. That's video conferencing happening in real-time in 1968.

They discuss some matters of the presentation, and they proceed to link the workspaces. They are then essentially doing live-coding. Seriously, this presentation is epochal.

With this contextual background we can move on to the last piece of historical context we need: Xerox PARC.

PARC was the place where Alan Kay, Adele Goldberg, and Dan Ingalls, created Smalltalk. This language was designed to be a vehicle for human-computer symbiosis. It's a language that is designed to fade into the background fast and let you express yourself, just like a musical instrument would. It offers the programmers two core capabilities:

  1. Classes and Objects, which are used to represent things and processes, and
  2. Message-passing, that provides a communication layer for those objects.

Something worth noting is that Alan Kay has repeatedly said that when they invented object-oriented programming, the important part was not the objects themselves, but the messages. It's about the communication.

Let's look at an example of this systems:

We can see an animation of a ball, in what appears to be some sort of static page. But in reality the animation is being programmed as objects, so we can stop it and step through the frames until we find the one that we want. He then opens up a browser to see what messages the animation has available, and does the same thing with the painter object below.

After finding the right messages, he just gestures a conncetion between the two objects and the system figures out that there needs to be a message so offers an input to write it out. The message links the current frame of the animation above with the current image on the editor below.

And he'll then edit the frame as the animation plays above. This is all live editing of the software that a user otherwise would have consumed.

In fact, all of these applications are customizable by the user to fit their needs. They really turn the whole computer into a bicycle for the mind.

All fo these have been examples that built on each other to formalize the idea that our world is concurrent, everything around us happens in parallel from us, and we communicate with everything around us by sending messages.

I want to talk about 2 ideas. The first one is the computation model behind these applications. The second one is the philosophy behind them.

Computation Model

Let's begin with the first one.

When we model an application in Smalltalk, we model it in terms of objects that interact with each other via message passing. Each one of these objects performs hopefully one very small task, and has a number of messages that it understands and that it sends to other objects. It may have some internal state that can change over time as it receives and processes some of these messages.

Normally a Smalltalk application will have millions of objects, and you maybe even think of those tiny objects as computers on their own.

If we look at this diagram we can see that we have some Button object that will send a clear message to an Input object. Concurrently, a Container object will tell the Input to draw itself somewhere.

The underlying principles behind how Smalltalk works have been formalized (with some differences) as the Actor Model.

In the actor model we have several actors, essentially independent entities, being executed in complete isolation. They solve problems by collaboration, and they collabroate via message passing. Just like I send a text to someone to open the door when I've arrived.

Modelling systems with this approach has 3 interesting properties.

  1. Failure Isolation by Default
  2. Asynchronous Nature
  3. Trivially Parallelizable

1. Failure Isolation by Default

Have you ever been in a website that was completely unusable because of some unhandled exception that blew up the complete application stack? I think we all have. If our applications are normally composed of dozes of independent collaborating systems, why do we treat them as a single monolith that we have to incredibly carefully program?

We know that our applications are scaling massively in complexity and preserving good experiences for the people that use them is perhaps the definition of our day job for some of us, so why are we risking so much?

In the actor model, an actor failing does not take down the entire system. In fact, if built carefully, other actors can be on the look for failures and restart parts of the system that fail.

Of course we could decide that certain failures should crash the entire application, but it is now a conscious decision to degrade the experience to an irrecoverable crash.

2. Asynchronous Nature

When it comes to the nature of the applications that we build, we've had to go lenghts to create applications that can react to users instantaneously. Any actor system can choose to be as reactive (or proactive) as they need to be, and the choice is limited to what to do when we receive a message.

3. Trivially Parallelizable

Lastly, we struggle to parallelize our stack-based applications because we have a single one, running on a single thread, and any coordination between multiple threads has to be done manually.

When thinking in terms of Actors, we could potentially run every actor parallely. This is because each actor is its own tiny computer that knows nothing about the rest, other than their name, to be able to send them a message.

It is impressive to see how these 3 properties work together in practice. Most notably, Erlang is built under the same principles (although it uses a different terminology), and it is these ideas that allow for massively concurrent systems.

I will grant you that we don't have 2 million users per browser, but knowing that your application can crash and recover itself on the fly is incredibly powerful for raising the quality bar of any experience that we design and develop.


The last point I'd like to make today is that of the philosophy behind these graphical systems of the past. Smalltalk applications, and those built on modern derivates such as Pharo, show 2 key ideas:

  • The idea of Liveness of an application, and
  • The idea of Directness of an application.

Liveness is the ability to ALWAYS respond to a users actions. This means that whatever you do on the system, and whatever the system is doing, there never is a complete stop, a gap in the feedback loop. Naturally as the workload of the system increases and the computing resources get scarce, the system will respond more slowly, but it never stops responding.

Now remember the last time you were on a website that just didn't do anything for some time? Maybe because it was loading something, or because an unhandled exception made it to the main event loop. Failure isolation is foundational to Liveness.

Directness, on the other hand, means that whatever the user is seeing, the graphical representation of the system, is a point at which the user can begin to explore the complete system. They can inspect a button, change its attributes, restructure the behavior, reconstruct a user flow to suit their needs better, persist those changes, all by modifying the thing which they already see.

How do we get there?

It is likely hard to agree with me right now that we need to rethink the foundations on which we build applications, after all with all these fancy frameworks out there, backed by huge corporations, how could they be wrong?

I invite you to take a first step into this world by trying out Pharo Smalltalk. Pharo is a dialect of Smalltalk that is quite alive and has a growing community, and it should be more than enough to showcase why some of these attributes are paramount to increasing the quality of the experiences we ship.

You'll find that these same properties, alongside a highly reflective language, allow for a development experience quite unlike we have seen in other mainstream languages.

But most importantly, what can we do to start Building WebApps like it's 1972?

My best answer is to start by learning about them. In the meantime, at SRC we are working as hard as we can on formalising a universal actor virtual machine, StageVM, that we can use to bring this computation model to the browser via WebAssembly. It will be some time before we have something worth demoing :)

If you're interested in actors, and want to learn more about Smalltalk and Erlang, please come and say hi after this talk!

Thanks a million again for the opportunity, and enjoy the rest of JSConf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment