Introducing T3: Enabling Large Scale JavaScript Applications

Sorry JS developers. Guess you have to rewrite all your React apps in T3. Yes, I know you rewrote your Angular apps 6 months ago, your Ember apps a year ago, and your backbone.js apps before that, but that's just how front-end dev works.

PS: I'm currently hiring for developers with 3+ years of T3 experience.

I've checked their examples on http://t3js.org/examples/ and I appreciate the effort they put in but in general there is one thing I never understood with these examples :

Why most js frameworks relay on very simple examples while they promising the wonderland? I need an advanced sample than a classic todo to evaluate a framework. Something like does multiple async ajax calls, survives page reloads while juggling data / models, and gracefully handles the errors and/or initial states. An example close to a real world project would be much appreciated.

PS: If that matters, in my day time job I'm using Angular...

edit: fixed typo.

I don't know much about how to architect JavaScript applications, but I am struck by how much of this stuff seems to be glued together by strings. For example, from footer.js (https://github.com/box/t3js/blob/master/examples/todo/js/mod...)

    switch(name) {
        case 'todoadded':
        case 'todoremoved':
        case 'todostatuschange':
            this.updateTodoCounts();
        break;

        case 'statechanged':
            this.updateSelectedFilterByUrl(data.url);
            break;
    }

Accidentally wrote 'todostatuschanged' instead of 'todostatuschange' (in keeping with the tense of all the other actions!) and you'll get a silent failure.

Or from isListCompleted() in the list module:

    moduleEl.querySelectorAll('#todo-list li input[type="checkbox"]')

I'm not picking on T3, since all JavaScript frameworks seem to have this problem. There has to be a better way than that!

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.

Coming from Flex development, I see some similarities with the Robotlegs, PureMVC and the other Flex architectural frameworks. For example Modules look similar to Mediators and T3 Services are much like Proxies and Services of the aforementioned frameworks.

Unlike Robotlegs, PureMVC etc it does not specify where to put models. We should not just ditch this concept because the separation of data and view proved to be useful.

If there is a need for ViewModels then I believe they can reside in Modules. This may be convenient for a virtual DOM - based solution or data binding. The global models can reside in Services.

What the framework is missing is a more elaborate example with React or vdom and server interaction.

It doesn't seem to be over-engineered. All the decision seem to come from practice and not from architectural astronautics.

It may not be ideal, but it looks very practical, well aligns with my view on frameworks and I'll keep an eye on it.

I just do not see why Box needed to create another Javascript framework. Am I missing something here? As a front-end developer I get excited about this stuff, but I just do not see what T3 brings to the table that other frameworks do not.

I appreciate that Box have released T3 for free and if people want to use, well then that's great. Nobody is being forced to use it, 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?

To me this looks very similar to AngularJS (albeit a little more stripped down). Looking at their example code, it just feels like they've made their own ES6 modules/class implementation. A better choice in my opinion would have been to take the same path that Rob Eisenberg with Aurelia has taken by making the framework ES6 and then providing Gulp and Babel to transpile it. T3 feels similar to AngularJS in that you spend an exorbitant amount of time writing class-like modules when ES6 and transpilers already give us a cleaner standards based approach.

I do not want to sound negative, I am just offering constructive criticism. I would love to hear the thoughts of the Box team as to why something like React.js would not have worked for them instead. Considering React.js promotes modular component development like T3 does, it makes me question if Box needed to build T3 when React.js and its similar MVC-less approach is the same. It is cool they did and it takes dedication and work to build a Javascript framework, but I feel like perhaps it is wasted effort.

I like the concept of the separating concerns and no direct coupling between modules. I think they could have taken it one step further by using messaging but I'm biased there :)

I'm curious why they decided to roll their own modules when the web component standard has been around for a few years. Granted the polyfills may not have been available years ago when they started this but I feel like contributing to those, especially since the coding styles are so similar, would have been very fruitful. Looking at it today I'm not sure why I would use their modules versus web components unless I needed IE8 support.

The jQuery dependency is a little odd; is it going to keep up with the latest version of jQuery or eventually drop it? At a job I had a few years back I had to create a new web application where I was forced to use a platform that required a very old version of jQuery (otherwise it would break horribly) which made using a newer version a little annoying (though obviously doable thanks to noConflict()). It's rare to see frontend JavaScript frameworks with dependencies.

Overall this is pretty neat though I'm not sure I would necessarily use it.

Two things to consider before pulling the yet-another-js-framework card:

1. Do you have hundreds of developers working on a big application? If not this is not for you. Move on.

2. Have you seen what it does? Is it a whole new paradigm of MV*? Do you really have to rewrite your angular/ember/react application? From the docs and code you could clearly see it is not heavy weight at all. It is simply a framework that helps you organize your code into modules especially when disparate teams are working on a single app.

This is a framework that has been tested in productions and found useful at Box for over a 1.5 years. Don't be too quick to dismiss things. I think there is a place for frameworks like this for complex web applications.

It looks like the TodoMVC[1] example has a bug:

1. Create an entry "foo"

2. Check the box, observe strikethrough on "foo"

3. Check the "check/uncheck all" box (left of input box)

4. Observe strikethrough still present on "foo"

Digging in to the code[2], it looks like the "model-less" tenet caused the CSS class on the text and checkbox to go out of sync. In React, this would be a re-render and change in the virtual DOM, or in Angular, both would be bound to a shared model/scope.

If the simple TodoMVC example has a bug like this, the framework might not work too well for larger applications.

[1]: http://t3js.org/examples/todo/

[2]: https://github.com/box/t3js/blob/gh-pages/examples/todo/live...

It looks interesting but what problem does it solve? modules and services are well understood, the elephant in the room is how to deal with the DOM ,how to build a composite view with its own widget logic, while not having to manually write event handlers,event delegation, and clean up the handlers.It doesn't look like this framework solves any of these issues.

This only serves to exacerbate my analysis paralysis[0] (the paralysis of decision).

[0] http://en.wikipedia.org/wiki/Analysis_paralysis

"Modular Design", "Made for Collaboration", "Promotes Best Practices" says nothing to me.

I was skeptical going in but seeing as Nicholas Zakas is involved, I'm cautiously optimistic. For those who don't know him, he has written a number of influential books on JS as well as working on YUI.

I don't come from a frontend background, most of my experience is just cobbled together websites that use jQuery and maybe a spot of Angular.

The myriad of JS frameworks is bewildering to me sometimes.

Here's the first page I found that explains what T3 code actually looks like:

http://t3js.org/docs/getting-started/module

I'm surprised to see such tight coupling to the DOM. When they said you could plug in something like React, I figured T3 was mostly scaffolding for dependency injection, cross-component messaging, and global config.

The event handling in particular looks gross. You register for all the events of a certain type across your whole component and then manually filter them in the listener.

T3 sounds a lot like Ember-cli's structure:

- T3 Services -> Ember helpers

- T3 Modules -> Ember components

- T3 Behaviours -> Ember mixins

I've also found that the code I'm writing in Ember is much easier to test because of these abstractions.

People here don't know Nicholas Zakas?

Interesting comments here to this post. I was introduced first to this concept after watching the original ScaleApp architecture talk by Nic. Since then I have built couple of really large front-end applications spanning large teams. The concepts of this and other such frameworks I find greatly simplify development, testing and allow scaling that backbone, ember or such frameworks simply cannot provide. These concepts do require other frameworks for building functionality, but they use those so called frameworks for their toolsets rather than structure.

If you have ran your application through dependo and the resulting graph crashes the browser, you really need to look at this.

MVC is perfect for User Interface applications. Why this is NOT MVC is surprising. Also I was expecting a lot of new web technologies in a framework that was introduced in 2015. Web Components?

I spent a lot of time looking at JS libraries and frameworks. From jQuery, to Knockout, to Backbone, to Angular, to Batman, before finally settling on Ember. I am extremely skeptical about the need for more frameworks.

I usually don't give a new JS framework more than a couple of minutes to introduce itself. If it does not look like it will revolutionize how apps are built, I quickly write it off as a slightly different way to slice the pie.

You can't solve a problem from the same level of consciousness that created it -- Einstein

Here is a solution for ClojureScript: https://www.youtube.com/watch?v=DYzwfekWSzQ

> We found that almost everything we build fits into one of these three components

What doesn't fit? I think it's important to know where the framework lacks, they seem to have made some experience with things that didnt quite fit into this component structure.

Can someone elaborate how does this compare do Backbone.js which has the same motivation - a basic, not too opinionated, skeleton for your app?

Is this better? Worse? Just different?

"T3 is made to be unopinionated while prescribing how some problems might be solved"

You keep using that word. I do not think it means what you think it means.

I'm not a fan of heavy duty MVC frameworks on the front end like Angular or Ember. I like T3 a lot. Simple and light weight.

Reminds me a bit of Twitter's Flight framework with a little more structure around how application lifecycle is managed.

Based on how there examples work, I'd say this is extremely similar to meteor's blaze framework.

Is there anyone in this thread who actually took the time to give this thing a shot or...?

Repo just went down. I know traffic isn't causing it. Did they have a regret?

Interesting approach. Thanks and congratulations on your release!

Dear Box,

April Fool's Day was two weeks ago.