| 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. |
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.
It's just sad that there's still only one, four year old book on Closure. I'm sure the library's evolved since, JS sure has: http://shop.oreilly.com/product/0636920001416.do
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.