I think Yahoo is moving in the right direction on many fronts, and this decision is definitely welcomed within the company. At the breakneck pace of the web, every framework must eventually meet its demise; YUI is no different.
As the person who first brought Ember to Yahoo a year ago, I can tell you that both the mood and perspective towards SPA development has changed significantly; it's refreshing. Developers are definitely beginning to embrace the direction of web components, and the majority now see the value that these newer frameworks provide.
There was a time (not too long ago) where Yahoo mandated the use of YUI. We are now seeing the pendulum swing in the other direction, and teams have more freedom to choose which framework works best for their situation.
Out of all the modern SPA frameworks, Ember is currently leveraged the most right now here at the 'hoo, with almost two dozen projects using it. This is mainly because our division adopted it early, and we were fortunate that our UI engineers were able to get over the learning curb and build some impressive apps pretty quickly. Besides Ember, there are pockets of Backbone and even Angular apps. However, it's pretty clear that the YUI team is especially intrigued with React right now, mainly because it is the most lightweight (again, pendulum) and allows more freedom for the developers to do things their way without opting into a more opinionated framework.
Some on this thread have expressed that they wished Yahoo would have recommended an alternative. Well I can give you my personal answer:
Choose the best framework that fits the job.
Each brings its own strengths and weaknesses, and the best approach you could take is to understand the nature and scope of your project to know which one makes the most sense for your needs. For example, many projects at Yahoo have a ton of code that can't immediately be replaced or refactored. For those projects, React may make more sense because it only solves just one piece of the puzzle (albeit very well), and can add a ton of incremental value. If you are starting a project from scratch, choosing Ember or Angular might be the better choice if you want a more mature framework that addresses the many facets of SPA development. We happened to put more weight behind Ember for our greenfield projects because it provided more structure than Angular, and that helped us immensely when our apps grew in complexity.
It's really great to see the state of JavaScript development in 2014. Even though we are losing a great framework in YUI today, the future does indeed look bright. Cheers!
At the moment I don't see many alternatives that offer what YUI offers to small one or two person development efforts. Larger, more well resourced projects can afford to go with a framework+whatever-small-libraries-they-need approach. Smaller outfits don't have the developer resources to provide the time required in dealing with the testing/bugfixing/integration issues of third party code required by this approach.
It sounds like the general consensus is that YUI has gone the way of the dodo because it was too monolithic. Monolithic has a lot of advantages to small dev teams who don't have the development bandwidth to waste time on code quality issues in code outside what they are actually writing.
YUI provided a well tested monolithic framework, where you could be confident everything you needed worked , and more importantly worked in combination with all the parts of system, something the 'take a bit from everywhere' approach makes hard to guarantee, unless you want to be responsible for fixing other people's code yourself.
Those congratulating Yahoo on how this was handled should consider that in hindsight it has been obvious for quite a while that Yahoo has been planning the abandonment of YUI. It is clear this announcement has come many many months after a decision to shift resources away from YUI was made. I personally have a lot more code to transition to a new framework than would have been the case had Yahoo been more open and honest with their plans earlier than it has been.
I'm now 80% through a transition from YUI2 to YUI3, a choice that seemed like a wise decision when started, but had started to look increasingly stupid as Yahoo continued to back away from YUI over the last 12+ months, and with today's announcement looks just plain dumb. Just as I was approaching the point of being rid of YUI2 legacy code, I now find I've simply moved to a new legacy code base as of today. Yes, change is inevitable, and there had been warning signs, but change is a lot easier to manage if those making the change decisions signpost the way a bit more clearly.
It is also clear today's announcement was the result of Yahoo's hand being forced by continuing concerns expressed by the community, and some recent tweets by ex-team members. Those tweets finally made it obvious that what the community was fearing was actually true - despite reassurances from within the dev team that things were ok. Why not tell everyone when the stepping back was first planned, rather than waiting until it had become so obvious, that the lack of announcement was simply an ongoing embarrassment?
Can anyone recommend a single library source (i.e. "monolithic" library/framework) where everything is tested together that provides the YUI elements I've most relied on:
- Widget framework (datatable, tabview, charts, calendar etc).
- App framework (but also ability to work well outside a single page application mindset).
- Combo Loader
- Custom event system.
- Convenient dom manipulation
- Normalised behaviour across wide range of browsers, including handling for both mobile and desktop interactions with the same code base.
Supported by a large corporation would be great (I liked the fact that YUI was used at scale at Yahoo), but also having a large actively contributing external community to carry the project along should their corporate sponsor decide to move on would be very handy too :-)
Finally, a thanks to all the devs on the YUI team over the years that made the library as good as it was. A special thanks for the efforts put into making it easy to write self contained modules with YUI3, something that will make the migration to whatever I move to next a good deal easier than it could have been otherwise. It is nice to see that the YUI team's modularisation efforts will live on in their influence on the ES6 module standards.
> Can anyone recommend a single library source (i.e. "monolithic" library/framework) where everything is tested together that provides the YUI elements I've most relied on: - Widget framework (datatable, tabview, charts, calendar etc). - App framework (but also ability to work well outside a single page application mindset). - Combo Loader - Custom event system. - Convenient dom manipulation - Normalised behaviour across wide range of browsers, including handling for both mobile and desktop interactions with the same code base.
Google Closure? I suspect it will continue to evolve/be supported even if things shift quicker than anticipated from today's Angular.js-Directives middleground to Polymer/Web Components.
And whatever Microsoft's building these days on TypeScript. I wouldn't count them out. I expect they'll get about as much traction as Dart. Not yet sure which I'd bet on though. They're both very different from the plain JS suggestions above, or Facebook-style React.js and both used heavily internally on different projects, I think.
An alternative from back in the day, for an "enterprise-supported" framework would perhaps be Sencha's tools. IBM and maybe others, use Dojo. But I'd bet on TypeScript and Closure surviving and evolving more, at this point.
But that's kind of the point. Everybody's contributing code that works for them. Consider Netflix's RxJava/RxJS which they took from Microsoft. It's not really integrated in any framework as a pattern, so if you want to use it, you kind of have to abandon or refactor all your other libraries. And all this stems from the relative immaturity of the browser environment to abstract out these widgets. Not to say things will become perfect in the future, but when you've display libraries reimplementing the DOM, something's definitely broken here and could use fixing in the future. Eventually.
As the person who first brought Ember to Yahoo a year ago, I can tell you that both the mood and perspective towards SPA development has changed significantly; it's refreshing. Developers are definitely beginning to embrace the direction of web components, and the majority now see the value that these newer frameworks provide.
There was a time (not too long ago) where Yahoo mandated the use of YUI. We are now seeing the pendulum swing in the other direction, and teams have more freedom to choose which framework works best for their situation.
Out of all the modern SPA frameworks, Ember is currently leveraged the most right now here at the 'hoo, with almost two dozen projects using it. This is mainly because our division adopted it early, and we were fortunate that our UI engineers were able to get over the learning curb and build some impressive apps pretty quickly. Besides Ember, there are pockets of Backbone and even Angular apps. However, it's pretty clear that the YUI team is especially intrigued with React right now, mainly because it is the most lightweight (again, pendulum) and allows more freedom for the developers to do things their way without opting into a more opinionated framework.
Some on this thread have expressed that they wished Yahoo would have recommended an alternative. Well I can give you my personal answer:
Choose the best framework that fits the job.
Each brings its own strengths and weaknesses, and the best approach you could take is to understand the nature and scope of your project to know which one makes the most sense for your needs. For example, many projects at Yahoo have a ton of code that can't immediately be replaced or refactored. For those projects, React may make more sense because it only solves just one piece of the puzzle (albeit very well), and can add a ton of incremental value. If you are starting a project from scratch, choosing Ember or Angular might be the better choice if you want a more mature framework that addresses the many facets of SPA development. We happened to put more weight behind Ember for our greenfield projects because it provided more structure than Angular, and that helped us immensely when our apps grew in complexity.
It's really great to see the state of JavaScript development in 2014. Even though we are losing a great framework in YUI today, the future does indeed look bright. Cheers!
--Sam