The opinions in this article are entirely my own, and don’t reflect the opinions of Yahoo or members of the YUI Team who worked with me, both of whom I hold in the highest regard.
A few days ago, Yahoo released a blog post announcing the end of active development on YUI. Having been a YUI Core Team member for the last two years (up until a month ago), I thought that I’d share my thoughts on my relationship with YUI, and the people who built it.
Joining the Team
My involvement with YUI started in 2010 when I was still in university in Canada. Despite being inexperienced in front-end development, Thomas Sha and Eric Miraglia gave me the opportunity to be an intern on the YUI Team [1]. At the time, mobile development at Yahoo was in its infancy and YUI was heavily used across all Yahoo web properties, and for good reason. It allowed Yahoo to have a common front-end library across all its’ properties [2].
The next four months were one of the most productive of my life, as I tried to soak in all I could from some of the best front-end engineers in the business. It was intimidating as I didn’t want to make myself look silly, but I always thought that folks on the team made me feel smarter than I really was.
I returned for a second internship in 2011 and then joined the team full-time in 2012, and remained there until July 2014, when I left to pursue other opportunities.
Changes in Landscape
Being around the team for more than 4 years in some capacity allowed me to witness the changing role of YUI within Yahoo.
Here’s a brief list of what I noticed. I’ll try to be as unbiased as possible:
- There was always a struggle about whether YUI should focus on the open-source community’s needs or Yahoo’s internal needs when it came to prioritizing issues and feature requests.
- Giving priority to Yahoo’s issues/features while keeping the community happy always stretched the Team that also had to manage releases, tests, a website, a blog, a conference, and a company going through a tough phase between 2010 – 2012.
- Most front-end engineers joining Yahoo had little to no experience with YUI. New developers were encouraged to learn YUI, but this was hard to scale as there weren’t enough people teaching these courses.
- There were lots of internal developers who were either ignorant about why the company adopted YUI as its’ front-end library, or were extremely biased towards their library of choice [3]. This probably hit its’ peak around 2012, but has gone down since then.
- As Yahoo accelerated its hiring of front-end engineers in 2012, there was a greater proliferation of other JS frameworks within the company. In a quest to move faster, teams were allowed to use other frameworks and libraries.
- In 2013, Yahoo began doubling down on NodeJS and a lot of the YUI Team members shifted gears to work on server-side modules.
- In the last 2-3 years, JS Frameworks like Angular, Ember, React grew in popularity, and started doing some really novel things. Given that most of the team’s attention was on internal projects or working on new stuff in NodeJS, we missed out on innovating more in the browser.
- Yahoo has a “older” user-base, who probably use “older” browsers, so YUI has had to support IE6/7 forever [4]. This hindered the Team from iterating and innovating for the modern browsers.
- The YUI Team has historically been great at engineering, but not-as-great at marketing the products that it makes. As a result, nothing YUI did was ever “sexy”.
The Legacy
I think halting development on YUI is the right step for Yahoo. Its time has passed, and there are a lot of new tools that front-end engineers can leverage today. Instead of working in a walled garden, the team can now contribute more directly to the JavaScript community, which they are.
However, most developers my age probably don’t know anything about YUI, which saddens me since I have seen the role it has played and continues to play in shaping the JavaScript community.
- It defined and used a module system with dynamic/conditional loading before it was cool.
- It helped establish JS best practices when JS was still a fledgling language that wasn’t taken seriously.
- It was one of the best resources to learn more about JavaScript, with a very active blog that was used by industry experts, and a Theater that had JS videos.
- It brought sanity to front-end engineers at Yahoo at a time when browsers were extremely fragmented and didn’t follow standards as well as they do now [4].
- It remains one of the most well-tested libraries out there. The unit testing infrastructure that the team built for YUI is very impressive.
- Members of the YUI Team [5] continue to participate in TC39 and they played a major role in getting the ES6 Modules spec to be where it is today.
It’s sad to see YUI go into the sunset, because I have seen the effort that went into building it. From a personal point-of-view, I feel honoured to have been a part of the team that engineered it, and the community that supported it. There were lots of ups and downs, but I guess that’s the case for everything.
The front-end community at Yahoo is pretty strong at the moment. Even though the Team has changed from 4 years ago, the bar is very high when it comes to engineering expertise, and I know that they are working on solutions to some complex front-end problems. It just kinda sucks a little bit that YUI won’t be a part of it anymore.
[1] At the time, I didn’t have any experience with YUI, but I knew my way around vanilla JavaScript and had a decent understanding of CS fundamentals.
[2] It might have been mandatory, but I don’t know for sure.
[3] I’m not counting folks who genuinely cited their problems with the library, and suggested a work-around. I’m talking about folks who basically trolled the ilists. The YUI Team and the greater engineering community had to repeatedly justify themselves, which further stretched the team.
[4] YUI still runs on IE6 while supporting the latest mobile browsers.
[5] The YUI Team is now known as the Yahoo Presentation Technologies Team.
The cover photo is by Mr. TimDC. CC BY-NC-ND 2.0