Christian Heilmann

You are currently browsing the Christian Heilmann blog archives for January, 2014.

Archive for January, 2014

Myth busting mythbusted

Monday, January 13th, 2014

Today CSS tricks features an article on JavaScript animations vs. CSS animations entitled Myth Busting: CSS Animations vs. JavaScript guest-written by Jack Doyle, one of the people behind the Greensock animation platform. Not surprisingly, Jack debunks the blanket statement that CSS animations are always better for performance and functionality than JavaScript animations.

Mythbusters by Sephie monster
Mythbusters parody by Sephie-monster

Jack is doing a great job arguing his point that CSS animations are not always better than JavaScript animations. The issue is that all this does is debunking a blanket statement that was flawed from the very beginning and distilled down to a sound bite. An argument like “CSS animations are better than JavaScript animations for performance” is not a technical argument. It is damage control. You need to know a lot to make a JavaScript animation perform well, and you can do a lot of damage. If you use a CSS animation the only source of error is the browser. Thus, you prevent a lot of people writing even more badly optimised code for the web.

A blueprint for “considered harmful” articles

These kind of articles are lots of research but easy to write: you take a “common practice truth” and you debunk it by collecting counter arguments. Extra points go to having lots of performance benchmarks or demos that can not be done with the technology you debunk.

Personally, I have no problem when libraries, frameworks or software solutions are getting debunked but I have a real problem when solutions built into browsers and defined in standards are being painted as inadequate for the sake of a yet another library or – in a lot of cases of articles of this kind – your own product.

This is not helping us having a professional platform. If there are issues with performance or functionality of a standard, we should get them fixed on browser and spec level. Yes, this takes longer and we can not be the hero to the rescue that built the quick library that fixes all these problems. But we also fix it for everyone and not just for the moment as inevitably following one of these articles will be another one a few months later showing that the solution of the first one has issues.

And thus, the cycle restarts. We discuss things, we create performance tests, we find proof in a certain environment and we give once again the message that everything on the web is broken and needs people to fix it with JavaScript.

An endless source of dispute

Here are a few truths about web development:

  • It will never be perfect – the idea of the web is to release code into the unknown. All you can do is make sure you don’t deliberately make it harder for people by expecting a certain technology or hardware to be available.
  • You can always find a problem that is not possible with standard techniques – you can then use JavaScript and the DOM to solve that problem. Then you have the problem of people using your JavaScript solution and be ready to fix it for all the new platforms, browsers, environments and connection speeds to come. That’s what web development is about. That’s what browsers need to do.
  • “Technique $X is the best to use” is a fleeting statement – table layouts were the only way to create a multi column layout and got replaced by CSS. CSS layout with positioning and floats is a make-do solution, too. Flexbox is the up and coming solution to the problem of layout on the web. It is not ready across all browsers and not backwards compatible if you want all browsers to create the same layout. See where this is going?
  • There is no “one” solution for any web development problem – this is the beauty of the web. It is the “bring your own solution” platform. If you want to make it better for everybody, use standards and let the browsers worry about the performance issues and do report them to the browser makers. Everything else is patchwork and will be debunked as “not working as expected” over time
  • In 90% of the cases mythbusting articles solve one problem – the argument is not that a technology is flawed, the argument is that it is not good enough to solve problem $x. Which is OK, there will always be things that can not be done. The real question is “do you need to solve problem $x and what dependencies, issues and problems does the solution bring along with it”?
  • Everything on the web is best achieved with a mixture of technologiesCSS animations are great for certain jobs, but will not be good enough for others. You can achieve almost everything with JavaScript but that doesn’t mean you have to or should. Flash was used for a lot of things, some it was damn good for, others awful. There is no way – ever – that one technology can 100% replace another. Our use cases change and we should strive to use the technologies that gives us the best result for the least effort whilst allowing browsers to optimise for us. It is not about what we can do, it is about what makes sense to do.

All of this would not be an issue if people looked at the source of the article, the date of it and see it as a problem solution in a certain environment and time frame. What we do though is keep quoting them out of context and as gospel. Until someone else will take that argument without context and writes a mythbusting article about it.

Automating typing in screencasts with AppleScript or how to look like a hollywood hacker

Thursday, January 9th, 2014

Update: The awesome that is Stuart Langridge also created a way to do what we describe here with a plugin for Sublime Text 2. Read his blogpost to learn how

We’re busy creating a lot of screencasts for the Firefox Developer tools at the moment and it isn’t as easy as the final products make it out to be. One of the biggest issues is typing along as you speak. First of all, this is hard to do. Secondly, people keep forgetting to use an external microphone on a headset which makes the screencast sound like a bad drum and base session.

swordfish

Fret not, for my esteemed colleague William Bamberg came up with an ingenious way to work around the problem. All of this is on a Mac, so if you don’t have one, please add the info how other systems can do the same on the Wiki.

The trick is to use AppleScript to automate the typing of a certain piece of text in an editor.

You write a script using the AppleScript Editor and save it, then you use a tool like FastScripts to assign it to a keystroke and voilà, you look like a hacker in a hollywood movie.

This is the script I am using to type the content of the file /your/script.js in Brackets (I tried my normal weapon of choice – Sublime Text 2 – but it does too many clever auto indenting and closing of braces things that do mess up the output).

set fc to read POSIX file "/your/script.js" as «class utf8»
 
set the text item delimiters to (ASCII character 10)
set mylines to text items in fc
repeat with currentline in mylines
  write_string(currentline)
end repeat
 
on write_string(the_string)
  tell application "System Events"
    tell application "Brackets Sprint 15" to activate
    repeat with the_character in the_string
      keystroke the_character
      delay 0.05
    end repeat
    key code 36
    key code 123 using command down
  end tell
end write_string

You can see the result in this screencast.

This, as anything, can of course be improved and I learned along the way that AppleScript is just not for me. For someone who writes code in other languages it seems just odd – it is the uncanny valley between programming and natural language.

In any case, it should be helpful. And if everything breaks, make sure to do some extreme pair programming – that works in the movies.

This developer wanted to create a language selector and asked for help on Twitter. You won’t believe what happened next!

Wednesday, January 8th, 2014

Hey, it works for Upworthy, right?

Yesterday in a weak moment Dhananjay Garg asked me on Twitter to help him with a coding issue and I had some time to do that. Here’s a quick write-up of what I created and why.

Dhananjay had posted his problem on StackOverflow and promptly got an answer that wasn’t really solving or explaining the issue, but at least linked to W3Schools to make matters worse (no, I am not bitter about the success of either resource).

The problem was solved, yes (assignment instead of comparison – = instead of === ) but the code was still far from efficient or easily maintainable which was something he asked about.

The thing Dhananjay wanted to achieve was to have a language selector for a web site that would redirect to documents in different languages and store the currently selected one in localStorage to redirect automatically on subsequent visits. The example posted has lots and lots of repetition in it:

function english()
{
if(typeof(Storage)!=="undefined")
  {
  localStorage.clear();
  localStorage.language="English";
 window.location.reload();
  }
}
 
function french()
{
if(typeof(Storage)!=="undefined")
  {
  localStorage.clear();
  localStorage.language="French";
  window.location.href = "french.html";
  }
}
window.onload = function() {
if (localStorage.language === "Language")
  {
   window.location.href = "language.html";
  }
else if (localStorage.language === "English")
  {
   window.location.href = "eng.html";
  }
else if (localStorage.language === "French")
  {
  window.location.href = "french.html";
  }
else if (localStorage.language === "Spanish")
  {
  window.location.href = "spanish.html";
  }

This would be done for 12 languages, meaning you’ll have 12 functions all doing the same with different values assigned to the same property. That’s the first issue here, we have parameters on functions to avoid this. Instead of having a function for each language, you write a generic one:

function setLanguage(language, url) {
	localStorage.clear();
 	localStorage.language = language;
 	window.location.href = url;
 }
}

Then you could call for example setLanguage(‘French’, ‘french.html’) to set the language to French and do a redirect. However, it seems dangerous to clear the whole of localStorage every time when you simply redefine one of its properties.

The onload handler reading from localStorage and redirecting accordingly is again riddled with repetition. The main issue I see here is that both the language values and the URLs to redirect to are hard-coded and a repetition of what has been defined in the functions setting the respective languages. This would make it easy to make a mistake as you repeat values.

A proposed solution

Assuming we really want to do this in JavaScript (I’d probably do a .htaccess re-write on a GET parameter and use a cookie) here’s the solution I came up with.

First of all, text links to set a language seem odd as a choice and do take up a lot of space. This is why I decided to go with a select box instead. As our functionality is dependent on JavaScript to work, I do not create any static HTML at all but just use a placeholder form in the document to add our language selector to:

<form id="languageselect"></form>

Instead of repeating the same information in the part of setting the language and reading out which one has been set onload, I store the information in one singular object:

var locales = {
    'us': {label: 'English',location:'english.html'},
    'de': {label: 'German',location: 'german.html'},
    'fr': {label: 'Français',location: 'french.html'},
    'nl': {label: 'Nederlands',location: 'dutch.html'}       
};

I also create locale strings instead of using the name of the language as the condition. This makes it much easier to later on change the label of the language.

This is generally always a good plan. If you find yourself doing lots of “if – else if” in your code use an object instead. That way to get to the information all you need to do is test if the property exists in your object. In this case:

if (locales['de']) { // or locales.de - the bracket allows for spaces
	console.log(locales.de.label) // -> "German"
}

The rest is then all about using that data to populate the select box options and to create an accessible form. I explained in the comments what is going on:

// let's not leave globals
(function(){
  // when the browser knows about local storage…
  if ('localStorage' in window) {
    // Define a single object to hold all the locale 
    // information - notice that it is a good idea 
    // to go for a language code as the key instead of
    // the text that is displayed to allow for spaces
    // and all kind of special characters
    var locales = {
        'us': {label: 'English',location:'english.html'},
        'de': {label: 'German',location: 'german.html'},
        'fr': {label: 'Français',location: 'french.html'},
        'nl': {label: 'Nederlands',location: 'dutch.html'}       
    };
    // get the current locale. If nothing is stored in 
    // localStorage, preset it to 'en'
    var currentlocale = window.localStorage.locale || 'en';
    // Grab the form element
    var selectorContainer = document.querySelector('#languageselect');
    // Add a label for the select box - this is important 
    // for accessibility
    selectorContainer.innerHTML = '<label for="languageselectdd">'+
                                  'Select Language</label>';
    // Create a select box 
    var selector = document.createElement('select');
    selector.name = 'language';
    selector.id = 'languageselectdd';
    var html = '';
    // Loop over all the locales and put the right data into 
    // the options. If the locale matches the current one,
    // add a selected attribute to the option
    for (var i in locales) {
      var selected = (i === currentlocale) ? 'selected' : '';
        html += '<option value="'+i+'" '+selected+'>'+
                 locales[i].label+'</option>';
    }
    // Set the options of the select box and add it to the
    // form
    selector.innerHTML = html;
    selectorContainer.appendChild(selector);
    // Finish the form HTML with a submit button
    selectorContainer.innerHTML += '<input type="submit" value="go">';
    // When the form gets submitted…
    selectorContainer.addEventListener('submit', function(ev) {
      // grab the currently selected option's value
      var currentlocale = this.querySelector('select').value;
      // Store it in local storage as 'locale'
      window.localStorage.locale = currentlocale;
      // …and redirect to the document defined in the locale object
      alert('Redirect to: '+locales[currentlocale].location);
      //window.location = locales[currentlocale].location;
      // don't send the form
      ev.preventDefault();
    }, false);
  }
})();

Surely there are different ways to achieve the same, but the important part here is that an object is a great way to store information like this and simplify the whole process. If you want to add a language now, all you need to do is to modify the locales object. Everything is maintained in one place.

Finding real happiness in our jobs

Tuesday, January 7th, 2014

Want to comment? There are threads on Google+ and Facebook

It is 2014 and you are reading a post that will be talk at a web development conference. We’re lucky. We are super lucky. We are part of an elite group of people who are in a market where companies come to court us. We are in a position to say no to some contracts and we are so tainted by now that we complain when companies we work for have lesser variety in the free lunches – things that proverbially don’t exist – than the other companies we hear about.

happy critter in flower

I’ve talked about this before in my “Reasons to be cheerful” and “The prestige of being a web developer” presentations and I stand by my word: there is nothing more exciting in IT than being a web developer. It is the only platform that has the openness, the decentralisation and the ever constant evolution that is necessary to meet the demands of people out there when it comes to interacting with computers. All of this, however, relies on things we seem to have forgotten about: longevity, reaching who we work for and constantly improving the platform we are dependent on.

The ebbing revolution

What do I mean by that? Well, I am disappointed. When the web came about and became widely available – even at a 56k connection – it was a revolution. It blew everything that came before it away:

  • Merchants could sell products 24/7 and reach people far, far away without having to open a shop locally or print catalogues and get them delivered.
  • Writers and other creatives could distribute without being hindered by contracts of publishers and an assurance of making money for everyone involved before getting creative.
  • The fixed state of the interface was no more. I could resize the font if I needed it to be bigger, I could copy and paste some text into a translation engine to make the content accessible to me.
  • Content distribution was without quality loss. Papers were sent in digital formats, openly readable by all instead of being faxed or sent as a Word document on a floppy disk

It was a shock to the system, a world-wide distribution platform and everybody was invited. It scared the hell out of old-school publishers and it still scares the hell out of governments and other people who’d like to keep information controlled and maybe even hidden. Much like the printing press scared the powers in charge when it was invented as it brought literacy to the people who otherwise weren’t allowed to be literate.

In Renaissance Europe, the arrival of mechanical movable type printing introduced the era of mass communication which permanently altered the structure of society. The relatively unrestricted circulation of information and (revolutionary) ideas transcended borders, captured the masses in the Reformation and threatened the power of political and religious authorities; the sharp increase in literacy broke the monopoly of the literate elite on education and learning and bolstered the emerging middle class.

The web is all that; and more. If we allow it to blossom and change and not turn into TV on steroids where people go to consume and forget about creation.

But enough about history, let’s fast forward through a period of abundance and ridiculous projects for us: the first Dotcom bubble, the current entrepreneurial avalanche and move on to the now.

We’re losing the web

The web was good to all of us – damn good – and it is slipping away from us. When the president of the United States of America declares that people should learn to “code” and not to “make”, I get worried (code is only a small part of building product to help humans, you also need interfaces and data). When schools get iPads instead of computers with editors I get worried. When we measure what we do by comparing us with the success of software products built for closed environments and in a fixed state then we have a real problem with our self-image.

The web replaced a large amount of desktop apps of old and made them hardware and location independent. Now we go back full cycle to a world where consuming web content means downloading and installing an app on your device – if it is available for yours, that is. This is not innovation – it is staying safe in an old monetization model of controlling the consumption and being able to make the consumption environment become outdated so people have to buy the newer, shinier, more expensive one. Giving up control is still anathema for many of our clients – but this is actually what the web is about. You give up control and trade it for lots more users and very simple software update cycles. The same way we have to finally get it into our heads that the user controls the experience and we can not force them into a certain resolution, hardware or browser. Then we reach the most users.

However, there is a problem: the larger part of the web still runs on outdated ideas and practices and therefore easily can be seen as inferior to native apps.

The web of others

When was the last time you saw a product used by millions and making a real difference to people being built with the things we all are excited about? I am not talking about the things that keep us busy – the Instagrams, the Twitters, the Imgurs – these are time sinks and escapism. I am talking about the things that keep the world moving. The banking sites, the booking systems, the email systems, the travel sites, government web sites, educational institutions. The solutions we promised when the web boomed to replace the clunky old desktop software, phone numbers and faxes.

Case in point: check out the beauty of the ESTA Visa waiver web site where you need to fill in your personal information if you want to travel to the States. Still, it beats the Indian counterpart which only works in Chrome or IE8, and from time to time has no working SSL certificate.

The ESTA web site

Getting a Visa for India - if you dare

How come there is a big gap between what universities teach and what we do – we who are seen as magicians by people who just use the web? Of course universities are not there to teach the most current, unstable, state of affairs, but it has been over 15 years and a lot of coursework is still stuck with pre-CSS practices.

One main issue I see is a massive disconnect between the people who pay us and what they care about and our wants and needs. This becomes painfully obvious when you contract, build something and a few months later have to remove it from your portfolio as the maintenance crew completely changed or messed up the product.

Many times our clients don’t get excited about the things we get excited about. All they really want is to have the product delivered on budget, on time and in a state that does the job. I call this the “good enough” problem. Reaching a milestone in the product cycle is more important than the quality of the product. How many times have you heard a sentence like “yes, this is not up to our standard but it needs to get out the door. We’ll plan for a cleanup later”. That cleanup never happens though. And that frustrates us.

Navel gazing

So what do we do when we get frustrated? We look for other ways to get excited; quick wins and things that sound innovative and great. This is a very natural survival instinct – we deserve to be happy and if what we are asked to do doesn’t make us happy, we find other ways.

dog playing fetch with himself

If the people who caused our frustration don’t understand what we do, we find solace in talking to those who do, namely us. We blog on design blogs, we create quick scripts and tools that are almost the same as another one we use (but not quite) and we get a warm fuzzy feeling when people applaud, upvote and tweet what we did for a day. We keep solving the same issues that have been solved, but this time we do it in node.js and python and ruby and not in PHP (just as an example). We run in circles but every year we get better and shinier shoes to run with. We keep busy.

This has become an epidemic. We are not fixing projects, we are not really communicating with the people who mess up all of our good intentions. We don’t even talk to the people who build the software platforms our work is dependent on. Instead, we come up with more and more plugins, build scripts, pre-processors and other abstractions that sound amazing and promise to make us more effective. This is navel gazing, it is escapism, and it won’t help us a bit in our quest to build great products with the web. The straw-man we erected is that our platform isn’t good, our workflow is broken and that standards are not evolving fast enough and that browsers always lag behind. Has this not always been the case? And how did we get here if everything is so terrible and in need of replacement? Is live reloading really that much of a lifesaver or is switching with cmd+tab and hitting cmd+r not something that could become muscle memory, like handling all the gears and pedals when driving a car?

Ironically we solve the problem of the people who we blame not to care about our work – we concentrate on delivering more in a shorter amount of time with lesser able developers. We’re heading toward an assembly line mentality where products are built by putting together things we don’t understand to create other things that can be shipped in vast numbers and lacking individual touches.

Finding genuine happiness

What it boils down to is motivation and sincere happiness. There is an excellent TED talk out there by Dan Ariely called “What makes us feel good about our work?” and it contains some very interesting concepts.

Dan’s research

As part of his research, Dan conducted an experiment: people in a study were asked to look at sheets of paper and count letters that are double. They are told that they get paid a certain amount of money for each sheet they work through. Every time they finish with a page the interviewers renegotiated the money people get, giving less and less with each sheet. The idea was to test when people say “no, that is not worth my time”.

The study tested three scenarios:

  • In the first one people would put their name on the sheet, do the task and give the final sheet to a supervisor. This one would look at the sheet, nod and put in on a pile on the table.
  • In the second scenario no name was added to the sheet and the supervisor would not look at the sheet, but instead just put it on the pile.
  • In the third scenario no name was added and the supervisor would just shred the paper in front of the study participant without looking at either.

This lead to some very interesting findings. First of all, although people saw their papers being shredded without being looked at, they still did not cheat, although it’d be easy money. Secondly there was not much of a gap between the minimum viable price per sheet in the scenario where the paper was shredded to the one that was not looked at.

The most important part was not what happened to the paper or if money would still flow – it was adding a sense of ownership by adding a name and being recognised for having done the work. Validation was the most important part that kept people going.

The reward of creation

The other study was asking people to fold origami objects with or without detailed explanations. Instead of just paying people to do that, the supervisor afterwards asked people for how much these should be sold. Other participants were asked how much they would pay for the final products, not knowing how much work went into them. Not surprisingly the creators of the origami structures valued them much higher than the ones who were asked to buy them. The origami structures done without detailed explanations were of lesser visual quality, which lead the prospective buyers to value them even less, whereas the makers ranked them higher, as more work went into them.

Dan calls this the IKEA principle – if you make people assemble something with very simple instructions but that still needed some extra work people value it much more. The other example he showed that explained this were ready-made cake bake mixtures. These were not a big seller, although they promised homemakers to save a lot of time. They became much more successful when the company making them removed the egg powder and asked people to add an egg. This meant people customised the cake – if only a bit – and got a feeling that they achieved something when they bake a cake. Furthermore, adding fresh eggs made for higher quality cakes at the same time.

This all sounds amazingly familiar, doesn’t it?

Finding real happiness in our jobs

There is a reason I am so happy to be a web developer: I fought for it. I didn’t start in a time where advice I got was to “use build script X and library Y and you are done”. I didn’t start in a time where browsers had developer tools built in. I did start in a time where browsers were not even remotely rendering the same and there was no predictable way to tell why things went wrong. That’s why I can enjoy what we have. That’s why I can marvel at the fact that I could do a button with rounded corners, drop shadows and a gradient in a few lines of CSS now and make it smoothly transition to another state without a single line of script.

This is happiness we don’t allow newcomers into our market to find these days as we force-feed them quick solutions that make us more effective but to them are just tools to put together. Instead of explaining outlines and brush strokes and pens we give them a paint-by-number template and wonder when there is not much excitement once they finished painting it out. We don’t allow people to feel ownership, to discover on their own terms how to do things, and thus we get a new generation of developers who see the web as a half-baked development environment compared to others. We don’t make newcomers happy by keeping them from making mistakes or find out about bugs. We bore them instead as we don’t challenge them.

Instead of creating a weekly abstraction to a problem and declaring it better than anything the W3C agrees on maybe it is time for us “in the know” to take our ideas elsewhere. It is time to make the whole web better, not the shiny echosphere we work in. This means we should talk more to product managers, project managers, CEOs, CMS creators, framework people, enterprise software developers – all the people that we see as not caring for what we care for and we’ve been ignoring as being boring.

These are the people who build the enterprise solutions we are baffled by. These are the people who need to deal with compliance and certifcations before they can work. And for that, they need standards, not awesomesauce.js or amazingstuff.io.
We chickened out having these hard and tiring conversations for too long. But they are worth having. Only when people realise just how much a labour of love a working, progressively enhancing interface that works across devices is we will get the recognition we deserve. We will not have our papers shredded in front of us, but get the nod instead. Right now we are being paid ridiculous amounts of money to do something other people do not want to care about. This is cushy, but leaves us empty and unappreciated on a intellectual level.

This is not the time to feel important about ourselves. This is not the time to make us more effective without people knowing what we do. This is the time to be experts who care for the platform that enabled us to be who we are. Each and everyone of you has it in you to make sure that what we do right now will continue to be good to us. This is the time to bring that out and use it.

Want to comment? There are threads on Google+ and Facebook

Endangered species of the Web: the Link

Sunday, January 5th, 2014

Once the Web was a thriving ecosystem of happily evolving, beautiful creatures. Like with any environment, sooner or later man will step in and kill a lot of things – actively or by accident – and diminish the diversity and health of said ecosystem.

In this series we will look at some of the strange animals that make up the Web as we know it, re-introduce them and show how you can do your part to make sure they don’t die out.

We start with the most important part of the Web: the Link.

not the weakest link
A Link is what makes the web, well, the web. It is an address where you can access a certain resource. This could be an HTML document (another animal we’ll cover soon), a video, an image, a text file, a server-side script that does things like sending an email – anything really.

In order to make links work two things are needed: a working end point where the Link should point to (URL or URI – for the difference meet a few people who have too much time and not enough social interactions in their lives and discuss) and an interaction that makes a user agent try to fetch the Link. That could be a user typing the URL in an address bar of a browser, a cURL request on a command line or an HTML element pointing to the URL.

Links are kind of magical, insofar that they allow anyone to have a voice and be found. Check Paul Neave’s “Why I create for the web” to read a heartfelt ode to the Link. And it is true; once you managed to publish something at a URL all kind of wonderful things can happen:

  • People can go there directly
  • Search engines can index it so people can find it searching for similar terms
  • Consumers can get the content you published without having to identify themselves and enter their credit card details (like they have to in almost any App Marketplace)
  • Consumers can keep the URL for later and share it with others, thus advertising for you without being paid for it
  • And much more…

It is the most simple and most effective world-wide, open and free publishing mechanism. That it is why we need to protect them from extinction.

In HTML, the absolutely best animal to use to make it easy for someone to access a URL is an anchor element or A. But of course there are other elements – in essence anything with an href or src attribute is a link out to the Web.

Endangering the interaction part

There are may ways people kill or endanger Links these days. The biggest one is people not using real links and yet expect Web interaction to happen. You can see anchor elements with href attributes of “javascript:void(0)” or “#” and script functionality applied to them (using event handling) to make them load content from the web or point to another resource. Ajax was the big new shiny thing there that made this the practice du jour and so much better than that awful loading of whole documents.

This is not the Web and it will hurt you. In essence these people do something very simple very wrong and then try to cover their tracks by still using anchor elements. Of course you can glue wings on a dog, but you shouldn’t expect it to be able to fly without a lot of assistance afterwards. There is no need for not pointing your anchors to a real, existing URL. If you do that, anything can go wrong and your functionality will still be OK - the person who activated the link will still get to the resource. Of course, that only works if that resource exists where you point to, which does lead to the second problem we have with Links these days.

Cool URLs don’t mutate

The practice of creating script-dependent links has also lead to another mutation of the link which turned out to be a terrible idea: the hashbang URL. This Frankenstein URL used fragment identifiers acting as Web resources, which they are not (try to do a meta refresh to a fragment if you doubt me). Luckily for us, we have the history API in browsers now which means we don’t need to rely on hashbang URLs for single page applications and we can very much redirect real, valid URLs on the server to their intended resource.

The second, big player in the endangerment of the Link is them dying or mutating. One of the traditional ways of dealing with Links to make them happy is to herd them in enclosures like “bookmarks” or “blog posts” or “articles” where you can group them with like-minded Links and even feed them with “tags” and “descriptions”, yummy things Links really love to chew on. Especially the “description” helps a lot – imagine giving a user a hint of what the anchor they click on will take them to. Sounds good, doesn’t it? People would only call those Links they want to play with and not make them run around without really caring for them.

Catch me if you can?

Talking about running around: social media is killing a lot of Links these days using an evil practice called “shortlinking”. Instead of sending the real URL to people to click on or remember we give them a much shorter version, which – though probably easier to remember – is flaky at best.

Every jump from URL to URL until we reach the endpoint we actually wanted to go to is slowing down our web interactions and is a possible point of failure. Try surfing the web on a slow connection that struggles with DNS lookups and you see what I mean.

Instead of herding the real Links and feeding them descriptions and tags we add hashtags to a URL that might or might not redirect to another. Bookmarks, emails and messages do not contain the real endpoint, but one pointing to it, possibly via another one. It is a big game of Chinese Whispers on a DNS lookup and HTTP redirect level.

In essence, there is a lot of hopping around the web happening that doesn’t benefit anyone – neither the end user who clicked on a link nor the maintainer or the resource as their referrers get all messed up. Twitter does not count the full length of the URL any longer but only uses 19 characters for any URL in a tweet (as it uses a t.co redirect under the hood to filter malicious links) thus using URL shorteners in Tweets is a pointless extra.

How can you help to save the Links?

Ensuring the survival of the Link is pretty easy, all you need to do is treat it with respect and make sure it can be found online rather than being disguised behind lots of mock-Links and relying on a special habitat like the flawless execution of scripts.

  • If what you put inside a href attribute doesn’t do anything when you copy and paste it into a browser URL field, you’ve killed a Link
  • If you post a URL that only redirects to another URL to save some characters, you killed a Link

You can do some very simple steps to ensure the survival of Links though:

  • If you read a short article talking about a resource that has a “/via” link, follow all the “via”s and then post the final, real resource in your social media channels (I covered this some time ago in “That /via nonsense (and putting text in images)“)
  • Tell everybody about server-side redirects, the history API and that hashbangs will not bring them any joy but are a very short-lived hack
  • Do not use social media sharing buttons. Copy and paste the URL instead. A lot of these add yet another shorturl for tracking purposes (btw, you can use the one here, it uses the real URL - damn you almost got to say “isn’t it ironic, that…” and no, it isn’t)
  • Read up on what humble elements like A, META and LINK can do
  • If you want to interact with scripts and never ever point to a URL, use a BUTTON element – or create the anchor using JavaScript to prevent it from ever showing up when it can’t be used.

Please help us let the Links stay alive and frolic in the wild. It is beautiful sight to behold.