Building with JavaScript

write less by using the right tools

Christian HeilmannFramsia Meetup, Oslo, Norway, October 2010

Javascript has won the title of most used web programming language.

The reason is that its syntax is forgiving and that it comes with a few incredibly powerful tools.

The other reason is that libraries allow us to write JavaScript instead of catering to browsers and fixing them.

This comes with a few dangers though.

The “write less, achieve more” attitude is a scam.

Less code does not mean a better solution.

Less redundant code means a good solution.

If writing a few more lines of code makes it easier for others to use what you have done then you built a professional product.

If you are the only one understanding what is going on you used the web as a dumping ground.

You can write incredibly small solutions that work for everyone.

If you use the right technology for the job.

If you want to build for people, use progressive enhancement.

Progressive enhancement means not making everything work in IE6.

It means checking the depth of the river before diving in.

The physical world is in a final state.

A pair of scissors cannot change themselves when a left-handed person picks them up instead of a right-handed person.

Web applications and systems can do that - if we allow them to.

A lot of the criticism of progressive enhancement is based on people working in walled-off environments.

If all you write is an iPad app or something for the iPhone you have it much easier than building a web app.

A Chrome extension will never have to work in IE6 - there is no point in that.

On the other hand an Opera extension is a W3C widget and also works on Vodafone mobile phones.

And all 20 users will be very excited about that.

Anyways, let’s go through a few examples and how to write a damn small amount of JS to achieve a lot.

http://10k.aneventapart.com/Entry/185http://github.com/codepo8/worldinfo

This is a system where I was only allowed to use JavaScript.

Were this to be a product, I’d have taken another approach - more later.

So here’s what I did...

Get all the geographical information of all the countries in the world using the Yahoo GeoPlanet API.

Store the information in an object and loop through it to create the navigation.

I am using buttons for the navigation elements. Why?

There is no real navigation happening here. Everything is dependent on JS. This is what buttons are for. And they are keyboard accessible.

This should be a huge nested list. Why isn’t it visible?

Use CSS instead of simulating it.

Hide the loading message, add the new HTML and show it again.

Then show the first entry and make the buttons trigger the right functionality.

Instead of storing data in DOM elements with custom attributes I have two variables to store the currently shown section and the full data set.

Instead of looping a lot of elements and assigning redundant event handlers one event does the whole job.

The differentiator is the length of the button text. If it is one character show the section - otherwise load the country info.

Next step was to show the country info.

Fade the old container and show a loading message.

Read the country name from the button and get the value which is the number of the data set.

That did it - a bit more code than “real” jQuery developers would have done...

...but it is bullet proof and does the least amount of DOM lookups possible.

However, it was slow as heck as it takes time to download the world.

As you’ve seen earlier, it loads much faster the second time you go to the page.

The trick is that I am using “HTML5 Storage” to cache the whole navigation.

That way the interface is loaded from HD and not from the web.

You can extend that to cache full HTML interfaces.

http://www.wait-till-i.com/2010/08/26/using-html5-storage-to-cache-application-interfaces/

Other progressive enhancement approaches use a single page as the data container.

http://github.com/codepo8/warwickshirehttp://isithackday.com/demos/warwickshire/

http://www.youtube.com/watch?v=_uAOyzw50PY

My favourite approach uses the backend as a simple API.

http://github.com/codepo8/flickrcollectorhttp://isithackday.com/hacks/flickrcollector/http://www.youtube.com/watch?v=i_1sVnNkN2M

Write the app as a simple form submit in PHP...

Then return chunks of HTML according to the parameters that came in.

All you need to do in JS then is to override the requests with Ajax calls.

You maintain your whole app on the server and can monitor and cache like heck.

And you still use the goodness that is JavaScript on top of that.

The dangers of “useful” shortcuts.

$.ajax({ url: url, dataType: 'jsonp', jsonp: 'callback', jsonpCallback: 'datain'});function datain(data){}

Getting JSON-P data in jQuery:

$.getJSON(url+'&callback=?', function(data){});

Getting JSON-P data in jQuery (shorter):

http://{...}&format=json&callback=datain

$.ajax():

$.getJSON():http://{...}&format=json&callback=jsonp1282497813335

random number

getJSON() breaks the cache of the service you request.

As each request has a unique URL - even when you ask for the same data...

... you’ll end up being banned for an hour very quickly.

less code == better?

Analysing the impact should be part of your solution.

The danger of quick solutions is that people tend to copy and paste them and not try to integrate them.

And if we put together solutions from lots of copy and paste examples they become huge and hard to understand.

Which is probably the main reason of all the massive CSS files out there.

Use technologies to their strengths to write very short and efficient code.

★ Progressive Enhancement with the correct HTML

★ Event Delegation ★ Adding CSS classes instead of

using hide()★ Rendering on the server side.★ Caching on the client side.★ Configuration objects and

variable caches instead of custom attributes.

Keep an eye out on how libraries help you with writing bullet proof code - not how to write small scripts.

Christian Heilmann http://wait-till-i.com http://developer-evangelism.com http://twitter.com/codepo8

Thanks!