Web development is not what it used to be. It has undergone so many transformations and changes that it is pretty confusing to keep up with what is going on. My main problem right now is that as someone working for a player that provides the world with a browser and is involved in defining the future technologies of the open stack I wonder who our audience is.

There is no one “web developer”

I am a web developer. I build web products and I love how simple it is to create meaning with semantic HTML, interactivity with JS and make things beautiful and more intuitive with CSS. I come to this from a developer angle, as I am a terrible designer. This makes me an endangered species.

In the last few years web development has gotten a lot more players. Moving JS to the server side and the advent of Websockets, Node.js and technologies like Phonegap and Emscripten, and yes, even GWT allow a lot more people who never bothered with the web to build web apps. And this is damn good as different knowledge can lead to better and more scalable solutions. It also means we can deliver faster to a market that is hungry for more and more products. And it also forces us to re-think some of our ways.

I’ve talked to people who are amazing in HTML/CSS/JS and feel the need to learn at least one server-side language or at least get into patterns to understand what their colleagues in the web development team are talking about. It seems the shift from web sites to apps means that we need to shift much more to traditional app development than we are ready to admit yet.

Staying in our comfort zones

However, I don’t see much mingling going on. The design-y conferences of this world talk about “mobile first” and how responsiveness will always beat strict native apps and the tech-y conferences get very excited about replacing old-school web development with MVC frameworks in JavaScript and how to use JS to replace other server-side architectures. We’re stuck in a world of demo sites and showcases and “hello world” examples that can “scale to thousands of users per second” but never get the chance to.

I know, there are a few outstanding examples that are not like that and I generalise, but look around and you will see that I have a point. We get excited about the possibilities and revel in academic exercises rather than getting real issues fixed and showing how to deliver real solutions. This goes as far as discussing for days whether to use semicolons in JS or not.

Who is the audience?

But let’s go back to browsers and standards. I really am at a loss as to who we are talking to when it comes to those. Personally I see a lot of that in the feedback I get. Say I just gave a talk about HTML5 and what it does for us. Audio, Video, richer semantics, JavaScript APIs that allow us to draw and store data locally, all that. I normally end with something like GamePad API, Pointer lock or WebRTC to show what else is brewing. The feedback I get is incredibly polarised:

• Yeah, yeah, cool but why don’t you support the new experimental feature $x that browser $y has in the latest Nightly?
• That’s cool but I don’t like using your browser (my favourite, as it has nothing to do with the talk :) )
• This is all fine but none of my clients will ever need that
• Great, but I can not use this as all my clients use browser $shouldhavedied and will never upgrade

Now the luddite fraction of this has a point – a lot of what we show when we talk about “the bleeding edge” can only be used (for now) in Nightly releases of browsers or need certain flags to be turned on. In some cases you even needed a special build of a certain browser (like the GamePad API in Firefox or Adobe’s first CSS regions proposal). This means we do expect a lot of investment from our audience for something that might change or be discarded in the near future.

The “ZOMG YOU ARE SOOO BEHIND” fraction has a point, too – if they put their money where their mouth is and really use these new technologies in products rather than just getting excited about getting something new and shiny every week. Otherwise this is just borderline trolling and doesn’t help anybody.

Getting the bleeding edge into the mainstream

The question then is how could we ever get the new technologies we talk about used and implemented? There is no doubt that we need them to make the web the high fidelity app platform we got promised when some company arrogantly proclaimed Flash to be dead. But who will be the people to use them? In a lot of cases this only happens inside the companies that drive these technologies or by partners these companies pay to build showcases to prove that things could be amazing if we just started using new tech.

To me, this is not scalable and sad. We should be innovating for the people who build things now and not for a future that needs to come. This is less sexy and means a lot more work but it means we build with our audience rather than trying to lure them to change.

If you keep your eyes open then you see that actually a lot of what we consider amazing work is a very small percentage of the market. Tech press loves to hype them up and companies love to (pretend to) use bleeding edge technology to attract tech talent to work for them, but the larger part of the market wants one thing: getting the job done.

The majority of developers use libraries and frameworks

In the case of the web development this means one thing: libraries and polyfills. Yes, the things we considered a necessary evil to be able to build things fast and still support outdated browsers are now the thing people use to build web products. These are also the things they tell others to use – try to find a question on Stack Overflow that has no “use jQuery” as at least one of the answers. Try to find a CSS example that supports various prefixes rather than pulling a “this works only in webkit” or “use Less, no, use SASS, no use SMACSS...”.

Abstracting away the need for basic knowledge

Talking to colleagues and peers in other companies I hear a lot of moaning and complaining that it is impossible to hire real JavaScript developers as 90% of applicants come in and only know jQuery. They have no clue what an event handler is, how to navigate the DOM or create a simple XHR call without the library. Ridiculous? Not really – we are actually to blame.

The “in-crowd” scene has a fetish for abstraction. Instead of building applications and solutions we build more libraries, micro-libraries and polyfills to abstract the evil away from implementers and then we are surprised if implementers don’t know the basics any longer. Well, they used the precious time they had to learn what we build and started getting things done. And this learning time multiplies with the amount of things we release. The hour learning backbone, SASS, LESS, hammer.js or whatever is gone and should be used to build things with it now. All the more despicable when as the “cool kids” we just drop those libraries a few months later and build the next big thing.

Shouldn’t we innovate with existing libraries?

The question I am asking myself right now is this: when most of the market uses libraries to get their job done, why do we bother assuming that people would go back to writing “native” code for browsers – especially when we fail to produce standards that do not differ across browsers?

Wouldn’t the better way to get something done to build jQuery plugins that use the new APIs we want people to play with in an unobtrusive way and see real applications built with them? A great example are performance enhancements like requestAnimationFrame and pageVisibility. We can whine and complain that libraries are horrible and especially on phones drain the battery mercilessly or we could just start playing where our audience hangs out and improve where the errors happen rather than pointing them out.

Of course some things need us to find people to play with tech outside the libraries but a lot could be sneaked in without people knowing and then allow us to show real examples where a plugin that uses a new feature made an older implementation perform much better.

I’ve tried to do this with my talk at jQuery UK earlier this year. I showed the JavaScript equivalents of jQuery solutions and that browsers now have those and how following their ideas and principles could lead people to write better jQuery. I got good feedback so far. Maybe I am on to something.

Drop me an answer on Google+ or Facebook’s HTML5 group.

This cost me far too much of my time yesterday night: I had reconnected my Android Tablet (Galaxy 10.1) after running out of battery for quite a while and connected to my wireless and surfed the web – all fine – except for “certificate errors” on a few pages. This is nothing new, SSL is broken far too often sadly enough.

When connecting to the Market to download new apps or get my Google Mail or Reader items it always told me though that I was offline. Looking at Android forums I got a lot of wrong advice like “Going back to Best Buy”, “Deleting cache and force-stopping Market and rebooting the device” or “doing a factory reset”.

The fix is simple:

If your Android tablet throws certificate errors when surfing and can’t connect to the market, your time and date are wrong and set in the past. This breaks the SSL negotiation. Simply fix time and date and it works without you losing data.

This should be part of the error message when you get certificate errors.

Things that made me happy this morning:

• The new employee’s handbook at Valve (PDF) is pretty much how things like that should be written. Great job.
• Adobe’s new HTML landing page shows their open source web things in one spot
• Angular.js by Google is a new MVC framework in JavaScript
• Twitter hacking the software patents world with their
• Twitter releasing a Code Class video. this.droid joke FTW
• Brad Frost, who will be the next web superhero, delivering a great article on HTML5rocks.com on Creating a Mobile-First Responsive Web Design
• My boss Stormy opening the lid on how Mozilla creates communities of awesome at the Global Community Champions Workshop
• Browser Pairs is a lovingly designed HTML5 game pairing browser images(source on GitHub) – an upgrade of my attempt at that, if you will.
• Benham’s top is an interesting little optical illusion creating colours by spinning a black and white pattern
• Stroll.js animates lists while scrolling them
• Open Exchange rates is a JSON API for hourly updated exchange rates
• Transferring apps and data from one Android device to another explains just that
• I love the internet is something I say every day, too

A common issue when you play music loud in a shared environment is that you will inevitably play songs that someone in the room hates. In the past this was less of an issue as changing the tape or CD was quite a task. Nowadays we have millions of songs to choose from and – of course – also have a much higher chance to miss the taste of your colleagues.

Agency republic in London chose to tackle this issue in an R&D project by putting up a poster in the office that says “change the tune” and when you hit it with a piece of paper (or other things handy) an Arduino powered simple piece of hardware in the poster changes the tune on Spotify.

We have a shared music machine in our studio. Anyone can put anything on they want at any time, no rules. It’s a democratic system that seems to work 99% of the time. But occasionally the system fails and that’s what inspired me to build this poster. Built as an R&D project at agencyrepublic.com

Check the video on Spotify:

Now Michael Robinson needs to release the code, Muahahaha!

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+