Welcome, guest Sign In

Video: Christian Heilmann — YQL and YUI: Building Blocks for Quick Applications

Video published 2010-02-08.


Christian Heilmann: Thanks for coming. My name is Chris. I am our International Developer Evangelist — that's the fancy title that I have in this company — which basically means I go out to the world and tell them what cool stuff Yahoo! does, and what they can use it for. Then I come back to the company and tell the company what people want, and what people think our products should be like, and what other features we should put in there.

It's a very unique and interesting job because I travel around the world and I meet developers from all over these different places and in their different environments. It's quite funny to see when you work here and you always have your fastest connection, you have your newest computers, and you use the newest gadgets. You think this is what web development is. But if you go into the Indian countryside, you go to mainland China, you go to places like rural France, then you realize… You go into an internet café and there's these really old computers sitting there, and it's always a great and humbling experience to realize that we're building things for the web, and nobody should be actually forced to use a certain technology, forced to use a certain gadget, to actually see our website.

The great thing about web technologies is that they work everywhere; this was the whole idea of the web, and we shouldn't treat that badly nowadays. It's quite funny now with the iPad coming out, and everybody's going nuts right now, like 'that will change the internet, and we will build things completely differently!' It's a $500 gadget that's not even out yet. So no, you don't change today, because it might take four months in countries outside America to get this thing, if ever. I mean, then you get an Australian one which is always the wrong way around and these kind of things; it doesn't work that way.

I just want to do a quick talk about YQL and YUI and why I use these technologies to build websites and to build web applications. The main point is I'm lazy. The main point is I've been doing this job for 12 years, I've build etoys.com, I've built visitbritain.com, all these websites that we have to support things like Netscape and other things like IE 5, and it was just not fun. Nowadays we have the fun but we don't treat the web the right way. We actually treat it like: oh, here's something cooler. We put it out there and hope it works. We have the technology to make everything work out there, and YQL and YUI are two great examples for that.

I'm known to be able to quickly build cool demos. Whenever there's a mash up competition or something, I get asked to come in and train people. And 24 hours before they're like 'and can you make a quick demo to do something like that?' Normally it works out because I don't need much sleep, but it's quite funny to see how people always expect that of you quite quickly. Internally we have this Hack Day here, 24 hours, and we show that if you let developers lose, if you don't breathe down their necks and you let them play, they can come up with great stuff.

A problem is that, as developers, we always want to come with our own stuff as well. We have this little creature on our shoulder that tells us 'you can do it better, you can do it in 5 lines of code rather than the 200 that YUI uses'. And this is why we're actually shooting ourselves in the foot over and over again, because we don't release things. We just make another plugin for JQuery, we make another extension for another library, we make another CSS hack to make one solution that works in every browser right now and next month it's broken, because we want to do this, we're driven by that. And we shouldn't have to, because actually if we want to build things for the web, think about the end users. Think about what people want to do with it.

Some of the things I've built, for example, when Yahoo! BOSS came out I was in France, in Paris, and the BOSS team was there talking about that we have keywords now in Yahoo! BOSS, in the search results. I'm like 'great'. At the conference there I started hacking this together, which is a keyword finder. You put in a keyword, it gets the first twenty results of Yahoo!, gets the keywords of all those results, and gives it back to you as a list of keywords that you can copy and paste back into your keyword blog and your HTML page, or in your content management system, or you can tag it this way, and so on and so forth. That was quickly put together and it was a purpose that people wanted to have. The main thing that I wanted to show with it was the multi-language support as well, because that one was quite good at BOSS and still is.

I could have done that myself, I could have written the whole CSS and everything myself, but I just didn't want to. I just used the CSS Grids Builder, that I'm going to show later, and put this thing together. I concentrated on the back end and concentrated on writing the 50 lines of PHP that does the whole thing.

News Mixer — I was asked to do that for The Guardian release. The Guardian newspaper in the UK released a really, really good API so you could get all your Guardian content as XML and JSON, and it's properly searchable and filterable and so on and so forth. 24 hours before they released it they basically said 'we need more hacks because we want to show to the press what you can do with our demo'. The problem was, of course, 24 hours before they just released the API key so nobody else had a chance to build something before that. So I did it last time I was here on the way out, on the way to the airport I uploaded it, and next morning I presented it in London. Same thing — I used YQL for the data, I used YUI for the interface, and it works. I don't have to worry about it.

GeoMaker is when we release Placemaker. Placemaker is an absolutely amazing API, and there's nobody in the competition that has the same API. You give it a URL, you give it an RSS feed, or you give it any text, and it gives you back the geo locations in this text. It also does the disambiguation for you, so it finds London, England first, London, Ontario second. When you look for Paris you don't find Paris Hilton, you find Paris, France. It does this really nicely.

The only problem is it's a post API, you have to sign up for an API key, and people didn't know how to use a post API, sadly enough. People still are out there that have this kind of problem. So I used YUI to build this interface, used Yahoo! Maps to allow you to input your things, filtered out the results using Data Table from YUI, and then it generates a map for you for copy and paste, or it gives your text back as a microformatted geodata already. Copy and paste it in. Fourth of July, slow news day, Tech Crunch actually reported about it, nearly killed my server. But it was good; for the first time Tech Crunch said something nice about us, so it's good.

This QuickTrans is a W3C widget for mobile phones. I was asked by Vodafone to be a judge at a 24 hour competition to build W3C widgets for their mobile phone platform, and I needed a demo. I didn't know what to do, so I basically used the Google translator API with YQL and allowed you to translate something on your mobile phone. I got back home after giving my talk, and after coaching some people said OK, why not put it in the competition? A week later I had a new mobile phone and a laptop, because I won first prize with this. But this is basically, other people thought, about the greatest, coolest, best looking solution, and it didn't work, it wasn't finished, it didn't do anything for end users. This makes sense. If I go out in a pub and I want to have a German beer, I know how to call it here now.

This was another demo when people asked me about how you can use the different APIs as search engines. That's Goohoobi, which basically uses Google, Yahoo!, and Bing next to each other. It has an interface where you can see the results and it's great for researching something if you want to just quickly see the different search engines going out there. Bit of a problem, because Google Ajax API has really strange content compared to the Life API, but they're working on that as well. But this one is available also as a screen cast of how I built this thing in 30 minutes using YQL and YUI — well, not the styling, the styling was another half hour, but fair enough. But this is how easy it is to build something like that quickly.

UK House Prices. I was asked to do something for the UK Government data release; like Data.gov in America, we have UKData.gov right now. One of the things was a CSV, Excel sheet with the house prices in England over the years. This was what was released. Tim Berners-Lee showed it, and it was in all the newspapers in the UK, and it was built within a day, as well, using out-of-the-box components. You can see here this is the slider from YUI, this is the AutoComplete from YUI, the YUI button, and then a [inaudible] graphing engine. I'm going to come back to that. Down there I'm doing a YQL call to Astoria which gives you house prices that are currently available in the area, which is very, very depressing if you earn as much as I do and you live in London.

The reason why I can build these things quickly is that I build them with things that work, and I don't have that passion anymore to say: look, I've got to do it myself. I could write an AutoComplete, yes. I could spend another day writing another AutoComplete solution. But there is a great one in YUI, there's lots and lots of plugins for JQuery, there's lots and lots in Dojo. Everybody solved that problem already, why do I have to do that again? Because my ego tells me to, rather than what the end user gets out of it. Something like YUI: if we have something that is documented like that, that has great examples like that, look at those and use them rather than trying to reinvent the wheel. Because there's new wheels to be built, there's new good stuff out there that we should concentrate on. But no, we do the same things we've done five years ago.

It gives me time to concentrate on the important things about the application, and the important things about the application are two things to me: it's the data that the application has, because if there's nothing of interest in there, why should I use it? The biggest problem is that people come up with new social networks right now. 'Let's make a social network!' Well, what is your social network about? 'It's about connecting to your friends and following each other.' That's been done before. If you don't have a social thing in the middle that people care about emotionally, you're not going to be successful. Twitter is the way around, but partly it's also because people want to stalk celebrities. That's why people follow Douglas Crockford on Twitter a lot, and these kinds of things.

The other thing for me is the interface. The interface should work, and the interface should work for everybody. It's just scary. I've been doing web accessibility for about ten years, and I still see people doing the same things over and over again. They build a flashy interface and then they try to make it accessible. You're like, this is not working anymore, you're going to spend two months on that and it's not going to work out. Whereas if you use plugins that actually work, like the area plugins of YUI, you have a certain amount of accessibility even in the most interactive element, and you don't have to think about it. Or you should help us make it better rather than trying to shoehorn accessibility in it, like there's this button if you want to have the non-JavaScript version, and you load that one, and we don't maintain that anymore. So don't expect anything out there to be there for you.

There's terrible browsers out there, there's terrible computers out there. There's terrible companies out there that don't allow people to install things, they don't allow people to upgrade. That's why we have things like IE6 floating around — it's not that people are evil, that say 'I don't want to upgrade because I want to see a shit website', it's people that have an IT department that tells them 'you cannot upgrade, it's insecure.' I had people tell me flat out, I cannot upgrade from IE6 to IE7 because IE7 is insecure. I don't know why, but this is basically what I heard, and these are the kinds of things that we have to deal with.

I'm bored of writing CSS layouts. That's one of the things that annoyed me over the last few years: CSS is not a good way of laying out information. It's good for what it does, it's good for styling things, it's OK with what you can do with it, but every CSS layout right now is a hack. Floating is a hack, positioning is a hack, and we just have to hope it works in browsers. If there's a rounding error of the percentages, we have a drop flow, all kinds of things happening. So no, I don't want to do that anymore. I want to use the technology, and I want the browsers to behave. I don't want to work for browsers, I want to work with technology, and this is why libraries are out there to help us with that.

That's why whenever I start with a new CSS layout I use a very simple solution, and that is the YUI CSS Grids Builder that's done by Dav Glass. It was originally, I think, at an internal Hack Day, and then we released it for the YUI. This one allows you to build your layout, click it together, here a row, there a row, there's three columns, there's two columns, and so on and so forth. You can see immediately what it's going to look like, and then you basically press a button and you get the code back for you, copy and paste it out, and start putting your content in. This is three hours of hacking CSS that I saved myself. I don't have to do that anymore, and it will work. Yes, if the styling is different, go nuts, do your own layout, it's great. But for me, for my kind of applications, this is exactly what I want. I want to make it work. I don't want to make it 5 pixels here, 3 pixels there, 2 half pixels and a drop shadow there. This is for me, it's not the web anymore. When you see Mac books, Net books, mobile phones, we don't have a chance to actually say anything about the interface. We have to make the interface flexible so that it actually helps people to read our things rather than just have scrollbars all over and hope it works out.

The reason is that I want to support browsers and not work for them. I want to support a browser, yes. You can come with any browser to my website and you will get something; you will get something that works for you. I don't want to spend another six hours to make something work for Safari 1.0.3 or Opera 5. I don't want to do that. This is not what I'm here for. I'm here to deliver cool content with an interesting interface to people out there. Browsers are not my clients, people are my clients. So Safari, Firefox, Opera, Chrome, are great browsers. Then there's also Internet Explorer. But yeah, we should give them something. Give them HTML and CSS. If JavaScript is too much for Internet Explorer, fair enough, why not? Nobody's going to miss it.

It's quite amazing how many times we spend hours fixing things for Internet Explorer 6. Anybody who does that, go home, install Internet Explorer 6, and surf the web for two hours. You'll want to shoot yourself. It's really not a fun experience, it's really not nice to have. People are already OK with that, they're already used to a bad experience, so don't give them something extra. It's like this Stockholm Syndrome of people trying to defend a browser that should have died years ago.

I'd rather be able to update a CSS URI than re-write my CSS when a new browser comes around. That's the biggest problem with any engineering out there — with any development we always think we have the best solution now ever, and then in half a years time in the web our environment changes completely. Something new comes out: iPhone, iPad, maybe something from Microsoft too, you don't know, and it messes up what we've done. Once again we're like 'now it works for every browser!' My favorites are the tutorials that say 'works in modern browsers', especially when they say 2004 in the date, or something like that. 'Modern browser' is like a moving target; you cannot build for them.

So, things you spend far too much time on. Hacks to make browsers work. 'Oh, these rounded corners don't work in Internet Explorer 6 without 16 pictures.' Don't give them rounded corners — problem solved. Optimizing prematurely. 'Oh, my JavaScript now uses 5 cycles on this processor and 6 cycles on that processor.' No.

Optimize when it hurts, where it hurts. End users don't optimize on a language level, where you might be, in this case, in Internet Explorer and in that version. There's a great talk at Full Frontal this year, in Brighton, by Jake Archibald from the BBC. He gave a talk that was called Optimize Where It Hurts, where he basically went through a lot of optimization and performance blogposts and took out some truisms and actually debunked them completely, with proper testing and with proper examples on the BBC website. It's just amazing how happy we are to cut down on two lines of code, but then we don't have time to make it available for a blind user or somebody without JavaScript. So optimize where it makes sense, rather than prematurely. I saw that in this company a lot, that we don't release products quickly because we want to make them scale for 16 million users that might not show up at all. I mean, Twitter doesn't scale. It's still out there. Basically, get things out, don't optimize them.

Using our pet language, environment, or library is something that drives me nuts as well. Every time I write a cool tutorial on YUI the first 20 comments are: 'this is great, can you do it in JQuery as well?' Or, 'can I do that in Dojo?', or 'can I use it in .net for really sick people?' Yeah, if something is out there in JQuery, that's cool, use it. Use it, don't say 'oh, we have to do it in YUI now'. Don't go out and try to evangelize people into another library. It's about solutions, it's not about the library that we use. If you write PHP and you love PHP, write it in PHP. If you like Python, write it in Python, not a problem either. As long as you write maintainable code that is understandable by other users, you're a good developer. If you write in the same environment for ten years and your code is only understandable to you and the two guys next to you, then we have a problem. I remember seeing source code with Korean comments. That was great.

Talking of which, reading badly written tutorials and incomplete documentation is another thing that people waste their time on. There's so many books out there that are written in a fluffy, happy way, so you read the book and you feel like you're a JavaScript God after the first three lines, or after the first two pages. Because it gives you this: 'oh yeah, document write is the best thing ever, you only have to use that in JavaScript. CSS, yeah, just make sure you order all your properties in alphabetical order, then you have great CSS,' these kinds of things. It's amazing how many people read documentation and then wonder when it doesn't work and haven't looked at the data for documentation, or a tutorial. You know, if it's from 2000 it's probably not going to be good advice right now. It might be, and Douglas Crockford's website is an example, but fair enough.

Then we use bleeding edge effects and interfaces and then we try to create a fallback solution. Start with the thing that works, then make it fancy. This is all it takes. This is the main trick about web development: start with something that works for everybody, then make it fancy. Don't make the drag and drop solution on the cube in 3D with lightsourcing and then wonder why somebody without a mouse can't use it. This is not how we should build things. And then we build flashy effects all the time.

What we really should start with is data. I love data, I love information on the web. I love that the Governments throw out all the information right now. There are so many cool things that you can build nowadays, and it's amazing if somebody like the Government realizes that it's a great thing to give information out to the people. We should use it, we should do something with that and show them what can be done. It was interesting with the data competition of the UK Government because they hardly found people to write hacks for them, because a lot of geeks were like 'oh, that's working with the Government, you're bringing it back to the man, that's just not it.' We're not punk, we're not hardcore, we're web developers. There's a difference. [laughs] It's quite interesting to see how hardcore some people are.

This is where APIs and web services come in. APIs and web services are 4,470 or something on programmable web right now. The problem with them is that all of them are written by developers as well, and every developer thought this is the best way to build an API, this is the best way to authenticate for one, and this is the best way of getting information out. So all of them are completely different, and we spend most of our time using four or five APIs, reading the documentation about it that normally doesn't exist, so we have to even find it somewhere or ask somebody, and then we don't get the data back that we want. So they're written differently, they expect different authentication, they give back different data, even in interesting formats. The main Government data format is RDF and SPARQL. SPARQL I hadn't even touched since 1997, 1998, when I first came around this kind of stuff and I'm like no, I don't want to do that anymore.

This is why we built YQL. Jonathan here and other people built this awesome product called YQL, and this is by far the coolest thing we have at the moment. YQL is a SQL style language for web services and web data. It's basically your data interface to the web, where you don't need to know anything about authentication, you don't need to know anything about what data goes in or what data comes out, you don't have to read documentation. All of it is in one interface, and it works for you. So you have select {what} from {where}where {conditions}, and this is what we had to use internally when we wanted to use Flickr, when we wanted to use Yahoo! Answers and we wanted to use Ports on one website. We were trying to go through TWiki pages and talking to people for five hours finding this information. With YQL we now have it one interface where we can click it together.

This is one of the demo examples that I always show. This is 50 lines of PHP that gives me a static website about Frankfurt, or Paris, or London, or Sunnyvale. I scrape the first three paragraphs from Wikipedia, I show a Yahoo! Map next to it, I get Yahoo! Weather, I get events from Upcoming, and I get Geolocated photos from Flickr. This can be done nowadays in like 20 lines of code, using YQL. This would have won a Hack Day six years ago because it would have been eight hours of work trying to make this thing work and filter together and get the right information out. But with YQL it's really, really easy.

YQL also is not us, it's everybody. Everybody on the web can be part of YQL. All you have to do is write an XML schema, point to your data endpoint, and then give us an open table on GitHub that we will copy over to datatables.org, and you are part of this interface. I've just spoken to LinkedIn two days ago and I'm talking to Google tomorrow about some of the other stuff that they haven't released yet, and it's just amazing. If you go through the YQL console right now, you see every startup that has good data. You see every big data set in there. We have it for you, you don't have to go through the Bing documentation and reload frames randomly and these kind of things.

A few examples. Select star from Flickr.photos.search where the text is donkey finds you photos from Flickr where the text, or the description, or the filename is donkey. Before that, you had to go to the Flickr authentication, you had to get your auth key, you had to get the data back, so most of the time when people did something with Flickr before they used the RSS output rather than the API. But now you can use the API with full text search and actually get the information back. Select star from flickr.photos.search where text is donkey and license equals 4. Very important if you ever show Flickr photos online, make sure that they have a creative commons license, because otherwise a lot of Flickr people will come down on you like a ton of bricks. I've had that before, people say 'oh, you stole my pictures, and Google indexed my photo on your website on page 215 with that search term,' and I'm like well, that's terrible. But I will ask them to delete it, it's good.

Select star from craigslist.search where you select sfbay, type is sss, and query is flower pot. In case you want to have a flower pot around here, you can now find that with a line of code rather than having to go through the whole of Craigslist and trying to use their search. Search star from google.news where query is healthcare. What happened on Google News right now about healthcare?

How about you compare things? Select star from query.multi, which is where you list several queries and they get run one after the other. You say select from New York Times article search where it's healthcare, Microsoft Bing News where it's healthcare, Google News where it's healthcare, get it all back as its own interface, and you can build Goohoobi again quickly. This is basically how I built that, and this is how easy it is. This is great for comparison of different sources rather than having to click through them one by one.

What's interesting is when people don't have an API you can still make an API out of a certain website. This is, for example, Fox News. Select content from HTML where the URL is http://foxnews.com, and XPath is //h2/a. Every link that is an H2… Well, it goes through FoxNews.com, gets the HTML, and runs it through HTML Tidy, so even if somebody used the content management system HTML would come out in the end. And then you can use XPath to filter it down to only what you want — in this case, only the links that are inside headlines — and then give me the content of those links. This content is hard to find, because sometimes in the documentation… We have to fix that a bit.

Then you can, for example, take the headlines and translate them into French if you want to. You have the power of all the web services, of all the data sources of the web, in a language like this, rather than having to go through Beautiful Soup and Python, or PHP Frameworks, or whatever. Or even update, delete, and insert. This, for example, would allow you to send something to a Wordpress blog, so you could write an interface where people can blog to their own Wordpress blog using this line of code. Go over HTTPS, because otherwise the password and username is visible in public, which is not too good. But it's just amazing that you can do this, and it's just fun to build little interfaces using this YQL.

So it has a lot of benefits. There's no time wasted reading API Docs. And I've written several API Docs, I help people writing API Docs, I translated them. Most of them are terribly bad, and they're really, really hard to understand. Most of the time things are explained that you don't need, and the simple things are not. So going through the console, you just get the data, you use it, you mix it up with another interface, done. Using the console makes it easy to create complex queries, as well, because you will get error messages that really are meaningful. It's just like 'this should be queue instead of text', 'this data comes back as an integer rather than a string, that's why it doesn't work'. So it gives you error messages that work, not like 'undefined is not defined and now that's not an object.'

You can filter the data down to the least amount necessary before you use it. This is a very important thing as well. Most of the time with APIs you get a massive chunk of data and then you have to become the regular expression God, or you have to filter it with some other system to get it down to the one that you only want to have. Whereas with YQL you can filter it down with local and with remote filtering, you can say give me only the first five, start at the ten and give me the next forty, filter them by dates, sort them by dates, sort them alphabetically. All of this is possible, and in the end you get a little chunk of JSON or XML back rather than having to calculate that.

On a computer it's not a problem, but on a mobile device, for example, this is a very, very powerful thing to have. Instead of 6,000 lines of XML you have 60 lines of XML, only with the data you need. And it has fast pipes. The YQL team keeps telling us our pipe is bigger than yours, that's why you should use our service. I've done some testing with this and it's actually quite impressive, if you use YQL as a proxy, what you can do in terms of the speed of your applications. It caches and converts it for you into formats that are usable, like XML and JSON, rather than RDF and SPARQL. The caching is actually quite good as well because that means next time you hit the same query term, it's terribly, terribly fast.

One thing that gets me very excited, as well, is server-side JavaScript. In Open Tables, in the table definitions of YQL, you can embed JavaScript if you need to do complex filtering. If you say give me all links that start with A and have the word dog in them, that's something you cannot do easily in YQL; you can write a line of JavaScript to do that for you and give the data out. So what I'm doing with [xx] is I'm taking data that is coming back as XML and I convert it into HTML and send it back to you, so you don't have to do that on your PHP or JavaScript anymore. It's a very powerful way of using JavaScript.

This is a speed test that I've done — it's been released on some performance blogs as well — where I read five different RSS feeds and printed them out, and measured the time that it took to do them. That was yesterday night in the hotel. With a simple cURL, like a cURL request for each and every one of these RSS feeds, it's 10 seconds. With a multi-cURL it was 4.35 seconds, with a YQL cURL test it was 0.9 seconds, and with executable YQL with conversion on the server it was 1.6 seconds. The second time I ran this, the test went down even more. The main point was that my computer did not have to connect to these five different random servers all over the world to get the data back, because I connected to the YQL server and the YQL server has a fatter pipe than my desktop in a hotel room, and all of a sudden I cut down on the time my application needs immensely. If you hit that a second time, the caching kicks in, and it's even a lot less.

Using YQL itself is terribly easy, because YQL itself is a web service. All you have to do is take your data, you take your structure together so you don't have to use the console, you select statement here, Flickr photo search with a start and an end, where if there is a where on earth ID where the where on earth ID is this and the text is that, and then you point it to the public query endpoint of YQL, URL-encode to an end cURL, and you're done. You get it back as JSON, you do a JSON decode, and then you have your object in PHP that you can loop over, that can write HTML out, that can do whatever you want. This is all you really need to do to have your first YQL statement out in the wild.

If you don't like PHP, or you are in an environment like widget platforms or some mobile phone devices where JavaScript is the only thing you have available, you can do the same in JavaScript with JSONP. You do select star from Flickr.places, where lat and long, and encode the URI component, put it together as a URL string, create a script element, set the URL, put it into the head, and the output function will be called as soon as it gets the data back. Then test if something has been returned and alert it out. This is how easy it is to do it in JavaScript.

Another really interesting thing about YQL is the output format called JSON-P-X. If you say the output format should be XML but you give it a call back parameter, you get a JavaScript callback with an object that has the HTML as a string in it rather than as a massive JSON object that you have to put together as a string again. Very powerful for little widgets, like if you want to scrape some websites.

What I tend to do with YQL is build APIs that render out HTML, because I'm tired of writing the same four loops in JavaScript or in PHP all the time. So basically I write a little PHP script that does a cURL call, renders out HTML, and I can use that anywhere I want to. With the example we had here, we had a photo ID on Flickr, we do Flickr.photos.info with photo IDs, do a cURL call, get the data back, and write out a paragraph with a link to the right URL on Flickr with the name of the user, with the proper alternative text, and information about the license as well. So I'm writing a lot of HTML out and in the end I just echo out the HTML.

This means, now, that I can actually use it as an include in PHP. I can use that in any other platform; I could use it in an iframe if I wanted to. But it also means that I can re-use it for my JavaScript solution as well. So instead of doing the whole thing in JavaScript, over and over again, I just write one single PHP script that I can use in two places. An API like that allows me to build a non-script version and re-use it with Ajax for a slicker experience. And you can send it out to the outside world as well, so that's another thing. Every time I build something with little APIs like that, in the end I build the interface and then I say little link API, you can use it yourself. Like GeoMaker, the map platform you saw earlier — that one has an API, and three other websites are using that at the moment, which is quite cool because I just didn't want to answer their questions how they can do it themselves.

To build the interface, then, I normally use libraries. Yes, we are in Yahoo!, and I've used the YUI for several years, and it's still my favorite because it actually teaches you good development practices while you use it. That's what I like about YUI the most. And it scales up to our size, that's the other thing about it. There's Dojo. I play with Dojo as well, it's pretty good. There's MooTools and JQuery. JQuery's probably the most out there that people will talk to you about, and I've been using it as well for a long time. I'm not that happy with either of them, really, because I'm a JavaScript guy. I normally get this little creature on my shoulder, like 'I can do it too'. But don't, don't. JavaScript is just so broken in browsers right now. Browsers are so broken with JavaScript that it makes so much more sense to use a library to make things work, rather than hoping it works with your own JavaScript.

Then you get all these awesome, awesome articles nowadays, like '37 More Shocking JQuery Plugins', '50+ Amazing JQuery Examples', '45 Query Navigation Plugins and Tutorials', '37+ Great Ajax and CSS Tap-Based Interfaces', '45 Fresh Out of the Oven JQuery Plugins' — I didn't know we have to cook them — '30 JavaScript Ajax Techniques For Sliders, Scrollers, and Scrollbars', 'Exceptional Ajax, JavaScript Techniques, Recently Created', 'Ten Smart JavaScript Techniques for Manipulating Content', 'Free Slide Shows, Gallery, and Lightbox Scripts'. Stop this. It's unbelievable how much bad, bad blog posts and tutorials are out there right now, because everybody builds an own plugin. Everybody builds an own JQuery plugin, so hey, we can write another blog post. This one now does the fade in blue, rather than yellow, so yeah, it was necessary to have a new plugin for that. Great idea.

So we have all this stuff out there, and I get these… I don't know, I sound old now, but I've been web developing for so long, I remember the DHTML tutorials, like animated menus that work in Netscape 4 and Internet Explorer 5. It's the same thing over again, it's just a different technology. We're running the same trap of building things for ourselves, rather than building things that make sense for the end users. So build interfaces that work.

Here we have the UK house prices thing again, which is the AutoComplete for the city you want to get in, the date range for the date you want to see, and there is the charts down there, a little map, and direct link, download, delete. All these things work because they're YUI, and they're tested across browsers. But what if JavaScript is turned off? The problem is that a lot of these examples then give you data that doesn't work. In this example I have a drop down for the AutoComplete, and I have a drop down for the slider, and I'm using these as the datasource for the AutoComplete and for the slider rather than maintaining it somewhere else in an external JSON block or whatever. It makes much more sense that way, because it's in my page already, so why don't I just re-use it?

The charts were quite interesting as well, because I wanted to build this thing to be… I thought it would be hit a lot, with the press in the UK going for it. And I also wanted to re-use it in another environment, which I'm going to come back to later. So a charting solution was my big problem. Because there's Google Visualization API — awesome, best if you want to do something with charts just with a URL. Great. There's High Charts, there's Ajax.org, there's all kinds of platforms. There's the YUI Charts. But all of them were rather heavy — they either used images or they used Canvas or they used Flash, and I didn't want to have to do that.

So I basically wrote them in pure CSS. This can be done nowadays. Basically, that's the HTML, and with a few lines of CSS they turned into these bar charts right now, and a PHP script that actually writes out the internal styles that are necessary for that. This can be done nowadays with browsers. This is where being creative comes in benefit. Not like: oh my God, I just used the 15-level drop down menu with fading in CSS only, great. But does CSS only make sense? The rollover is not really necessary; the information is still there. Of course in IE6 the rollover doesn't work, but for all the other browsers, done. We don't have to run the JavaScript for that. The API in itself was, yeah, UKHousePrices.com, and then you have a start, and a location, and an end, and that one renders out plain HTML, as well, that I can use in the system itself with an Ajax call, or I can embed it into another document again.

Then I basically said: OK, let's write the JavaScript now. It works. It worked for everybody. Drop downs worked, the PHP works. Then I said OK, let's do it for JavaScript. First thing I did was go into the configuration thing of YUI where you basically click together what you want to have of the YUI and you get it back as one single URL to put in your document. This is amazing, this is what I love about it. I don't like these 'one size fits all' library solutions that give you 15 MB of JavaScript and you will probably need this in 3 weeks time. The great thing about YUI 2, and YUI 3 even more, is the granularity. It gives you only what you need, which came with a bit of confusion, like what do I need to include when? This is why this YUI Configurator is absolutely perfect for that. Just click it together, you either get it as a URL to embed into your page, or even as a JavaScript to load it on demand, and this is what we should be using for our things.

Then I went to the other complete control, looked at one of the examples, copied and pasted the examples and started messing around with it. Because this is what developers do — we don't go for documentation, we take one of the examples that you put and then we mess around with it as long as we can so it actually makes sense. And if we break it, we complain that there is no documentation, and then the people of documentation point out there is documentation, you just haven't looked, and you're already bored of it. So, good example. That is my talk on Thursday. Good coding examples are the most important thing we do out there. Code examples that we put on our documentation should be the best code we write, because this is what people copy and paste. This is what people think good code is, as well, because it comes with a Yahoo! label on it. So if our code examples are bad, then it is bad for the people out there.

I took the AutoComplete Basic Array function, then I took the slider example, copied and pasted that one, and then I started my own JavaScript. I put them all together in the page. The great thing is that all of them work together. That's cool. But it also was quite interesting to see that when you know the developers — and even if you don't know — you see where different developers come from in their coding styles. All of the examples were a bit different and I had to clean them all up to make them one style — my style, really — again, and then they work together.

Then I said OK, let's do JavaScript. Then I started getting evil, because I tried it out in our reception area — because that's the only IE I've got access to right now, because my VM died — and it didn't work there. So I was like OK, I'm annoyed now. I have to release that tomorrow, so let's block out IE. Let's give IE just the example without JavaScript. It works, it doesn't matter, nobody's going to complain anyways. So this is probably the cleverest way and the most evil way at the same time to test for Internet Explorer: isMSIE = /*@cc_on!@*/false. In every browser this actually comes out as isMSIE is false, but in Internet Explorer it comes out as isMSIE ! false, which is true.

It is amazing that Internet Explorer in JavaScript has these inline conditional comments. You don't have them in CSS where they will be useful. Only in JavaScript can you do inline conditional comments, or conditional whatever-they-call it. It's pretty cool to actually have one line of JavaScript to reliably say: this is Internet Explorer. This will always work. Then you say, if isMSIE is false, which means it's a browser, I hide the non-JavaScript block, I show the JavaScript block. This is basically just hiding the drop downs. I keep them in the document because if you find them with a screenreader you can still use them. I didn't want to delete them or anything, I just hide and not shown them, and that's that.

I have a namespace, I create a script node, and call my widget's function which is basically all the code that came with it. There I do shortcuts for the YUI different controllers, like utilDOM, utilEvent. I do the init slider which I copied and pasted more or less from that example, and cleaned it up a bit. I do the AutoComplete, and you can see that I read out the selects in a for loop here and get the data into the AutoComplete that way. So I store the things that are in the HTML already and re-use it as the fancy AutoComplete. I set up my response scheme and I do a for selection use shadow and so on and so forth, and then I basically set a value of a location when the drop down has finished, I do my inner charts thing which basically is only setting classes so the charts get displayed, and onDomReady I test for MSIE and see if there are any charts and so on and so forth. Actually not necessary, really, because I only included it if it's not MSIE, but anyway, it didn't hurt.

So this is all the code that I have to do, by copying and pasting things that have already been done and cleaning them up a bit. And let's not say this is bad practice, because this is what everybody out there does. It's not that people go and read our documentation or read a YUI book and then start using YUI. I mean, there are great examples. If people want to learn more, send them to our documentation, send them to the main page. Klaus here has a great group of blog posts introducing YUI in James Bond style. It was absolutely cool, really well written. And we have to do more of that.

The other thing that I use this application for, as I build it with YUI and as I build it with an API to get the data, iI can easily put it into our own platform right now to run it on the Yahoo! homepage. This is the same application, more or less, with a little bit of different styling because I don't have a head and a body, but this is what it is. So I could re-use that whole information in two different spaces, because I build unreusable components, and that didn't start from scratch every time I want it to.

This is what I spent yesterday night on, because Eric kept telling me that I use YUI 3 now, as well. So I spent a few hours with YUI 3, and this is what I built. It's for myself, for starters, and I'm going to release it as soon as I've cleaned it up a bit. This is now using YUI 3 to search Flickr with YQL and allow me to actually put together photos for copying and pasting into a blog post, for example. We can quickly switch to that, I think. This one now is, if I just reload it… Too many tabs.

Without JavaScript this is all I would get. I would get the ones down there, the drag to collect and drag to remove. It would not be visible at all because I create that with JavaScript, because it doesn't make any sense without JavaScript. So every time you have something in the page that is dependent on JavaScript you've done something wrong, because you've promised people functionality that you don't deliver, and that's a terrible thing to do.

What you can do here is you can basically just click on the different images. Of course, the first search is for kittens, because we need that. Then you find the license here, and you can copy and paste it into your blog post already if you wanted to. If you find more kittens that you like, you can start dragging them. You drag them into your collection box. If you realize this one is ugly and you don't want to have that then you can remove it, you can drag others into the box, and you can do searches for donkeys and these kind of things. All of this is using a few lines of PHP, a few lines of YQL, and YUI components, that once again came out of the box and I had to shift around a bit and clean up a bit for myself.

For some reason donkey gives me cars, and that's not useful. I want to have a real donkey. There's a real donkey, there we go. I can click through that, or I can preview those again, and so on and so forth. If I'm happy with all the donkeys and all the kittens that I have, I can see all the code, copy and paste it here, and I get the whole code back with the copyright and the license and the people that if I want to mention them at the end of my blog post. Done.

All of this, I could have written it myself. I could have written it myself in clean JavaScript, but using YUI 3, and using these kinds of APIs, it was really easy to do. The Thumbs API, for example, here does a cURL call to YQL, and then writes up my HTML like I showed in the other examples as well. The full view does the same thing if you send an ID through, and I've got the different licenses here and so on and so forth. All of this is like a few lines of code put together. The YUI 3 code of this will be on GitHub once I clean it up a bit. It's like 123 lines of code, and that's because I've been verbose with the variables and things like that. We don't have to reinvent the wheel. We have all the things out there, and YUI 3 is completely open source, it's completely out there for you to extend, for you to make cool things with, and we should do that. Back to keynote.

Kids these days. This is the University Hack Day in Dundee in Scotland on the right hand side, and these were the two winners, two 18-year-old ladies that won one of our Hack Days. So every time people say oh, there are not enough women in IT, there are. You just have to find them, that's the problem. The other one is the Young Rewired State, which was a hack event from 14 to 18-year-olds to build Government hacks. I was completely amazed by these events, because all these kids came in, had no idea what JavaScript, or HTML, or anything was, and started building web applications by using libraries, by using JQuery, by using YUI after I pushed them. They built a cool application in 24 hours because they didn't have that block that we have in our head that we should do it ourselves. They basically have the idea: we want to build something, here's technology how to build it. It's like lego bricks. We just put the thing together and we build something cool with it.

And we don't have to do that ourselves anymore, either. So we can learn from these new hackers coming up. It was pretty impressive what they've done in 24 hours. Because they used out-of-the-box components they had time to style it, they had time to write proper documentation, and they had time to do a usability review with other people — all the stuff that we don't have because we build code, and re-code, and re-code, and re-code every time. By using out-of-the-box solutions and keeping a pragmatic mind, you can quickly build something and it will work, because all the components are tested and they work, and they do their job.

If that's not creative enough for you, then actually help the libraries. If you find a bug in YUI, then fix it. If you find a problem in the documentation, if you don't understand the documentation, go through it, write your own documentation, and send it back to the YUI team. They're happy to put it in there. I mean, it's a team of a lot of people working on it, but the outside world always sees more. This is why we release code, this is why we release code to the outside world. I could make money with something like the Flickr thing, but I release it to the outside world so people can implement it in their environments, find bugs that I didn't think of, find use cases that I didn't think of, and that way qualify, or make my product better quality because it works for something that I could not have anticipated anyway.

Only by using, testing, and improving, we can build better solutions, not just reinventing the thing and starting from scratch every time. Use the things that are already out there, give them a prod, kick the tires off YUI, and build something with it. Then we can make it better. So go out there, give these things a go, and if there's anything you think could be better, talk to us, talk to the YUI people, talk to the JQuery people, talk to the Dojo guys. All of these things are only better by people using them rather than writing another plugin to do another visual effect.

This is all I wanted to talk about, so I thank you very much.


Recent Blog Articles

Copyright © 2016 Yahoo! Inc. All rights reserved. Copyright | Privacy Policy

Help us continue to improve the Yahoo! Developer Network: Send Your Suggestions