By Craig Buckler

10 Common Mistakes Made by Novice Web Developers

By Craig Buckler

I was amazed at the response to my recent article, 10 Common Mistakes Made by Novice Web Designers. I anticipated an angry mob congregating outside SitePoint HQ with pitchforks and flaming torches. Well, I expected a few incendiary comments at least.

It’s time to redress the balance and give web developers some flak. Will they be as open-minded? Are they willing to accept a little criticism? Obviously, this article isn’t aimed at you … you’re a SitePoint reader who already uses best-practice techniques. It provides a list of typical mistakes made by new web developers — but we were all novices at one time. Some points may also apply to that antagonistic co-developer who refuses to accept any notion that their code isn’t perfect…

1. Ignoring web standards
Web standards were invented for a reason: they help you create device-independent web sites and applications. Few people want to learn them, not everyone likes them and most developers will disagree with some aspects — but ignore them at your peril!

A novice developer will make typical mistakes such as:

  • forgetting or using inappropriate DOCTYPEs. I still don’t understand why so many developers use a transitional DOCTYPE — do they really want to add font tags and background attributes?
  • using old-school HTML such as table layouts and center elements
  • not appreciating the subtleties of inline or block elements, e.g. putting h2 headings inside a span
  • not validating their code. Or worse, using a validator then ignoring the results and arguing that validators are inherently flawed.

2. Visualizing the visuals
Do you rely on WYSIWYG design software? Have you avoided learning HTML? Sorry — you’re not a web developer.

WYSIWYG software forces you to think visually — you’ll be focusing on how the page looks rather than the content structure. Use a text editor and consider the presentation layer at a later stage.

3. Semantics shemantics
Here’s how a newbie web developer will code a page’s main heading:

<h1>Main Heading</h1>

Unfortunately, many developers then go wild with their newly-discovered HTML powers and end up with this sort of monstrosity:

<div class="mainheading" style="color:black;"><strong>Main Heading</strong></div>

They were right at the start. HTML provides most of the content tags you require (especially if you’ve migrated to HTML5). Use them appropriately.

You should also watch out for divitis and classitis: the novice developer’s solution to browser problems. It’s time to stop and rethink your code when your HTML starts looking like this…

<div id="content">
	<div id="main-content" class="main">
		<div class="first-item">
			<div class="para1">
				<p id="top-para" class="para">Hello World!</p>

4. Practicing presentational class names
Presentational class names are another cardinal sin, e.g.

<div id="blue-left-column-96px">...</div>

This initially seems logical — it’s self-documenting code. That’s great until your design changes and the block becomes a 150px right-aligned red column.

5. Lazy browser testing
I’m going to let you in on a little secret. You know how developers moan about IE6? Well, any web site or application can be made to work in Microsoft’s ancient browser. Sure, it takes extra time and the browser has bugs, but they’re all well-documented. It’s often easier to fix a site for IE6 than IE7.

However, leaving IE6 testing until the end of the project will cause no end of grief. Fixing browser issues is no fun and that’s what your developer is really complaining about.

It’s not just IE6, of course — all browsers have bugs, quirks and problems. If you test early and test often, most of the issues can be rectified during the development phase. Unfortunately, the lazy novice developer will:

  • test in one browser throughout the whole of the development process
  • spend more time persuading people that other browsers are rubbish rather than fixing their application
  • and, if they’re given no other choice, they’ll implement horrible quick fixes using browser-sniffing and hacks.

6. Paying no attention to portability
The novice developer will use fixed file paths, hard-coded database connection strings and make assumptions about the environment. Their application will fail dismally if it’s not placed in a folder named “MyApplication1” in the root of an IIS web server running PHP with register_globals enabled. Oh yes, and it connects to an Access database running on their PC.

The ideal web application should be maintenance-free:

  • it should run wherever the files are located
  • configuration parameters should be contained in a single easy-to-edit file
  • if appropriate, it should work on different OS and web server combinations.

As a side note, be careful with sessions. They can catch you out when your popular application moves to a multi-server hosting platform.

7. Brushing off bandwidth
The problem with testing on a local PC server is that bandwidth issues aren’t usually noticeable and your 4MB background image will appear in an instant. Including 27 different JavaScript libraries — on the off-chance you may need them — won’t cause any delays either.

The novice developer does not care about bandwidth. Actually, I’m slightly concerned that our recent SitePoint poll indicated that 23% of developers didn’t care about bandwidth. I’m sure they must have been intranet developers…

8. Awful accessibility
To the novice developer, accessibility == image alt attributes. It’s like assuming you can drive because you successfully tuned the car stereo.

Accessibility is about supporting multiple devices with differing technical capabilities, e.g. mobile phones, screen readers, browsers without JavaScript, missing Flash plugins, or systems without a mouse. It’s not always a high priority — no one will use an online video editor in a screen reader — but there are few excuses for content-based websites. For example, if your page widgets, forms, or links rely on JavaScript, you’re simply blocking a percentage of your audience.

9. Scorning SEO
I partly blame this on the search engine optimization industry. SEO is presented as a mixture of psychoanalysis, technical complexity, and mysterious black arts. Businesses pay extortionate amounts for SEO witchcraft — they have no idea what they’ve paid for, what’s been done, or have any guarantee of success.

Novice developers therefore assume SEO is a wishy-washy soft-skill best left to the marketing department after the website’s gone live. That’s too late — SEO should be planned from the start just like any other aspect of the project.

I’m now going to reveal another industry secret: most SEO techniques are bleeding obvious. (Was that the sound of a thousand SEO sales consultants keeling over?)

If you’re selling Green Dooberries, make sure you mention it — especially in titles and the URL. Adhere to standards, do a little keyword research, produce decent content, add a sitemap, submit the site to search engines, and you’re 90% done. Forget keyword stuffing and other tricks: they won’t work.

10. Useless upgrading
Why should websites and services disappear for several hours owing to “essential maintenance”? I can understand it when hardware fails or you fall victim to a denial of service attack, but normal maintenance tasks should never require more than a few minutes downtime. All files and data can be uploaded, tested, then switched over in an instant.

In addition, if you have the same content, your users should never see a 404 page. URLs may change but it’s easy to redirect old addresses to new locations.

11. Bonus blunders
Here’s a collection of rants which didn’t make my main list:

  • little appreciation of client-server methodologies. This is especially evident when desktop developers start coding for the web — I know one who wrote a component which could only be used by one website visitor at a time!
  • quoting statistics as justification for ignoring or not testing in some browsers
  • not using source control when it matters
  • continually rewriting and refactoring the same code
  • spending hours arguing why technology X is better than technology Y rather than getting on with the task
  • developers who continually fail to address the real problem so they can concentrate on frivolous issues which are more interesting
  • woefully under-estimating development time
  • using duplicate ID names on the same HTML page
  • using form reset buttons — when has anyone ever needed one?
  • relying on bloated libraries when a few lines of JavaScript would suffice
  • not validating user input or assuming client-side-only validation is adequate
  • using JavaScript to apply effects which would be better handled by CSS
  • not playing nicely with other JavaScript code
  • over-use or inappropriate use of Ajax
  • creating separate CSS files for every browser (not just IE6/7 conditional comments)
  • adding inline styles everywhere
  • inappropriate use of Flash
  • using images when HTML text and CSS effects could achieve the same thing
  • forgetting to add a background color for the body
  • using vague technical jargon to bamboozle clients and co-workers.


Have I missed your most irritating novice web developer mistakes? Do you disagree with any points? Let the backlash begin!…

  • palgrave

    Nice article and I especially like the quote about the car radio. One minor point though – if you are coding HTML5 you can wrap anchor tags round pretty much anything (and rightly so).

    • That’s a very good point and you’re right – it should have been permitted in earlier versions of HTML (although an anchor inside an H2 seems more logical to me). I’ve changed it to a span to prevent any confusion.

    • Deborah Smith

      In my experience novice front-end developers use these bad/deprecated methods because they’re self tought from an old book, or they’ve gone on a course where the tutor learned in the 90s and never updated their skills. By the time a newby discovers that they are using ‘frowned-upon’ methods they are no longer a newby. There is a NVQ level 3 Web Design course in my local town (funded by ESF and Big Lottery) where the tutor is teaching several batches of newbies per year to create web pages in design view of a wysiwyg editor, to use spacer gifs and other frightening things, because she knows no better. Not helpful.

  • Anonymous

    When you say “separate CSS files for every browser,” …
    I can understand you getting annoyed if you know people who duplicate their entire CSS file several times over, but is it really so bad to use conditional comments to serve CSS override files for IE6 and 7 sometimes? If so, why? I’d much rather that than have to cope with several CSS hacks in one file.

    What do others think / do?

    • No, it wasn’t aimed at conditional comments (although I do think many developers rely on them too much). It’s for developers who use different CSS files for every browser. The point’s been clarified though.

    • mousti

      I think in some cases separate style sheets for IE6 and maybe 7 are a necessary evil when implementing certain functionality. Most of the time the bugs can be avoided however little things that add a bit more interest to the page shouldn’t be avoided just because they don’t work in IE without a separate style sheet.
      Recently I was rotating headings on a site so the text would be displayed vertical, and to achieve consistent positioning, a separate style sheet was needed for IE6 and IE7.
      Otherwise a great list!

  • Andy White

    Re #10, Useless Upgrading, sometimes you just gotta take something down for a period of time. A great example was the forum upgrade to SitePoint Forums earlier this year (not trying to put egg on your face her Craig – I had a good reason to do it!)

    If you leave things up and running, users can still post and comment. If they’re adding content, the database is changing. If you’re modifying a database with an upgrade script while data is still flying around, things can go nasty quickly.

    I could have just locked the database tables to the forum app, but we figured it was more elegant to let people know that an upgrade was taking place and to expect a bit of downtime.

    I’ll freely admit to not being as rigorous with some of these other points though (usually due to time constraints) – definitely some room for self-improvement.

    • Ahh, but Andy – you didn’t write the forum code. If you had, I’m sure you’d have devised an easier upgrade process!

      Seriously though, it can be important to ensure no one’s using a transaction-heavy system at the time it gets upgraded. An online banking application is a prime example. Even then, there’s no reason why it should be unavailable for any longer than an hour.

      There’s little excuse for most applications, though.

      • As good as it gets

        You might want to talk to the developers over at Apple about their Apple Store :)

      • I wouldn’t dare suggest that Apple could be wrong about something. If they decree shoddy standards, it will become law and we must obey!

  • James

    I only failed on two of the bonus rants, but I passed the first 10.

    – woefully under-estimating development time
    – not using source control when it matters

    I don’t entirely agree with you on #10 though, some times updates/upgrades will take more than a few minutes, but I always make sure these are done in the early hours when the site is hardly used.

    • It depends on what you’re attempting to do, but there’s rarely any need for sites to go down for several hours at a time. It just shows that the developer didn’t consider a smooth upgrade path.

      When was the last time GMail, Facebook or YouTube went down for maintenance?

    • Wardrop

      There the only two points I failed on also. I should probably care a little more about portability also, but the type of websites I’ve been created as of late, would no benefit a whole lot from such things (mainly intranet sites).

  • Hutchy

    #1 “I still don’t understand why so many developers use a transitional DOCTYPE — do they really want to add font tags and background attributes?”

    No – but if it uses a content management system with a WYSIWYG editor what’s the betting the client will.

    • I agree that many WYSIWYG editors produce shocking code, but it’s usually possible to replace them with better alternatives or cleanse the resulting HTML using a few nifty regexs.

      It seems a shame to produce an elegant template then have it trashed by users. It happens all the time, though.

      • joezim007

        I mainly have been using Transitional for most of my stuff because it needs to be done quickly, which means instead of trying to find good ways to create line breaks with CSS, I use the br tag. The br tag isn’t allowed in Strict.

      • What you’re doing is changing the document structure to fix layout/design issues. That may be a quick fix (and it’s sometimes the only fix), but it could lead to further problems later on, e.g. if the design changes.

      • W2ttsy

        @joezim007 W3Schools disagrees there. <br /> is fine for strict use in XHTML/HTML4.

        I think some of the bonus ones are open to anybody, not just newbies, but also seasoned pros. Alot of these are also critical of poor team management.
        Employing strategies such as pair programming, stand ups and peer code review will ensure that these issues are stamped out at the very start. Especially if there are a few new hires coming into the company.

  • mwistrand

    Great post. #1 I use strict DOCTYPEs for everything, except when working with Joomla!, which can only handle a transitional DOCTYPE (grrr). #7 Guilty. Well, my company is guilty. All of the sites we build have massive background images, and use some obscure font for the navigation (so I have to use images for the navigation).

    “continually rewriting and refactoring the same code” — also guilty (at least when it comes to JS). I’m a bit of a perfectionist when it comes to my code. It’s probably time to get over that.

  • Jo

    Cross browser compatibility is an issue that seems to be ignored or actually feared by many. Speaking personally, one of the more satisfying parts of my web development career has been wrestling to the ground and taming IE6/7 (IE8 seems much more well behaved.) Once you get used to the quirks, MSIE is no longer the monster that many people think it is, and is more akin to a bothersome brat.

    However, from the perspective of time saving, I’ll be thankful when IE6 is no more. :)

  • ahallicks

    I think making the transition from a web designer, to a web developer (or, more appropriately, from front-end to back-end) certainly aids all of those issues with developers being lazy and ‘transitional’. I started my career in the industry doing HTML and CSS and got into creating sites that adhered to the latest standards from the first lesson I had.

    From there I tried some PHP and then became more of a developer, but because the front-end skills and mindset were there first, I’ve never forgotten them, and still use them to the best of my ability.

    But for developers that don’t need to worry, or care about the front-end side of websites, and just see it as something that needs to be done, most of that doesn’t matter.

    Different personas yield different results.

  • Chris

    Good article. I just have one minor issue. You didn’t correctly open your tag.

  • ammark

    Very cool article. i am in middle of what you have wrote. i give the software engineers a validate code. they do they there php coding and when they give me back. i m faced with nick of time. and then its most like that i do inline, or use hacks to cover my problems. to meet the deadline. the problem with this is that tomorrow if anyone validate the code or see the inline structuring etc, can raise a complain about my work. which make me in fear of getting fired. but then again i am doing and giving what they need. in this situation what can i do. i would say i am intermediate web designer but their work and nick of time put me to novice. any suggestions?

    • The best option is to keep your HTML code very clean and minimal. Provide plenty of examples to the PHP developers: they should know exactly what HTML should be output given a particular condition.

      Even better, you could provide templates which the PHP developers can use directly within their View structures.

      Ultimately though, the backend developers will make errors, e.g. not closing tags, additional elements, etc. It’s their job to fix those problems — you shouldn’t need to add hacks to fix their mistakes.

      • ammark

        Yes but they are Dev of a kind, ignoring the facts. now the fact that they think that designing is there realm,that leaves with deadlines and totally “stupid code”, and a boss who think the senior software engineer is right. and ignores me

      • HTML, CSS and JavaScript were considered as second-class development citizens at one point, but that attitude has changed during the past few years. One thing’s for certain: your back-end developer would have trouble sorting out the problems in all browsers.

        Ultimately, ammark, you have to ask yourself whether it’s worth the effort. Do you want to do a job where you’re ignored?

  • ammark

    @Craig..your right but then again there aren’t any good jobs around who have much of business coming. also that i m thinking of diving into php to get to know what blender they did, having said that i would ask for advice for letting me know how to make a prominent boundaries telling boss that i am not responsible for such blenders (though i can fix and he want me to), still i get less pay then the engineering who code like :P, i need to make them understand that i can’t work like that. i do wanna quit but no good jobs around

  • ghendry

    “not using source control when it matters”


    Source control ALWAYS matters.

    • Wolf_22

      What do you use for source control, ghendry?

  • spheroid

    Re: #3…are you saying using multiple nested divs is bad?
    I hope not.
    The layouts from Matthew James Taylor (and I’m starting to look into 960 Grid System) have proven invaluable to design without tables. If that’s what you’re saying, then what’s your solution?

    • No, I’m saying that multiple nested DIVs are bad when there’s absolutely no need for them. Minimize your markup!

      • ammark

        When you get much of php before Doc Type declration, the validation won’t validate. what to do?

      • ammark, PHP never hits the browser so it isn’t validated unless someone is using echo() or print() in their PHP before the DocType

  • Fluffy762002

    I’m laughing as I’m sure I’m guilty of some of these ‘bad’ things, but improving..although hopefully with Sitepoint’s help and another web developer’s help, I will be able to stay on the right path!

  • harp B

    Using fixed-width layout for 1 part of the site, and using fluid layout for a different part of the site. It seems unprofessional, as if the content manager has not realized it themself.

  • Sphamandla

    Nice article well its nice to see that some people exploit all these developers who do floppy work, i will admit that im also a victim to some of these mistakes myself but work in progress. It’s kind of nice to recieve criticism because it makes you think before you do in future. Thanks great article

  • “As a side note, be careful with sessions. They can catch you out when your popular application moves to a multi-server hosting platform.”

    Yeah, about that… any tips? I can’t find nothing in the PHP manual… and nothing generically about it either. A topic for a separate article I hope?

    • I’ll consider that. The solutions I’ve used…

      1. If you’re using a load balancer, configure it so users stay on the same server throughout their session.

      2. Write your own session-handling code which saves data to a central database.

      3. Avoid sessions altogether!

      There are probably many other options.

      • Sounds simple enough when said like that.

        But what’s the advantage and disadvantage of each? I’m guessing in the bottleneck and ease of implementation are the differences, but what are the implications of each option?

        (now THAT is article worthy… I guess I’d figure it out if I get into such an environment, but I don’t have such to test with)

  • ServerStorm

    Yes have a central database that the multiple servers have access to and store your sessions in the database.

    If your servers are load balanced then it will not matter if one user request is handled on one server and the next same user’s request is handled on another server the session remains persistent as it can be retrieved from the database.


  • djeglin

    I agree with most of this, but the deprication of the target attribute for links in strict really annoysm me. I don’t want to have to rely on javascript to open a link in a new window (not a problem on small scale projects usually, but on some of the large corporate sites I have worked on it gets specced as a requirement). My personal preference is always to use strict… but I refuse to use js for something like that.

    • When I read the article originally I thought “I’m sure there’s a reason why I’d come a cropper when I tried strict doctypes” but I couldn’t remember what it was.

      This is it.

      Thanks for jogging my memory … and saving me a load of grief / wasted time trying to go back to strict doctypes. I’ve not looked yet, but I’m willing to be that HTML5 allows targets on elements …

    • Absolutely! That is my main bone of contention with strict too. I like to validate my sites and I appreciate ‘strict’ but target is a pretty important attribute of the anchor tag when you are linking out to PDF’s, Word docs, Podcasts, etc… which it seems my clients need to have.

      One solution is to write your own DocType and use Strict as the foundation. It’s not that difficult to do and it does work.

      • ZenPsycho

        I would suggest first, finding ways to convert those documents to plain HTML (except for podcasts, which, to be honest, I am completely baffled by that. Why on earth does that need the target attribute?)

        If it’s just not an option and you need to leave it as the source type, then use the HTTP content-disposition header to force the file to download instead of opening directly in the browser, and clearly mark the link with the file size.

      • Thanks ZenPsycho, good suggestion forcing download for non html content. PDF’s and links to other sites will still require a target no matter how you slice it. I guess this will once again be a non-issue (except for usability ‘experts’) because HTML5 supports target.

    • ZenPsycho

      Have you considered maybe that target was left out for a good reason, and you should think about perhaps not opening new windows at all? (Personally I find it very annoying when websites do this)

      • I’ve considered it many, many times but consider how annoying you find opening new windows and then consider how annoying it is for unsuspecting or less sophisticated visitors who click a link to a podcast, PDF, word doc, PPT presentation, another website or any other non-linear type of content that businesses require on their websites.

        For me, it’s a matter of providing the least annoying method to the end user. At the moment it appears that target=”_blank” is the winner but I’m open to suggestions.

  • Darren884

    Wow, good article. I think you hit it right on the dot with the CSS issues. Another one is following the standards.

  • ChuckLez

    Guilty on Bonus #2: One of our clients wanted their site to look good in Safari 1 a couple months ago…..I think we were justified in quoting stats on this one.

    Thankfully have been clean on others for at least a year now (If I saw this article about 1.5 years ago, I would have said “….what, doing that is bad?”) :P .

  • I find the less a developer knows about HTML they more of it they end up writing.
    Instead of a div with a class name, they’ll keep adding markup until their positioning problem is solved with brute force and you get a table in a table in a div with a center tag and font tags to make a paragraph look like a heading and a string of s for padding.

    • the.peregrine

      “I find the less a developer knows about HTML they more of it they end up writing.”


  • Mea.Culpa

    Some of these I agree with, but at the same time some of them I dont.

  • spheroid

    Craig, I wonder if there would be interest in a post on how well commercial/open source applications fare against your criteria? Example…many say osCommerce is horribly put together (read: “spaghetti-like code”). Included would be forum packages like vbulletin or phpbb, ecommerce like Pinnacle Cart or xcart.

    • In my experience, many apps (especially the more popular ones) use or enforce horrendous HTML: table layouts, inline styles, poor accessibility, etc. They’ve obviously been written by good back-end developers who don’t have the same front-end skills. Hopefully that situation will improve.

  • the.peregrine

    Great article, great comments everyone!

  • dragonsdesign

    lol, i love the part about SEO being easy, thats the reason so many businesses are being ripped off, everyones an SEO expert because they think it’s easy and offer the service for a ridiculous amounts. We should all hold top spot in google, good luck.

  • astrotim

    These lists are great. I’m a jack-of-all-trades-freelancer, so it’s a good opportunity to check for any red flags. I’ve definitely been guilty of most of these things at some stage… and still guilty of a couple.

    Criticism makes for better results, so keep it coming. PS: I too noticed you didn’t open your tag :)

  • jayther

    Very excellent read. I remember I had a whole lot of these novice mistakes (including the bonus ones) when I was starting out and when I was switching to XHTML. I started when table layouts were the standard, and was very hard for me to switch to DIV layouts. x] I was also one of those “screw IE” guys until I came to realize that IE is STILL the most-used browser, and will be as long as IE comes with Windows computers.

  • ramakrishnachunduri

    in Lazy browser testing u stated that we leave ie6 till the end of project . that’s ok

    please let us know a way how we can have ie6 and ie7 in same system(machine) and test among both of them simultaneously


    This is an excellent post . thanks for pointing our mistakes , we’ll follow ur suggestions

  • Arkh

    You forgot #1 : trusting your user input.

    And I have to agree with ghendry : source control always matter. Even if you’re developing alone, the possibility to go back to an old version is too good to not be used.

    • Yes, that’s a very good one. Relying on client-side validation only is also a huge mistake. I’ve added it to the list.

  • Craig, you’re an idiot. (You were asking for that kind of comment on Twitter, so I thought I’d help you out. ;))
    No, really, it’s a good list of bad practices and mistakes. Of course you can debate some points, and some rules you list don’t apply in every context, but it’s a great post. Oh, and I think you could have used “front-end developer” instead of “web developer” in the title. You’re not really dealing with server-side development in this post.
    The only issue I have with this post is that you list Transitional doctypes along with not using a doctype at all. Those are totally different matters. Not using a doctype triggers Quirks Mode (which, in IE 6-9, amounts to using a rendering mode mimicking IE 5.5; the effects in other browsers are less drastic), so it’s a definite no-no. Using a Transitional doctype? No big deal. Actually if you need to use IFRAME elements (say, for third party widgets), or if third-party scripts create IFRAME elements in the DOM, you should be using a Transitional doctype.
    Or maybe you were referring to the abridged HTML 4.01 Transitional doctype (with no DTD URL), which validates but triggers Quirks Mode?

  • ammark

    Craig, wanted to know. sometimes i tend to forget classes functionality. say my web app has tons of pages and everyone has some classes for margin or padding for tables (i know tables are old, but its an tabular app) so sometimes i end up making multiple classes for new pages which has same functionality. given that what would you suggest me. also i get very confused in naming my classes.

  • Thanks Florent V … I miss the abuse!

    Most of the points apply to front-end development because I wanted to make it generic enough for all web developers. There are some horrendous things you can do in, say, PHP which wouldn’t be applicable in ASP.NET. Some of the bonus blunders apply to server-side technologies though.

    As for DOCTYPEs, anything that gets you into quirks mode is bad (I’ve not made that particularly clear, but the article would have doubled in length!) Using a invalid DOCTYPE is probably worse than none because it’s far harder to spot the problem!

    However, I’ve also known developers use transitional DOCTYPE because it was the first/only one offered in their IDE or it prevented ‘errors’ in their code.

  • I agree with you on the browser testing. From my experience a developer should be able to fix the problems before they even occur. The double margin bug in IE6 with floated div’s for example. When writing the CSS simply add a “disply:inline” as you code and the problem is solved.

  • Tim

    As a novice web developer myself, I appreciate this list! Thanks!

  • Couldn’t agree more with the entire rant. Heck there were times I thought I wrote it. I especially agree with the SEO part. I am so sick and tired of seeing clients pay good money for a garbage site that then has to be re-coded from the ground up because the initial * cough cough * developer didn’t give a rat’s patootey about SEO. It’s REALLY easy folks if you just pay attention!

  • Dan

    Here is my list in order of importance
    1) Not caring about your old urls when you change your site. “Why dhould we care that about all the links coming from other sites, when we have such a cool new web site with SEO urls”. I’ve lost the count of how many times, i saw an old article, refering me to an interesting link, which when clicked, sent me to a “Opps, this page cannot be found”. What is worse, is that i found those dead links on big websites like zend, and ibm.
    2) Protability – “to use our program you need to change php.ini”. This is a mistake that Pear and zend framework make. Did they ever consider the situation that some developers can’t change their online php.ini?
    Also here i should mention using non-standard extension like .inc for server side configuration files. Maybe you know to setup your server to interpret .inc as .php, but think about the scurity hole you put in your application, when the script is moved to another server.
    3) readfile($_GET[‘url’]); without any validation (and his variant include $_GET[‘page’]). Just try to call your script with geturl.php?url=./index.php and see what’s happening :),
    4) Putting 2MB image files, as thumbnails, it will not only make your website to load slow, and to consume a lot of traffic, but it will also kill your visitor browser if you display them in galleries, and they will not forgave you for that :).
    5) Not using MVC. Maybe you know your way around html, and decide to mess php and html in the same script, but think about the problems when your project manager decide to hire someone to redesign the site. How much time it will take for him to learn, where to find the html code to change, hidden all over your php scripts.

  • Adam

    It’s time to redress the balance and give web developers some flak.thanks for the post.

  • Akram Abbas

    I tell one thing,
    If we will keep developing websites for old browsers i.e. IE6 etc… so IE6 will never die. We are the people, who want to keep alive IE6…
    I know, there are people, who still uses IE6. approx 6% .. so why they are using?? because we are telling them not to be grow…

    anyways thankx… and think deeply :)

    Akram abbas

    • As web designers and developers, we can help influence the browser market. But it’s not that simple: if it were, IE wouldn’t have the largest market share.

      Some large organizations use IE6. Or consider online shops where IE6 users are likely to account for around 5% of traffic. Would Amazon really block 1 in 20 people and $millions in revenue?

      Ultimately, your target market will influence your list of supported browsers. For example, the Apple App Store or Mozilla add-ons sites have little reason to support IE6. For general content, though, there’s no reason why you can’t have a great site which remains functional in IE6. At least you’ll then have an opportunity to tell users about the benefits of upgrading.

  • Penguin Pete

    Loved your post, and I especially want to kick the tail on anybody who sets out to be a web designer while skipping HTML. Why do people get into a tech field if they hate to code???

    Since you specifically referred to “SEO wotchcraft”, may I recommend a story arc from my webcomic a while back which paints it as just that?

    It starts there and goes on for about the next 15 strips…

    • Love it … and, seriously, not far off the SEO advice I hear clients have been given!

  • Darren Bell

    Nice article, I’m only just starting out and found it interesting.

  • Wow, great post!

    My favorite 4 are:
    1) Ignoring web standards
    2) Lazy Browser testing
    3) Paying no attention to portability (how many times do I run into this one!)
    4) Scorning SEO (I build in the 90% checklist when I build a site too)

    * And every point in the Bonus rant ; )

  • lucideer

    relying on bloated libraries when a few lines of JavaScript would suffice

    Wow, I can’t believe that someone, somewhere on the web actually thinks this. I thought I was the only one.
    This should definitely be in the top 10 imo, and I don’t think it’s even restricted to “novice” developers either. DRY is an excellent development principle, but there is definitely such a thing as taking it too far.

    • Thanks lucideer. Watch out for another article about the subject soon…

  • “It’s often easier to fix a site for IE6 than IE7.”

    Dear God, that is so true. I have come to hate IE7 more than IE6… Luckily, it does seem to be on the way out from my browser stats.

    “It’s like assuming you can drive because you successfully tuned the car stereo.”

    On the other hand, my failed attempts to tune the stereo when driving have caused several fatalities. (Joke!)

    “I’m now going to reveal another industry secret: most SEO techniques are bleeding obvious.”

    Absolutely! But then were else can you get money for old rope these days?

    Excellent article, Craig!

  • If you consider web development to start and end with the presentation layer, this is a good list. However, e-commerce sites are seldom simply a collection of static pages and the underlying data model can make or break the performance. I seldom see articles on SitePoint that discuss data modeling beyond that required for user authentication.

    Until someone convinces me that they understand the rest such as how a file system works, file types (at least text vs. binary), relational theory, and SQL (to name a few), I wouldn’t consider them Web Developers.

    • I totally agree, although a list of SQL, PHP, ASP.NET etc. mistakes would have made a far longer list. Watch out for similar articles though…

  • Luke Gedeon

    Now wait a second, you used a “/end-of-rant” tag without a corresponding “end-of-rant” tag. And isn’t using / and “end-of” redundant, or at least not useful? Where does the end of the rant begin?

    • :grin: Quite right. Totally non-semantic tag! It would only make sense if it was an empty tag, like br/. So you would have “end-of-rant/” on its own at the end.

  • ammark

    How do i make email stop. i been receiving em like anything since i posted :(

  • Bryan

    Good article. I used to be a newbie like that. I will admit that I am still guilty for a couple things here, such as the validation one. I’m determined that they’re flawed!

    The comment by Deborah Smith about spacer gifs reminded me of that hack newbies sometimes use for dropdown menus, which always irritates me. For one, why use JS for a dropdown menu when you can use CSS, and secondly, why rely on a blank image to detect and call a MouseOut function.

    • CSS-only drop-downs are flawed; primarily because they don’t provide hover-over latency or keyboard support. JavaScript can fix those issues and gives you far more control.

  • Al

    Ha… as an older guy who has been in IT since 1969, when computers cost millions of $s and programmers never got to see them, let alone touch them… I was amused to see how much importance you place on coding. In a world of automation and components, if it hasn’t already been coded – what value are you adding, by urinating on the wheel and claiming it as your own idea?
    Are you suggesting we all return to coding binary, machine code, writing operating systems, new protcols, etc…
    As with all wars the real victim here is ‘the truth’… content is what is important, a box of crap is still a box of crap whether text, image or video, left, right or centre… go figure.
    Coding languages come and go, believe me, I have been through enough of them and vice versa…
    Before there was HTML there was DCF, I would hate to go back there again – word processors changed all that.
    Thankfully, much of this BS (Binary Stuff) has been automated by smart developers otherwise we’d still be coding 1s and 0s, yes it keeps the code tight, but who has the time in these days of compression?
    Get over your self, your virtual world and the mark you have left on this planet – beauty and art have some value, coding is like cutting digital grass, it is not sustainable and can waste a lot of your life, go outside and plant a tree.

    • “Get over your self, your virtual world and the mark you have left on this planet – beauty and art have some value, coding is like cutting digital grass, it is not sustainable and can waste a lot of your life, go outside and plant a tree.”

      You must be responding to someone, somewhere in the thread I guess because I don’t think the author put a great importance on coding or “urinating on wheels”.

      But anyway, what if we like cutting digital grass? Isn’t “code” just another medium like canvas, paper, wood or metal? Our tools just happen to be more abstracted from the 1’s and 0’s of days gone past (I’d rather write ASM than binary to be honest though).

      Why can’t we be productive little coders or digital designers in our virtual worlds and also go outside to plant trees, play music, paint or draw?

    • @Al
      I’m not totally sure if I understand your point but, reading between the lines, are you saying we shouldn’t write HTML when there are plenty of WYSIWYG tools which allow us to concentrate on the content?

      That’s fine if it’s all you want to do, but those tools are limited to the functionality implemented by the developer. Writing your own code provides infinitely more freedom of expression. IT moves forward because programmers improve existing systems and push the boundaries.

      You can’t compare writing HTML with binary or assembly language.

  • Anonymous

    I would also add not testing your web site on different OSs and different monitor resolutions

  • Totally agree with 95% of the article and would like to give copies of it to some coders I’ve worked with.

    On the reset button point– it does annoy me when someone drops a reset button into a form out of habit. It’s horrible for accessibility for most forms that are presented for end consumers– sometimes they hit it instead of Submit, and then the tears begin! But for a lot of the applications that I work on now, which are often apps that query a database according to some filters, a reset button makes sense to remove all of those filters. In fact, having to go over 5+ filter form fields and set them all back to “all criteria” is a bit annoying.

    The reset button issue is– think about what your users are actually doing, and serve that purpose rather than following a brainless rule. That seems to be a thread running through your (very good) article– we’ve all met web developers who would rather mess around with some bleeding edge Ajax library because it’s does cool stuff, even though it breaks the accessibility and usability of the site of the site. I want to mess around with that stuff too– it’s not that good web developers don’t want to be up to date on the latest technologies– but we’re aware that we have to serve the user first and not our own masturbatory tendencies.

Get the latest in Front-end, once a week, for free.