- Software Development
“That’s all well and good, except that doesn’t tell you the whole story,” he continued.
(Box’s T3 framework is not to be confused with the T3 Joomla framework for building extensions for the Joomla CMS.)
The Other Side of Scalability
But this is not a backend story.
The other side of scalability is the story of how a backend server, to whatever degree it may be scaled, communicates with the myriad graphical components maintained within the Document Object Model of an app inside the browser.
The same principle that applies to scalability on the backend applies to the T3 framework on the frontend. Think of how microservices architectures promote statelessness between functions. With T3, new kinds of abstractions support the establishment of loosely coupled components, which can be more easily rewritten and replaced.
It’s how Box has become a more gradually evolving system in recent years, implementing changes steadily and incrementally, including how it behaves in browsers and Web apps.
It’s one of the ideals I professed two decades ago when I was writing books on Visual Basic (yes, you’ll notice how I mangled my own name back then): If you build modules that can respond to anything, then you don’t need complex data structures for those modules to communicate between each other what each “anything” may possibly be.
Behavior as a Separate Thing
But here is where Zakas’ ideas take T3 in some new directions. In most object-oriented programming of the 1990s and 2000s, modules were defined by their behaviors. In T3, modules and behaviors are two separate classes of functionality. What something on the Web page is, and the discrete actions that unnamed somethings on a Web page can do, are defined separately and then associated with one another later.
A standard module has an init method that boostraps itself. A behavior clause does not (Zakas doesn’t use the word “clause,” but I will since the object needs to be something). This is extremely important because execution is never passed between modules, or from modules to behaviors and back. This is how Zakas’ rule of loose coupling is enforced: Communication between modules is restricted only to explicit messages, which are broadcast to one another by way of a messages array to which everyone listens.
“Messages are not commands as to what should happen,” reads the T3 documentation. “For example, makerequest is not an appropriate message name. Messages are intended to share information about what has happened, not what will happen. That allows others modules to react appropriately.”
So the init method for a page is where everything begins. Purely reusable code is reserved for use by what T3 calls services, so modules can call reusable functions that belong to services with which they’re associated. But the relationship between modules and services is strictly mathematical — or, as a developer I once saw at a convention characterized it, “Platonic.”
Is it the Right Focus?
In a message last week to Hacker News, independent software consultant Ivan Bulanov wrote, “For a change, it is nice to see a purely architectural JS framework. It solves what I would call a rather important problem of GUI development: what to put where. It also imposes rules of access: who calls who. Unlike the more encompassing solutions like Ember or Angular, it focuses on just that and allows the developer to pick the other parts himself.”
Not all the Hacker News reaction was positive. “I appreciate that Box has released T3 for free and if people want to use it, well then, that’s great. Nobody is being forced to use it,” wrote user DigitalSea, “but it is situations like these where I can’t help but wonder if efforts might have been better spent contributing to an existing open source project instead?”
Wrote Nicholas Zakas last week, “We found that almost everything we build fits into one of these three components [services, modules, and behaviors] and the ability to mix and match them is powerful enough to create many different types of user experiences. Furthermore, there’s nothing preventing us from using Backbone, React, or another framework in addition to T3, if we so desire. T3 really just helps better organize individual code while allowing our engineers to piece together a full client-side stack out of whatever they want.”
Feature image via Flickr Creative Commons.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.