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
I will code up and play the worlds smallest violin in reactjs today in their honor.
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.
They're richer than Facebook, sure. But at many non-tech companies, spending tens or hundreds of millions of dollars to build a solid library is simply not in the cards. (Why should we spend so much on engineers? All they're doing is slapping together some HTML, my nephew in high school does that!)
Hasn't been the case for years (and I'm pretty sure it was never the case actually). They are valued by their assets (funds in accounts, real estate holdings, equity in companies/investments, etc). Facebook's valuation appears to be based on nothing but magic.
In other words, such valuation of a big corporation has little to do with the direct utility to, or meaning for a single individual.
It's like a red blood-cell wondering why the eye is so highly valued compared to the liver.
And this is the most ridiculous thing in those bailouts. You manage responsibly and competently and, in return, you get government funded competition.
There should be a better way.
When did Facebook become the benchmark? Facebook is tiny compared to an awful lot of companies.
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.
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.
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.
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.
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.
Occasionally I still see YUI tutorials but to be honest, the usage is quite low. At least the number of "mentions" today.
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).
I'll be a bit melancholy today, but I'll raise a glass to YUI tonight. RIP.
Also, super excited about the work Yahoo has been doing with React. Keep it up!
+ New devs can soak up a ton of knowledge quickly.
+ New devs don't come with a lot of baggage and tend to enjoy trying lots of new things.
+ New devs brought new ideas to the team that often challenged traditional ways of thinking.
+ While veteran devs acted as mentors and shared best practices.
From a recruiting standpoint, it's also easier to find new developers than veteran ones. So many companies fight for experienced talent that they overlook inexperienced talent, which meant I could assemble a good team relatively quickly.
It changed the recruiting process quite a bit though. Interviews became more about assessing potential and ability to learn than existing skills (which I think is more important anyways). It's not easy to assess for these things though.
It also changed the training process and team dynamic. The environment was one of constant learning and collaboration. New ideas were welcomed, code reviews were frequent, everyone was encouraged to hold a quick informal brownbag session on something they learned (even if others were known to be the "experts"), formal mentoring programs were established, etc.
And it made the veteran hires even more important. These devs needed to not only be strong technically, but strong with interpersonal skills too. But someone who can do this and support an inexperienced team with lots of potential is worth their weight in gold.
A lot of good developers emerged from this process. And I should add that new != young developers. There were some devs who changed careers to become devs, and shared the same energy and ability to learn as recent college graduates.
Cheers to people like you!
You know... It's still open-source.
If not even Oracle could manage to kill MySQL, I seriously doubt there is a way to kill YUI.
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.
bower is also a package manager, IIRC. I'd avoid it.
Isomorphic single page apps seemed to be buzzwords to me.
Grunt, Broccoli, and Gulp are all tools used to create build scripts in the Node community. You only need one, and you could pick Grunt or Gulp with a coin flip and not be worse off.
React, Backbone, Ember, Polymer, Angular...they're all client side JS frameworks. IMO, go with React if you want stability. But in any case, this is what you would use instead of YUI. And these tools work well with the rest of tools Yahoo mentioned.
Mocha is a unit testing framework. You need some testing framework, and this is a good one.
Casper...I think that's a headless web browser. Not sure, I've never used it.
Evergreen web browsers is a buzzword for the practice of Mozilla and Google of putting out updates every 6 weeks. It's a state of the environment, not a technology.
The explosion of tools in the JS environment started with Node.js. It was a critical point in the history of JS, and it means that if you want higher quality software, you have more tools to do so. Make sure you aren't choosing tools because they are trendy, but because they solve a problem you are having.
How would you describe a single-page app that is pre-rendered on the server? Hmm, maybe "pre-rendered" would have been a better term than "isomorphic".
It's an abstraction and utility library that sits in front of headless web browsers.
If you eleminate all the serverside tools, then you only need a framework (AngularJS for instance) and a testrunner ( like Jasmine,you can even run it on the browser directly). You might need a tool to minify code, but gzip compression,a cdn and caching are often enough to reduce the load.
I remember being is such a "pitch" meeting once with relatively senior managers. They were discussing the difficulty integrating some components of a client side web framework, and I recall some developer excitedly announcing how some <insert random moniker> by <some random hacker> had come out just 2 weeks ago on Github that would solve all their problems.
The looks on their enterprisy faces was priceless.
You mean 500 Billion.
And if you want something enterprizy just tell them you will be using Google Closure which looks enough like Java that they are going to leave you alone.
What "management" makes these kind of tech decisions? Sounds like a flawed management structure.
It would be great if the YUI team stood up and said "We're moving to something, and think you should too."
I guess Yahoo official support for any other library is very unlikely to happen in the near future.
just sayin' :)
Perhaps that wasn't the smartest architecture decision made. Now, don't compound it by rewriting it in the same deeply coupled way for the next shiny framework that sashay's by.
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.
To emphasize the "still a risk" part: Angular is only four years old, and its popularity is arguably only two years old. People are just barely starting to get a feel for the advantages and disadvantages of building the Angular way. There's some significant things to like about it, but there's absolutely no guarantee those things won't be subsumed into something else or devs won't decide some other way is better, either on the merits of careful thinking or enthusiasm for a fashion of the moment.
(If someone had told me 10 years ago, for example, that relational databases were soon to fall out of vogue for hierarchical/document databases or key-value stores, I would have said history seemed to be against them, but here we are.)
This is software, ephemeral foundations and vicissitudes are pretty much a given.
I promise you this is some sort of bias you have. Relational databases are still used way more frequently than NoSQL databases, probably to the tune of 1000-10000 times more.
Many of you have already seen Kovacs' comparison of nosql stores. Just throw a SQL DBMS into the decision matrix. Consider how several might work together.
Fowler's microservice post is a decent introduction to the microservice architecture, which is more or less what I'm describing.
Granted, this probably isn't how to get the MVP out the door. But once you grow, this architecture can prevent the formation of monoliths of pain.
Those who don't learn from history are doomed to repeat it.
Personally, I have found react.js to be much better than Angular but in any case I found your comment to be filled with a heavy use of unwarranted intensifiers ("far superior") and some amount of fortune telling.
Front-end development is a fast moving field, and the new ECMAScript 6 changes, as well as further browser updates, will probably shake up the scene, but it's hard to predict what will happen. I doubt that we'll reach a point of stability any time soon where you didn't have to throw out at least some decent amount of code after 5 or 6 years due to library changes and browser updates.
This is a tangent, but can you explain why?
In my opinion the approach that React takes (as well as its siblings like Mithril and Ractive) will eventually be the default approach, even for the bigger frameworks (new or 'refactored').
Angular has some fair parts (testing, resources) and some really convoluted and what's more important bug ridden parts (directives and scopes).
Do you want composability? Write a bunch of element directives and nest them -- it'll end up looking almost exactly like React's classes and components. The main difference is that in React you throw away MVC and replace with with a big ol' render() function that spits out "HTML" (well, a shadow-DOM version of it anyway)
Scopes are just objects that use prototypal inheritance to
inherit from outer scopes. Create an new (isolated) scope in your directive to isolate data to that component and its subcomponents.
Also, using AngularUI Router is essential.
As for composability they did not seriously thought this through. One bug I found out, the one that got fixed, showed up for anone who created two directives with isolated scope and transclusion, one used in template of the other. Basically isolated scope of outer directive got transcluded into inner one instead scope outer in relation to outside directive.
Scopes suffer from the same flaws that with() statement in js suffers mainly that when you assign inside it will be assigned not where you at first expect (current leaf scope not the scope of closest controller). When you add to this the fact that humble ng-model assigns you have a huge hole that nearly all newbies fall into at least once.
Another gripe is that angular doesn't eat it's own dogfood. For example ng-required is not a directive. It's just attribute parsed internally by input directive.
AngularUI router is worthless if you need to have multiple tabs inside your web app as it allows you to have just one branch of views tree shown at any given time. There are suggestions about implementing parallel subviews but last time I checked it was too hard for them.
Angular is set of legos with lots of weird pieces. React is blueprint how to make your own bricks so they fit together and won't turn into tower of ugly chaos when assembled.
I was distrustful towards virtual dom at first. But that's just a way of batching and saving dom changes. The architecture that's enabled by it is all about composability and maintaining control over your project.
UI Router states are pretty tightly bound to the URL fragment path, which makes it difficult to point to all the parallel states that make up that particular view "configuration"
Say you have a page /foo that shows two sets of tabs, A B and X Y. To point to foo with tabs A and X open, you need put that in the URL, e.g. /foo/A,X, or express it as a state path foo.A,X. It gets even hairier if you then want to activate children of those states, e.g. A.a and X.x.
You could implement your own subview routing with ngSwitch and stateParams (perhaps query parameters). It's obviously not a great solution.
I think that this particular example shows that rather than extending framework of directives to nicely incorporate lightweight directives such as ng-required angular team chose to hack it into input/select/textarea directive because it was easier that way for them. There are many places like that in angular where the hacky path was chosen and due to this, architecture is lacking some of very obvious features like one-way binding of expression given in attribute to isolate scope (which is what ng-requried does to get it's value). You need to use & as workaround to achieve one way binding.
As for Angular UI as I said there were people that wanted to figure out how to implement tabbed views but they got no love from core developers. Basically recent advice about using UI Router to implement tabbed app is "Don't".
So I just went to implement my own stuff with $route, $routeParams, $location and ng-include.
Simply put, no. React.js can be treated as a simple, dumb view or part of something larger ala Backbone, Flux, etc..
Angular.js doesn't even have a model layer aside from $scope, which in my experience is being thrown away more and more in favor of controllerAs syntax & convoluted services masquerading as 'models'
Personally I'd go for company-backed projects.
The problem with GWT is that newer Google-associated projects are perceived by some people as better (and the comparison is not always apt): Web Components, Polymer, Dart, Angular, etc.
But that doesn't somehow make GWT any _worse_ than it was before, and it's still improving. The compiler is faster, they're adding Java 8 features like lambdas, the JS interop is better, they're tracking web APIs closer, and I think they have a even plan for web components integration.
I used to use GWT extensively, and I would be one of the ones to argue that it's approach was great at one time, and probably a bit outdated now, but it's not abandoned and it's evolving to fit better with today's modern browsers. I might not choose it today, but I wouldn't regret choosing it a few years back, or be in a huge rush to move off of it if I had a large codebase.
I still believe it's doomed though just because I don't believe they can match the pace of the JS world.
The Chrome Dev Tools or Firebug are >>> the GWT debugger. The GWT Dev Mode plugins required for debugging, is also no longer supported in Chrome, and soon in Firefox. (I discovered this last week, the first time I've touched GWT in half a year. There's a newer Dev Tools alternative, but I've been unable to actually get it working.)
In summary, GWT was awesome, but I see no reason to use it today. It helped me find my current job, so I'm grateful for that. However, if you were looking for a web framework, you would be much better served (IMO) if you chose React, Angular, or Ember rather than GWT.
At the time I loved using it as it had many nice features. But sadly it's very hard to migrate from. Most importantly is the vendor lock-in with the 2 framework specific RPC mechanisms used to communicate to the server.
> Personally I'd go for company-backed projects.
You mean company-backed projects like YUI?
Of course if you chose YUI a few years ago and you're still using and relying on it, that means it is still serving you well. Was a great past decision ay?
Analogy if the goal is to go for a smooth car drive, why would you want to stop and be replacing/reinventing wheels every few minutes?
The trouble is that people often use examples of what you can accomplish with a framework if you follow the common path. But we've all been there -- a 20 hour feature where you build 90% of it with heavy framework support in the first 10 hours, then spend the next 10 fighting the framework for whatever it is that you need done differently than the framework prescribes. This blunts that seemingly-huge time save that a framework appears to provide when you watch a 5 minute build-a-blog screencast. So in the end, it comes, as it usually does, to mastery. The guy who has developed mastery over his tools will outperform, and I think it's a lot easier to master these small libraries with accessible source code.
This misses the point. A good developer, in my mind, has the ability to adapt regardless of they framework they choose. The only risk is really the one who chooses not to adapt, regardless of the way their CV is positioned at any one point in time.
That being said, COBOL developers still get paid $100's of dollars per hour in today's environment due to legacy software holders.
This is the kind of snake oil that's been sold to developers for decades. We never (collectively) seem to learn.
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.
Because you need to learn that framework.
And the new packaging system.
And the new *SQL database.
And SASS, LESS...
And the new test framework
And another build tool.
And a new programming language.
And understand the business logic of the new client.
And sleep 8 hours, exercise, see your friends, spend time with your gf...
Modern web development could be overwhelming, I'm still young and willing to learn but I totally can understand why some people stick with "old" technologies.
when i do read/code outside of work, i either focus on high level design pattern usage or on increasing knowledge of obscure js/css performance hacks. e.g. angular is dead-simple to write code for once you pay attention the patterns behind it instead of the conventions/syntax. otherwise it's a mess of hacked together code and googling for a better way to do what you're trying to do.
frameworks come, frameworks go. learn the foundations well and the rest of it matters a whole lot less.
If you never want to learn anything new, then be my guest, but I don't understand those developers.
Besides, developers should learn new software all the time, not develop with YUI for five years and suddenly learn everything at once.
But I would say to those people that if the maintainers of your favorite library are saying that there are better things out there, then you have reason to learn new things.
A framework is just a tool to abstract some complex/repetitive tasks and work faster, but they're in no way a replacement for the language they're written in.
For example, jQuery.ajax(), you should not treat it as a black box, and pretend everything is done by magic.
You should at least understand the process behind it: Creating the XMLHTTPRequest object, setting the onreadystate event to check if the request was successful, etc.
If a feature brought by a framework is good enough, it will be added eventually to the language, ex. document.querySelectorAll().
That's not true.AngularJS allows a total an clean separation between AngularJS and your code through dependency injection.
It means that your code can be totally decoupled from the framework (even the directives).
That's not the case for Backbone,Emberjs and others.Their first sin is the use of Active Record,which means vendor lockin,and over reliance on inheritance (Backbone.Model.extend ... )
A few month ago I had to make some business logic work in a webworker,without duplicating it ,nor using angulars,in an angularjs project. Because AngularJS uses an IoC container,it just worked,the only thing I had to do is to manually wire up dependencies,but the same code worked without a single line of Angular code.
Backbone and Ember suffer from the same "rail's way" problem.AngularJS is a good compromise between configuration and conventions without Active Record .
People often say Backbone is "lightweight" ,actually I think AngularJS is lightweight compared to Backbone,and that's why it is so successfull, with one lib, one gets everything one needs to build small apps as well as large apps,without all the boilerplate.
Edit: Oh and it isn't polite to write things like "That's bullshit", then come back and edit it out later on without flagging that you've edited your code.
React and Angular are both able to avoid those.
> Edit: Oh and it isn't polite to write things like "That's bullshit", then come back and edit it out later on without flagging that you've edited your code.
You look frustrated, you sound you chose the wrong framework then came here to complain about those who made a smarter choice. But you're not saying anything,other than arguing on the form.
> New application frameworks (Backbone, React, Ember, Polymer, Angular, etc.) have helped architect web applications in a more scalable and maintainable way.
Then they say:
Ember and Angular are heavier weight but they do play well with others in different cases (there is definite lock in however with those).
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.
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.
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.
Can any if the other libraries mentioned here (especially the newer ones like React and EmberJS) provide the same thing?
Again, does anyone know here of alternatives for sandboxing?
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...
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.
Liferay, meh they seem break stuff with every new release anyway :)
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 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.
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 ?).
Hope Yahoo continue to develop more smaller libraries, purecss is a really nice example for a small clean project.
Abandoning YUI is a sensible move by Yahoo for a technology whose time has passed.
Yahoo owns tumblr.