
Introducing T3: Enabling Large Scale JavaScript Applications - mparr4
https://www.box.com/blog/introducing-t3-enabling-large-scale-javascript-applications/
======
hendzen
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.

~~~
rvdm
While this made me laugh because it's an exact description of the last 3 years
of my professional life, I am happy new frameworks keep popping up. The holy
grail of front end frameworks hasn't been invented yet but with each new
framework we ( hopefully ) make some progress.

~~~
idibidiart
It has been invented[1] and we're bandwagoneering[2, 3] it for you:

1\. [http://reagent-project.github.io/](http://reagent-project.github.io/)

2\. [http://www.meetup.com/Reagent-Minimalistic-React-for-
Clojure...](http://www.meetup.com/Reagent-Minimalistic-React-for-
ClojureScript/)

3\.
[https://www.youtube.com/watch?v=DYzwfekWSzQ](https://www.youtube.com/watch?v=DYzwfekWSzQ)

~~~
e12e
Amazing, a homepage for a js front-end framework that actually has useful
content with js disabled, like a web page (as perhaps, opposed to a web app)
should.

------
devmach
I've checked their examples on
[http://t3js.org/examples/](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.

~~~
apike
While it would be nice to have a more complex example than a todo app, studies
show that a todo list is the most complex JavaScript app you can build before
a newer, better framework is invented:
[http://www.allenpike.com/2015/javascript-framework-
fatigue/](http://www.allenpike.com/2015/javascript-framework-fatigue/)

------
millstone
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...](https://github.com/box/t3js/blob/master/examples/todo/js/modules/footer.js))

    
    
        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!

~~~
glibgil
Yes, it is called static analysis
[http://en.wikipedia.org/wiki/Static_program_analysis](http://en.wikipedia.org/wiki/Static_program_analysis).

It exists for JavaScript:

[https://github.com/sinelaw/infernu](https://github.com/sinelaw/infernu)

[https://github.com/facebook/flow](https://github.com/facebook/flow)

~~~
reverius42
I don't see how static analysis helps the switch-case on strings. It might, if
JS had a more expressive (static) type system. An enum type, perhaps?

~~~
gnud
I usually do something like

    
    
      var Constants = {
        valueA: function valueA() {},
        valueB: function valueB() {}
      };

~~~
Mister_Snuggles
Why do you use empty functions instead of a number or a string?

~~~
madeofpalk
My guess is than a function will always be a unique object, rather than if it
was a number or string, there's a chance you use the same value twice.

~~~
gingerrr
an object literal would provide the same guarantee but without the overhead of
function prototype methods, wonder if there's any other reason?

~~~
drifkin
Maybe they're using functions so the values can have names? Perhaps easier to
debug.

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

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

~~~
mandeepj
React came just now. It's was officially released few weeks ago. T3 team might
have started working on it's framework from quite long time ago.

Edit - Just to clarify - Reach and T3 are totally different things. T3 talks
about structuring your application components for better code management.
There is nothing stopping you from using both of them together.

~~~
visarga
Dividing an app into modules/parts as T3 does is great, but I prefer React's
ability to compose and simplicity.

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

~~~
Noobies
You can do inter-module communication via messages. Notice the onmessage()
inside the todo example here
[https://github.com/box/t3js/blob/master/examples/todo/js/mod...](https://github.com/box/t3js/blob/master/examples/todo/js/modules/footer.js)

As for $ dependency, a small discussion
[https://github.com/box/t3js/issues/12](https://github.com/box/t3js/issues/12)

~~~
BinaryIdiot
Ah thanks for the info; didn't notice the onmessage. Still I'm biased towards
my own messaging library but that's neat :)

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

------
thelastnode
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/](http://t3js.org/examples/todo/)

[2]: [https://github.com/box/t3js/blob/gh-
pages/examples/todo/live...](https://github.com/box/t3js/blob/gh-
pages/examples/todo/live/js/behaviors/todo.js#L123)

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

~~~
mandeepj
Is this what you looking for? [https://medium.com/@addyosmani/javascript-
application-archit...](https://medium.com/@addyosmani/javascript-application-
architecture-on-the-road-to-2015-d8125811101b)

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

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

~~~
ch0wn
And even more specific to front-end frameworks and libraries:

[http://addyosmani.com/blog/front-end-choice-
paralysis/](http://addyosmani.com/blog/front-end-choice-paralysis/)

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

~~~
coldtea
You could check the provided code then. Your comment doesn't say much to us,
either.

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

~~~
Jgrubb
Agreed. Lots of folks bashing on this thing, but Zakas has a serious pedigree.
I have several of his books. I have to think if anyone in JS land is capable
of surveying the other ideas out there and distilling some solid concepts out
of them for their framework, he's the guy.

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

~~~
mattdeboard
I also consider myself a backend developer but have written a non-trivial
amount of ReactJS code. It is really a pleasure to work with. I highly
recommend next time you find yourself having to do something on the front end,
use React.

~~~
swah
Another guy that enjoys both frontend and backend here.

Something that's holding me back on ReactJS is that I'd like to render pages
server side, and I don't want to use Node.js, but Go or Python instead.. and
there aren't many folks doing this combo.

(Maybe the best option is a "render server" in Node.js?)

~~~
mattdeboard
Yeah you would have to dispatch your server-side rendering out to a Node
process which probably wouldn't be worth it.

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

[http://t3js.org/docs/getting-started/module](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.

~~~
nevir
Feels like they could clean up a fair bit by making those modules as custom
elements

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

~~~
msane
Even closer to Angular's:

\- T3 Services -> Angular Services

\- T3 Modules -> Angular Modules

As for behaviors, they seem closer to the Controller concept in both
frameworks, rather than mixin.

------
ExpiredLink
People here don't know Nicholas Zakas?

~~~
TheSisb2
Exactly what I was thinking. Also a lot of comments here seem to be upset at
"yet another JS framework". T3 is actually pretty nice from what I've seen so
far and does follow best practices.

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

------
msoad
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?

~~~
tracker1
MVC typically relies on an event model which is difficult with larger
applications structured across many developers. If you look at some of the
reasoning behind Flux/React this is pretty effectively outlined.

OO and MVC aren't the end all, be all of application design.

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

~~~
tracker1
Right now the clinet+server-side (isomorphic) story for a lot of these tools
is less than outstanding... React, or something like it will likely win in the
end. Although I've also been keeping an eye on mercury, riot and polymer.
Angular 1.x was too annoying in practical use, and wrt Angular 2, may as well
just use React.

~~~
GordyMD
Have you checked out Meteor.js and skit.js? They seem to me to be the
frameworks currently most geared towards reusing code on client and server
(e.g. isomorphic - sorry mathematicians).

~~~
tracker1
I've looked at Meteor, and haven't looked into skit... admittedly when I
looked into Meteor very early on, I didn't like their security model (or iirc
lack of).

May take a look again... also, it seemed to be very tied to mongodb, which I
didn't mind at the time, but am moving away from.

------
idibidiart
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](https://www.youtube.com/watch?v=DYzwfekWSzQ)

~~~
bronson
It would be nice if you stopped spamming.

~~~
visarga
Your comment made me curious and I checked his comment history. There is no
spam there, just normal activity.

~~~
idibidiart
If they don't like your opinion they push it down. If you post to help explain
what you mean they call it spamming. I feel empathy toward those who act like
this. I really do.

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

------
romankolpak
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?

------
al2o3cr
"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.

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

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

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

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

~~~
lewong
Yes, am working with it, and seems true to form. The large scale aspect
requires a re think. Couldn't be integrated into an entire code base like
mine. Too much code, too few engineers.

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

------
TheSisb2
Interesting approach. Thanks and congratulations on your release!

------
rubiquity
Dear Box,

April Fool's Day was two weeks ago.

