The legacy of legacy you might ask?

In all walks of life we deal with legacy, someone else's code, outdated browsers, someone else's designs, someone else's training methods, someone else's recipe, someone else's cat. Legacy is always around (including that pesky cat) and it's difficult to sometimes know when it is time to cast legacy off into the eternal long good night. Saying goodbye to legacy can be both a liberating and rewarding experience yet also a challenging and quite depressing thing.

What is legacy you may ask? You may already have an inkling as to what it is and for those who wish for me to not just assume we all know. I did mention a good few examples in my opening sentence so if you have an idea of where we're going, you've paid attention so far, well done.

Well legacy actually can mean a multitude of things and if you read an at-hand dictionary, or google it if you do not have a dictionary, you will find the meaning. In this context, however, I speak of legacy as:

anything handed down from the past, as from an ancestor or predecessor.
This is relating to old or outdated computer hardware, software, or data that, while still serving a purpose of functionality, does not work well with up-to-date modern systems.

Yes I speak of the very things we can and can't control that have come from before, pre-us (not the car) and now must adapt, fix, amend to work with current, modern day systems and tools.

Now if that last paragraph has rung a few bells in your head and you can identify with what I am talking about, then you are a sufferer of legacy and it's high time we discussed how best to approach this ever changing beast and what we can expect from it. I said ever changing their and that means what it hints at, legacy is always going to be their, how about some examples, such as:

  • An app update in relation to a major software update on a phone
  • A on out of date CMS or framework
  • When to update PHP code that only supports back to 5.2,5.3,5.4,5.5 etc.
  • Someone who refuses to learn new skills
  • When to change from jQuery to pure Javascript
  • Use CSS3 without legacy support for non CSS3 browsers
  • A non paying customer asking for free work
  • HTML5 only front end
  • Start using versioning control (people still don't see the benefits of git and SVN).
  • A design that is no longer constrained by previous design choices

So we see a few things here that I would class as legacy issues, if you have any suggestions or disagreements then please get in touch and this list can become more appropriate for your reading pleasure and anyone else'.

Let us now go into a common legacy issue over the past decade that has plagued many a person in the web industry.

The legacy of legacy Browsers.

I speak of the thing you are using to read this very article, the world wide web's viewing portals, the web browsers. They have been a technological revolution that has transformed the way we communicate with each other around the planet, the ability to share information to one another has been an ever evolving change for good. The means to visualise this information to the user, from simple text & imagery to videos, movies and even computer games has been one technological leap to the next all within the browser. What could be possibly next for the future?

When each of the browsers release a new version with a cool new innovation, the previous version of course does not have this fantastic new feature. While those that update get access to the brilliant new feature, those that do not update still wish for the sites they view to work and will become frustrated when it does not.

As the years have rolled on changing and updating and each new iteration of browser from a vendor has of course meant that their are a back catalogue of older version with less features. From the early browser wars of yesteryear to the plethora of browsers we now have today spread across a wide range of devices. Here, there and everywhere is a browser these days and the user base for each of these browsers is split, while not evenly, amongst them all. Whilst we are aware of the hugely popular Google Chrome and Mozilla Firefox browsers their are others and these have legacy versions that run amok today for some of us.

Many are aware of Internet explorer and its many versions over the years and will sigh at having to support some of their legacy versions but it is not something that should be such a terrible chain and ball on your sites as IE8 is a far easier browser to support back to then IE6.

On a side note to IE detractors, Internet explorer has helped shape the modern web world for the better. From when it first was released their was not much else to use and it is now the modern browsers who have picked up the torch to carry on the foundations laid by Microsofts IE browsers of yesteryear.

With Microsoft recently announcing a new browser/name, Project spartan, we will be potentially dealing with the legacy of Internet Explorer as a whole for many a year, although with IE11 auto updating it does confuse as to how that is maintained if spartan is the path that Microsoft chooses to focus as their primary browser.

What can be done?

So far, the majority have managed to create a solution that will act as a stop gap. This should hopefully bring forth some stability in regards to the browser being the issue with features and legacy. Gone are the days of firefox 3.5,3.6 and chrome 1,2,3,4,5,6,7,8. Instead the version number is no longer being aired around each release (you can still see which version they are on in the about area of the browser). What this will hopefully do is usher in an era of exciting web development & design free from non-updating users. The constraints of certain browsers no longer being the issue and the knowledge that a very high percentage of your site viewer base will be using a modern, updating browser. This means you can be safe in the knowledge that any new features that are implemented in the W3 Specification sheets will be implemented rather quickly for your sites. Rather than years it can mean months or even weeks to features being implemented. This means cooler stuff, sooner.

Of course you also need to know when to draw the line on support of older browsers. When is the appropriate time to cut loose IE8 or 9? How many versions back of Chrome and firefox should you support? Which version of iOS do you support and native safari? These questions must be asked, answered and outlined to yourselves and to your clients.

Some clients are not aware of the pitfalls of older browsers, it is time you informed them. If it takes an extra week just to support browsers that only have a 1% market share, surely the client would be happy to cast that time aside. Especially if you inform them of the benefits to doing so. This is just being open and honest and of course this improves your relationship with your client as they have come to you for your expertise. Tell them.

If the client needs to support those browsers for their own specific reasons, then as long as you outline the pitfalls and the extra time needed then that is the clients decision (and mistake you may say) to make. And of course to pay for.

The other thing that can be done? Time. The web is fast paced moving industry and I remember wondering when in the world IE5.5 and IE6 would leave me alone. I remember wishing upon a star for the day those browsers would leave me alone and look, they are years ago gone for me now. In 6 months you could have the problem already solved for you. Be patient, it gets better.

Well with this wave of auto updating browsers, it is fair to say that the issue and grievance of blaming older browsers and browser versions will slowly die away. This will then give rise to a rise in better code and standards. This means we now have the focus of legacy's gaze fall firmly on ourselves. Be it developer, designer, copy writer and who else is on the other side of the browser wall we must look at what we are producing.

The legacy of legacy code. Our Code.

To look for change, one must also look within. We can look to the browsers for help. They will push forward with web standards. They will push forward with each new feature of the latest W3 Spec. But their is legacy in our own code and markup. And we must address it.

Their are many areas where we have built sites and they look and work well. Only recently have you noticed that speed has started to hamper them, perhaps your site was built to ensure IE7 was supported and Androids first wave of browsers. The code you used back then worked, but now on modern browsers it takes forever to load all these extra libraries/checks to ensure backwards compatibility. Their is one particular area that might be worth looking at.

Are you using jQuery? Perhaps it is time you made the move into pure javascript. Why? Well jQuery was created back in January 2006 to ease the issue of traversing the DOM but also to enable better browser support for using javascript with a nicer and easier syntax.

You may now have the knowledge of no longer needing to support legacy browsers anymore. You have the skills to now provide a pure javascript experience to your site.

Now I am not saying to stop using jQuery completely! Far from the truth as it is an excellent library and still has its use, particularly the sizzle engine. What I am saying is for certain sites it might not necessarily be needed if all you need to do is hide or show elements. It's knowing when to use it.

If a lot of your site has animation attached to elements, perhaps you are using jQuery's .hide() or .show() methods. You could easily just add a class to the element and use CSS to hide and show it. You could save the page load of having to load jQuery just to achieve this with pure javascript. Performance is a key thing now in browsers but is not the topic of this post.

If you are looking to move into pure javascript I have found a handy site to help you move away from jQuery is aptly named http://youmightnotneedjquery.com/. It is very good for showing you what can be used to achieve common actions used in jQuery that can be achieved with pure javascript.

PHP

This example is looking at javascript and how that can be looked at to make changes. PHP for example releases a major update that always brings with it a raft of new features. Obviously for security and a quicker site, your PHP vesion on your server should ideally be the latest. However we all have come across those clients or servers that are tethered to the past of an older version and instances of this include even recently a PHP version stuck at 5.2.

What these versions bring in features can have a knock on effect, one of my favourite things as of PHP 5.4 shorter array syntax. A quick example of the shorter array syntax:

[php] <?php $array = array( "foo" => "bar", "bar" => "foo", ); // as of PHP 5.4 $array = [ "foo" => "bar", "bar" => "foo", ]; ?> [/php]

This small change has been one of my favourite additions and I write all my array syntax in this way. Any mini scripts or libraries I may put together will include this syntax. However if uploading these scripts to a pre PHP 5.4 server then it all falls to pieces! This means I can either force the client to update or redo my arrays in old syntax. This legacy is a difficult one to go with as the longer syntax is always going to work. You may leer at this idea but it is guaranteed to work. But it is legacy of syntax and makes sense to use the old syntax moving forward. It would be interesting to hear feedback on others who have experienced similar instances.

So legacy can be out of our control and well within our control. When it is within our control we must make the important decisions on how to deal with legacy.

So what is the legacy of legacy?

Legacy is always going to be around. Sorry if that sounds like a terrible summary of all this but it is true. You need not look at this as negative but in a positive of how to set your stall when dealing with your legacy code or anyone else's.

Dealing with our legacy is the legacy of legacy. Where to make the cut off point and when to make the changes. Legacy is always going to be around, its how you propose to deal with legacy moving forward. Set your line and don't budge, when you improve pushing forward so must your tail come with you, don't let it get too far behind you supporting so much legacy. If you do that you'll never get to enjoy the cool stuff of the future. You'll end up hating the past and the legacy of things you no longer wish to be pestering you. Think cut the mustard. Think future. Think better.

Monthly Archives: February 2015

The legacy of legacy

The legacy of legacy you might ask? In all walks of life we deal with legacy, someone else’s code, outdated browsers, someone else’s designs, someone else’s training methods, someone else’s recipe, someone else’s cat. Legacy is always around (including that pesky cat) and it’s difficult to sometimes know when it is time to cast legacy

Read more