Things I’ve learnt as a Web Developer
I’ve been a software developer for almost 5 years – the last year and a half of that I’ve spent doing web development. I don’t pretend to even think that I’m anything close to an expert in web development. The following is simply a mixture of common mistakes I’ve come across as well as some concepts I’ve learnt which I’ve found greatly beneficial in my career as a web developer.
1. Avoid inline JavaScript and CSS
It is estimated that around 80% of the end-user response time is spent on the front-end. Most of this time is spent downloading the different components in our pages – stylesheets, images, JavaScript files, etc. To save you some time your browser will cache these requests – this means you don’t need to retrieve the stylesheet or JavaScript libraries for every page in your site. However if we use inline JavaScript or CSS the browser can’t cache these resources – this places unnecessary load on your server and degrades the user experience.
Inline CSS is also more difficult to maintain – you usually end up duplicating styles across pages. I’m not aware of any advantages in using inline CSS – you simply don’t have any excuse here.
2. Know how browsers cache resources
Web caching is one of the most misunderstood technologies on the Internet. If you’re using meta tags to control caching, you’re doing it wrong. If you’re using a Pragma: no-cache header, you’re doing it wrong. If you think that Cache-Control: no-cache means the resource won’t be cached, you’re doing it wrong. Developers often ignore caching headers and only the defaults are used – it’s a good idea to fire up fiddler and make sure your resources are being managed in the way you expect.
I have seen situations where massive amounts are spent on infrastructure instead of properly implementing caching. If you haven’t done so already, read this article. (Keep in mind that Ajax requests can also be cached when implemented correctly)
3. Know how cookies work
Cookies seem to be another misunderstood concept in web development. HTTP is a stateless technology (this fact also seems to be lost on some developers) – cookies goes a long way towards solving this problem, but also brings a whole new set of difficulties. How are cookies sent to the browser? How are cookies sent back to the web server? Are all the cookies sent to the browser, or just some of them? What happens when you click that ‘Remember me’ checkbox? If you can’t answer some of these questions, or you don’t understand things like cookieless domains, I suggest you take a look at Cookie Central.
4. Know how your browser loads resources
In a nutshell – put stylesheets at the top (in the head element) and scripts at the bottom (just before the closing html tag). Keep in mind that the HTML standard allows browsers to load elements in parallel (but no more than 2 per hostname) – this directly affects the rendering of your page. Unfortunately most ASP.NET templates put JavaScript includes in the head element which will block parallel downloads – while a script is downloading the browser won’t start any other downloads, even on different hostnames.
5. Table tags are for tables, not layout
With the introduction of HTML 3 (in 1996) came HTML tables. For the next 5 years or so tables became the preferred way of laying out your web pages. Your entire page would be structured as nested tables: the navigation bar on the left was a table cell, so was your content area on the right.
With the introduction of CSS in HTML 4 (1999) the need for tables as layout elements have disappeared. Now that we’re in 2010 there is absolutely no reason for using tables for layout. CSS is a much more powerful and flexible tool and techniques are available for the most complex layout decisions so your markup can be completely independent of the on-screen presentation.
Of course tables still have their uses – mainly for displaying tabular data. All web developers should understand how to markup tables properly.
6. Understand the difference between presentational and semantic markup
HTML defines several elements, such as <p> for paragraphs, <em> for emphasized text, and <h1> <h2> … for headers. These are called semantic elements, because they convey a meaning.
Older versions of HTML introduced elements such as <b> for bold text, <i> for italic text and <font> for using different fonts and sizes. These are called presentational elements, because they tell the browser how to display the markup – bold, italic, with a specific font, etc.
In short, you should never use presentational elements in HTML, but use meaningful elements and style them with CSS. I recommend you checkout mezzoblue’s markup guide.
7. Understand how Sessions work
If you’re an ASP.NET developer you should understand what happens when you use the Session object. How does the server know that a specific session belongs to a specific user? How is the session stored on the server? How do cookieless sessions work? What happens to the sessions when we need to restart IIS?
8. Understand how load-balancing works
Load-balancing is usually an issue avoided by developers and left for the infrastructure guys to figure out. There are a few issues you need to be aware of that makes load-balancing works. Most importantly, what happens with sessions in a load-balancing scenario? You should be aware that in-memory sessions are still possible with a load-balancing scenario. More importantly, you should be aware of your options.
9. Understand how IIS works
This is an area where I find most ASP.NET developers are seriously lacking. I’m of the opinion that every ASP.NET developer should understand how requests are processed and how this ties back to the Windows infrastructure. How many threads are allocated to each site? How can you configure this?
10. Learn as much about web security as possible
Last year I was lucky enough to attend a presentation by a professional web security consultant. Since I only had about 7 or 8 months of web experience I expected learn a few things, but I was absolutely blown away by how little I knew. I have since then learnt a few things about security and I have also learnt that most web developers are completely ignorant of the realities of web security. In my opinion it’s reasonably easy to implement the basics of web security, but it requires a good knowledge of the different aspects of web development – HTTP, HTML, cookies, JavaScript, SSL, etc.
To implement a completely secure website (again, this is my opinion) is pretty close to impossible. There’s a good reason why you’ve read stories of all the big players in the internet world falling prey to hacker attacks – web security is difficult. Implementing secure websites requires an in-depth knowledge of every single aspect of web development – and even then you’re still vulnerable to flaws in the different browsers and protocols being used.
My only advice here is to learn as much as possible about web security. Read, read, read. Every day new vulnerabilities are being discovered and exploited – you need to be aware of these and how to stop them.