Christian Heilmann

Posts Tagged ‘javascript’

Will a new browser war help web innovation?

Friday, January 2nd, 2009

Aircraft in formationI just spent an hour on the cycle in the gym watching the video of Douglas Crockford’s Web Forward presentation on my iPod touch. Douglas makes some great points about the state of the current technology for the web – especially browsers – being counterproductive to innovation.

I agree with all of what Douglas says (especially the security aspects of JavaScript and the need for vats), but I am not too sure about the notion at the end that we need another browser war to go forward.

I understand Douglas’ point about browser vendors and users knowing what they need, but I also see a big danger in allowing the way we work on the web to become multi-track once again. I worked through the first browser wars, and I am thoroughly sick of having to write code to work for one or the other browser. This is why we use libraries to work around these issues. The thing that is a bit academic about the view that browser vendors could fuel innovation by navel-gazing is that the end users are not really going to upgrade their browsers just to make our lives easier. Even serious security flaws don’t really get people to upgrade their browsers (I am not talking about us geeks, I am talking about offices and home users that just want to read their mails and get the news). We can innovate until the cows come home, but if it doesn’t reach the people we work for this is progress that makes us move away rather than forward.

I agree with Douglas that the W3C standards are a failure when it comes to innovation. For starters they haven’t moved in ages and the standards are not nearly as good as they should be to make us work efficiently. The DOM standard is too complex, HTML does not really provide what we need to describe interfaces and interaction and CSS is not the layout engine it could be and we need to hack with positioning and floating just to get a multi column layout.

You have to cut the W3C some slack though – if browser vendors hadn’t concentrated on putting bespoke functionality in browsers and followed the guidelines we’d have had a much easier life as web developers in the last few years and could have concentrated on working with the W3C to get the standards extended. This has improved immensely in the last years and even the biggest evildoers now got the CSS2 specs supported in the 8th revision of their browser. Communication is happening, the problem is speed.

The process of the W3C is academic and broken, I do very much agree with that. The WHATWG are kicking butt left right and center with the HTML5 specs and got a good gig going working with browser vendors to get support for what they do. I think this is a great approach and seeing that the W3C is now looking at HTML5 in favour of the overly complex XHTML shows we are moving in the right direction.

What I lack in the proposals of innovating with techies is that a standard is much more than how it works technically. This is what we have already done in the first browser wars: we coded to make it work. It bit us in the butt a few years later as what we built was either flaky and broke or bloated and full of hacks that are not needed any longer (I doubt you’d ever need a if(document.layers){} these days).

Web Development is a very frustrating and complex job. Simply making things work to me is not enough – it needs to work, be usable and easy to understand for developer who take over from you. Hacks and browser specific solutions are the opposite of that.

To me, pragmatic development means “keep it easy to understand”, not “make it work in all browsers” as “all browsers” is a very moving target. The danger we are running into right now is that we are looking at (bleeding) edge cases and see them as innovation and great pragmatic ways of working. I am a big fan of performance tweaking and saving bytes wherever we can. However you can overdo that. As Dustin Diaz explained Google are using as their doctype to save on some bytes and David Calhoun proved that it is working across the browser board right now. Fine and in the case of Google or Yahoo this does make quite a difference. However, a DOCTYPE is not only there to trigger standards mode – this is a nice side-effect. Its purpose is to tell user agents (and that is more than a browser) what the document is, how it is structured and what elements are allowed in which hierarchy. If you wanted to convert a document with this “skinny doctype” you are in trouble as the conversion tool has to hope that all is fine and dandy. Systems like Yahoo Pipes or YQL are a great way of getting data from the web and re-using it. If the data we put out on the web is not in a format we can rely on being valid, this data is unavailable.

I like to see the web as a pool of semantic and linked information, not as a collection of documents that render correctly.

At least one thing is for sure: this year will be interesting in terms of innovation and how we build for the web.

Check out Douglas’ video:


Douglas Crockford: "Web Forward" @ Yahoo! Video

(I am tempted to add VNV Nation’s Darkangel as the ambient soundtrack)

Making Yahoo BOSS easier with yboss

Monday, November 10th, 2008

Having had a lot of hackers at the Open Hack Day Brazil get confused on how to use the JavaScript output of Yahoo’s Open Search platform BOSS I’ve spent a short while to write a wrapper library for it. You can now easily search the web, images and news of Yahoo in one go with a few lines of code:



The wrapper does all the work for you: creating the different script nodes calling the BOSS API with the right parameters and either returning a JSON object with all the mandatory search data (links in a certain format) or returning a bunch of HTML lists that can be printed out as innerHTML anywhere you like.

Check out the yboss homepage and download the script for yourself. The hackers at the Hack Day loved it and the winning hack in the BOSS category was based on it. Also check out the presentation I’ve given on BOSS at the hack day to learn all about the system itself:

[slideshare id=733718&doc=javascript-and-boss-open-hack-day-brazil-2907&w=425]

The art and pain of teaching JavaScript – my talk at <head>

Sunday, October 26th, 2008

I just delivered my talk on teaching, learning and writing JavaScript for use. The slides are available on slideshare below and if you don’t want to sign up, I’ve also put them up on S3.

[slideshare id=695060&doc=javascripttutorialshead-1225047967659425-9&w=425]

I’ve covered the different types of JavaScript consumers: Users, Tinkerers (explaining that there is nothing derogative about this term), Implementers and Developers. I then started to explain where these people come from, what they expect and how we can reach them.

Other topics where how to battle successful but outdated information, ideas how to keep systems upgradeable and generally to consider moving away from an “OMG Ponies! Technology! Let me show you what I can do” to a “Here’s why I love using this and this is how I did it” approach.

Hopefully I inspired some people. I thoroughly enjoyed the session, although it is weird to talk to a monitor :)

Maintainable JavaScript – Videos of my Fronteers talk are now available

Saturday, October 11th, 2008

The lovely people (check the interview to see what I mean) at Bachelor ICT just released “the videos of my talk about Maintainable JavaScript”http://www.bachelor-ict.nl/christian-heilmann at the Fronteers conference in Amsterdam:

Here’s part one of the talk:


Chris Heilmann: Maintainable JavaScript, part 1 from Bachelor-ict.nl on Vimeo.

And Part 2:


Christian Heilmann: Maintainable JavaScript, part 2 from Bachelor-ict.nl on Vimeo.

They also interviewed me after the talk to re-iterate some of the points:


Christian Heilmann: Maintainable JavaScript from Bachelor-ict.nl on Vimeo.

Great job guys, thank you!

You can find the slides of the talk at slideshare.

Useful tweets widget using Yahoo Pipes and some JavaScript

Sunday, September 28th, 2008

If you look on the right side of this blog (and you can see) and you have JavaScript enabled you’ll spy a little “Useful tweets” widget (list). This is done with Yahoo Pipes and some JavaScript. As people asked me how it is done, here goes:

The idea

I use twitter a lot. Some of what I write is very relevant to the blog here, some is not fit for publication and some is just personal. So publishing all the tweets here would have been disruptive, hence I tried to find a way to filter things down.

What I do is that I end every tweet that I want to show up here with a § symbol, thus giving me a handle to filter out the good ones.

Playing nice with twitter and not summoning the fail whale

As twitter is probably the most hit API out there I didn’t want to go through the API and all the authentication malarkey. Instead I am using the ATOM feed and pipes to get the information and to filter it down.

Yahoo pipes is still full of win when it comes to filtering, mashing and converting data, and the pipe in question that I am using is available here: Useful tweets pipe

It takes the atom feed of a twitter user of a certain ID, removes all tweets but the ones ending in a § and removes the user name of the output.

Using the pipe and displaying the content

In order to display the pipe all you need is a small JavaScript and the right HTML in your page (or in my case WordPress template):




The link means the thing still makes sense when JavaScript is not available and the script does the rest. One thing you need to do to show your useful tweets instead of mine is to change the class on the DIV! You get the number from your twitter page:

  • Go to your twitter page, f.e.: http://twitter.com/codepo8
  • Click the RSS link at the bottom
  • Check the URL of the feed, your ID is the number in between the slash and ‘.rss’, f.e.: http://twitter.com/statuses/user_timeline/13567.rss

The JavaScript for display of the badge is no rocket science whatsoever:


var tweets = function(){
var x = document.getElementById(‘mytweet’);
if(x){
var twitterUserId = x.className.replace(‘user-’,’‘);
var s = document.createElement(‘script’);
s.type = ‘text/javascript’;
s.src = ‘http://pipes.yahoo.com/pipes/pipe.run?’ +
‘_id=f7229d01b79e508d543fb84e8a0abb0d&_render=json’ +
‘&id=’ + twitterUserId + ‘&_callback=tweets.tweet’;
document.getElementsByTagName(‘head’)[0].appendChild(s);
};
function tweet(data){
if(data && data.value && data.value.items){
if(typeof data.value.items.length !== ‘undefined’){
var ul = document.createElement(‘ul’);
var all = data.value.items.length;
var end = all > 5 ? 5 : all;
for(var i=0;i < end;i++){
var now = data.value.items[i];
var li = document.createElement(‘li’);
var a = document.createElement(‘a’);
a.href = now.link;
a.appendChild(document.createTextNode(now.title));
li.appendChild(a);
ul.appendChild(li);
}

x.appendChild(ul);
}

}
};
return{
tweet:tweet
}

}();

  • We check if the element with the ID mytweet exists
  • We then extract the user ID from the class name and create a new JavaScript pointing to the JSON output of the pipe. This, once loaded, will call tweets.tweet() and send the data as JSON
  • The tweet() method checks if data was retrieved, creates a list of links and appends it to the DIV.

Hope this is useful to someone else, too.