Mind blown ... part three
Pre-script: Since I wrote this, I’ve discovered Stimulus-Reflex, which on the surface, is exactly what I want. After diving a bit deeper, it’s not quite right, so I will be starting my own version - more on that next week.
I was watching a talk by Rich Harris from the "You gotta love frontend" conference about reactivity and Svelte. As I said, my mind has been blown away a bit by it.
But it made me think.
All this talk of "reactivity done correctly". I've heard it all before.
Ruby is a direct descendant of Smalltalk. Smalltalk is known for being one of the original object-orientated languages.
But it's so much more.
It was part of the Xerox Parc machine that used pervasive networking. The Smalltalk environment was both the first proper Integrated Development Environment and the first proper Graphical User Interface (as using the computer also involved programming the computer - although because of Smalltalk's syntax it didn't look like programming). To locate a class (or instance) you would use a "browser window". A browser window that looks just like a NeXT file browser. The NeXT file browser is the direct ancestor of the Mac's Column View in the Finder. As well as being how you used an iPod when navigating through your albums and playlists.
Lisp people go on about the purity of functional programming. Well Smalltalk was pure. Everything was either an object or a message - there are only seven pieces of Smalltalk syntax and they are just punctuation. Everything else - class definition, method definition, operators, if statements and loops - they're all just sending different messages to the right object.
But Smalltalk also invented Model-View-Controller.
Rails claims to be Model-View-Controller, but it's nothing like Smalltalk's MVC. That's because Smalltalk had something called the "Dependency Protocol" built in to every object. You'll recognise it - it's now known as "Observable" or maybe “Reactive”. Any Smalltalk object can declare itself the dependent of another object, which means it will get notified when the target object updates. In effect, every object has event listeners and event handlers built in.
In Rails the Model sits in or near the database and represents your "application". The controller receives requests from the outside world, gathers up the relevant models, adjusts them if needed, then renders the relevant views and responses back to the caller.
In Smalltalk, the Model, once again, represents your application. But the controller only ever deals with inputs - mouse clicks, keyboard presses - and calls methods on the model it knows about. It knows nothing about views. Instead, any relevant views register themselves as dependents of the model, so when the model changes (whether because of a controller, or because of something else), the view get notified and redraws itself.
Imagine a list of people rendered on-screen - there are ten people each represented by ten “Person” views. When the "Person 1 Model" is edited, it notifies its dependents - and the "Person 1 View", and only the "Person 1 View" redraws itself. The other people in the list were never notified, so they do not change. This is exactly the reactivity that Rich Harris is talking about in his talk about Sveltekit.
Rails' MVC is structured differently because Rails is a traditional request-response web-framework - whereas Smalltalk and Svelte are both client-side technologies - Smalltalk in a desktop environment, Svelte in a browser (or similar).
But we now have the pieces to do "true" MVC across the web.
We can send updates to the models without prompting a full page refresh using the technology FKA Ajax. Web-sockets allow our views to register themselves as dependents of models and receives notifications when they change. All that stuff is there. Couple that with Opal.rb or Ruby WASM and I think we might be able to build a framework that's as elegant as Svelte coupled with the joy of Ruby.
And now I've got something else to build, when I find the time!
