Q:

Best approach to create footer links

I want to create footer links inside my master page, and I was wondering what's the best approach to achieve this, do I create a SharePoint List to store my lists and embed it as a list and change its look using JSLink?  
What are the pros and cons about this approach?  Or do I use server side code and use caching to create this section?  Any recommendations? 

A:

As I suggested in a comment to another answer, there are numerous ways to accomplish this that don't involve deploying server-side code into SharePoint.  Here are a few that I could think of, I may have left some out; each have some advantages and possible challenges. 

TL;DR: Use the JavaScript injection pattern (especially with SharePoint Online - -- this is the current Microsoft Patterns and Practices team recommendation) unless you need to do heavy re-branding in addition to adding footer information -- in which case I recommend customizing an existing SharePoint master page or creating your own.  Just remember the custom master page route involves some expense in up-front and future effort on your part. 
Edit: Chris O'Brien recently published a timely and more thorough blog post about customization issues in general (since they have been evolving over the past couple of years) over on his blog that does a fantastic job of explaining some of these choices while discussing the decisions the SharePoint team have been making as well as those that developers and designers should be making: http://www.sharepointnutsandbolts.com/2015/01/custom-master-pages-and-web-templates-in-office-365--thoughts.html

Now for the details of some various approaches:
1.  JavaScript Injection
How it works: Create JavaScript that injects your footer markup and any other supporting styles onto a page.  Use an App or solution to deploy the JS asset programmatically to the host web using CSOM/JSOM, then add the script to the site's custom actions so that it runs on each page load.  See a rundown on this technique from Andrew Connell here: http://channel9.msdn.com/Blogs/Office-365-Dev/JavaScript-injection-in-SharePoint-Online-Office-365-Developer-Patterns-and-Practices
Advantages:

Leaves master pages unmodified, which allows updates from CUs (on premise) or update releases (SharePoint Online) to be applied to your site as soon as they're published by Microsoft
Possible to implement as a SharePoint Hosted or Provider Hosted App
Possible to alter built-in UI elements like the ribbon or Status notifications
Single JS source file
This technique is the current Office Dev Patterns and Practices (PnP) recommended guidance for branding and page customization

Disadvantages:

Relies on page markup that you may not have direct control over
More complex to setup and update than other solutions
Updating content inserted this way requires an update to the source script (some dev/designer intervention needed) Possible to implement a service call to pull the information from a list or file source in a library; this introduces another HTTP Request into the process (disadvantage) but would allow for simplified editing by end/power users (advantage) and allow the page to render and become usable before all the content was retrieved from the server since standard JS data retrieval methods do not block the UI thread (advantage)

2.  Modified SharePoint Master Page / Page Layouts
How it works: Use seattle.master or oslo.master master pages as a starting point and make modifications to copies of them to suite your specific branding/content needs (you should not modify these master pages directly).  Upload your version of the master page to your site collections.  Reference this page as the master that should be used in your site settings.  For more information, I suggest: "Master pages, the Master Page Gallery, and page layouts in SharePoint 2013" on MSDN; SharePoint 2013 Branding and User Interface Design by Randy Drisgill, John Ross and Paul Stubbs; and Pro SharePoint 2013 Branding and Responsive Web Development By Eric Overfield , Rita Zhang , Oscar Medina , Kanwal Khipple
Advantages:

Relatively simple to implement
Greater degree of control over markup, content, and styling

Disadvantages:

Breaks inheritance from the built-in master pages; updated functionality added by Microsoft will not automatically be applied to your sites when SharePoint is updated
Requires uploading to and configuring each site collection individually (or requires you to implement a solution that does this in some automated way, perhaps with PowerShell and/or CSOM)
Content update requires updating EACH version of the master page you are using throughout your deployment (also possible to implement a JS solution in conjunction with the master page that pulls the data from a list somewhere, this provides the same advantages and disadvantages as noted for JavaScript Injection updating).  Possible to solve this issue by using cross site publishing features new to SharePoint 2013, but requires you to set this up.  Also possible to mitigate this problem by deploying a farm solution and placing the master page in the server file system, but this introduces many other problems...

3.  Custom Master Page / Page Layouts
How it works: There are some options in how to approach this, but typically you would start by making a regular HTML page that looks like you want, then convert your HTML file into a SharePoint Master page then proceed as in the edited master page description.  See all of the resources listed for customizing the built-in master pages for way more information from people who know a lot more about this than I do! 
Advantages:

Greatest control over structure, style, and content

Disadvantages: Same as disadvantages for "Modified SharePoint Master Page / Page Layouts" but with added complexity of building the entire design yourself. 
4.  Content Editor WebPart with External Source
How it works: Create a text or HTML file that includes all of the markup you want to place in your footer area.  Add a Content Editor Web Part to each page where you want the footer to appear and reference your text or HTML file as the content source.  You'll need to include appropriate styles with the content (in a <style> tag, for example) or somewhere in your own CSS style sheets. 
Advantages:

Simplest solution to implement for small number of site pages or single portal pages
Single source file to update if changes are needed
Possible to combine with JavaScript to dynamically pull values from other SharePoint lists (although this has consequences, see disadvantages section under JavaScript injection)

Disadvantages:

Pretty awful for large-scale deployment.  Content editor needs to be added to each page with its source set to the referenced file; possible to mitigate this using CSOM/PowerShell solution but you would need to set this up. 

5.  Content Editor / Script Editor WebPart with inline Source
How it works: Insert a Content or Script Editor WebPart on each page you need your footer information to display.  Instead of defining an external source (as in the previous example) define the markup/script contents directly in the web part source via the web part editor dialog.  
Advantages:

Simple to implement

Disadvantages:

Terrible for large-scale deployment: each content/script editor needs to be modified individually -- possible to automate this using CSOM/PowerShell but you would need to implement this. 

6.  Themes / Composed Looks
How it works: Allows you to specify a custom master page and color scheme that an end user can apply to their site and customize under "Site Settings" > "Change the look" (see this Office how-to article for more information).  Setup is a bit laborious, so I will just provide a link to the relevant MSDN documentation on the subject. 
Advantages:

Provides a high degree of control because you are defining your own master page (see advantages for customized master pages)
Allows end user site admins to configure and preview the changes to their site, as well as combine different color scheme (theme) combinations with different master pages

Disadvantages: There are a number of disadvantages that are well-covered by Heather Solomon at http://blog.sharepointexperience.com/2013/05/when-to-use-a-sharepoint-2013-composed-look/ as well as better instructions than I have given for how to set this all up.  To summarize: the changes they make are difficult to manage in large environments, users are allowed to specify their own background images and color schemes (problem for many designers out there), the solutions are difficult to debug, and you need to re-create your master page design to generate the .preview files but there are enough differences in the formatting and component use to make this a chore (you need to almost repeat yourself... but not almost enough to copy and paste...). 

A note on caching and performance: SharePoint is an ASP.NET application under the covers, and ASP.NET in general and SharePoint specifically have a number of tricks for caching the results of most outputs, to include: page outputs, list contents, query results, and large amounts of binary information (such as videos and other file types -- note binary large object (or BLOB) caching is not enabled by default, it must be turned on by the farm admistrator).  You can find a MUCH more thorough explanation of the caching options within SharePoint over at Microsoft's Technet site; here is a particularly good article on the subject.  These settings cannot be as fine tuned as something like a farm solution using the server-side object model, but they do offer a mature, well-tuned solution that applies to your entire farm and will suffice for the vast majority of content your SharePoint installation delivers. 
The reason I mention any of this is to clarify that SharePoint already has many mechanisms for improving performance through caching; it's not really required that you implement a farm solution to have a performant solution when it comes to customization. 
I would also add that performance and the perception of performance are two different things.  A web page that waits for a bunch of webparts to render on the server will typically be percieved as having much worse performance than a page that makes a bunch of AJAX calls to load the content without blocking the UI, even though the page using AJAX may actually have taken a longer time to complete its work. 

Something important to remember for any solution involving JavaScript; you need to remember to make sure your script can handle Minimal Download Strategy (MDS) environments -- this adds a bit to the complexity of the solution, but does greatly enhance the overall experience for 2013 and SP Online sites. 
I'm certain I've left out many of the problems and possible mitigating techniques to use for each approach, feel free to add to those that you notice. 

A:

I would go for a User control with server side code.  The UC can read from a list you (or the user control itself) creates and then create HTML from that result.  You can then style the HTML with CSS if needed
I would use HttpCache or similar to cache the final HTML for as long time as you think is viable for your use case (note that an IISRESET will clear the cache) to get great performance and low stress on the server. 
The user control can then be added to the master page directly or through a delegate control depending on wether or not you have a custom master page.