I go to a lot of conferences. I organised events, a conference and a few unconferences and I spoke at a lot of them. Lately I also stepped back a bit to coach people to speak instead of me going everywhere.

I think conferences should do a few things: educate, entertain, allow people to network and make speakers and experts available to attendees.

You don’t need to go to conferences to learn things – all the information is on the internet and signing up to a few good feeds, groups and lists will get you all the info you want.

What conferences do is bring the human factor into it. A good speaker can make a topic come to life and show you an angle you had not thought about and inspire you to play with it. A good workshop gives you guidance how to use a technology and gives you a way in without being overwhelmed by a big scary topic. A conference gives you time out from the day to day delivery and allows you to do things that are not yet on the radar of your company but might be soon.

And then there are “browser war panels”. The original premise of the browser war panels was that an audience could hear the latest and coolest about different browsers and ask questions. The first ones were held at Yahoo and had lead engineers from the different browsers to show how the different products work as that was dark magic back then.

HTML5 defines how a browser should deal with the content it gets – we have a lot more predictability already in the standard. A lot of great information on this topic is out on the web and the accelerated speed of delivery of browsers makes the appearance of platform engineers not happening much. There is no need to repeat the standards, instead the discussions are much more about what makes which browser stand out and in a lot of cases this means what the company wants to promote – not what developers want to use now and get stuck as it doesn’t work.

Browser panels these days get people from companies who are either product evangelists of the browsers or general tech evangelists, advocates, or – in the worst case – sales people. This could be good, they can point out features that are in the browsers people don’t know about and they can show some of the plans for the future of the browser. It can also be awful. As browsers are interesting to the media out of a sudden you see a lot of patterns being followed. Instead of giving information about the browsers, dealing with concerns of developers and implementers or showing changes panelists begin to fall into predefined roles and repeat the messages of the companies they represent.

It becomes predictable to see which company representative will value speed over everything else, which one will praise a great experience in the browser as part of a bigger OS experience, which one will talk about following standards and complain about sites blocking out browsers and which one will point out that the browser is the choice of the user and should keep them in control by being open about everything whilst following standards.

The bigger focus on browsers we have these days makes a panel much less of an educational part of the conference (many a time you will get “I have to go back to the engineering team for this”) but pushes it into the entertainment part of a conference. It is a veiled sales pitch.

Everybody loves a good drama. You could go as far as saying that we have a whole tech journalism market that lives on drama. It is fun to see people disagree on topics and make good arguments about one side or another.

A quite open, unscripted and unplanned format like a panel makes for great drama. It is easy to take potshots at each other and score browny points with the audience with pointing out flaws of the other browsers in a glib fashion. It also gives browny points with the audience to make sweeping statements or deliver soundbites.

Soundbites, being witty and fast are becoming the most important part. If you look at the Twitter stream of a browser panel you will hardly ever find a “oh feature $x will ship in browser $y – so cool” but you will get more “$x of browser $y just called $z out on the $a issue”.

Soundbites are also loved by the press. And as drama brings headlines many a time you will find a sarcastic remark or glib retort show up as “Company representative $x said $y about the competition”. A quick shot to get a giggle out of the audience can cause the communications team of a company to get a lot of unnecessary work. Is that worth it?

I’ve even been on panels where the organisers deliberately asked panelists to find topics to disagree on or seen panel moderators throw out one loaded question after another to entice people to disagree and get the drama going. We call this trolling or baiting, and not a way for conference participants to learn about what is going on in the browser world.

It is not hard to find what is going on in the browser world when you look at the open source engines. You hear much less about the closed ones and to me a panel that has no participant of Apple on it is not a “browser wars” panel as it lacks a massive player who should answer quite a few questions web developers have.

There are exceptions. I thoroughly enjoyed being on the panel at State of the Browser 2 in London and I think as there were no egos and no artificial drama we managed to answer quite a few questions from the audience. But on the whole, these are few and far between and many a “Browser Wars” panel is entertainment and cheap laughs or “wow, did he just say that” moments.

This, in the long run, is not fair to the audience who paid good money (and should get real comedians or entertainers if entertainment is the goal), it is not fair to the platform engineers (as they are misrepresented instead of allowing people to peek under the hood with them) and it does not get us anywhere in the real “browser wars”.

As developers you should not be tempted to build for one browser only and you should not have to build different versions for different browsers. Keeping it all about drama and who shouts the loudest and comes across as most witty doesn’t make that happen. It is a waste of time.

The easiest way for this are all the “new” services like JSFiddle, JSBin, Dabblet, Tinker.io and others (there seems to be a new one every month now) and you can even embed them into other documents, but it means you need an iframe and load content from another service (which might go down or get forgotten in the future).

The other way of course is to use Ajax/JavaScript to load the code into the page. Back in 2008, I wrote the Ajax Code Display script for that (and subsequently I never used it much).

I was wondering how you can simply demo and show inline JavaScript in a document without needing any extra libraries. The simplest way seemed to read out the innerHTML of the SCRIPT element and write it out into a PRE using textContent (innerHTML would render HTML or greater signs in the script, which isn’t the idea).

However, you can do a simple demo and display of the same script much easier these days using CSS. Check out this demo page for an upcoming Smashingmag article:

If you do a view-source you find no other script in use, yet it displays in the page. What is this sourcery^*? Simple, and it was Mathias Bynens who got me onto it: just display script elements as block and add some generated content to show the “Source” text:

script {
  display: block;
  white-space: pre;
  text-shadow:none;
  background: #333;
  color: #fff;
  font-family: monaco, courier, monospace;
  padding: 10px;
}
script::before{
  content: 'Source:';
  color: #0f0;
}

Mathias has much more detailed explanations on why that works but I for one am once again amazed just how much easier things are these days with the awesome browsers that we have.

^* Sourcery = magical code that does (seemingly) unexpected things.

I love public speaking – so much that I spent most of the last year on the road (39 conferences in 27 countries to be exact). This year, I thought I cut back a bit on that (so far I very much failed in that, but hey). Instead, together with my awesome colleague Shezmeen Prasad I am concentrating more on making other people in the Mozilla community speak. This means I want local people to step up and speak at conferences rather than flying around the globe for talks. This doesn’t mean that I won’t be speaking, it just means I want to be a bit more selective and I want to hand over opportunities to amazing people from the Mozilla community who would be easier for you to get to your conferences and get a chance to shine at the same time.

I am also a very busy man (yes, my Twitter stream might make you think otherwise, but I am not kidding) and I am getting roughly 200-300 emails a day and about an offer to speak each day. This is not boasting, I am happy that people want me to speak, and I don’t want to disappoint anyone.

This is why we set up a council of people in Mozilla who deal with all the speaking request the people from Developer Engagement get. All conference communication should go through that council so that we can avoid double bookings and frustrations on your and our side.

You can see where we will be speaking at the Where’s Mozilla site and in order to tell me about a great opportunity, here is what you do:

Send an email to dev-events@mozilla.com which will go to the council. Please include (if possible):

• The dates and location of your conference
• The nature of your conference (who do you target, how many people you expect, how many talks will be there)
• The nature of the talk (keynote, workshop, panel…)
• If there are any travel arrangements or not

I have a few simple rules about my talks:

• The slides will be public and I can’t provide them upfront (as I write a new talk every time)
• I want a recording and coverage of the talk to be released after the conference
• I want to have a prime-time slot or keynote (bored of half-empty rooms)
• I talk about web development in a holistic sense, I am not the “Firefox guy” to go on a panel to fight with other browser makers – this is boring and destructive to the cause

Sorry about that, but I put a lot of work into my talks and I want to make it worth while for everybody.

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.

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.