TL;DR: if you advocate omitting sensible syntax as parsers will fix that for us, you are not a visionary developer. You waste your and our time. And you come across as a semi-colon.

We finally arrived at the official JavaScript drama with big players like Brendan Eich and Douglas Crockford involved in the discussion. The start of this is part of the bootstrap library that is missing a semicolon at the end of a line and thus failing minification using JSMin.

clearMenus()
!isActive && $parent.toggleClass('open')

Now, this could be easily solved – by adding the friggin semicolon. However, this is not what this is about. It is about being right and questioning the status quo and authority (granted, some of the sweeping statements by the authorities do invite a certain resistance). The culprit of the code above is a person who proudly announced that he doesn’t write JavaScript but code for browsers which allows him to omit semicolons.

I know, therefore I can be sloppy…

Well, whoop-de-do! Way to fight the system and lead us into a better future. My favourite here is the quote stating “i have learned to use them, that’s why there isn’t one present.” When being rudely asked to learn how to use semi-colons. This is the equivalent of “I know English, which is why I write in TXTSPK”.

Not a good comparison? I disagree. The main issue with these parser-fetish arguments is that they assume that you write code for a parser – sometimes even a certain browser – and not for other developers. To me, this is either arrogant, sloppy or lazy. Pick one.

Why would any intelligent person want to make it harder for others to understand what they’ve done, keep booby-traps in their code that will cause errors or deliberately write in a way that might make others stumble? Is this some kind of code-trolling I don’t get?

We do this because we can and fail to say why

The technical benefits of doing these parser tricks are in most cases negligible – in this case even non-existent – yet in the debate the most requested feature is arguments why you should not do them. Before we do that, why not give us a few arguments why we should omit a few characters that make things much more understandable for no discernible gain?

You don’t hire writers and editors who can not write without using autocorrect and a thesaurus – you expect them to know their job and how to write. The same should apply to development – we stick to an agreed syntax that works instead of celebrating how well our tools undo what we did wrong and start thinking for us.

Enforced harmony means slower execution

The brain is a wonderful thing. It seeks harmony. In graphic design and pixel work we rely on our brain fixing things for us – a lot of animation is trickery using the laziness of the eye to finish a curve for us. Antialising makes things look smoother by showing colours that are close to each other as a blur. Our brain fixes minor issues automatically for us. This mns we cn frget to wrt sm thngs nd our brns still make them work for us. But it comes with a price. As the brain is busy with making connections we read less in the same time. It is a security blanket, an error case with repair measures and shouldn’t be something we rely on.

If we write code a parser fixes for us but seem weird or incomplete for developers reading our code we continuously rely on their brains to fix things for them. This makes all the efforts of “writing code faster” pointless as we push the time-wasting to a later part in the project – and make other people suffer for our laziness.

But parsers are TEH AWSM! Let’s use them

A lot of talks praise the amazing efforts that went into the HTML5 parsers of new browsers which makes it possible for you to not close tags, not add quotation marks and in general write a total mess – the browser will make something workable out of it. Browsers do this step in any case – the DOM representation we see is not the code we wrote. Mathias Bynens does a good job showing us just how much you can omit and still get a valid DOM from the browser. Which is good – he pokes the parser and shows the browser makers what works (also in terms of CSS parsing and JS variable names). It doesn’t make it a sensible way to work though.

The reason why our parsers are so lenient is that the web is already filled up to the brim with horrible code and we don’t want to break backwards compatibility. It is not a carte blanche to write more sloppy code. We’ve done that, we should not write more code faster but cleaner code and re-use it more often.

Write people-friendly, forward facing code, don’t be a semi-colon

All in all I get the feeling that people who argument for code that needs magical insertions and fixes by browsers simply want to show off that they can do things differently. I can type with my toes, doesn’t make it a good idea in most of the cases though. Writing clean and readable code makes you a nice person to the people who take code over from you. If there is a benefit for browsers to have certain things removed you can still do that with a build-script. No need to confuse people out there and force your idea of optimisation on them.

My biggest concern about parser-fetishism is that all the examples I see do not scale for sensible other use cases. The most obvious one being omitting quotes around attributes:

<a href="http://b3ta.com" class="external">go on, waste your afternoon</a>

is equivalent to

<a href=http://b3ta.com class=external>go on, waste your afternoon</a>

Except the second version looks horrid when it comes to colour-coding:

Now, what if we need a second class on the link?

<a href="http://b3ta.com" class="external unicorns">go on, waste your afternoon</a>
<a href=http://b3ta.com class="external unicorns">go on, waste your afternoon</a>

Oops, out of a sudden we need the quotes! Adding them up-front makes sure a maintainer doesn’t need to do that for us – and they get lovely colour-coding to boot. All for the price of a ” which even gets closed automatically by our editors. Some even offer autocomplete for the content that goes in them. Magic!

Closing tags is another example. I remember seeing a talk by Paul Irish where he praised the readability of not closing table cells and using the saved characters to lay out the text in the grid the table will be:

Regardless of the fact that CSS could be used to totally layout that table in a different way this also shifts horribly when you translate the content:

Another example are curly braces. Yes, the following works fine:

if (navigator.golocation) deploySelfDrivingCar();
else asknicelyforlocation();

But when you add more functionality, it’ll break:

if (navigator.golocation) deploySelfDrivingCar();
  notifyFlyingMonkeys();
else asknicelyforlocation();

Adding braces from the very beginning means it is easy to extend:

if (navigator.geolocation) {
  deploySelfDrivingCar();
} else {
  asknicelyforlocation();
}

Adding more features is obvious and even comes with a nice indent. In some editors you can even collapse the condition to make your code faster to scroll through:

if (navigator.geolocation) {
  deploySelfDrivingCar();
  notifyFlyingMonkeys();
} else {
  asknicelyforlocation();
}

So, if your code needs syntactical changing when it gets extended, to me you’ve optimised prematurely. Code will always change and making sure our maintainers have a hard time breaking it is a very simple and good idea.

Summary

I think it is a sign that as developers we are either terribly bored or we are out of ideas when we start to go down to bickering about violating accepted ways of development. We should concentrate on building amazing tools and experiences for users out there rather than smugly trying to undo conventions we’ve been following for years now. The web standards movement was not about enforcing arbitrary code syntax on poor developers who now have to type a few keys more. It is about making code predictable, extensible and easy to explain to newcomers. Confusing these matters doesn’t help the cause of making a new generation of developers embrace the web as a platform. Don’t be that guy.

And if JavaScript or HTML doesn’t do the thing you love in the other language you like – tough. I don’t like the inconsistencies between French, German and English and yet I have to follow them when I want to be understandable. If you don’t want to speak a certain language, don’t do it; partner with somebody who does instead.

Let’s discuss it on Google+

After giving my talk “HTML5 and the near-future of the web” (screencast and slides) at the Mosync hackathon in Stockholm, Sweden I thought I should have a bit of fun using the Gamepad API with my trusty USB Competition Pro. The result is the joystick powered kitten cube:

All in all, I put a few old hacks and ideas together. The 3D cube transformation from a few months ago, Paul Hayes’ animated cube and a bit of Gamepad API magic:

var xAngle = 0,
    yAngle = 0,
    cube = document.querySelector('.cube');
 
window.addEventListener('MozGamepadAxisMove', function(e) { 
  if ( e.axis === 0 && e.value === 1 ) { yAngle += 90; }
  if ( e.axis === 0 && e.value === -1 ) { yAngle -= 90; }
  if ( e.axis === 1 && e.value === -1 ) { xAngle -= 90; }
  if ( e.axis === 1 && e.value === 1 ) { xAngle += 90; }
  cube.style.MozTransform = cube.style.webkitTransform =
  cube.style.msTransform = cube.style.oTransform = cube.style.Transform =
   "rotateX("+xAngle+"deg) rotateY("+yAngle+"deg)";
}, false);

That was all that was needed. No kittens were harmed in the experiment.

So here are a few Things That Made Me Happy this morning – some of them need a bit of your time, but are worth while. Two of them made me cry – not ashamed to admit.

• Caine’s Arcade is a video of a kid building his own cardboard arcade in his dad’s car parts shop. Dedication at its best
• Alive Inside tells the story of people in a nursing home who stopped reacting at all to the outside world and getting back into it by getting iPods to listen to music from their past
• Bret Victor – inventing on principle is a talk showing how the future of development, design and animation tools could look like and why you need a principle to guide you when inventing. The Live Scratchpad and the editor of the game Frogatto are demos how to implement some of these ideas
• Daniel Sternlicht’s portfolio is a fully playable 2D adventure game
• Wollstonecraft is a Kickstarter project to release a pro-math, pro-science, pro-history and pro-literature adventure novel featuring Ada Lovelace
• Travel posters for lazy people make your life look so much more glamourous
• The Hackday Manifesto sets some sensible ground-rules for hack days
• The Weapon of mass instruction is an art tank that gives out books

One of the things we want participants in the The Evangelism Reps program to do is give us a quick introduction video of themselves to have a face to connect to a name. This should not be anything big, a simple, “hi, here I am” will suffice. So here is my introduction as an example.

All in all the production and publication time of this was an hour – and that included cycling a mile to find a shop that has Tofu sausages and Babybel cheese. Here’s what I used:

• A MacBook Air (could be any laptop with a camera)
• Photobooth (or any other tool that can record a camera – this could be on your mobile, too)
• MPEG Streamclip

The first thing to remember when trying to do something like this is to simply for go for it. So I wrote myself a little script and just had it open next to the recording tool:

Technically, this is not good, but I wanted to do this quickly. You can see my eyes flicking to my script from time to time. I shouldn’t have to as I knew what I wanted to say but humans work that way. Give us a “Linus blanket” and we will always come back to it.

Regardless, of course this didn’t work in one go, so here is the full recording with out-takes:

This is the simplest way to record – don’t try to re-start the recording and delete it in between failed takes, just go on and cut the bits that didn’t work afterwards.

You can see that I waved my hand over the screen every time I started again. This is the sign to myself that another take started.

For cutting, I used MPEG Streamclip which couldn’t be simpler:

1. Go to the hand movement and find the start of the next take
2. Hit O for “out” – this highlights the video from start to where you are now
3. Press cmd+x to cut (delete) the video up to the point where you are
4. Find the end of the video
5. Press I for “in” to mark the video from there to the end
6. Press cmd+x again
7. Save as MP4

You can see this in action on vid.ly.

All in all this is very simple to do, so I am looking forward to a lot of those cropping up in the nearer future.

As a ramp-up measure for the Mozilla Evangelism Reps program I just finished a first draft of tips and tricks how to approach technical blogging in Mozilla.

Topics covered are:

• Basics of blogging – being a spokesperson
  • Be professional (no racism, sexism, calling names)
  • No political and religious views
  • Have something to say
  • Speling duz kount
• Doing research and finding gaps to fill
• Tone of voice
  • Use active voice
  • Use short sentences
  • Skip the foreplay
  • Give a full disclosure
  • Answer the WIIFM - “what is in it for me”
  • Stick to one thing and explain it well
  • Give credit where credit is due
• Structuring your post
  • Use proper headings
  • Tell your story
  • Use lists
  • Give away everything at the beginning
  • Add breathing space
  • Extra value goes to the end
• Linking
  • Link meaningful text
  • Links are proof, not context
  • Know your link targets
  • Test your links
  • Provide “read more” resources
• Images
  • Link to the resource
  • Use absolute image paths
  • Have a sensible alternative text
  • Crop what is not needed
  • Play nice with people’s bandwidth
• Multimedia (Screencasts, Audio)
  • Provide a fallback link
  • Keep them snappy
  • Cross-link from the video site
• Code examples
  • Link the original source
  • Embed readable code (colourcoding, Gists, interactive code examples with JSFiddle/JSBin/Tinker.io/Dabblet)
  • Make your code work
  • Write code for the web
• Cross-posting and promotion
  • Do not publish the same blog post on different blogs
  • Write targeted smaller posts linking to the main one
  • Link all the resources back to the blog
  • Find outlets to promote the post

A lot of this might appear basic to the casual observer, but I am constantly amazed just how many simple things are done wrong when posting technical content. So I hope this will help some people get started on solid footing.