Box Opens T3, a System of Rules Applied to JavaScript for Large-Scale Apps – InApps Technology 2022

“The hot term right now in JavaScript is MVC,” said Nicholas Zakas, a front-end engineer at file sharing service Box, during a 2012 speech sponsored by his company. “‘Oh, you know JavaScript architecture?’ ‘Well, I do MVC, so I obviously must know JavaScript architecture,’” Zakas went on, mimicking a conversation one might easily overhear.

“That’s all well and good, except that doesn’t tell you the whole story,” he continued.

It was the launch of an idea for an application framework for JavaScript — not a library, but something he hoped would provide some foundational structure and scalability for modular JavaScript programming. That idea came into fuller fruition last week, with Box announcing the open source release of T3, a framework intended to provide compartmentalization of the components of a Web page, making them each addressable by the backend application.

(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

When we talk about scalability in these pages, it’s usually in the context of deploying containerized applications in the cloud, and re-architecting monolithic applications around microservices. Backend JavaScript, such as Node.js and its one-time competitor io.js, have been discussed in conjunction with these goals, insofar as JavaScript has made the effort to adopt more formal structures.

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.

“A lot of other JavaScript frameworks,” reads the open source T3 documentation, published last week, “assume you want to handle all HTML rendering in the client. T3 assumes that the HTML content is already present and simply allows components to interact with that content. We believe that progressive enhancement is a more robust approach for large-scale applications.”

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

T3 is not a language in itself, but a system of rules applied to JavaScript and enforced by the T3 client-side component. A module becomes a self-contained unit of functionality. And, as the original Visual Basic attempted back when dinosaurs roamed the Earth, each T3 module is a pluggable, reusable, easily replicated unit.

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.

I want to call a behavior a kind of module, but Zakas would correct me. The difference between a behavior and a module is that the former describes an action or set of actions, and the latter a thing. An action, once defined, may be triggered by an event. In JavaScript, events are responded to using methods, such as onClick. In T3, the same format onEvent responds to the event defined in the behavior’s clause.

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?

There is nothing about T3 that bends or contorts JavaScript into something it was not intended to be, and conceivably it should apply just as well to future renditions of JS, such as ES6.

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.”

Years ago, I said the undoing of JavaScript would come when its lawlessness and lack of structure would become impossible to manage at scale. As it turns out, with more attention being paid to giving structure to JS than to a completely new client-side language, its most glaring omission has quickly become its greatest strength.

Feature image via Flickr Creative Commons.