41 ms·

Introducing T3: Enabling Large Scale JavaScript Applications

188 points by mparr4 12y ago

suyash 12y ago
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.
DigitalSea 12y ago
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 12y ago
  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 12y ago
    Dividing an app into modules/parts as T3 does is great, but I prefer React's ability to compose and simplicity.
bahador 12y ago
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 12y ago
  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/
s0l1dsnak3123 12y ago
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 12y ago
  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.
santiagobasulto 12y ago
"Modular Design", "Made for Collaboration", "Promotes Best Practices" says nothing to me.
- coldtea 12y ago
  You could check the provided code then. Your comment doesn't say much to us, either.
BinaryIdiot 12y ago
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 12y ago
  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/modules/footer.js https://github.com/box/t3js/blob/master/examples/todo/js/mod... As for $ dependency, a small discussion https://github.com/box/t3js/issues/12 https://github.com/box/t3js/issues/12
  - BinaryIdiot 12y ago
    Ah thanks for the info; didn't notice the onmessage. Still I'm biased towards my own messaging library but that's neat :)
djhworld 12y ago
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.
- tracker1 12y ago
  As someone who is trying to keep up with a lot of it, and using node/io.js on the server it's pretty cool and overwhelming at the same time. On the one hand, there is more choice than ever. On the other, there's almost two choices... and when you look one day, and get delayed/deferred for a few months, something you'd written off then deserves a second look. My leanings lately are towards React+Flux-like tools. Using the npm and browserify ecosystem. Which is far better than anything I've used in the past for building web applications.
- mattdeboard 12y ago
  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 12y ago
    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 11y ago
      Yeah you would have to dispatch your server-side rendering out to a Node process which probably wouldn't be worth it.
devmach 12y ago
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.
- rvdm 12y ago
  Fully agree with devmach. Angular has a very similar problem and they know it. I think that one of the things we can expect from Angular 2.0 is a much larger example app. I'm ready to see the end of TodoMVC and the beginning of CMSMVC or SocialNetworkMVC or whatever. That said, I like the idea behind T3 and am very curious to see how it will mature and what adoption will be like.
- apike 12y ago
  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/
- TheAceOfHearts 12y ago
  I wrote a blog post[0] relating to this as well. If you're going to flaunt your framework as the next big thing, you should give real world examples. My unhappiness with angular is part of why I wrote this up as well. In their own docs they do things that are considered bad practices, they don't have readily available examples for how to test certain things, and they don't have any examples of how a "real" app should look. I'd love if people that put out these frameworks released a non-trivial app WITH tests, using the framework. I think Rails has done an amazing job with these things. Their guides are outstanding. [0]: https://blog.cesarandreu.com/posts/testing_not_as_an_afterthought https://blog.cesarandreu.com/posts/testing_not_as_an_afterth...
aikah 12y ago
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 12y ago
  Is this what you looking for? https://medium.com/@addyosmani/javascript-application-architecture-on-the-road-to-2015-d8125811101b https://medium.com/@addyosmani/javascript-application-archit...
drew-y 12y ago
Based on how there examples work, I'd say this is extremely similar to meteor's blaze framework.
bsimpson 12y ago
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 12y ago
  Feels like they could clean up a fair bit by making those modules as custom elements
ExpiredLink 12y ago
People here don't know Nicholas Zakas?
- TheSisb2 12y ago
  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.
hendzen 12y ago
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.
- curun1r 12y ago
  Luckily this doesn't appear to compete with React. This seems to be focused on composing a large-scale application from many different component applications. It's the kind of thing you have to do at large companies that have many different groups and are bad at communicating and collaborating on a single code base. React helps you simplify your view logic. The two should work together quite nicely. Just yesterday we had a meeting with the team at my company that's responsible for building the glue to allow our flagship product (~$4b profit per year) to be composed by independent releases created by independent teams that aren't always communicating on a regular basis. They built a library based on the whitepaper that was published by the main developer behind T3. At the time they started, there was nothing publicly available that served the need. But now, a company following in our footsteps will have T3 and won't have to waste the time that we did building it.
  - Noobies 12y ago
    Yeah, doesn't compete with React. If React were being used client side only (not isomorphic) then one can roughly do stuff like https://gist.github.com/priyajeet/c2731789d3a688ee85a9 https://gist.github.com/priyajeet/c2731789d3a688ee85a9 (5-min hack)
  - mparr4 12y ago
    Curious, what's the whitepaper?
- steamy 12y ago
  I'm currently hiring for developers with 3+ years of T3 experience. You should be one of these clueless HR managers (( 10+ years of jQuery Experience )) - Hello, jQuery wasn't around 10 years ago ... But seriously and with all due respect when will these people realize that the market for JS frameworks is INSANELY saturated and released products are ASTONISHINGLY optimized that there's no need for the time being to push yet another framework and torture us devs with the task to master it out of the fear of being left behind and feeling irrelevant skills-wise?
straws 12y ago
Reminds me a bit of Twitter's Flight framework with a little more structure around how application lifecycle is managed.
rubiquity 12y ago
Dear Box, April Fool's Day was two weeks ago.
ralmidani 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
ivanb 12y ago
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.
msoad 12y ago
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 12y ago
  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.
ssiddharth 12y ago
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 12y ago
  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.
millstone 12y ago
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/modules/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!
- glibgil 12y ago
  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 12y ago
    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 12y ago
      I usually do something like var Constants = { valueA: function valueA() {}, valueB: function valueB() {} };
      - Mister_Snuggles 12y ago
        Why do you use empty functions instead of a number or a string?
idibidiart 12y ago
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 12y ago
  It would be nice if you stopped spamming.
  - visarga 12y ago
    Your comment made me curious and I checked his comment history. There is no spam there, just normal activity.
    - idibidiart 12y ago
      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.
TheSisb2 12y ago
Interesting approach. Thanks and congratulations on your release!
thegreatpeter 12y ago
Is there anyone in this thread who actually took the time to give this thing a shot or...?
- lewong 12y ago
  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.
Meai 12y ago
> 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.
al2o3cr 12y ago
"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.
nell 12y ago
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.
lewong 12y ago
Repo just went down. I know traffic isn't causing it. Did they have a regret?
y1426i 12y ago
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.
thelastnode 12y ago
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/js/behaviors/todo.js#L123 https://github.com/box/t3js/blob/gh-pages/examples/todo/live...
romankolpak 12y ago
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?

188 points by mparr4 12y ago

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.

DigitalSea 12y ago

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 12y ago
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 12y ago
  Dividing an app into modules/parts as T3 does is great, but I prefer React's ability to compose and simplicity.

bahador 12y ago

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 12y ago
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/

s0l1dsnak3123 12y ago

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 12y ago
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.

santiagobasulto 12y ago

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

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

BinaryIdiot 12y ago

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 12y ago
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/modules/footer.js https://github.com/box/t3js/blob/master/examples/todo/js/mod... As for $ dependency, a small discussion https://github.com/box/t3js/issues/12 https://github.com/box/t3js/issues/12
- BinaryIdiot 12y ago
  Ah thanks for the info; didn't notice the onmessage. Still I'm biased towards my own messaging library but that's neat :)

djhworld 12y ago

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.

tracker1 12y ago
As someone who is trying to keep up with a lot of it, and using node/io.js on the server it's pretty cool and overwhelming at the same time. On the one hand, there is more choice than ever. On the other, there's almost two choices... and when you look one day, and get delayed/deferred for a few months, something you'd written off then deserves a second look. My leanings lately are towards React+Flux-like tools. Using the npm and browserify ecosystem. Which is far better than anything I've used in the past for building web applications.
mattdeboard 12y ago
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 12y ago
  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 11y ago
    Yeah you would have to dispatch your server-side rendering out to a Node process which probably wouldn't be worth it.

devmach 12y ago

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.

rvdm 12y ago
Fully agree with devmach. Angular has a very similar problem and they know it. I think that one of the things we can expect from Angular 2.0 is a much larger example app. I'm ready to see the end of TodoMVC and the beginning of CMSMVC or SocialNetworkMVC or whatever. That said, I like the idea behind T3 and am very curious to see how it will mature and what adoption will be like.
apike 12y ago
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/
TheAceOfHearts 12y ago
I wrote a blog post[0] relating to this as well. If you're going to flaunt your framework as the next big thing, you should give real world examples. My unhappiness with angular is part of why I wrote this up as well. In their own docs they do things that are considered bad practices, they don't have readily available examples for how to test certain things, and they don't have any examples of how a "real" app should look. I'd love if people that put out these frameworks released a non-trivial app WITH tests, using the framework. I think Rails has done an amazing job with these things. Their guides are outstanding. [0]: https://blog.cesarandreu.com/posts/testing_not_as_an_afterthought https://blog.cesarandreu.com/posts/testing_not_as_an_afterth...

aikah 12y ago

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 12y ago
Is this what you looking for? https://medium.com/@addyosmani/javascript-application-architecture-on-the-road-to-2015-d8125811101b https://medium.com/@addyosmani/javascript-application-archit...

drew-y 12y ago

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

bsimpson 12y ago

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 12y ago
Feels like they could clean up a fair bit by making those modules as custom elements

ExpiredLink 12y ago

People here don't know Nicholas Zakas?

TheSisb2 12y ago
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.

hendzen 12y ago

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.

curun1r 12y ago
Luckily this doesn't appear to compete with React. This seems to be focused on composing a large-scale application from many different component applications. It's the kind of thing you have to do at large companies that have many different groups and are bad at communicating and collaborating on a single code base. React helps you simplify your view logic. The two should work together quite nicely. Just yesterday we had a meeting with the team at my company that's responsible for building the glue to allow our flagship product (~$4b profit per year) to be composed by independent releases created by independent teams that aren't always communicating on a regular basis. They built a library based on the whitepaper that was published by the main developer behind T3. At the time they started, there was nothing publicly available that served the need. But now, a company following in our footsteps will have T3 and won't have to waste the time that we did building it.
- Noobies 12y ago
  Yeah, doesn't compete with React. If React were being used client side only (not isomorphic) then one can roughly do stuff like https://gist.github.com/priyajeet/c2731789d3a688ee85a9 https://gist.github.com/priyajeet/c2731789d3a688ee85a9 (5-min hack)
- mparr4 12y ago
  Curious, what's the whitepaper?
steamy 12y ago
I'm currently hiring for developers with 3+ years of T3 experience. You should be one of these clueless HR managers (( 10+ years of jQuery Experience )) - Hello, jQuery wasn't around 10 years ago ... But seriously and with all due respect when will these people realize that the market for JS frameworks is INSANELY saturated and released products are ASTONISHINGLY optimized that there's no need for the time being to push yet another framework and torture us devs with the task to master it out of the fear of being left behind and feeling irrelevant skills-wise?

straws 12y ago

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

rubiquity 12y ago

Dear Box, April Fool's Day was two weeks ago.

ralmidani 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.

ivanb 12y ago

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.

msoad 12y ago

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 12y ago
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.

ssiddharth 12y ago

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 12y ago
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.

millstone 12y ago

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/modules/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!

glibgil 12y ago
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 12y ago
  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 12y ago
    I usually do something like var Constants = { valueA: function valueA() {}, valueB: function valueB() {} };
    - Mister_Snuggles 12y ago
      Why do you use empty functions instead of a number or a string?

idibidiart 12y ago

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 12y ago
It would be nice if you stopped spamming.
- visarga 12y ago
  Your comment made me curious and I checked his comment history. There is no spam there, just normal activity.
  - idibidiart 12y ago
    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.

TheSisb2 12y ago

Interesting approach. Thanks and congratulations on your release!

thegreatpeter 12y ago

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

lewong 12y ago
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.

Meai 12y ago

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

al2o3cr 12y ago

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

nell 12y ago

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.

lewong 12y ago

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

y1426i 12y ago

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.

thelastnode 12y ago

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/js/behaviors/todo.js#L123 https://github.com/box/t3js/blob/gh-pages/examples/todo/live...

romankolpak 12y ago

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?