
Yahoo stopping all new development of YUI - traviskuhl
http://yahooeng.tumblr.com/post/96098168666/important-announcement-regarding-yui
======
columbo
I 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-
amazi...](http://www.yuiblog.com/blog/2013/11/08/yuiconf-2013-an-amazing-two-
days/))

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

~~~
smackfu
Isn'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.

~~~
irae
They 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.

------
clarle
First 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.

~~~
cnp
I have to give some serious props for Yahoo for taking a chance on a new dev
with little experience. A lot of people go through the same frustrating thing,
and many potentially talented people get looked over. Your story is inspiring
(as well as a little wink to hiring managers :)

Also, super excited about the work Yahoo has been doing with React. Keep it
up!

~~~
mikeleeorg
When I was a hiring manager at Yahoo, I constantly included a mix of new
developers to veteran ones (perhaps a 80/20 split) for many reasons:

\+ 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.

~~~
kentbrew
Those were amazing days, Mike. Thanks (again) for taking a chance on a
42-year-old retread with no formal engineering skills.

~~~
mikeleeorg
I wish I had kept a list of all the ideas you brought to the table that
significantly influenced the team. From the Clarion method of code reviews to
team seating arrangements to all the innovative ideas that we later saw being
implemented by other startups, you were and are a font of inspiration and
ideas! Your current team is extremely lucky to have you!

------
kingmanaz
"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
Walmart 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-...](http://venturebeat.com/2012/01/24/why-walmart-is-using-node-js/)

~~~
tootie
I 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.

~~~
Lennie
As I read it: they are rendering pages on the backend if a slow device visits
the site. On faster devices, it's better to let the Javascript run on the
client.

------
ecaron
When 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."

~~~
irae
Right 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
All 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.

~~~
cobookman
A few of us in Homepage & Verticals are using ampersand.js

------
mythz
Abandonment 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.

~~~
Rygu
FUD. Backbone is nothing but a bootstrap. It really just means that you
evetually rely on literally twenty or thirty other "micro" JS libraries to get
the same shit done that one framework could singlehandedly provide. Those
micro libraries have a higher abandonment rate than anything.

Personally I'd go for company-backed projects.

~~~
shangxiao
Just a note about company backed projects. I backed Google Web Toolkit a few
years back. Big mistake.

~~~
peterb
Why? This is not a troll, I'm very interested in your reasons.

~~~
gknoy
As someone who has been working with GWT, and since moved to JS, I can
elaborate on why I agree. GWT was an excellent tool when I started using it,
but has been eclipsed (no pun intended) by substantially nicer frameworks
(IMO). I am extremely thankful to be using it as little as possible, and am
migrating as many of our GWT apps over into Javascript apps as soon as
workload allows. (I'd LOVE to hear from someone who is currently using GWT,
and has compelling reasons that it's a great tool that are not driven by the
inertia of a large codebase.)

The main reason I'm glad not to use GWT is that I enjoy developing in
Javascript a lot more than I do in GWT (Java). I have found that I can
implement, modify, or troubleshoot a UI roughly an order of magnitude faster
than I used to be able to do it with GWT. This is due to a combination of
being able to reload by refreshing my browser (no slow re-compilation steps),
as well as being able to inspect elements/styles directly in the Chrome dev
tools.

There are about an order of magnitude (or more!) people who write about
Javascript, or $FrameworkOfChoice (Angular, Backbone, etc) than there are that
write about GWT. This includes both blogs and Stack Overflow, not to mention
examples on JSFiddle or the like.

GWT doesn't easily let me integrate other Javascript libraries or components,
so you have to implement your crappy version of Chosen (or similar) yourself.
There's no JQuery or Underscore or similar, because it's all Java (basically).

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.)

Javascript testing tools (Jasmine, phantomJS, etc) and build tools are now a
MUCH more mature ecosystem than they were when GWT was first invented. We used
to use a combo of JUnit + Watir/Selenium to test our UI, and now we can do
similar with Javascript frameworks in a less fragile way.

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.

~~~
calebrichardson
I have used GWT on two from scratch front ends within the last 8 months.

All of your points are true and well written, but at the end of the day, I
don't want to write and maintain large apps in JavaScript (or really in any
dynamically typed language for that matter). GWT is still the best way to
avoid that.

~~~
lmm
Have you touched on Angular in Dart? I agree with the value of typing, but
full GWT just feels very clunky.

------
cousin_it
First 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
Backbone, 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
If 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
I think he doesn't refer to components as in "web components", but as small
chunks of functionality. But maybe you already knew that.

------
preinheimer
I 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.

------
slg
I 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...

~~~
ks
You recommended a Javascript library that was maintained for 8 years. I
consider that a good recommendation. Backbone and Angular have only been
around for half that (yet)

------
jashkenas
This 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
That's from 2011, I'm not sure if that qualifies as 'recent' in the JS world
these days.

------
zmmmmm
Makes 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.

------
jdelic
The 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
The 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.

------
dmitrygr
[...] 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
Buzzwordy...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.

------
soseng
I 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
AUI 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 :)

------
sam-mueller
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!

\--Sam

~~~
jumbotumbo
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.

~~~
lstamour
> 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.

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](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.

~~~
jumbotumbo
Thanks for your thoughtful reply.

------
rip747
honestly 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
yeah jquery is not mentioned once but is maybe the single YUI killer here.

~~~
conradfr
jQuery 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
I'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
Hi! I'm a member of the YUI team. Pure is doing great and we're still
maintaining it!

~~~
jgalt212
That's great to hear! Our shop will continue to do new dev work with it.

------
onlywei
There 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!

------
abruzzi
YUI is used heavily in and enterprise application I work with (Alfresco). I
wonder how this will impact them.

~~~
maaaats
YUI, 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.

------
tszming
This 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.

------
BrandonM
Why 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
They had to reference some usage metrics - maybe that was the least painful to
acknowledge?

------
gorkemyurt
I 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
true, but running a highly visible and successful open source projects are
viewed as good engineer recruitment and retention tools.

------
jamesbowman
"Isomorphic". I do not think it means what Yahoo thinks it means.

------
progx
Good 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.

------
gourneau
YUI still has the best data grid around IMO. Thanks y'all.

~~~
jgalt212
I agree. That was the primary reason back in 2011 we chose YUI over jQuery
(plus a variety of plugins).

------
noelwelsh
All 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.

------
_RPM
I thought YUI was obtrusive when I saw a line of code that looked like this:

YUI.util.Event.addListener('el', 'click'...);

~~~
juandopazo
That 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)

------
shawndumas
I for one welcome our new EmberJS overlords at Yahoo.

------
Touche
Dojo is next. When is that going to happen?

------
pesto88
interesting to see what Squarespace is going to do in response to this

------
misterbishop
Looks like YUI is going to have bright years ahead!

------
like_do_i_care
In other news, a UI toolkit becomes abandonware. World still spins, over to
you Kent for the weather.

------
laurentoget
tumblr is an interesting choice of venue for an official yahoo announcement.
you would think they could host their own blog.

~~~
drgath
YUI 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/)

