27 ms·
Yahoo stopping all new development of YUI
- columbo 12y agoI know Wells Fargo went full-bore with YUI to the point of creating their own derivative (http://www.yuiblog.com/blog/2013/11/08/yuiconf-2013-an-amazing-two-days/ http://www.yuiblog.com/blog/2013/11/08/yuiconf-2013-an-amazi...) I have to say, enterprise companies like WF really have it tough. With thousands of applications and tens-of-thousands of developers by the time they implement anything it's already been rendered obsolete. At least they didn't go 100% Flex like some other companies
- lennel 12y agoFlex (for better or worse) is still widely used in the financial space. We started using the full google closure stack a couple of years ago and I am happy about that decision everyday.
- bellerocky 12y agoI was the person that initiated using the closure library for a team back in 2010. It took ages to release products using it, someone called it the "write more, do less" library and I have regretted the decision ever since, especially when Google came out with Angular which felt like a total slap in the face. Closure Library had half hearted support, and even teams inside Google hated it, which is why Angular probably came about. It felt like a slap because people that bet on Google supporting Closure couldn't just stop using it and start using Angular.
- DenisM 12y agoI feel for you. Same thing happened earlier to me with Google Web Toolkit. Frankly, it soured me on the whole third-party framework idea, seeing how it was impossible to predict which one will retain support over the years.
- lennel 12y agoIt depends on what your desired outcome is. Angular is not as solid, not as fast, nor is the whole product as able to be statically analyzed. Longer term maintenance is a pleasure with closure, adding new features a breeze, there are tons of exceptionally well tested components and I cannot stress enough how wonderful deep static analysis and dead code elimination is.
- tomjen3 12y agoI don't really think it is fair to compare Angular and Google closure. Angular is basically MVVM for the web, which is awesome because MVVM is awesome. Closure is OOP and "lets move heaven and earth to pretend we are still coding java, but with a weird syntax and lambda functions". It appeals to different needs.
- smackfu 12y agoIsn't this the big advantage of open source and Javascript in general? Even if the creator abandons it, you should have enough development resources to at least maintain status quo.
- deleted 12y ago[deleted]
- columbo 12y agoYeah it's the pro but the con (IMO) is that if you're the last active contributor then it has effectively become a custom framework... which nobody likes to support.
- SiVal 12y agoThat's not quite right. The advantage is that you (and others) are ALLOWED to do what you want with it (within license limits), but there's no guarantee that you have the resources to make use of that right. Even maintaining the status quo might require more resources than you have as the world evolves and bit rot sets in. It is nice, though, that open source leaves open the possibility that some other party can pick up the ball if the original developers drop it and you can't do it yourself.
- irae 12y agoThey chose YUI because of the current state of YUI and not because they believe on YUI future features anyway. So Yahoo bug fixes and security patches should be good enough for Wells Fargo for at least 1 year, maybe 3.
- Havvy 12y agoWells Fargo is big enough that they can spend resources maintaining their fork. Yahoo is no longer working on it, but if somebody else wants to pick it up, they can.
- pyrrhotech 12y agocorrect, Wells Fargo's market cap is 267 billion, 30% bigger than Facebook. They can pretty much do whatever they want
- StavrosK 12y agoHah, it's funny that the place that handles your money is only worth 30% more than the place you chat with your friends.
- gohrt 12y agoGood. They should be handling my money, not skimming it.
- cookiecaper 12y agoTo be fair, Facebook and other recent social IPOs are grossly overvalued.
- dasil003 12y agoPlus their "market"-share is significantly higher than Wells Fargo's.
- AJ007 12y agoTo be fair, banks may also be grossly overvalued. Their market valuations are entirely dependent on large government bailouts (although Wells Fargo was certainly in good shape relative to their peers in 08.)
- Alupis 12y ago
- JackFr 12y agoCompanies like Wells typically have governance policies and processes which expressly consider the scenario of the the open source 'vendor' ending development. Doesn't make it easier, but presumably someone considered the implications already.
- roel_v 12y agoHas anyone reading this ever worked at a place that had something like this (and was more than a paper illusion)? I think you're being overtly optimistic of big companies' IT practices.
- georgemcbay 12y agoIME, many big companies are so change-averse that an event like this is mostly irrelevant to their projects. Even if the external developer who was previously maintaining the library were still maintaining it, the project the big company is shipping would still be like 2-3 major versions behind with no immediate plans to upgrade. Having access to the source and the legal ability to modify it without releasing rights to their own IP is the only issue I've really seen big companies be wary about when it comes to using external libraries, and practically speaking that's probably all they should be worried about.
- buckbova 12y agoWorking at a large pharmaceutical, I can assure you this is real. There's a governance structure that rivals the size and budget of a medium sized business' entire software team's.
- jvagner 12y agoHe's not being overly optimistic at all. That level of consideration is very real at big companies.
- drcode 12y ago> I have to say, enterprise companies like WF really have it tough. I will code up and play the worlds smallest violin in reactjs today in their honor.
- joshmn 12y agoLooking forward to it.
- jgalt212 12y agogo easy on the grave dancing. For every framework, there comes a day like this.
- nine_k 12y agoIf a framework goes away because a clearly better alternative crops up, it is called progress :-) In 2006, YUI was a step forward compared to the general state of JS frameworks. Today ReactJS is a step forward compared to YUI. When something supplants ReactJS because it's clearly better, I hope, nostalgia aside, few people will protest.
- IgorPartola 12y agoI will bet $5 that you never had the experience where you build on top of a platform or learn to rely on a product and suddenly it gets taken out to pasture. Nostalgia is one thing, but realizing that the application that you are supposed to support and develop for years to come is built on a platform that no longer exists really sucks. It sucks in very real, very pragmatic terms, and for all the progress we can make in the general sense, the specific case of it happening to you is not going to be much easier just because there are now better alternatives and you have an excuse to start from scratch.
- nawitus 12y agoOne way to reduce this risk is modularization. If development stops for a single module, it can be replaced quite painlessly compared to rewriting everything because one relied on a monolithic framework.
- mildavw 12y agoI interact with Wells for some backend services. The only interface they expose is an IE-only java applet. Can't say I'm surprised they are lagging the industry by a decade.
- tracker1 12y agoSeveral years ago I worked on the redesign for the access request tools (ART in jQueryUI, and the backend system using ExtJS), it was a lot of fun, my understanding is ExtJS and YUI share some heritage. That said, I'm not really a fan of the likes of ext, yui or dojo... they're a bit bulky and unwieldy. Today, I've been working more on Bootstrap, React, Flux, Webpack and a few other bits... It's getting nicer all the time. I'm really appreciating JS front to back over other systems (.Net, Java) in terms of actually getting stuff done. Higher testing is pretty much required for a larger JS system, but modularity, npm, git etc go a long way.
- yeukhon 12y agoLinkedIn used to be YUI consumer too until 2-3 years ago they started moving away from it from what I heard. Occasionally I still see YUI tutorials but to be honest, the usage is quite low. At least the number of "mentions" today.
- abruzzi 12y agoYUI is used heavily in and enterprise application I work with (Alfresco). I wonder how this will impact them.
- maaaats 12y agoYUI, differently from the other big js frameworks, has been around for a long time and should therefore be "stable enough" and there's a lot of code examples and documentation around the web.
- preinheimer 12y agoI remember teaching a JS class with YUI like 9 years ago. At the time it was well featured, and had documentation that blew the competition out of the water. Good documentation was critical, I couldn't in good conscience teach a class where my students would be out of luck for more help after they left.
- BrandonM 12y agoWhy do people use "the number of [...] issues and pull requests" to measure the usefulness of an open source project? Shouldn't a project gradually trend toward maturity, when the vast majority of bug fixes and big-win features are already part of it? Is that really the best point at which to start spinning it down?
- ch8230 12y agoThey had to reference some usage metrics - maybe that was the least painful to acknowledge?
- slg 12y agoI honestly didn't know it was still actively being developed. It has long been surpassed by other options, but I do have some [mostly] found memories of working with YUI. In the early days it was a lot more feature packed than most other frameworks I tried. In the first big professional project I helped build some 7 or 8 years ago, I even fought to use YUI over jQuery. Maybe its time to send a mia culpa over to my old company...
- misterbishop 12y agoLooks like YUI is going to have bright years ahead!
- mythz 12y agoAbandonment is a risk facing any heavy "all-or-nothing" frameworks, not only is this bad for existing apps built on YUI, but it's also bad for developers skill set investments that will soon become obsolete. It's hard to imagine heavy popular frameworks like AngularJS falling to the same fate, it would need something far superior with a lot of traction to displace it. But it's still a risk if you build your application the "Angular Way", "The React Way" or "The Ember Way", etc where if the primary developers halt development for whatever reason, your app dev stack becomes obsolete making it harder to attract great devs (who don't want to invest in a dying platform). It's less of a risk with lightweight frameworks and libraries like Backbone.js where the code-base is so small and extensible, anyone can easily maintain their own fork. It's also less of a risk for WebComponents as the component model leverages the browsers DOM and lets you use modularized encapsulated components built with different technologies, so if one of the technologies ever becomes obsolete you can always start writing new components with newer tech and integrate it with your existing app, without having to rewrite it.
- Igglyboo 12y agoJust imagine if jQuery stopped development. Obviously someone would pick it up but if they didn't there would be a massive number of frontend skill sets becoming out of date.
- seanflyon 12y ago> skill sets becoming out of date To an extent. None of the people I know who use jQuery regularly would have any trouble adapting. They might be unproductive for a couple weeks. Large code bases that depend on jQuery seem like a bigger problem if for some reason no one was able maintain jQuery.
- SonicSoul 12y agomaybe i'm missing something, but I don't see jQuery as a massive skill-set investment. There is the selectors and the api, but it does overlap with a lot of other frameworks like underscore.js etc.. after switching it would be a matter of looking up the new syntax for a few weeks?
- laurentoget 12y agotumblr is an interesting choice of venue for an official yahoo announcement. you would think they could host their own blog.
- drgath 12y agoYUI did host its own blog, but it was shut down a few days ago. http://www.yuiblog.com/blog/2014/08/25/weve-moved-to-tumblr/ http://www.yuiblog.com/blog/2014/08/25/weve-moved-to-tumblr/
- Goopplesoft 12y agoThey own tumblr...
- nemothekid 12y agohttp://money.cnn.com/2013/05/20/technology/yahoo-buys-tumblr/ http://money.cnn.com/2013/05/20/technology/yahoo-buys-tumblr...
- Igglyboo 12y agoTumblr is their own blog. Yahoo owns tumblr.
- soseng 12y agoI work in Liferay Portal and AUI, which is a fork of YUI. Liferay will probably be impacted greatly by this. My company has done a few large scale Enterprise application implementations in recent years and continue to do more Liferay work (It's actually booming). YUI is a huge framework and not just a library. It contains a lot of neat UI Components and Utilities. Although styling the components and making them responsive always seemed tough.
- smrtinsert 12y agoAUI is kind of screwed. I remember it looking like an intentionally leaky abstraction of YUI. I would have used it had it not exposed so much in YUI. Liferay, meh they seem break stuff with every new release anyway :)
- kingmanaz 12y ago"Node.JS", "isomorphic single page applications", "npm", "bower", "Grunt", "Broccoli", "Gulp", "Backbone", "React", "Ember", "Polymer", "Angular", "Mocha", "Casper", "Karma", "evergreen web browsers", ad infinitum. While the above bouquet of random monikers may excite the cutting-edge startup developer, try pitching such an amalgamation to management in an enterprise environment. Inevitably, this week's fashionable web technologies will be supplanted by next week's fads. YUI was nice because it channeled the Borg in absorbing the good from multiple technologies while attempting to provide users with some form of a migration path, usually through its better-than-average documentation. YUI evolved. Many of the above technologies will be cut-and-run like the projects they supplanted last week. Perhaps the answer to this industry's flightiness will be found in the increasing use of transpilers. Javascript, with its callback-heavy code reading like so much thread through so many needle-eyes, does not seem to engender longevity in its creations. A framework built around something like gopherjs may be more libel to grow and adapt rather than becoming yet another abandonware.
- Igglyboo 12y agoWalmart uses node.js and it has paid off for them handsomely, I'm pretty sure they fit your definition of enterprise seeing as they have 2 million employees and close to 500 million in revenue yearly. http://venturebeat.com/2012/01/24/why-walmart-is-using-node-js/ http://venturebeat.com/2012/01/24/why-walmart-is-using-node-...
- dragonquest 12y ago> close to 500 million in revenue yearly You mean 500 Billion.
- studpuppy 12y agoI'm not sure what Walmart's annual revenue is, but I would guess it's a tad greater than $500 million :)
- tootie 12y agoI don't get that article. They are presumably not really using node client-side. It sounds like they just have a node backend. I'm guessig the use of node was coincident with them rebuilding from the ground up.
- rip747 12y agohonestly at this point, i think most people are using jquery with either jqueryui or bootstrap. Still its really sad to see such an established framework become EOL. Thank you Yahoo for all the work you've done on YUI.
- xsace 12y agoyeah jquery is not mentioned once but is maybe the single YUI killer here.
- conradfr 12y agojQuery was what killed YUI for me five years ago. Nowadays Angular is what killed jQuery for me (I still like to be able to use jqLite or jQuery if needed it though). I guess that (regular CS) pattern means that the next big thing will be a lightweight library (React ?).
- joeblau 12y agoI'm hoping they still continue work on Purecss. Pure is a far more manageable framework that doesn't come with all of the YUI bloat.
- juandopazo 12y agoHi! I'm a member of the YUI team. Pure is doing great and we're still maintaining it!
- jgalt212 12y agoThat's great to hear! Our shop will continue to do new dev work with it.
- ecaron 12y agoWhen teams halt development on projects, I really appreciate when they say "People should go use project X" instead. I know it is difficult to full their full-weight behind a single endorsement, but the team is obviously picking an alternative and since their followers trusted their original code they should trust the successor. It would be great if the YUI team stood up and said "We're moving to something, and think you should too."
- ceejayoz 12y agoGiven how many things YUI was composed of, I doubt there's one single "move to this" library out there. People aren't making these sorts of monolithic do-everything libraries anymore.
- EGreg 12y agoI am. http://qbix.com/EGreg/Q http://qbix.com/EGreg/Q just sayin' :)
- tnorthcutt 12y agoMessage on that page: "http://qbix.com/EGreg/Q http://qbix.com/EGreg/Q doesn't point to anything."
- irae 12y agoRight now the scenario here at Yahoo is mixed. We have teams using Ember and React, but no enforcement or recommendation to migrate any product based on YUI to any other technology. I guess Yahoo official support for any other library is very unlikely to happen in the near future.
- shawndumas 12y agoAll of the UI teams in Ads & Data are mandated to use EmberJS. Having said that, I do know of a team exploring AngularJS and know that ReactJS is ramping up in other departments.
- noelwelsh 12y agoAll is change. Only those who don't create don't create legacy. Abandoning YUI is a sensible move by Yahoo for a technology whose time has passed.
- jashkenas 12y agoThis is interesting, and more than a little bit sad, given that one of the big recent pushes that YUI had done was to build out their own "MVC" App Framework: Docs: http://yuilibrary.com/yui/docs/app/ http://yuilibrary.com/yui/docs/app/ Video: https://www.youtube.com/watch?v=wCexiX_eUJA https://www.youtube.com/watch?v=wCexiX_eUJA
- tuneladora 12y agoThat's from 2011, I'm not sure if that qualifies as 'recent' in the JS world these days.
- gorkemyurt 12y agoI wonder if YUI was solving any Yahoo specific problems, their goal (should be) is to make FrontEnd Dev easy for Yahoo employees not to build a framework that's a good fit for the rest of the world. So who cares if its losing traction in the open source community?
- jgalt212 12y agotrue, but running a highly visible and successful open source projects are viewed as good engineer recruitment and retention tools.
- gourneau 12y agoYUI still has the best data grid around IMO. Thanks y'all.
- jgalt212 12y agoI agree. That was the primary reason back in 2011 we chose YUI over jQuery (plus a variety of plugins).
- cousin_it 12y agoFirst they say: > New application frameworks (Backbone, React, Ember, Polymer, Angular, etc.) have helped architect web applications in a more scalable and maintainable way. Then they say: > The consequence of this evolution in web technologies is that large JavaScript libraries, such as YUI, have been receiving less attention from the community. Many developers today look at large JavaScript libraries as walled gardens they don’t want to be locked into. Huh?
- mikeryan 12y agoBackbone, React, and Polymer at least are component Libraries (Backbone can be used as a lightweight framework but its also a collection of tools) Ember and Angular are heavier weight but they do play well with others in different cases (there is definite lock in however with those).
- spankalee 12y agoIf by "component library" you mean a library of components, then Polymer is not a component library. Polymer is just a library that helps you write custom elements. The Polymer project has created two separate component libraries of elements made with Polymer - core-elements and paper-elements - but Polymer itself doesn't contain any components.
- armandososa 12y agoI think he doesn't refer to components as in "web components", but as small chunks of functionality. But maybe you already knew that.
- argonaut 12y agoEven the heavy frameworks (Angular, Ember) are significantly lighter than YUI.
- like_do_i_care 12y agoIn other news, a UI toolkit becomes abandonware. World still spins, over to you Kent for the weather.
- deleted 12y ago[deleted]
- _RPM 12y agoI thought YUI was obtrusive when I saw a line of code that looked like this: YUI.util.Event.addListener('el', 'click'...);
- juandopazo 12y agoThat was the good old YUI2. YUI 3 DOM code actually looked a lot like jQuery: http://www.jsrosettastone.com/#common http://www.jsrosettastone.com/#common
- jamesbowman 12y ago"Isomorphic". I do not think it means what Yahoo thinks it means.
- shawndumas 12y agoI for one welcome our new EmberJS overlords at Yahoo.
- clarle 12y agoFirst posted on /r/javascript, but I think it's worth posting here too: I was a member of the YUI team until a few months ago. I'm still at Yahoo now, just on a different team, but just wanted to give my own thoughts on this (I don't represent the company or the YUI team). My software engineering career started with the YUI team - I actually joined as an intern at Yahoo because of a Reddit post on /r/javascript. I was pretty new to engineering in general back then, and as a biology major with no real professional experience, I didn't have an easy time getting internships. Jenny, the manager of the YUI team back then, really took a chance on me, and that really changed my entire career path. I solved a bunch of YUI bugs, added a few features here or there, and I always tried to help other folks on #yui on IRC, the mailing list, or in-person here at Yahoo, which I really enjoyed. I learned a crazy amount of JavaScript, some pretty advanced debugging / performance profiling techniques, and even gave some talks. Eventually, a lot of people always came to me first whenever they had a question about YUI, which was pretty cool. From the view of some people in the JavaScript community, YUI was always considered a huge, monolithic framework that was only good for widgets. I never thought that was the case - YUI pioneered a lot of the techniques that are popular in advanced JavaScript development today, like modules, dynamic loading, and creating logical view separation in your code. A lot of the influence in RequireJS / CommonJS / ES6 modules can be seen from what YUI did first, which people used to consider "over-engineering". With a lot of new development in JavaScript though (data-binding, tooling like Grunt / Yeoman, promises and other async handling techniques), it was always hard for YUI to keep up with new features while still being able to maintain backwards compatibility with the constantly deploying products that people were building at Yahoo. We had to support product teams while also building out the framework at the same time, and making sure the user-facing products were the best was more important. Eventually, it was hard when developers who were familiar with newer JavaScript tools tried to use YUI, but ended up having to spend quite some time with the framework just to get it working with the rest of the JS ecosystem. In the end, I wasn't involved with this decision, but I think it was the right thing to do. A lot of the YUI (now YPT) team and other front-end teams at Yahoo are now working on helping out with more cutting-edge core JavaScript work, like internationalization (https://github.com/yahoo/intl-messageformat https://github.com/yahoo/intl-messageformat) and ES6 modules, as well as building out components for newer frameworks like React and Ember (https://github.com/yahoo/flux-examples https://github.com/yahoo/flux-examples). Yahoo still has a lot of really strong front-end developers, and working on these more important core components is more beneficial to both Yahoo and the JS community as a whole, than continuing to maintain a framework that's a walled garden. The one thing to take away from this is that no technology lasts forever, and in the end, what the user sees is the most important, whether it's JavaScript, Android / iOS, or holographic smartwatches. I'll be a bit melancholy today, but I'll raise a glass to YUI tonight. RIP.
- Touche 12y agoDojo is next. When is that going to happen?
- pesto88 12y agointeresting to see what Squarespace is going to do in response to this
- progx 12y agoGood decision and there is no further argument to say, you wrote everything in your post. Hope Yahoo continue to develop more smaller libraries, purecss is a really nice example for a small clean project.
- dmitrygr 12y ago[...] Node.JS [...] JavaScript [...] isomorphic single page applications [...] npm [...] bower [...] ecosystem [...] use cases [...] Grunt [...] ecosystem of plugins [...] Broccoli [...] Gulp [...] cohesive [...] Backbone [...] React [...] Ember [...] Polymer [...] Angular [...] Mocha [...] Casper [...] Karma Reading this buzzword soup makes me so happy to be an embedded guy who gets to work in C i think i'll go dance a little just to celebrate. Wow... seriously just wow...
- optimusclimb 12y agoBuzzwordy...maybe, but most of those ARE things you would be using every day to build the modern web based apps that millions of people use daily. You don't think dealing with those might be worth it to people to develop things like Soundcloud, Hipmunk, AirBNB, etc? I'm not a front end dev, but cmon - how can you not use some of the slick, modern, browser based apps these days and not think back to Windows 3.1, or Lotus Notes, or...anything from a decade ago and not just smiler at how nice the experience can be when done right? I guess if you never want to expand past the 32 keywords of C forever, then sure, celebrate.
- Gigablah 12y ago15/20 of your "buzzword soup" are simply names of languages, tools or libraries. You're being disingenuous here.
- sam-mueller 12y agoI 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! --Sam
- jumbotumbo 12y agoAt 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.
- zmmmmm 12y agoMakes me a bit sad, I built some very detailed and rich products on YUI. It was, at the time, the most well documented and comprehensively supported (for browsers such as IE6)framework around, and it had a complete set of widgets for every task. It was one of the few completely free JS frameworks I could show to enterprise and professional customers and not be embarrassed about. Unfortunately YUI3.x was a complete derailment for me. They tried to match the expressiveness of jQuery (which they only half achieved), but along the way the documentation got much worse, and half the widgets I was relying on disappeared and never got migrated to 3.x (with the excuse that you could run legacy 2.x alongside 3.x - do not want!)). I invested a lot of time, sweat and tears into this library and ultimately it turned out to be a big negative as my resume suffered from not having more light weight technologies like jQuery on it.
- tszming 12y agoThis is the right approach to sunset an opensource project from a big company, so people don't need to discover the project is dead by checking the last commit date, which happen quite often these days especially when the key developer of the opensource project left the company.
- jdelic 12y agoThe one thing that YUI does better than any other library is isolation. You can have multiple versions of YUI in the same page, each sandboxed against each other. That means that if you deliver JavaScript for other developers to include in their pages, YUI is an awesome framework or even the only real option. Thanks to YUI Loader it's even self-repairing. jQuery's noConflict is a far cry from that. Can any if the other libraries mentioned here (especially the newer ones like React and EmberJS) provide the same thing? When I read threads like this and I see pages like polygon.com that pull in tens if not hundreds of external JavaScript resources, I always think that the YUI sandbox model is still 5 years ahead of the status quo in other libraries. Again, does anyone know here of alternatives for sandboxing?
- ec109685 12y agoThe problem with that was that performance sucked when there were too many sandboxes, so the first thing teams did was combine into one yui instance, defeating the purpose.
- onlywei 12y agoThere are some core YUI methods that I think were really good. The one that comes to mind the most is Y.extend(), which is different from _.extend() in that it actually subclasses a class for you, and not just "mixes" two objects. I know some people have some kind of hate or disgust for JavaScript's emulation of classical inheritance in this manner, but I liked it a lot!
- Morcane 12y agoWell, time to learn a new thingy I guess. I've used YUI with tons of pleasure over the last 3 years, and am sad to see it go away. Here's to another 2 years of heavy influx prototyping, refactoring and writing everything over again (I'm an enterprise developer).