The Changelog: Software Development, Open Source - YUI 3, Node.js, JSLint, Douglas Crockford Code Reviews (Interview)

Episode Date: January 25, 2011

Adam and Wynn caught up with Adam Moore and Satyen Desai from the YUI team to talk about YUI 3, Node.js, and working with Douglas Crockford.

Welcome to the ChangeLog episode 0.4.6. I'm Adam Stachowiak. And I'm Winn Netherland. This is the ChangeLog. We cover what's fresh and new in open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. Head to github.com slash explore. You'll find some training repos, some feature repos from the blog, as well as the audio podcasts. If you're on Twitter, follow Change Log Show, Change Log Jobs, and me, Adam Stack. And I'm Penguin, P-E-N-G-W-I-N-N. This week's episode is sponsored by GitHub Jobs.

If you want us to feature your jobs on the show, head to thechangelaw.com slash jobs. Select advertise on the changelaw when posting your job, and we'll take care of the rest. Drumbeat's looking for a front-end web developer. If you rock the HTML5, the CSS3, jQuery, or want to work with Mozilla at drumbeat.org, head to lg.gd slash 5v.

And the good folks over at Remember the Milk need JavaScript pros, Scala engineers, and sysadmins. Check out lg.gd.com, 5z, 5d, and 5l. Le'Veon's looking for a UI designer with programming experience. Experience needed with Rescue, Delayed Job, XMPP, Blather, Windows API Knowledge, even Objective-C. If it sounds like your sort of gig, check out lg.gd.com. Because it's five times the size of ordinary gigs. That's right. Fun episode this week.

Talked to the guys over at Yahoo about the YUI library. Node.js came up again, so we kept that streak alive, I think. There you go. Found out what happens when you commit bad JavaScript when Douglas Crockford's on staff at your team. Yeah, they seem kind of scurry about that one. They run you through the JS lint. They sure do.

Fun episode this week. Should we get to it? Let's do it. We're chatting today with the YUI team from Yahoo. So why don't you introduce yourself, guys, and a little bit about what you do with the project. Well, my name is Adam Moore. I have been with the project since the beginning. I work on the core part of the library, the YUI global object and the loading system and the custom fit system. My name is Satyen Desai.

I've been with YUI for about four years now. And on the YUI 3 side of things, I work with the component infrastructure, so things like the attribute subsystem, the widget infrastructure, plug-ins, that kind of thing. For the uninitiated, why don't you give the elevator pitch on YUI and a little bit about what this rather large framework does. Yeah, so let me jump in. YUI is your JavaScript platform library.

We have the classical browser normalization layer, the ability to include script on the page, the ability to normalize DOM interaction and DOM event interaction. But then on top of that, we have kind of pretty robust app development pieces, generic utilities which help with internationalization, data access, remote data retrieval and then on top of that layer we kind of have the typical widget subsystem with a set of out of the box

widgets for browser based web development and now we're kind of branching into other environments such as the server and mobile based devices. So Adam you said you've been with the project since the beginning. How long ago was that and what's also new in version 3.3?

Okay, well, I started here in May in 2005. That's when we first started the project for Yahoo. When we first did it, we were tasked to build this library for Yahoo. There was no talk at the time of open sourcing it. It was in February 2006, I believe, that we actually released YUI 2.0, we called it, because the first version was internal to Yahoo only. And that one was the first open source effort. Or, yeah. So since then, obviously lots happened. YUI 3 was a complete rewrite of the library and many levels. It has a whole new sort of architecture for being a little more robust on the page

and cooperating with other, protecting your code from foreign code that might be on the page as well. And a more sophisticated infrastructure for dynamic loading and custom events. I'll let Satyen talk about 3.3.0, which was just released last week. Yeah, so with 3.3.0, I think the release was mainly centered around filling out some of our core widgets. So we're trying to get kind of parity in terms of porting over the YUI 2 widgets to the YUI 3 world. 330 kind of had the autocomplete control, which is a big control on the YUI 2 side of things, and that was kind of completely redesigned, refactored for YUI 3, leveraging a lot of

the sub-modularization pieces in YUI 3. We had the initial data table drop, which is your basic data grid, data table infrastructure. We had a new dial component, which is rather cool. It's an alternate approach to slider-based type interactions to select values between a range. And then we had our charts component, and we went from a Flash-based component in YUI 2 to a JS-based component in YUI 3. Additionally, we had the community contribute resize or your typical draggable resize utility to the stack. So I think those were the major highlights of 3.3, if I'm not missing anything. So this project started back in 2006, and it's called YUI, and it's an acronym.

So it's kind of easy to, I guess, forget that it's Yahoo User Interface Library. What was the core cause for Yahoo even starting this project in the first place? So in 2005 when we first started this, there wasn't actually a lot of toolkits that do all the core sort of browser normalization and additional utility layers that we needed at Yahoo. People were writing things, and you ended up with a lot of different implementations of the same thing, of various quality. And so the idea was that this is, you know, now that we know we need all this stuff that we really needed to build something that would be common across the company. At, you know, at the time there was not very many open source projects for doing this. I think Dojo

was around and maybe Prototype. jQuery hadn't been out yet. So we evaluated. I guess before I got hired, they evaluated what was out there and decided they wanted to do a new library. And so I was hired. And the first utilities were we needed drag and drop, and we needed tree control, and we needed animation. And out of that, the event system was born, and it just ballooned out from there. It kind of just grew organically.

So in terms of growing organically, Yahoo is a pretty large organization. What's the adoption rate across the various different properties you guys manage? Well, I don't know that there's any property that doesn't use YUI anymore. At first we did have to sell it. I mean, we had to build something good and then teach people how to use it and sell it to them, essentially. Now it's sort of a standard platform for any new product that comes out of Yahoo that's going to be running on YUI. So as a large organization, what has this done for you in terms of teaching new developers and bringing on a good team and then ultimately leading to

faster releases of products? Well, I guess I'm not the best person to answer that just because I'm not actually shipping those products, right? I'm building this library and we see it as being a great success for properties being able to do more with less resources. We've certainly seen the sort of front-end engineering culture at Yahoo mature and we think it's gotten better and we think we've helped towards that. But you'd have to ask maybe somebody at a big property like the Yahoo front page or Mail or Flickr how much they think it's really helped them. I think you'd get pretty positive feedback from them.

What is putting your source up on GitHub done for community contributions? I think it was, at the time at which we did it, it was long overdue. So, you know, we were an open source product. We were open source in terms of sharing what we built with the external world. And just the very nature of a platform product, having six or eight people work on platform solutions for an entire community really doesn't scale. So allowing people to look at the source code in progress,

contribute to it, and give us code back into the library, I think, was a massive win. And then just exposing the source that way, I think, drove more community involvement in general in terms of driving roadmaps and use case analysis for different features as they came on board. They could pick up components earlier in the release cycle, give us use case feedback on them, which we could roll back into the final release of the product. So I think it was something we intended to do for a while.

It just took us a while to get the infrastructure together, and I think the value is evident after that. Were you guys using Git before that, or was it a mirroring um process just to get the code up on github yeah so the we actually do use git locally here we have a sort of a source of truth um uh git server here that we push out to um the github um which uh we do that for control of our build process. So people submit stuff and we get it into our system so that we can verify it and then build it, do all the post-build things, and then shoot it off right back to GitHub.

By the time we released code on GitHub, our initial thoughts were that we were going to have a Git server ourselves, but then when we saw GitHub and all the great things it did, before we ever hosted our own server, we switched to that. So one of the things that has done a great job of evangelizing the platform has been YUI Theater. So how did that come about? So that came about really because we have Eric Moralia as being, you know, really incredibly talented at putting all this stuff together, presenting it, doing the videos themselves. And then also just because we have so many great resources here, people like Douglas Crawford and Nicholas Zakis speaking often on giving high-quality presentations

and teaching high-quality classes. And Eric's in there filming them, so we just have all this great content. So it's just grown and grown. I think it goes hand-in-hand with just the notion of promoting front-end development as a professional engineering skill. So the theater is part of it.

Training is another part of it. Best practices, principles theater is part of it. Training is another part of it. Best practices, principles are another part of it. So I think it goes all hand in hand and Yahoo does a good job at that in general. So what's it like working with Douglas Crockford? Have either of you had a get commit smackdown by Douglas?

You know, Douglas is, you know, he has a reputation out there for laying down smackdowns, especially for people who are complaining about J.S. Lint hurting their feelings. But he's a very thorough and considerate evaluator of some of our code and projects and everything. And it's nice to have him around helping us out. Adam and I had the opportunity to meet Douglas last year at Texas JS and found him just to be a really nice guy. Not what I expected from the severity of JSLint on my code. So one of the titles that intrigued me on YUI recently was YUI and Node.js. Have you guys played around with that setup? Oh, yeah, absolutely. I gave a little presentation at last year's JSConf in Washington.

In the early going of getting that stuff to work, Dave Glass has done a lot since then, getting our full infrastructure up and running underneath Node.js. And there's a lot of, we're still actively developing, we're using this as a platform for doing some new and fun things that this year is going to be one of our focus. Node is extremely hot right now, but I think people are still, it reminds me of what the Ruby stack looked like two or three years ago, where people are trying to figure out what the stack looks like and the components around it. To the extent that you can share, what other technologies are you looking at as far as

front-end proxies and other things for Node? In general, I think if you look at the library as a whole, and in particular YUI 3, there's a bottom-most layer which involves the DOM normalization and the DOM event normalization. And once you move above that, everything we have in terms of utilities and even component development frameworks,

like the custom event framework, for example, and the attribute infrastructure, attribute base and plug-ins, all of that stuff is generically useful for any kind of development. So whether it's developing apps on the client in the browser or whether it's developing apps on the server side of things. So I think the way we look at it is that we write generic, useful components which can be used on either side of the fence, on the server side or the client side. And I think the real value which kind of Node.js adds to the picture

is now you have the option of deploying and running that code, writing it once and then deploying and running it on either side of the fence based on bandwidth and latency and things like that. So you can have your server do more stuff for less capable clients or clients which are coming over low bandwidth, high latency connections, or you can move all that same code down to the client. So I think that's really appealing to us. And if you look at everything on top of the kind of base normalization layer,

all of that stuff can be used on the server for the most part. Even the widget infrastructure, for example, you can take a widget, render it on the server so you get your progressively enhanced markup solution and deploy that to the client and then add interaction capabilities on clients which support them. So it's just exciting to be able to develop one solution

which works on both sides of the fence. This weekend I noticed a thread on the Node.js mailing list that the title was I Can't Code Like This. And it was basically a rant against the complexities that arise from the asynchronous setup of Node.js. Do you think that that kind of Russian doll coding style will evolve the language to include other constructs to deal with that sort of complexity? Yeah, I think so. I think there's certainly, you know, if you look in the modules, additional modules section of the Node.js website, you'll see maybe 20 different utilities dealing with parallel processing of all these asynchronous actions because everybody's having a hard time with that. And I think that you'll see a lot of that, a lot of people needing to rely on that sort of thing

to get their program to work. Of course, in some of those cases, using that stuff kills some of the performance benefits of the event loop, but ultimately there's some pieces of code that you just can't do right without some kind of mechanism to help straighten that out for you. We're actually going to have some utilities for that, I think, directly in YUI because we're going to be our sort of Node.js YUI framework. We'll be using YUI to handle some of these things that we'll be calling asynchronous Node.js calls. And on the flip side of that, I think, to a certain extent,

when you're developing for the browser, you're kind of developing with an event loop mindset anyway. So a lot of people who develop for the browser are somewhat already familiar with the notion of callbacks and your code not being called in line with the thing which initiates the action. So I think that helps too in general. Speaking of targeting certain, I guess, platforms and browsers,

I noticed in your commit logs you're actually working on mobile with this. So what is YUI doing in the mobile space? I think the way we think of mobile, I think that one of the recent talks I gave is out on YUI Theater right now, but the way we'd like to address it is not think of it as a separate development environment. So a lot of the problems or a lot of the challenges which the mobile space brings up, addressing those challenges could help across the board, regardless of whether it's a desktop environment,

IE7 running on a crappy desktop, anything we can do to address performance constraints, which the mobile environment adds to the picture, helps across the board. And then when you look at the feature side of things, things like touch interaction, for example, there's no reason that you couldn't deploy gesture type support. So if I'm looking at a carousel on the desktop, instead of clicking a previous and next button,

it would be nice if I could flick my mouse to scroll through carousel items too. And moving further, I mean, touch is just going to end up on the desktop at some point or other anyway. So even in terms of features, it seems like we'd like to address them more in terms of analyzing the discrete features, which we'd like to address things like offline caching, touch capabilities, transition support, which leverages hardware acceleration on certain devices. All of that stuff can be just as useful on the desktop as it is on what people call mobile devices. And with tablets, that line gets blurred anyway.

So that's how we're addressing the whole mobile space, is treating it more in terms of features and constraints and applying solutions to specific features or specific constraints so they help across the board, whether it's the server, the desktop, or a mobile device. I see specifically in the commit law that it's mentioning iOS. Is it something that you can actually run native, or is it something that you're building native apps with this, or is it something behind the scenes that's running?

No, it's all web-based application development. The references to iOS probably refer to abstractions we needed to apply for a particular environment, but it's all web-based development. You know, JavaScript as a language is extremely flexible. In other server-side and sometimes client-side languages, you know, as adoption grows, you get a common library that develops. And like in the Ruby world, it's Ruby gems that, you know, an ecosystem of pluggable code that I can drop in.

For JavaScript, there seems to be, you know, an ecosystem of pluggable code that I can drop in for JavaScript. There seems to be, you know, a million different ways to do things. And we discuss things like the module pattern and, and how not to pollute the global namespace. Do you see JavaScript as a language ever maturing to a point where this is the way to do something, or is it going to be always, you know, just a multifaceted, multi-flavored world to develop in? I think that the flexibility is part of its charm. I think that we develop conventions and we're going to rely on tools like JSLint to help us avoid doing the wrong thing. I don't really see it getting, I don't really see us getting,

getting, you know, these two or three patterns that we use all the time. Although in a library like YUI3, it does sort of encourage you to code in a certain style. So I think that, and you see that with, you know,

jQuery and everything as well, that because how the boilerplate for YUI sets up this module for you, this function scope for you to work in, that it makes you program differently than if you were working directly in the global space and gives you things like being able to declare local variables without global pollution and that sort of thing. So I think

all of our documentation also, we have certain styles of doing everything, and that translates into implementations outside of what we do, to look a little bit like that. From my two cents, you know, I don't really have too many complaints about it in general. I mean, I used to develop in a Java world, and, you know, a lot of Java developers now are trying to do the types of things you can do with JavaScript's flexibility,

like not be tied into a static class hierarchy, be able to mix and match sets of methods on the fly dynamically, that kind of thing. So I think that the patterns and the idioms apply to any given language. There's a best practice of how to develop stuff in Java, and there's ways to work around kind of private method access in Java and that kind of thing. And I think the same thing applies to JavaScript. Looking over the landing page for YUI 3,

it seems that there's a lot of different features that are here. How do you guys manage the feature set of it itself? And then also, how do you add more into it when that time comes? Is it from production code that you guys have developed, or how do you even manage bringing in stuff from the open source world too? Well, I think one of the things that's happened the last year was the YUI 3 gallery. And the gallery is great because it gives anybody the opportunity

to add their code in an easy way to the YUI ecosystem and have these components discoverable and it even lets you deploy this code. If you sign a contributor's agreement, we will deploy the code onto our CDN, and so you get the benefit of having your code hosted on the Yahoo servers. And so one of the reasons we have it this way is I look at external features sort of debuting on the gallery. And as they mature and get the full set of documentation, everything that we really would want it to be, as you know, have in order to be part of the library, examples and API docs and all that,

then it can actually be rolled into the library. So when talking to developers, the guys who are listening to this podcast right now, and when you're looking for contributions from the open source community, what are some of the core things that you're looking for from the community itself? That's a good question in general, I think. So one thing we kicked off at the beginning of this year,

so we just had an open hour session, for example, this morning with the community to outline what we have in mind based on input from the component developers themselves. I, as the developer of Widget, for example, know what the demand set is for Widget in general based on external enhancement requests and bug requests and things like that. Based on that, we've kind of taken a first stab at our roadmap for Q1, Q2, plus the year based on what we think the inputs are. And we shared that this morning with the community. It gets fuzzier as it gets into Q3, Q4 space.

But even there, they can see what we're looking to aim for in Q3, Q4. And if they have something which is under development, you know, they can say, you know, I have something, you know, like Color Picker, for example, which I've already got worked out. You have it scheduled for Q4. I have one which is pretty much ready to go. I'll put it in the gallery. And if you want to roll it in, you know, you can roll it in, that kind of thing. So I think just giving the community visibility

into what we're thinking of developing next, seeing how much they want to help out with, and then using the gallery mechanism to feed that back into the library, I think is where we'd like to get. So when we chatted with Douglas Crockford last summer, one of the things that we talked about was the importance of having heroes in for programmers, right? It seems like as a profession, we rarely know folks in our field

over 40, right? I'm going to put you on the spot for a moment. And who are your programming heroes? And who do you think paved the way for you to do this as a living? You know, I have to say that, you know, programming, I started when I was very young, and, you know, for me, it's going to sound kind of geeky because I like to play computer games, and I think I like to program computer games first before anything else. So the people that did the old text-based games like Adventure and then Hunt the Wumpus game, whatever it's called, all those. Those guys probably paved the way for me.

So for me, I don't necessarily know if I have heroes in terms of individuals as such. I think way in the beginning the reason I got into programming was pretty much along the lines of what Adam mentioned. I like games and I

like programming games or parts of games. And I think, to me, just to focus on games originally, and if I had a second chance, I'd probably focus on that aspect of it again, or the 3D rendering part of things. But the reason I chose kind of UI or user interaction based programming was just, it was the ideal combination of kind of my need

for some visual feedback with the logical and analytical aspect of programming, I think. It provided the ideal mix. And then in terms of the JS world in particular, I think you've said the name enough times, but Douglas Crockford was terms of the JS world in particular, I think you've said the name enough times, but Douglas Crockford was kind of the first guy whose material I read, which made me think about JavaScript as a mature language. I think that's probably true for most people. And then aside from that, I think the people I work with, a bunch of really smart people.

So when you look at the open source landscape right now, we talked about Node, and you guys kind of got a little bit excited when we talked about Node for a second there and how it reflected onto YUI, but beyond, and you can say Node if that's the case, but beyond YUI, what else in open sources is out there and is something you want to play with? I'm a bad person to ask that. I'm kind of heads down on what I'm working with right now, so I don't really have a good answer for you there. I can't say I have either. I feel kind of bad about that,

but there's so much that I just have to focus on in my little world here that I haven't gotten a lot of chance to play with a lot of new fun toys. We'll put a different spin on that then. Bash, ZShell, Other. You know, Bash, I would use ZShell if I felt like customizing things to my heart's content. I kind of like just opening the MacBook now and having everything work, so Bash. I used to work on a Windows box until a couple of years ago, so I won't even comment. All right, so Vim TextMate or Notepad?

Vim. I'm an Eclipse user. JSON or XML? JSON. JSON. CSS or SAS? Good God. I have a newfound appreciation for CSS after I tried to do some Java-based UI development

and I ended up working with Swing and SWT. Well, thanks, guys. We appreciate you joining us today and taking the time. Well, thank you very much. Thanks. It was a pleasure. So how could I forget when I found myself for the first time Safe in your arms As the dark passion shows