looking for a full-immersion/face-to-face HTML5, JavaScript, and Mobile Web Development training in the heart of London? Book your spot

Friday, July 17, 2015

A Simplified EU Cookie Law Approach

Thanks for everyone starring the repo, cookies-monster made it to cdnjs!
I've already talked about the EU cookie law, but moaning about it won't solve the issue. Until common sense and competence will reach European politics so that this law can be erased, we should provide some info to our users.

Not Another Library

There are already few solutions that require a manual or libraries plugins that will cost much bandwidth.
I've decided to use my "special vanilla powers" and go lightweight for real: 578 bytes once "minzipped".
There is absolutely nothing else to do than just including the script. Zero config, drop in and go.

You Are Free To Text & Style

There's no predefined template, there's no predefined style, unless you'd like to use the same I've used for the following page:

You are in charge of the message to show, and you could put an optional link or a button in it with the class cookies-monster-accepted.
If the script will find such button, it will configure it as explicit call to action and once such link/button has been clicked, it will set a cookie that will expire in a year, and it will add the class hidden to the main container which should have a cookies-monster id.
Following an example of the most basic layout.
<div id="cookies-monster" class="hidden">
  This sites uses cookies. <a

Nothing else ... really

Since you are in charge of pretty much everything, you know what to write on your banner, with the needed language, and with any extra link or option you want. Just stick the script in and you are ready to go!

What would be awesome though, is some star to its repo, even if you have your own solution, so that we can move the script in cdn.js and forget once for all about this problem.

Thank You for reading and contributing!

Thursday, July 16, 2015

Why you should learn Mobile Web Development

When I've decided to define 3 courses and levels, I had to include the Mobile Web Development one.
When I tell developers or random folks about such course, they ask me:
"why? come on, I know Web, how different could that be? what's the point?"

Yet Most Websites Still Fail

For instance, I've tried to book a flight yesterday from my Android 5 daily phone which is not even in developer mode and I use the default Chrome browser (I know, shocking, but you gotta test what real world users will see!).
You can see I couldn't do it via this video:

Not That Site Only!

I'm pretty sure they will fix this problem at speed light, and while same operation worked on an iOS based device, it's shocking even most popular or famous websites can fail that bad at very most basic tasks like scrolling!

Few developers still believe Mobile Web is about bringing in some Mobile library and that's it. The amount of different things happening there, different surfing paradigms, and different, really, everything, is the most under-estimated problem we have these days.

And the best part everyone is missing is that you don't need to add libraries on Mobile Web, most likely you need to drop them!

Do You Trust The App?

Every business is apparently laughing at HTML5 and Mobile, offering an App for something they cannot even make it work on a browser.
Apps, are privileged pieces of software so I ask you one thing: why do you trust apps when the easier to develop Web counterpart doesn't even work?

As Summary

You don't have to come to my courses if you think you don't need it, but if you don't test on mobile, you can also stop right now offering poor alternatives nobody cares 'cause nothing works there anyway.
But please, stop saying that HTML5 or the Mobile Web platform is the problem ... it's simply NOT!

Sunday, July 12, 2015

Toward Better Code Quality

I regret yesterday I've written a post full of anger, in my "good old" style, a post I've put back as draft 'cause it will not reach who it should reach, but it will offend who won't care about the message I was trying to make: stop following other developers and other companies code styles!

OK, but where to learn how to code?

It's easy for me to spot things that aren't right, I have many years of experience and I know JavaScript specs by heart. What is not trivial at all for new comers, is how to recognize and where to find the right material in order to learn coding the right way.
Few days ago, at Microsoft JS Open Day, a developer humbly asked me which book would be good in order to update his ES6 knowledge. I've pointed him at latest Dr. Axel Rauschmayer's book, but that's already for someone that knows quite well JavaScript. I would eventually suggest Kyle Simpson's YDKJS books series too, 'cause while me and Kyle often disagree on patterns and sometimes pragmatism, I know Kyle's JS knowledge is hardly beatable and well transcribed in his latest books.
Another excellent effort in this field is given by Eric Elliott online courses, and I could go on mentioning gurus from CSS and HTML/UI world, 'cause indeed ...

It's not only JavaScript

I've graduated just yesterday at the first W3C's official HTML5 course, and the main reason I've taken such course was to understand its technical level. The course talks about basic things and never goes too deep into proposed patterns, it gives you a decent understanding of what's the web and how can you use it through HTML5 markup and JavaScript programming language at its very lowest potential.
However, the first course is not exactly an "up and running" one, there will be more courses to follow and I probably won't mind refreshing my knowledge there but you? What if you don't have 6 weeks time, no direct contact with a teacher if not through a forum, no ability to understand step by step every single dot needed to satisfy your needs? Many new comers indeed were full of questions and the support has been great, but we all know having direct interaction with "a professor" is not exactly the same thing of watching a video and practicing home by your own, right?
I've finally decided, beside doing regular consultancy, to stop moaning about how many bad articles, suggested practices, style guides are there on the internet, fighting the problem directly, exposing everything I know in full-immersion weekly courses of a maximum of 6 people in order to grant best ad-hoc, face to face, learning experience.

Introducing HTML5, JS, and Mobile Web trainings

That's correct, I am starting classes for both new comers and professionals that would like to learn how to code and step into the next level.
You can find all details in the HTML5, JS, and Mobile Web course page, and while I'm still completing site and classroom setup, you can already contact me if interested: we'll start from the 17th of August and I am looking forward to hear from you and tell you how to Web the right way. "What about server side and universal JS" ... you say? There is a course focused on JS only too, plus the flexibility to build up ad-hoc skills via face to face private consultancy.

Friday, July 10, 2015

On Whiteboard Interviews

I've been on both sides of Software Development interviews for years: as company/corporate interviewee but also as corporate interviewer. A quick and little honest spoiler is that while I've never failed as candidate (lucky me!), I might have failed as interviewer. There's surely a lot to improve in every interview process but today I'd like to underline, quite out of the crowd, why I believe the whiteboard is still good.

Flattened Skills

In Moto GP they say that rain is capable of leveling all racers, because technology there cannot do miracles or help creating performance gap. If you compare all races results you'll see that official teams are constantly on top. Every time it rains though, the pole position and quite often the podium too, will see participants usually forgotten behind the 6th place.
I like to think it's metaphorically similar in front of a whiteboard, where neither the candidate nor the interviewer can take advantage of their tools 'cause tooling is something that everyone could setup and should be completely out of the evaluation equation when it comes to hiring.

Instantly ready to go

Forget whatever waste of time a pointless and often religious war about Mate VS Sublime, Atom VS Visual Studio or Eclipse, Gulp VS Grunt, Bower VS npm, and all the BS we created around coding in these years ... you have a white paper or a whiteboard, and something to write on it.
This usually made me feel very comfortable because you know you don't want to even start talking about how cool is vi and that's all you need otherwise GTHO you are not a real coder ... etc ... etc ... it's usually not even an ice-breaker, interviewers are those feeling cool powerful individuals that will judge you from the framework of your choice, from the library you prefer, even from the Operating System you use because you just never bothered much as long as you could work.
Just avoid any opinion on tooling, try to understand what are interviewer preferences, and pretend to be interested about such good choice .. .seriously, get over ASAP any sort of conversation and look at the board asking: "shall we start?" with a kind attitude, regardless is the interviewer maybe irremediably asshole but hey, nobody is perfect!

No Keyboard Layout Barrier

Unless you can do the interview with your own laptop, something I've honestly never seen so far, you have no idea what kind of keyboard layout you'll find there. OK, you are in your own country maybe you don't care much, but I've interviewed in Berlin and coding with a German Keyboard has been the worst possible nightmare ever, and during the interview 'cause instead of focusing on the code I had to find out where the HACK all right keys where.
It's not that different if you have a UK keyboard and you code on a US laptop: watch out when you go face to face in the US from Europe folks, they often forget the rest of the world has different language which include a different keyboard layout. In case of UK, quite important chars such `, @, and $ are in completely different places and if the dumb interviewer ask you to use jQuery in his PC instantly memorize that's not the £ sign!!!
Or ... impress the interviewer asking to code at the whiteboard and every problem will be solved!

quick personal note for my Italians fellow: forget bloody Italian keyboard layout if you are a programmer, just buy a laptop with at least a UK one or a US keyboard layout and code there. You don't need triplo-salto-carpiato to write a back-tick and using the dollar will result the simplest thing on earth ( "yeah but I need to chit-chat with" ... NO! If you are a coder accents in letters are not important at all! but of course, do what you want ^_^ )

Smaller Tasks Due Constrained Space

Whiteboard is actually playing a decent role in keeping interviews tasks small enough in order to fit without doing gym. This is good because both the interviewer and the interviewee will have the whole task in front all the time. No need to scroll: it's there for you to keep in mind everything you are doing: the whiteboard is there to help focusing!

You Shouldn't Care About Typos

When I was interviewing for a vanilla front end JavaScript role, you know already 99% of candidates knew only jQuery but applied regardless the role was explicitly asking for vanilla JavaScript and DOM knowledge: they probably couldn't tell the difference.
However, knowing jQuery when the team was eating dragons each breakfast in order to have decent performance on first mobile phone browsers, was the most useless and pointless skill set we could have asked for: jQuery wasn't even targeting mobile browsers at that time and we needed someone medium/senior level ASAP!
This put me and others in a position where finding a good candidate became quite impossible, and we had to be less picky every time more about CVs we were receiving because ... well, no-hacking-body had experience in DOM and JavaScript (I'm fearing nowadays is every day even more like that, but that's another story ...)

Back in topic, you got the scene, now imagine this: I've never even considered an error the usage of jQuery itself to solve any problem I could ask during these interviews and I've never cared if the whiteboard was full of mistakes, imperfections or syntax errors and trust me, I'm quite good as human linter!

The real lesson here is that you shouldn't care about mistakes and you shouldn't care about writing down correct API methods as long as you know there is some solution and, if you don't, you reason why solving that way is a good thing. That's literally it!
Why would I even care about errors when of course in front of your laptop you wouldn't have done that?
Why would I pick on a library API when all I'm interested on is how good at basic performance common-sense/improvements are you? Use jQuery or anything else I can understand on the board, and show me you have at least an idea on how to solve the problem.
Here again the board will help because nobody it's going to copy and paste (AKA transcribe) all that stuff and verify, you are there as candidate to show you are confident with what you know as developer, and you are there as interviewer to analyze skills beside the tooling and the perfection 'cause maybe you caused a disaster-bug the day before so you shouldn't feel too cool there behind your "powerful hiring role", right?

For those waiting for the end of the little story: Yes, we found someone at the end, and a good one that learned indeed in few days how to forget about jQuery and why it was necessary, in those cases, to forget about it.
The candidate has been a huge help for the team for the entire time I've been there so: thank you!

Is "Can't Google" The Problem?

Beside the autocomplete, and the fact you might have some API suggestion once you type a dot, but again I've just explained having a fully perfectly working result in my opinion is less important than going through the solution understanding chosen patterns while writing shenanigans on the whiteboard, if you need the internet because when you code daily you use the internet all the time in order to document yourself, we've got a problem.
Actually, to be fair, we've got two possible problems:
  • the interviewer is simply showing off, asking something that difficult or unusual not even she/he would know if not out of experience happened by accident or finding it via Google: don't worry, you can clearly state "I'm afraid I've never encountered this specific situation, I might need to document myself before blindly trying to reinvent the wheel with a rock-solid solution".
    If whoever in front of you wouldn't appreciate such answer, you really don't want to be there and work with these kind if jerks around. Feel free to thank and leave the room (honestly? please do that, they'll be so pissed forever it'll be a pleasure)
  • you actually don't know something you supposed to know for such role. This is the not so trivial part: admit you have no bloody idea what they are asking you, and if you need Google per each question maybe you applied for the wrong position? It's true that whoever interviews usually is the asshole with the knee pointing at your side, but let's be honest when it's hard it's hard. I've appreciated million times a candidate that after 10 minutes clearly told me it was probably a bad idea to apply cause not a single thing I've asked or mentioned made sense (I swear I wasn't drunk!). We used the time to chat about possible alternatives, talking about real experience and out of coding skills.
It's tough to fail and while I've said it never happened to me at the white board, simply because I luckily got hired at the end every single time, I have failed more than once few tasks. I didn't feel ashamed, it has actually always been an opportunity to learn something more! Learn every single interview, even with the worst person in the world, so that you can eventually prepare for someone even worst or succeed next time a similar task will come up.

Going Through, Instead Of Running The Task

I've also done interviews with the interviewer computer, and it was OK. Although I've also notice a huge difference: the interviewer never paid much attention to what I was doing, mostly waited for the final result to work and that's it. There was no going through each line explaining or commenting, cancelling with a wipe and rethinking with some hint,it as rather a cold "let's see if this works", but as candidate, I'd expect that whoever is interviewing me would know if my answers, and my skills would work, not just a possible typo written in a rush, during a surely more than usual nervous time ... we're humans, after all.

It's Gorgeous

This is the last point that might make no sense to most of you, but I wish in my life I'll become at least half as good as passionate professors are in front of a board: they know their shit, they can write in front of thousands without failing a single equation, and they'd be best mates to learn from, and to create with new wonderful stuff!

Tuesday, June 30, 2015

How to serve SVG by default

With retina screens, TV and consoles, old, not so old, modern, and new devices, it makes no sense anymore to serve an image, unless this is a picture.
Logos, buttons, icons, everything that used to be that little png, today can simply be the very same image but served as SVG.

Forget about feature detection

Seriously, I've tried them all ... ! The read only property complete doesn't mean an SVG is supported. In order to be sure, we should draw such SVG into a canvas but even doing so, we cannot be sure the result is that such SVG will be shown at all.
There is only one way to do it right for various reasons: hold your chair, here it comes!

The inline onerror handler

To be sure that the browser will actually see something as meant and as soon as possible, we can use, trust, and recycle inline the onerror handler granting backward compatibility with pretty much every old browser we know.
<img src="image.svg" onerror="Image.onerror.call(this)">
That's truly it, unless you want to name the handler differently or set it on the global scope, same way we are supposed to set basic CSS inline per each page we serve, we could set basic JS too in the header and without needing a network connection at all
<!DOCTYPE html>
<html lang="en">
Bonus for such method is that we could always use it directly as DOM Level 0 onerror in case we need it, and we might also do eventually more with the event object, using as example Image.onerror.call(this,event) per each inline invoke.

But why an inline error in 2015?

Because around 95% of surfing browsers support SVG these days, and it makes zero sense to serve any other decoration or icon as png these days.
Accordingly, only if you would like to support old browsers too, you might decide to use above technique, if you don't care you can simply stick serving SVGs as Image src too.

The inline onerror handler is also the fastest possible way to react to problems instead of using async, defer scripts, or even DOMContentLoaded: the onerror will beat any other technique granting best compatibility!

The technique is indeed meant as "gracefully degraded" experience, so that old browsers will still show the icon as png and don't bother serving 2X icons there, none of these browsers support retina displays.

SVG Hints

Following a couple of hints regarding SVGs
  1. inline support is not as good as image source support, hence feel free to include SVG via <img> but don't inline them in the wild
  2. SVG as Image sources cannot be styled via CSS (and are slightly faster to be rendered because of this too, it's a bit like ShadowDOM in action)
  3. thousands SVGs are slower than thousands PNGs when it comes to raw rendering performance
  4. gzip/deflate compression to serve SVGs will make them not too much heavier than PNGs but will scale any screen and resolution (better for the cache too)
  5. if you have a ViewBox property but you don't have width and height, the SVG might be rendered deformed in some browser (mostly WebKit based gotcha)
  6. if you use SVG external files as CSS url you won't have any possible fallback
  7. IE8, IE7, and IE6 works well with the suggested hint, but using png8 might improve even more the support (or actually with a fallback as GIF that would be universally recognized as such)
For now, I think that's pretty much it. Use it if needed, ignore it otherwise ;-)

What about CSP?

AFAIK CSP is incapable of granting well known inline handlers, even if you use correct sha, which is, for above code:
  • sha1-KQlMcC5gY2yF2YJLHmj92eDINwM=
  • sha256-fdsC+rLqqoTxcoa4lsSYSr9c4HaAmjb7eToXB2X/um8=
If you find a way to enable above goodness via CSP please share, thanks!

What About Web App Icons?

I've honestly no idea why these days we have to write this pile of crap:
<link rel="shortcut icon" type="image/png" href="/img/favicon-16x16.png" sizes="16x16">
<link rel="shortcut icon" type="image/png" href="/img/favicon-32x32.png" sizes="32x32">
<link rel="shortcut icon" type="image/png" href="/img/favicon-64x64.png" sizes="64x64">
<link rel="shortcut icon" type="image/png" href="/img/favicon-96x96.png" sizes="96x96">
<link rel="shortcut icon" type="image/png" href="/img/favicon-192x192.png" sizes="192x192">
<link rel="shortcut icon" type="image/png" href="/img/favicon-194x194.png" sizes="194x194">
instead of just this:
<link rel="shortcut icon" sizes="any" href="/img/favicon.svg">
Please complain with browsers vendors about such ridiculous nonsense, thank you!

Wednesday, June 24, 2015

Rethinking the $()

If any developer extends or modify native prototypes is doing it wrong ... unless you are Paul Irish?
( please bear with me Paul, this post has nothing against you or your snippet, it's rather on how developers react to whatever you propose since you are well known in the industry ;-) )

I am talking about his bling snippet, and the instant hype around it.

Nope, still doing it wrong

I haven't asked him directly but I believe Paul intent was simply to demonstrate that for a sketchy quick and dirty jQuery like functionality you really don't need to put 7 tools in your chain, a CDN, pick the right version or learn the whole API, you can just go with few lines of code.
The problem is the hype that will inevitably see developers start doing that in production or in their own libraries, using an obtrusive approach which is also not strictly necessary.

Did you know that queryAll returns an Array subclass?

The reason that snippets contains the following line:
NodeList.prototype.__proto__ = Array.prototype
is because querySelectorAll returns a NodeList collection, which is a static collection that does not extend nor inherit from Array.

W3C knows this has been inconvenient for just about everyone, so it's going to replace querySelector and querySelectorAll with query and queryAll, where latter one will return an Array subclass.
Elements is an ES6-style subclass of Array with two additional methods. It's the new NodeList / HTMLCollection.
Accordingly, the little snippet could be even smaller, and also more reliable in terms of results since these new methods not only return array like results, will also fix relative CSS selectors, meaning these are also more reliable/less surprise prone methods.
window.$ = document.queryAll.bind(document);

Node.prototype.on = window.on = function (name, fn) {
  this.addEventListener(name, fn);
Elements.prototype.on = Elements.prototype.addEventListener = function (name, fn) {
  this.forEach(function (elem, i) {
    elem.on(name, fn);
If you are worried about query and queryAll compatibility, you can stop already since there is a poly for that, which will also normalize and fix much more, so nothing to lose.

Yet doing it wrong

No matter how small and pragmatic could be our snippet, we're playing dirty polluting both the global object and at least 2 prototypes. On top of this, add the usage of __proto__, which not only I'd like to not see anymore in favor of Object.setPrototypeOf, but it will also automatically break compatibility with IE < 11, and we realize that a little snippet, seen already as "cool one, will use it" from few developers, should probably stay confined in our browser console for debugging purpose and nothing else.
Accordingly, I think it would be wise not to start publishing libraries based on such snippet, and I also believe Paul would agree with me on this.

We still want the $ of jQuery without the jQuery.

Like the snippet says already, having a $ around is very handy indeed.
That could also be the only thing we need though, so that previous snippet could be simplified as such:
var $ = $ || (function (){
  function on(name, fn) {
    this.forEach(function (el) {
      el.addEventListener(name, fn);
  return function (css, parent) {
    var result = typeof css === 'string' ?
      (parent || document).queryAll(css) : [css];
    result.on = on;
    return result;
If we don't have queryAll or a polyfill in the page, we can simply use this line instead:
// change this
(parent || document).queryAll(css) : [css];

// with this
  (parent || document).querySelectorAll(css), 0
) : [css];
The snippet gives us the ability to add listeners to window or any node simply doing this:
$(window).on('load', function () { /*...*/ });
See? No need to extend any global object, neither global prototypes ... Hoooorraaaaaay!

What else do we need?

Many already pointed out that having an off method would be handy too, I'd like to add on top the need for a dispatch method so that's also easy to dispatch events as well.
If we then consider that extendability could bring in basically anything else we think we might need, I can tell you I've already described the entire functionality of QueryResult, an utility already available via CDN with a deadly simple API you already know and a subclassing behavior which will gradually and natively integrate with modern browsers as soon as these will ship ES6 classes and subclassing in their engines.
So yes, we can have the $, and we can still have it in few lines of code, without being obtrusive, and via modern approaches such subclassing and queryAll.

Wednesday, June 17, 2015

Quick Thoughts on WebAssembly

It's happening, all major browsers vendors apparently agreed on WebAssemply effort to bring .wasm files on the web.

I've read enough to give an instinctive, quick, probably premature, surely gut based, impression on this matter.
I'll cut the crap and throw the following bullets at you:
  1. bytecode is nothing new on the Web, it's actually what every Flash developer has been dealing for the last 15 years. On the non web side, LLVM has been one of the most successful target infrastructure "code", something every other non JS language has been hoping to find into the Web and JS platform as a target too. In few words, having an optimized universal language target, can bring only benefits for the entire programming ecosystem. Moreover, this means that JavaScript, or a (sub|super)set of it, will be most likely transpilable to LLVM. This means JS will gradually gain native-like horses power for all the things, including IoT devices. And this is huge!
  2. having all vendors and teams instead of being a proprietary format as it has been for the .swf before, means many more developers and engineers will be involved and happy to jump in. Beside the inevitable higher amount of consequential bikeshed, pattern that reminds me every time of the joke about "How many engineers does it take to change a light bulb?", we have proofs that sometimes this kind of effort works. For instance, the biggest release of ECMAScript since the third edition just got approved and most of the people involved were from all those browser vendors.
  3. asm.js will soon become a widely adopted intermediate target language, since every vendor agreed on .wasm which initial goal is to be compatible with asmjs code. This is huge for Web related performance!
  4. developers will finally be free to choose whatever language they want; transpiling to a more capable infrastructure than just JavaScript as another programming language, and with closer performance to what they expect from their original PL of choice
  5. it will take long time, in terms of cross platform compatibility, before we'll see real-world, full .wasm based applications, and my only hope is that .wasm won't slow down the Web, since this still needs extra attention and huge amount of improvements from every browser vendor
  6. we've got the proof that all people involved or not in Open Source still use "Closed Source" (private) channels to make decisions about "the destiny" of the rest of the world
  7. it might slowly cause the beginning of JS decline once available, since JS has been reforged to be backward compatible, but a fresh new general purpose intermediate language, that could be a better target for new programming languages too, might be a better idea, over a standard that inevitably carries on quirks trying not to break what's been developed for the last 20 years online.
I'm curious to see in 5 years what this little post spoiled, what misunderstood, and still I'm actually quite excited about this .wasm news.

I'm looking forward to see progresses, and contribute as I can!