1. Building with
JavaScript
write less by using the right tools
Christian Heilmann
Framsia Meetup, Oslo, Norway, October 2010

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

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

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

5. This comes with a few
dangers though.

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

7. Less code does not
mean a better solution.

8. Less redundant code
means a good solution.

9. 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.

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

11. You can write incredibly
small solutions that
work for everyone.

12. If you use the right
technology for the job.

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

14. Progressive
enhancement means
not making everything
work in IE6.

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

16. The physical world is in
a final state.

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

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

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

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

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

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

24. And all 20 users will be
very excited about that.

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

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

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

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

29. So here’s what I did...

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

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

34. I am using buttons for
the navigation
elements. Why?

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

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

37. Use CSS instead of
simulating it.

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

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

40. 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.

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

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

45. Next step was to show
the country info.

46. Fade the old container
and show a loading
message.

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

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

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

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

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

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

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

57. You can extend that to
cache full HTML
interfaces.

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

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

60. http://isithackday.com/demos/warwickshire/
http://github.com/codepo8/warwickshire
http://www.youtube.com/watch?v=_uAOyzw50PY

61. My favourite approach
uses the backend as a
simple API.

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

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

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

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

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

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

72. The dangers of “useful”
shortcuts.

73. Getting JSON-P data in
jQuery:
$.ajax({
url: url,
dataType: 'jsonp',
jsonp: 'callback',
jsonpCallback: 'datain'
});
function datain(data){
}

74. Getting JSON-P data in
jQuery (shorter):
$.getJSON(url+'&callback=?',
function(data){
});

75. $.ajax():
http://{...}&
format=json&callback=datain
$.getJSON():
http://{...}&
format=json&callback=jsonp1282497813335
random number

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

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

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

79. less code == better?

80. Analysing the impact
should be part of your
solution.

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

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

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

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

85. ★ 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.

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

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