for the change log of a cell 0 dot 4 dot 6. I'm out to go back. I'm going to win. This is the change log.
We have a expression new open source. You found us nice and draw us on the web at the change log. com. For also fun.
Get out. That comes like 24. We find some training posts on future posts on the blog as well as the audio podcast. If you're on clear full change log show, change jobs and meet times back.
And I'm going to be in GWY in. This week's episode is sponsored by GitHub jobs. If you want us to feature a job and show that the the change log comes like jobs, like advertising the change log, we'll take your rest. Jumping for a front end web developer.
If you rock HTML5, this is a three. J. I'm going to check it with programming experience experience. I needed to with rescue.
Do you have x and P people out. Windows eight analogy in a check of C. It sounds like you're sort of get check out G D slash 5x. Is it five times the size.
Ordinary gigs, right. Well, so just we talked to you guys about Yahoo about the YUI library. No JS came out again. That's probably how it happens when you commit bad JavaScript when it was offered on staff.
Yeah, I think kind of screw it up. That one. They run you through the JS lens. They should.
But I'm still going to get to it. We'll check out today with the YUI team from Yahoo. So much introduce yourself guys and we'll develop what you do with product. Well, my name is Amor.
have been with projects since the beginning. I work on poor library, the library's local object, the learning system, because of the system. My name is Artin Desai. I've been really like about four years now.
And on the library side, I work with the component infrastructure, so things like the attributes of system which infrastructure are plugins. For the advantage of you, what are you the other individual you are and all the other large-run models? Yes, so what do you want to do? My way is your JavaScript platform library.
We have the classical browser normalization layer, the ability to include script on the page, ability to normalize, dawn interaction, and dawn events interaction. But then on top of that, we have pre-robus app development pieces, generic utilities, which help with internationalization, data access, remote data retrieval. And then on top of that layer, we have the typical widget subsystem with a set of box-witted browser-based development. And now we're kind of raging into other environments such as server and mobile-based places.
So how many times have you been with projects since the beginning? How long ago was that? And what's also new in version three? Okay, I love.
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 time with open source analyst.
It was in February 2006, I believe that we actually released YUI2, zero, we called it because the first version was internal TIO only. And that one was first open source effort or, yeah. So since then, obviously, what's happened. YUI3 was a complete rewrite of the library and many levels.
We launched that in 2009 and it has a whole new sort of architecture for being a little more robust on the page and cooperating with other protecting your code for code that might be on the page as well. And a more sophisticated infrastructure for us, I'll let you talk about 3.3.0, which was released last week. Yeah, so with 3.0, I think the release was mainly sent around for one hour. Some of our core widgets.
So we're trying to get Perry in front of the porting over the YUI2, YUI3 world. And 3.0 had the OIC control, just big control on the YUI2 side of things. And that was kind of completely redesigned, refactored for YUI3, leveraging a lot of the sub-mightyurization pieces in YUI3. We had the initial data table drop, which is your basic data grid, data table infrastructure.
Now we had a new dial component, which is rather cool. It's an alternate approach to this library-based type interactions, this is like values between a range. And then we had our charts component, and we went from a flash-based component to YUI2 to a database component in YUI3. Additionally, we had the community contribute resized or your typical drag-able resized utility to the stacks.
I think those were the major highlights of 3.3 for not missing anything. So this part started back in 2006. And it's called YUI1. It's an acronym.
So it's kind of easy to forget that it's Yahoo user interface library. What was the core cause for Yahoo even starts in the first place? There was a, so in 2005 when we first started this, there was actually a lot of toolkits that do all the cores of the browser organization and additional utilities that we need to get. People were writing things and ended up with a lot of different implementations and things.
They're a very quality. And so the idea was that this is, now we know we need all this stuff that we really need to build something that would be common across the company. It's time there was not very many open source projects for doing this. I think dojo's around.
And maybe for a particular end-to-out add-in. But it's still evaluated. I guess before I got higher the evaluated was out there so I wanted to do a new library. And so I was hyped.
And the first utilities were we needed drag-and-drop and we needed a tree control and we needed animation. And how did that, the event system was born and it just blew it out from there. I just broke it up. So in terms of growing everything, Yahoo is a pre-organization.
What's the adoption right across the very certain properties as a managed? I don't know that there's any property that doesn't use my money. At first we could have to sell it and 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 the standard platform for any new product comes out of Yahoo that's going to be running away.
So as a organization, what has this done for you in terms of teaching new developers and bringing out a good team and not only need to fast releases of products? I'm not the best person to answer that because I'm not actually shipping those products. I'm building this library and we see it as being a great success for properties to be able to do more with less resources. We certainly see in the front end engineering culture at Yahoo, which we think it's gotten better and we think we felt towards that.
But you'd have to ask maybe somebody, a big property like the Yahoo for our page or mail or a flitter. How much they think it's really helped them. I think you'd get pretty positive with feedback from them. What is the point you're talking about for community contributions?
I think it was the time of which we did at a long overdue. We were an open source product or 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 platforms solutions for an entire community, really doesn't scale. So allowing people to look at the source algorithm and contribute to it and give us go back into the library. I think it 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 that came on board. They could pick up components earlier in the release cycle. Give us use case feedback on them which we could go back and find the release of the product.
So I think it was something we were excited to do for a while. Just a lot of infrastructure together. And I think the value is going to have to happen. Were you guys using Git before that?
Or was this a mirroring process just to put up on GitHub? Yeah. So we actually do use Git locally here. We have a source of truth.
Git server here that we push out to GitHub. We do that for controller build process of people's and stuff. And we get into our systems that we can verify and then build it to all the post build things and then shoot it off right back to GitHub. By the time we released code on GitHub, we already, like our traditional thoughts were that we're going to have and get sort of ourselves within, but then we start getting all the great things that did before we ever posted our own server.
We switched to that. So one of the things that's a great job of utilizing the platform has been while you're here. So how did that come about? So I think about really because we have Eric or Alia as being 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 Acres speaking often on you know, high quality presentations and teaching high quality glasses. Eric's in there filming them. So we just have all this great content. So it's just running around.
No, if you can't have this, just the notion of promoting front end development is a professional, you know, professional engineering skill. So the theory is hard to train is another part of it. Best practice as principles are another part of it. So I think it goes all hand in hand and yeah, that's a good job.
So what's the like word with Douglas Crawford if you have a presentation out there for laying out the fact that especially people who are played about Jazlyn pretty in the fields. But he's a very thorough and considerate the value of some of our code and projects and everything that's nice to have around the focus on. I have to interrupt him. That was Slasher Texas J.S.
And I found it just a little nice guy not expected from the very day. So one of the titles that intrigued me on YUI recently was YUI and no JSCD. Have you guys put on with that? Oh yeah, absolutely.
Back I gave a little presentation at last year's J.S. Carve in Washington. And early going up the end of the work of Dave Glass has done a lot since then getting our full infrastructure open running underneath the no J.S. And that is a lot of is still actively developed where using this as platform for doing some new fun things that this year's going to be one of our focus.
No, no, it's extremely hot right now. But I think people are still reminds me of what the release act look like two years ago when people are trying to figure out what the this act looks like in the other components around it. So you can share other technologies. Are you looking at as far as running properties and other things for note?
I was in general. I think if you look at the library as a whole in particular YUI 3, there's a bottom-most layer which involves that the DOM normalization and 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 attributes based plugins all that stuff is generically useful for any kind of development.
So whether it's developing apps on client or the browser or whether it's developing apps on the service side of things. I think the way we look at it is that we write generic useful components which make which abuse on the service side of the client side. And I think the real value which kind of node.js and the picture is now you have the option of deploying and running that code right at once and then deploying it on your side of the fence. You know 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 kind of low bandwidth high latency connections. Or you can move all that same code down to client side. That's really really interesting. If you look at everything on top of the kind of base normalization layer, all of that can be used on the server for the most part.
You know, you can switch infrastructure for example. You can take a widget rendering on the server so you get your progressive enhanced smart solution and deploy that to the client and then add interaction capabilities on client support. And so this is just time to be able to develop one solution to it. So it's like a fence.
Just reading. I noticed that the real node.js mailing list that the title is I can't code like this. And basically a rant against the complexities that arise from the asynchronous setup of node.js. Do you think that that an operation bell 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 into the module's additional module section of the node.js website, you'll see maybe 20 different utilities dealing with parallel processing and 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. And some of these methods that kills some of the four of the benefits of the event loop. But ultimately there's some pieces of code that you just can't do right with that. But that's some kind of mechanism to help strengthen that point.
We're going to have some utilities for that. I think directly in why the web is going to be are sort of node.js, why framework, who will be using why to handle some of these things that will be calling it easy to suggest. But on the side of that, I think to a certain extent, when you're developing for the browser, you're developing with an event loop mindset. Anyways, so a lot of people develop a browser or someone already familiar with the notion of callbacks and you're not being called in line with the thing which shapes the actions.
So I think that helps you in general. So we can start talking about certain platforms and browsers. I know there's an e-mail launcher actually working on mobile with this. So what is while you're doing on the mobile space?
I think the way we think of mobile, I think that one of the reasons that I gave is out on the right data right now. But the way we like to address it is not think of it as a separate development environment. So a lot of the problems or the challenges which mobile space brings up, addressing those challenges can help across the board regardless of whether it's desktop environment, i.e. seven running on crappy desktop.
Anything we can do to address performance constraints with the mobile environment adds to the picture, helps across the board. And then when you look at features 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 desktop, instead of clicking a previous one next button, it would be nice if I could flick my mouse to throw a few carousel items too. And when further, I mean, touch is going to end up on the desktop at some point or other anyway.
So even if it features, it seems like we like to address the more interaction analyzing the discrete features which you 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 faces, creating a bit more in terms of features and constraints and plan solutions to specific features or specific constraints that they have across the board, whether it's the server or mobile device.
I see specifically in the middle of this mentioning iOS, it's something that you actually run native or something that like you're going to get a bit of after this or something beyond the scenes. It's all web-based application development. The reference is why I'm probably referred to, you know, abstractions we needed to apply for a particular environment, but it's all web-based development. No, JavaScript is a language that's extremely flexible.
In other service side and sometimes as an option goes, you got a kind of library that develops in like in Ruby World, it's regions that you know ecosystem of flood will go down drop in. For JavaScript, there seems to be a million different ways to do things. And we discussed things like the module pattern and how not to leave the goal in the namespace. You see JavaScript is a language that a return to point where this is the way to do something is it going to be always just a multi-faceted multi-flavored world to build in.
I think that it's, you know, the flexibility is part of its chart. I think that we develop conventions in Ruby World. I actually want to to help us avoid good wrong thing. I don't really see it getting, but I don't really see getting, getting, getting, getting these two Ruby patterns that we use all the time.
And library like Y3 does sort of encourage you to go to certain style. So I think that and you see that with, you know, jQuery's and everything as well. That because how the, how the boilerplate for YUI sets up this module for you, this, this, this function scope for you to work in that. It makes you program differently than if you're working strictly in the, in the global space.
And because you do things like being able to clear little variables without, without global pollution and that sort of thing. So I think I, I think all of our documentation also, the answer in styles of doing everything and that translates into the limitations outside of what we do. So a little bit like that. For my two sense, you know, I don't really have too many complaints about it in general.
I use the development of Java world and, you know, a lot of Java developers now are trying to do the types of things you can do with JavaScript flexibility. You know, like not be talking to a stack hierarchy, the analytics and match, you know, sets of methods on the fly dynamically, that kind of thing. So I think the patterns and the items apply to any of the language, there's a best practice of how to develop stuff in Java and there's ways to work around kind of private methods and Java and that kind of thing. And I think the same thing applies to JavaScript.
A little bit over the landing page for YUI 3. Seems there's a lot of, a lot of features that are here. How many of the features that of itself know how you add more into it when that comes to the from production code you guys have developers and how you even manage bringing stuff in your approach world too? Well, I think one of the things that's happened last year was the YUI 3 gallery and the gallery is great because it gives anybody opportunity to add their code in an easy way to the YUI ecosystem and have these components discoverable and even has, even less you deploy this code.
If you sign up, you'll deploy the code onto our CDN so you can get a bit of having a code on the YUI servers. And all that's really, 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 wanted to be has, you know, have in order to be part of library examples, API docs and all that, then it can actually be rolled into library. So one of the one talking to developers, the guys are listening to this podcast right now and we need to link for contributions from the community. What are some of the core things that they should look forward to making itself?
That's a good question, Daniel. 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 a community, to outline what we have in mind based on input for 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 been thinking of first step, a roadmap for Q1, Q2 plus a year based on what we think the inputs are and we shared that this morning with a community, it gets fuzzier, 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, they can say, I have something like color picker, for example, which I've already worked out, you have it scheduled for Q4. I have one which is pretty much ready to go, but in the gallery, if you want to roll it in, you can roll it in.
That kind of thing. So I think just getting put the community visibility into what we're thinking of developing next, seeing how much they might help out with and then using the gallery, making a feedback and a delivery. I think it's where we like to get. So when we chat with that, I was going to talk to our last summer, one of the things we talked about was the importance of having heroes in programmers.
It seems like that has a profession we rarely know folks in our field over 40. All right. I'm going to be done a spot for a moment and who are your programming heroes and who do you think they've been able to do this? I have to say that, you know, programming started when I was very young, and for me it's like I'm going to take a place for a few games and I think I'm going to program the first thing.
So the people that did the old text by space games like adventure and then I don't want to see more of this. Those are probably the things that we've had in the past. So for me, I don't necessarily know if I have heroes in terms of individuals as such. I think, when the beginning, the reason I got into programming was pretty much along the way I mentioned.
I like games and I like programming games or parts of games. And I think to me, just to focus on games originally, if I had a sense of a problem, I'd focus on that. I got it for you rendering part of things. But the reason I chose kind of UI user interaction based programming was just it was the ideal combination of my my need for some visual feedback with the logical and what the classic programming provided the ideal mix.
And then in terms of the JS world in particular, I think you said the name of time that was brought to the first guy who's materialite, which maybe think about kind of JavaScript as a mature language, and that's all you do for most people. And then second, that's what people I work with on to really smart people. So when you look at the open source landscape right now, we talked about it now because you guys kind of got a little bit excited when we talked about not just knowing how to reflect on the YUI, but beyond, you can say, no, that's the case. But beyond YUI, what else in open source is out there and something you want to play with?
I'm a bad person. I'm going to hit sound on why I'm working with right now. I don't have a good answer for you. I guess I have either.
I feel kind of bad about that. But there's so much that I'm just out of focus on in my little world here that I haven't gotten a lot of chance, but I think a lot of people haven't talked to it. What would be your spin on that then? Bash is each all other.
You know, Bash, I would use each other. I felt like I customized in things to my time. I kind of like just opening the MacBook now and have everything work. So I used to work out in those boxes until a couple of years ago.
I don't even comment. All right. So if you have to make your new bad, then I'm a glistian. Jason or XML?
Jason? CSS or SAS? Good guy. I haven't found a vacation for CSS after I tried to do some job-based UI development.
I ended up working with swing and SLUT. Well, thanks. I appreciate you joining us today. Thank you.
Well, thank you very much. Thanks, Mr. Platt.