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.
In regards to your job posting, I represent a firm of talented coders in India all with 3+ years of T3 experience. We can do the needful for your Java app.
Sorry, so, you're telling me that picking a subset of developers from a nation to represent the entire nation's developers should be found funny? I disagree.
How quick is "too quick"? I never knew there's a velocity associated with this issue. In the rest of the world, we call out racism almost immediately when we see it.
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.
I wonder if you've looked at riot.js[r]? I ask, because I've so far steered clear of js-heavy front-end development -- and in my search so far, it seems the best among simple, plain js frameworks. I'll probably end up playing with elm, or do something with clojure-script -- but riot.js checks a lot of boxes:
* Is dogfooded for a real app by authors (muut.com
Discussion-as-a-Service)
* Is small (code size and file size)
* Is simple
* Avoids(?) being simplistic (too simple)
* Has an idea of components
Maybe not enough though... looks like js is rediscovering object-oriented MVC design slowly (a sane way to keep the html templates, the event listener/handling code and any needed css in one place).
I think polymer might be the closest alternative, but muut has a comparison that doesn't speak too well for polymer: https://muut.com/riotjs/compare.html
Just out of curiosity, what constitutes a holy grail framework in your opinion? Has the holy grail of back end framework been invented? Is it ruby on rails or django? How about the holy grail of database engine, build system, etc.
I don't think there's exactly one way of doing anything, there may be leaders in some spaces but I doubt any of them are considered holy grails. Pick the tool that best fits the problem at the time and don't wait for a potential holy grail in the future.
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.
Sorry but this is the kind of attitude that hinders progress. I often hear people say "don't use a framework, make your own", well these guys did and they released it for free, I don't see the problem. No one is forcing you to use it. Even if T3 has one good new idea that gets integrated into another framework then it's already a win.
The point of the "don't use a framework, make your own" is that your needs are different enough from everyone else's needs that it's worth writing code just for your needs. The problem with releasing a framework is that your needs are different enough from everyone else's that it's not worth releasing that code.
Personally I'm glad that T3 released their framework - it doesn't harm me, after all, and they did all the work - but I think some people have unrealistic expectations on the value of code re-use. The problem is the economic incentives in the software market: chances are, if your problem is close enough to somebody else's problem that you can re-use the bulk of their UI code, your market is too undifferentiated for you to exist as a separate company. When frameworks do attain market success (eg. JQuery in 2006, when IE6 was the dominant browser, Firefox & Safari were brand new, and Chrome didn't exist), it's usually because the big company in charge of the overall platform has been asleep at the wheel, and then the need for a framework disappears once they get their act together and start moving the platform forward (eg. JQuery in 2014).
In the world of Enterprise software (which is where most of the money actually is), most peoples needs _aren't_ that different. Basically everyone is writing CRUD + data summaries.
I'm curious as to why you think JQuery is a framework. From my view of things, it seems to be a library in all definitions I've encountered.
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.
Oh poor you, all these people providing you with free tools. If it solves your problem, use it, if it doesn't don't.
If you don't want to take the time to figure out if it will actually be useful for you, wait for early adopters to kick the tires, write blog posts, etc. Then if it gains enough critical mass, and it seems to solve your problem much better than how you previously did things, use it.
Oh poor you, all these people providing you with free tools. If it solves your problem, use it, if it doesn't don't.
Do you really believe that the motive behind this charity is 100% altruistic?
Oh man, I gotta an ocean front house in Arizona to sell ya!
Joking aside, these people publishing and releasing these frameworks to the public at min looking for reciprocal treatment in terms of improvements to their product made by the community and the general adoption of it by wide segments of the community making it easier for them to recruit and integrate new team members with minimal costs in training and sunken costs.
So, this symbiotic relationship between us devs and these corporations is neither altruistic nor patrimonialistic
Yeah, no, you don't make a project open-source and expect people to improve it as much as you will. It just doesn't work like this.
An open-source project is a burden, you probably won't gain anything from them, and will probably lose a lot of time. Almost all of my projects are OS, but I don't do it expecting people to come over and help (even if it is sure nice when they do).
"Furthermore, there's nothing preventing us from using Backbone, React or another framework in addition to T3, if we so desire."
PS nobody goes out and rewrites their app just because a new thing came along. This performative exasperation with the amount of options in JS-land is getting old really quick.
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?
Since everything has a price, there will be market for it.
Anybody who wants can use it, anybody who doesn't please don't let the door hit them on their way out.
I guess that you might know that we devs don't have the final say on all of this. Clients or employers dictate in one way or another the way to go with front end web dev. If it were for me and I guess many devs, we'd just settle for one or two frameworks max. and just ignore the rest and their existence.
"Us devs"? You act like the people writing open source frameworks are not developers. Far more productive than you perhaps, but developers nonetheless.
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...
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/
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.
YES! Agreed 100%. Biggest irritation in my life with regard to doing anything with Javascript is when some library talks about some miracle function, then the example is like:
miracleFunction() {
alert("It works!")
}
ARGH. Give me an example of what the body of miracle function should look like!
Totally agree. The problem with a Todo app as the prototypical example is that a 'todo' item doesn't really have any nesting whatsoever. Something like a list of Album/Tracks is much more illuminating about a web framework for anything that has a web form or model.
Absolutely. As a fellow Angular (2 years) developer, I've become familiar with the actual pain-points of real SPA apps. When I started I didn't have a clue, but jumped straight in because the Angular examples seemed awesome. It's time to switch, but I'll be way more careful this time.
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!
If you have static analysis then it makes sense to use types instead of strings. If you don't have static analysis then there isn't much motivation which is why you see strings everywhere in unanalyzed JavaScript.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?)
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.
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.
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?
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.
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.
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.
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).
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.
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.
> 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.
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.
PS: I'm currently hiring for developers with 3+ years of T3 experience.