I am in Vancouver, Canada right now and yesterday night the Super VanJS meetup attracted around 160 people to come and see Rebecca Murphy, Robert Nyman, Jim Andrews, Preet Jassi and little me talk about all things JavaScript.

My own talk was the last of the day and was an ad-libbed introduction to a few of the things I coded lately wrapped in a request to reclaim HTML5 as JavaScript developers. The audio of the talk is available on archive.org:

The links to the demos I talked about are available here and here is a gist of what was covered:

I started by explaining my confusion about Supervan JS as Supervan is a terrible movie from the 70s with very interesting cover and back sleeve art and even more awesome posters.

I then continued to explain my unhappiness about the decline of HTML5. With this I meant that there are lots of marketing demos of HTML5 using a lot of technologies that are actually not HTML5 or use it in a very Flash-intro-ish way. I showed just how annoying it is to play Angry Birds online and how the recent Cut the Rope port looks much smoother. I also pointed out that none of them really use the web to their advantage by for example have feedback mechanisms or allow for level editing.

In essence I wanted the audience to think about bringing HTML5 into the “boring” world of day to day deliveries instead of just games and showcase sites. For this, I showed a few code examples and explained how they can benefit from HTML5 features.

I showed how to move an element to the current mouse position and how you can make this faster by using CSS translate instead of left and top using translateZ(0) to trigger hardware acceleration even when you don’t go 3D. I then showed that you can move things smoothly by adding CSS3 transitions instead of writing a JavaScript animation.

I continued introducing the 3D CSS maker, a tool to play with CSS 3D translation and animation that generates code for you.

The blue beanie maker was next showing how you can use drag and drop to put an image into the browser and manipulate it with Canvas.

The image cropping with canvas demo shows how you can enhance the functionality of browsers without having to write and install extensions. In it you can get a bookmarklet to crop any image on the web in the browser by double-clicking (in Webkit and Opera) or with a context menu (in Firefox).

I then continued to show a demo of less obtrusive video overlays showing how you can add hints for overlays on videos by reading data- attributes in the HTML and reading the current time of the video.

The last demo was a simple game with a an HTML twist that showed using canvas for game animation, touch, orientation and keyboard events to control a game paddle and how to read the necessary game data from HTML and thus making it easy to rebrand and change the game.

I ended with a plea to try some of these things out and play with all the cool APIs and hooks browsers provide us with these days instead of relying on frameworks and libraries for everything or build for one single environment. HTML5 is there for developers, if we allow only marketing people to play with it we do a disservice to ourselves.

I will follow up this with in-depth posts on hacks.mozilla.org and we also shot videos of the talks which will (quality permitting as there were some issues) be released soon.

All in all I had a great time, got lots of good questions and enjoyed the event a lot. Seeing that Vancouver is only a 2 hour flight from the valley there is a big chance I will be back soon.

During some interesting discussions on Twitter yesterday I found that there is now more than ever a confusion about JavaScript dependence in web applications and web sites. This is a never ending story but it seems to me to flare up ever time our browsing technology leaps forward.

I encountered this for the first time back in the days of DHTML. We pushed browsers to their limits with our lovely animated menus and 3D logos (something we of course learned not to do again, right?) and we were grumpy when people told us that there are environments out there where JavaScript isn’t available.

Who turns off JavaScript?

The first question we need to ask about this is what these environments are. There are a few options for that:

• Security systems like noscript or corporate proxies that filter out JavaScript
• Feature phones like old Blackberries (I remember switching to Opera Mini on mine to have at least a bearable surfing experience)
• Mobile environments where carriers proxy images and scripts and sometimes break them
• People on traffic-limited or very slow connections
• People who turn off JavaScript for their own reasons
• People sick of modal pop-ups and other aggressive advertising

As you can see some of them are done to our end users (proxying my companies or mobile provider), some are probably temporary (feature phones) and some are simply their own choice. So there is no way to say that only people who want to mess with our cool web stuff are affected.

Why do they turn off JavaScript?

As listed above, there are many reasons. When it comes to deliberately turning off JavaScript, I’d wager to guess that the main three are security concerns, advertising fatigue and slow connectivity.

Security is actually very understandable. Almost every attack on a client machine happens using JavaScript (in most cases in conjunction with plugin vulnerabilities). Java of course is the biggest security hole at the moment but there is a lot of evil you can do with JavaScript via a vulnerable web site and unprotected or outdated browser and OS.

Slow connectivity is a very interesting one. Quite ironic – if you think about it – as most of what we use JavaScript for is to speed up the experience of our end users. One of the first use cases for JS was client side validation of forms to avoid unnecessary server roundtrips.

Now when you are on a very flaky connection (say a free wireless or bad 3G connectivity or at any web development conference) and you try to use for example Google Reader or Gmail you’ll end up with half broken interfaces. If the flakiness gets caught during first load you actually get offered a “HTML only low version” that is very likely to work better.

The best of both worlds

This is totally fine – it tries to give an end user the best experience depending on environment and connectivity. And this is what progressive enhancement is about, really. And there is nothing evangelical about that – it is plain and pure pragmatism.

It seems just not a good plan under any circumstances to give people an interface that doesn’t work. So to avoid this, let’s generate the interface with the technologies that it is dependent on.

With techniques like event delegation this is incredibly simple. You add click handlers to the parent elements and write out your HTML using innerHTML or other, newer and faster techniques.

So why is this such a problem?

Frankly, I really don’t know. Maybe it is because I am old school and like my localhost. Maybe it is because I have been disappointed by browsers and environments over and over again and like to play it safe. I just really don’t get why someone would go for a JS-only solution when the JS is really only needed to provide the enhanced experience on top of something that can work without it.

The mythical edge case application

A big thing that people keep coming up with are the “applications that need JavaScript”. If we are really honest with ourselves, then these are very rare. If pushed, I could only think of something like photoshop in the browser, or any other editor (video, IDE in the browser, synth) that would be dependent on JavaScript. All the others can fall back to a solution that requires a reload and server-side component.

And let’s face it – in the times of Node.js the server side solution can be done in JavaScript, too. Dav Glass of Yahoo 2 years ago showed that if a widget library is written to be independent of its environment, you can re-use the same rich widget client and server side.

The real reasons for the “App that needs JavaScript” seems to be a different, non-technical ones.

The real reasons for “Apps that need JavaScript”

Much like there are reasons for not having JavaScript there are reasons for apps that need JavaScript and deliver broken experiences.

• You only know JS and think people should upgrade their browsers and stop being pussies. This is fine, but doesn’t make you the visionary you think you are as it is actually a limited view. We called that DHTML and it failed once – it can fail again
• You are building an app with a team without server side skills and want to get it out cheaply. This can work, but sounds to me like apps that “add accessibility later”, thus quadrupling the time and money needed to make that happen. Plan for that and all is good.
• You want to get the app out quickly and you know you’ll have to re-write it later. This is actually a pretty common thing, especially when you get highly successful or bought by someone else. Good luck to you, just don’t give people the impression that you are there to stay.
• Your app will run in a pure JS environment. Of course this means there is no need to make it work without JS. One example of this would be Air applications. Just make sure you bet on tech and environments that will stay on the radar of the company selling it.
• Your app really needs JS to work. If that is the case, just don’t offer it to people without it. Explain in a nice fashion the whys and hows (and avoid telling people they need to turn it on as they may not be able to and all you do is frustrate even more) and redirect with JS to your app.

In summary – sort of

All in all, the question of JavaScript dependence reaches much further than just the technical issues. It questions old best practices and has quite an impact on maintainability (I will write about this soon).

Let’s just say that our discussions about it would be much more fruitful if we started asking the “what do we need JS for” question rather than the “why do people have no JS”. There is no point in blaming people to hold back the web when our techniques are very adaptive to different needs.

There is also no point in showing people you can break their stuff by turning things in your browser on and off. That is not a representation of what happens when a normal visitor gets stuck in our apps.

Maybe all of this will be moot when node.js matures and becomes as ubiquitous as the LAMP stack is now. I’d like to see that.

A few days ago I was in Berlin to speak at the JSConf EU for the first time. As a topic I covered how we as a JavaScript community should be doing more to bring our knowledge out to the world and I showed off some upcoming great developer tools Mozilla is working on.

The presentation slides are available here.

The audio recording of the talk is available on archive.org.

JSConf was amazing, I had a great time and I hope I managed to inspire some people.

Yesterday we went to a cool park in Krakow, Poland where they have all kind of physics experiments for kids (and me):

One of the things that always fascinated me was the optical illusion of non-concentric circles turning into a 3D cone. Take the following picture:

And then rotate it and you see what I mean (video on screenr).

Now, coming back (like any other kid) I wanted to recreate this for myself, and it is actually pretty easy in HTML5 canvas. If you get the embed below, then click the play button to see the result.

Check the source code. In essence all you do is paint a number of concentric circles with alternating black and white colouring and you decrease their radius. Instead of keeping the centre of the circles the same you move it back forth with a sine wave.

The animation works simply by rotating the canvas around the centre – no need to calculate the rotation in the loop.

This is what also ailed me about this: as the main image doesn’t change and we simply rotate the canvas, there is no need for the painting loop in the animation. Although the performance seems to be fine (at least here on this Macbook Air), I am pretty sure that the animation without the calculated circles will be smoother and less resource hungry. That’s why I painted the circles in one canvas and copy it into the animated one as an image. You can see the two canvases (the painting one in lighter grey) in this demo. Again, if you get the embed below, then click the play button to see the result.

The next step was to take the advice that everybody tells you right now and think about CSS animation as it is hardware accelerated and much better (citation needed, but that is the impression that I get). As all I am doing is to rotate a canvas around itself, it seems to be a good idea to do that. So, in the next example I animate with CSS and only use canvas for painting:

Smooth! I like it. What I don’t like is that now it does nothing in Opera for example. The other thing that annoys me is that the CSS is ridiculously verbose as I have to repeat all the animation information and keyframes for each browser with different prefixes.

That’s why I wanted to see if I can use CSS animation when it is supported and create the animation on the fly. That can be done but it is not that easy. Check out the result.

This seems to work nicely, try it in Opera and in other browsers to see the differences and get information what kind of animation was used. If I used transformation instead of animation it would even be easier. As it stands now, you can’t access, create and change keyframes that easily. this post has some more info on the issue and Joe Lambert did another showcase. Makes you wonder if we shouldn’t create an easier bridge between JS and CSS animations.

I am currently at YUIConf in Sunnyvale, California to learn lots about YUI3, Node.js and YQL straight from the horse’s mouth. Yesterday I gave my first talk on using YQL in a sensible manner – coming from using webservices in JavaScript up to using localstorage to speed up your apps and keep state for your end users.

The Slides

The Audio

Now I need to write my second talk for later on – stay tuned for that one.