Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

Burning Excessive Code The Vanilla Web Diet

Editor’s note: This is an introductory article about a book idea to be published by Smashing Magazine with Chris Heilmann. Check out what we propose as an idea — explaining a way to reconsider how we build websites to ensure they are leaner and more future-proof. At the end of the article, we’d ask you to fill out a quick survey to show your interest.

The Web as it is now is suffering from an obesity problem. If you surf the Web on a flaky mobile connection or some hotel wireless, you’ll find yourself a lot of times staring at a page or app that doesn’t do anything and doesn’t tell you what is going on either. The spinner in the tab or the URL bar seems to be the thing that gets the most mileage in browsers. Surfing with a net tab open in your developer tools shows you an incredible amount of data being sent for seemingly very simple end products.

Why is that? Shouldn’t years of Web development and advocacy about performance by Yahoo1 and Google2 and many others have born fruit and made us aware of how much each HTTP request costs? If you look at the final products, it doesn’t seem that way.

The Vanilla Web Diet3
Image Credit: seelensturm4.

Reasons For An Obese Web Link

There are a few reasons why our Web is on the chubby side, and most of them actually are possible for us as developers to change.

We Don’t Develop in Realistic Environments Link

Probably the main reason is that as developers, we work on fast and big computers connected to a fat line, and the first time someone tests our products on slow connections is during quality assurance (QA). And as QA is the first thing to get ditched when deadlines are not met, sometimes this never happens at all.

Clinging On to the Past Link

Another reason for the love handles on our Web products is a false sense of allegiance to outdated and old technology, namely browsers of the ’90s that refuse to go away. There are many attempted solutions to the problem of legacy environments, each of them with its own problems. The fact is that there are a lot of end users out there on terribly outdated computers with — in our view — bad browsers and probably limited connections. These users should not be blocked out, but they should also not dictate what we build.

Browser Differences Link

Another big reason is the annoyance of browser differences. There are not many Web technologies and APIs where all browsers are in agreement when it comes to supporting them, and many times we need to repeat code and fork and test to give the same functionality to all of them.

Embracing The Chaos And Celebrating Differences Link

The last point is the main mistake we make: instead of embracing the chaos that is the Web and our end users’ environments and abilities, we don’t seem to be able to give up on the dream of having a product that works and looks exactly the same everywhere.

My Browser Isn’t the World? Link

In the worst case, we try to achieve this by blocking out all the browsers we don’t like and proclaiming proudly that “everybody uses browser X and whoever doesn’t is an enemy of the modern web.” This, of course, is just lying to ourselves, and is based on the fleeting concept of a “modern web.” A lot of the most terrible web-based products out there were built years ago to only work in Internet Explorer (IE) 6, which was the bee’s knees at that time. It does not matter which cool hardware has a hardwired browser that is hot right now — we are making the same mistake again if we only build to one browser and lock out others.

Locking out any browser means actually writing more code to test for browsers, and it is almost impossible to reliably detect which browser is in use. If you want proof, just take a quick look at the user agent string of the Yandex browser5, which contains the names of almost every browser engine out there:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.5 (KHTML, like Gecko) YaBrowser/1.0.1084.5402 Chrome/19.0.1084.5402 Safari/536.5

I hope we can agree that building for one browser (or engine) only works for you if you are targeting a certain market and group, and even then you are not safe from losing them in the near future.

Libraries Are The Future Link

Another attempt to achieve the dream of cross-browser uniformity is a strategy of abstraction, using libraries, polyfills and frameworks to allow us to write in one language and have all the browser-difference magic happen under the hood. For production use, this is a very good idea. In the long run, libraries should get us where we want to be — almost every software environment, sooner or later, is running using libraries that unify the access to hardware or data APIs. For app development, we need to define and nurture these libraries and use them to our advantage.

Built-In Redundancy Link

The issue we have now, though, is that libraries and abstraction frameworks are becoming the starting point, and in the case of simple websites with a bit of extra flair, they are not needed. We just started to use them without considering their impact or even forgot how to do things without them. And in many cases, a lot of the things we do with them are already available in the browser for us, we just need to use what is there instead of simulating it. Libraries themselves start to suffer from obesity, and in a lot of cases, the extra fat is the functionality to make legacy browsers do things they were never meant to do but that browsers based on the HTML5 specification have already built in.

Death By A Thousand Plugins Link

Misuse of abstraction of code is rampant these days. We use libraries and converters that allow us to write the least amount of code possible to achieve a lot. This comes with a price. The three lines we write in an abstracted language can result in dozens after conversion to browser-understandable code. It is very tempting to use 20 small scripts on our pages when all of them are just a few lines, but this amounts to a mass of HTTP requests and generated code that chokes the browser. As we never see this code, it doesn’t appear to be our mistake — we just wrote the least amount of code possible. Surely adding yet another script with just five lines of code can’t make a difference?

So this is where we should start thinking harder about what we do right now. We’ve become dependent on abstractions for the most simple things and follow a cult of adding lots of helper tools, as they make things much simpler and are needed for a product to be maintainable and able to grow. A lot of the best practices in Web development were found and defined by large companies who had to build products that are maintained across different countries and teams and have to stand up to the requests of millions of users. What is a best practice for the Yahoo homepage or Gmail does not necessarily have to be what makes your smaller product most effective.

Jonathan Snook has a great example of this when he talks about his SMACCS6 approach to writing CSS. He points out that almost every product starts with a reset.css file, but once finished, removing that file doesn’t show any difference at all because for the elements we use we do define the margin, padding and sizing.

A Vanilla Diet For The Web Link

So here is what I propose: we need to put the Web on a diet, using vanilla Web technology that comes with browsers. As Alex Russell put it in his talk at Fronteers this year, if we want to change the Web it is up to us to move it ahead, and using polyfills and libraries is a future tax we currently pay.

Every successful diet is connected with a change in lifestyle. For the Vanilla Web Diet, here is what I propose we can do to slim down the products we build. This will not be applicable to everything, of course, and there is a place to start with a library and an abstraction layer. As I said before, sooner or later we will have an environment where libraries allow us to build great apps and products. But for a simple website with a few enhancements, it is time we stop randomly putting things together because they look shiny or seem very small.

The principles of a vanilla Web diet:

  • Build on what works
    Our base layer should be HTML, plain and simple and doing the thing the product is meant to do. Something that looks like a button but doesn’t do anything is not helping our users. When everything else fails, HTML is the thing users get — let’s not deprive them of that.
  • Lack of support is an opportunity
    If an old browser cannot do something, it allows us to test for that and not give it that functionality. In 99% of cases, the functionality is a nice-to-have and not needed.
  • Browser-specific code cannot be trusted
    Every functionality you make dependent on browser-prefixed code adds to the landfill of code that breaks very, very soon.
  • Use a mix of technologies — each for what it does best
    It is very tempting to do everything in JavaScript, but it is not needed.
  • Ask questions
    Whatever you do should be wrapped in an “if,” making sure that only environments that can apply what you want get it.
  • Write as much as needed, not the least possible
    Let’s think about what we write before we write it, instead of adding lots of small, quick solutions.
  • It is not about what you can add — it is about what we can’t take away
    Basic functionality should always be there.
  • Usefulness beats consistency across browsers
    Instead of giving everyone the same experience, always consider what is the best way to ensure people can use what we build.
  • Load only what is needed
    Why should a browser get a library or a data file if it cannot do anything with it?
  • Analyzing effects beats adding FX
    If you want to add shiny things, make sure they can perform in a shiny fashion; nobody likes their browser to slow down for a laggy effect.
  • Strong foundations beat a possible future addition
    A lot of times we add a lot of code and interfaces to allow for a future that will need them. This future hardly ever comes about. Let’s build for the now.

A Quick Example: Adding A Video To A Website Link

Let’s take a simple example: adding a video to a page. Conditioned and burdened with years of Web development, our thinking might be:

  • HTML5 video is nice, as it is native to the browser, the controls are readily accessible and I could build my own controls using the JavaScript API that comes with it.
  • Older versions of IE, however, don’t play any HTML5 video, so I need to add a Flash fallback.
  • Furthermore, not all browsers support MP4, so I need to have the video in two formats, MP4 and WebM, as well as OGV if I want to support even older Firefox and Opera.

With these in mind, we’ll probably get a video player from GitHub and use that one. The video player would be clever enough to recognize what the current browser supports and write out a Flash video or a native video. It will not help with the codec and browser support issue, unless we also use a player that detects that and sends the correct format, like Vid.ly7.

That makes everybody happy and ensures everyone can see the video, right? True, but it also adds a lot of overhead that is really not needed. Let’s think about the use cases here:

  • If I am on an old browser, do I want to load a JavaScript library, have some detection happening and get a Flash player? What if I have no Flash? I loaded a library for nothing and I still cannot get to the video at all.
  • If I am on a modern browser, I loaded a library, and if I have Flash enabled, then I will get a Flash player with all the memory consumption and initialization overhead (granted, this isn’t much, but on my MacBook Air for example, the fan mostly starts because of Flash).

A vanilla diet approach to this would be the following:

<video controls="">
	    <source src="hedgehogs.mp4" type="video/mp4">
	    <source src="hedgehogs.webm" type="video/webm">
	    <a href="hedgehogs.mp4" style="border: medium none;">
	        <img src="/web/20121114223746im_/" alt="Frolicking hedgehogs">
	    Click image above to download video

HTML5 video-capable browsers will show the video, and others will get an image preview linked to the video. This way, users on old computers and bad connections or browsers without HTML5 video capability will get an image and can watch the movie in the video app of their operating system. They can even do something else while the video is downloading instead of staring at a “buffering” message.

Is is too much work to have the video in two formats? Fine, use one and move the link out of the video tag — that way you offer the option to download the video to everyone on flaky connections:

<video src="" controls="">
	    <img src="" alt="Frolicking hedgehogs">
	<a href="hedgehogs.mp4">Download video (MP4, 3MB)</a>

Don’t want your video to be downloadable? Use Flash or Silverlight. This will not stop anyone dedicated enough to download it, but it makes sure you’ve done your part in securing the content. It blocks quite a few potential customers and readers, though.

Another Example: Expandable News Items Link

A lot of times we use a JavaScript library to have some headings that, when clicked or rolled over, show some paragraphs below them. jQuery’s show() and hide() are meant for that and there are a myriad of plugins to give us that functionality.

If you want to do this in a vanilla Web diet way, there is no need for JavaScript. Let’s start with the HTML. There are many right and wrong ways to do this — lists, definition lists, headings and divs and so on. Many an hour was wasted on forums discussing what the perfect markup is for this. Taking a leaf out of Nicole Sullivan’s book, let’s apply some OOCSS8 and make ourselves independent of the element names by adding classes:

<article class="collapsible">
  <h1 class="trigger">Interesting news</h1>
  <p class="content">Amazing stuff happened</p>

Now, in order to make these collapse and expand in a smooth way, all we need to do is apply some CSS:

.collapsible .content {
  overflow: hidden;
  max-height: 0;
  opacity: 0;
  transition: 1s;
.collapsible:hover .content,
.collapsible:focus .content {
  max-height: 200px;
  opacity: 1;

Here you can see some of the principles in action. Older versions of IE do not understand max-height or opacity, so they will never apply the styles that hide the content. The much larger max-height of the hover and focus states makes sure that the browser expands the content all the way (it will always go to the real height, the only problem you will have is when the content is higher than 200 pixels, so this is something to point out to whoever is maintaining the code). The transition of one second makes sure the browser does this smoothly instead of just showing the content. Browsers that don’t support transitions still show and hide the content. You can add browser-prefixed transitions, too. Firefox and IE10 already dropped the prefix for transitions and others will follow.

Now, if you want to add onclick functionality to the header, we need some JavaScript. First of all, though, we change our CSS to look for a class on the collapsible element instead of relying on hover. We also make the hiding dependent on a JavaScript class as we don’t want to hide the content in browsers that don’t fulfill all the requirements of our script.

.js .collapsible .content {
  overflow: hidden;
  max-height: 0;
  opacity: 0;
  transition: 1s;
.js .content {
  max-height: 200px;
  opacity: 1;

When the user clicks the header, we want to add the class of show to the collapsible element, and then remove it the next time the user clicks. For this, all we need is a single event handler on the document. To remove and add the class, we could change the className property, but newer browsers have the much more flexible classList9 implementation. We test for the things we use in an if statement and end up with not much code at all:

if (addEventListener && 'classList' in document.body) {
 document.addEventListener('click', function(ev){
   var t =;
   if (t.classList.contains('trigger')) {
 }, true);

Older versions of IE don’t understand addEventListener(), so this will not be executed as we test for its existence. If classList is supported, we apply a click handler to the document. We then test for and toggle the show class to trigger the CSS change using classList whenever the element with the class trigger is clicked.

More? Link

Now here’s the idea: I am planning to write a book about this, published with and by Smashing Magazine. I really believe that there is a lot to be said about the things in HTML5 that browsers now give us and that allow us to write simple and effective code to release pragmatic products instead of adding a lot of code we just don’t need for what we want to achieve.

If you are interested, quickly fill out the survey below or drop us a comment and we’ll go ahead.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9

↑ Back to top Tweet itShare on Facebook

Chris is a Developer Evangelist living in London, England, who writes about Javascript development, accessibility, and all things open web. After several years evangelizing at Mozilla Foundation, he's now working at Microsoft's EdgeDev team.

  1. 1

    You make so many great, thought-out points. I love your simplistic approach of implementation — this is how things should be.

    • 2

      English Teacher

      November 14, 2012 9:45 pm

      “Simplistic” is not a fancy word for “simple” or “straightforward,” and using it that way makes you sound pretentious and ignorant. Simplistic means *overly* simple — in other words, it’s a criticism. Did you mean to be critical?

      • 3

        So using ‘simplistic’ incorrectly makes you sound ‘pretentious’? So what does calling someone out over the misuse of a word make you sound? Pot meet kettle.

  2. 5

    Isn’t this just progressive enhancement, but with a twist? Namely: serve everyone ultra-plain stuff, and make the next quantum the very latest browser?

    Most websites are built that way already, but client demand for support on intermediate browsers (e.g., IE7/8) forces web developers’ hands to use things like polyfills. I.e., it’s market demand, not developer ignorance, that produces the current mish-mash.

    Once IE9 is the accepted standard browser, all new development will be done like this anyway.

    • 6

      Christian Heilmann

      November 13, 2012 7:00 am

      As someone who has promoted progressive enhancement for years, I am with you and I so wished it were that way. But every time I do, I get a _lot_ of people telling me that it is impossible to do PE…

    • 7

      Leslie Wildesen

      November 13, 2012 9:42 am

      Once IE “X” stops being synonymous with “security flaws” and starts running on Mac, it may have a chance to become a “standard” browser. No Microsoft Kool-aid for this small business. Our government clients can’t afford the vulnerability and we don’t have time to mess about with daily patches.

    • 8

      @Anthony – “Most websites are built that way already..”

      There’s a growing trend for pushing all duties to the front end, making it completely reliant on Javascript, whether justified or not. I think the influx of ex-Silverlight and server side devs into front end has aided this, the concept of a ‘sealed’ codebase concentrated at one half of the connection appeals to them, as does targetting single browsers like Chrome only.

      You can achieve a highly responsive, ajax-driven site using progressive enhancement, pushstate and server side partial templates. Much faster and more robust than sending everything to the client for assembly.

      The tendency for sites to have to look the same on all browsers surely originates from design / creative. Front end engineers need to better articulate the adverse effects of this, and this book would be a great addition.

      Sign me up for this book and I’ll spread the word as far as I can, I strongly agree it’s the right approach.

  3. 9

    Would you be interested in purchasing this book? The answers should be radio inputs and not checkboxes.

  4. 11

    With every project I work on, I start out with the best of intentions by trying to ensure the code being written and the overall end quality performance is the best it can be while at the same time being easily maintainable. What inevitably happens is that as the project evolves and things change or need to be revised, but the sand continues to run through hourglass. More often than not, in order to save time, the “easy” road is taken and things end up being more bloated than intended, even though by today’s standards that result may perform quite well.

    Excellent article and a good illustration of how things “should” be done, but it takes some pretty serious effort and willpower by all involved to maintain that solid direction until this approach becomes a regular habit rather than a one-off. Would definitely read further thoughts and ideas on this topic.

    • 12

      Hey Calbick,

      No website is usually ever a one-time do and forget thing (unless, of course it is and it has short half-life). Because of that we should always factor in maintenance time. And this is the time when you have a chance to go over your code and fix all the little misstakes, take proper routes (instead of the easy ones) and increase the performance. No one codes perfect from the start, even perfect programmers (as no one has 100% clear idea what it’s gonna look like). But everyone must go back and fix their misstakes. It’s like writhing a book – you need to edit it, no matter how good of a writer you are.

  5. 13

    Awesome post. I could not agree more. A couple of years ago I was all about jQuery and extra plugins but now I hate when I have to use it. Really enjoying trying to push out sites that are just blazing fast

  6. 14

    Great article and a few really good ideas in there. Speed is the thing I look for most when developing. The faster and more lightweight the site is, the happier I am.

    Keep up the good work and produce a book. I’ll be one of the first to buy it!

  7. 15

    I like much of your thinking here. Could I suggest adding that how we are educated also plays a part in this? Even for those of us with a degree/s in this area we turn to places like Smashing Magazine for tutorials etc. But too many of the tutorials just use plugins or libraries. It’s often frustrating to find an actual ‘from scratch’ tutorial. For one thing we ( as a culture) have conflated the idea that not re-inventing the wheel means don’t build it yourself. Whereas what would help educationally would be to see how to build it yourself but not re-invent the methodology or algorithm (which is where that phrase originated from in the first place). What I am getting at is that many of the things on your list could be helped if we were taught how to develop without a crutch, because then we might have the better judgement of when to use and not use a plugin, framework etc. I think your getting at that here and would like to see it expounded on.

    • 16

      Christian Heilmann

      November 13, 2012 7:38 am

      Yes, very much. We have the issue of keeping new developers in the dark by showing “3 minute solutions” as they give us a lot of hits in our tutorials. We need to find a way to get the same excitement but not teach an abstraction but understand the fundamentals instead. Brad Victor’s Learnable Programming is amazing in that respect:

    • 17

      100% with you on that one.

  8. 18

    Isn’t the web a big mess because its webdesigners doing a webdevelopers work? The market is now full with ‘Front-end-webdevelopers’. Who are mostly people that know how to point and click in Photoshop and Dreamweaver, but when it comes to actually coding something they lack the skills.

    I blame jQuery for this. jQuery is in a developers perspective one of the worst frameworks out there. It’s badly written, it’s not modular. And it’s STUFFED with code that nobody uses.

    Also the jQuery plugins, and the hell that is called jQuery UI, is one big mess in performance and best coding practices.

    Then it’s the ease of use. Just copy-and-paste. It works. Webdesigners heaven, webDEVELOPERS hell.

    • 19

      Kelvin, there will be always something to blame. But blaming software for accessibility (although it might be the cause) will not solve anything. What’s best thing to do is to educate ourselves and build better websites. Your background does not matter: if you are willing to learn, you will. And those who prefer for quick fixes and cheap knockoffs – can’t really fight those guys, at least they’ll make our work look better :)

      • 20

        Actually the point i was trying to make is that webdesigners see cose as ‘something neccessary’ and web coders as ‘art’ or ‘something of their own’. Wich can explain the use of bad practises you see all around the web. So that points out the work Chris is doing is actually going to help those people :)

  9. 21

    Good point on keeping in mind that today’s best browsers could very much be pieces of shit years down the road. I see a lot of web apps directed at Safari only or Chrome only – and they are good, but only as experiments to test the latest technology. In now way should they be accepted as full-functioning websites.

    Excellent point on “Death by a Thousand Plugins”. I am a bit biased, but this is pretty much the reason I avoid using WordPress or any other CMS unless it is a simple blog structure. I’ve seen too many websites with too many plugins which are pretty much the same thing as GeoCities accounts back in the day – lots of animated gifs ;)

    One thing that has not been stressed here though is unavoidably large, media-heavy websites. For example video websites such as Vimeo will have huge files (videos) that you will need to download to actually use the site (although it does not go into calculating total page size). Then there are imaging sites like or which present high-quality images, which we absolutely have to download to see the page (otherwise there is no point to visiting the website). What do we do then? (So far, CDN and server upgrades have been the only straight-forward solution I’ve seen around)

    • 22

      Christian Heilmann

      November 13, 2012 8:45 am

      Well, the idea of Vimeo is to watch movies and the idea of 500px to see images. Their job is to make it easy to upload and share media and comment on it and make it embeddable. So I don’t think we should blame them for being heavy as this is what they are for and people going there expect high quality content that is not text.

      Where it gets more interesting is when content is media heavy for the sake of being media heavy. Phil Hawksworth’s talk at Fronteers ( had some really great examples of that (5:40 onwards) – for example is almost 6MB without giving you much news. This is hard to battle though as it looks lovely and clients think they get a lot for their money.

  10. 23

    Howdy Christian

    Just a quick note. I appreciate your concern for :focus, as most code examples do not consider the keyboard user. However, article is not in the normal tab flow. Add tabindex=”0″ to the article tag and the example will work.

    I would also suggest people avoid using JS calendar modules. If your database does not require a specific date format than the form could simply use type=”date”. Browsers are beginning to offer some great date pickers and the user will have a much more consistent experience.

  11. 24

    I agree with this so hard it makes my toes curl. The modern day “trends” remind me a little of the days of Flash. Just because you CAN do it, doesn’t mean you SHOULD do it.

  12. 25

    SMACSS and others needs to be discussed more. We’re so focused on novelty that we miss on optimizing what we’ve had for years now. Thank you for (re)starting that conversation.

  13. 26

    I’m already dedicated to the lean/mean approach defined in the principles list – what would be most meaningful to me are specific use cases that I might be blind to (the description of “show more” with css instead of javascript is a good example, although I’d like a more detailed explanation of how to determine when there is a tipping point where javascript or jQuery makes more sense), because I tend to build a lot of interactions around javascript and jQuery by mental default. I’m not sure I would buy a book if the content is mostly overview and justification – but I would definitely read articles and would be much more likely to buy a book if there were a ton of meaningful specifics.

    (Also I wonder if a different name for the paradigm might be considered? I hate to see something I love doing and find exciting called “vanilla”! Won’t it make it sound like we’re making boring websites?)

    • 27

      Christian Heilmann

      November 13, 2012 9:52 am

      This will be mostly about examples and specifics, not a “we should do this wonderful thing”.

  14. 28

    Christian Varga

    November 13, 2012 9:50 am

    For a while I’ve been subscribing to the method of using javascript to toggle classes that alter the display of content. I can say that it’s pretty damn easy, much more semantic, and often the effects are smoother due to hardware acceleration coming into play on CSS animations now. Problem is, I still use jQuery in nearly every project. And I’ve never thought about it before, but now that I am, I realise that 90% of what I need jQuery for is for selecting, iterating, binding, and ajax. I could probably do without all of jQuery’s bloat and just switch to a library that *just* offers these, like Zepto.

  15. 29

    Thanks for this very inspirational post.

    Will the book talk about optimizing JS ? Cause I know how to use JS, prototypes, functions, closures, objects, and all this stuff, but my code is always laggy…

    It’s hard to find good stuff about pure JS to teach how to do great and functionnal code working without.

    So I was wondering if the book will just be a kind of ewamples with use of CSS instead of JS, or it will speak also about making good JS ? If not, is there good way to learn this ?

    Thanks for reading !

    • 30

      Christian Heilmann

      November 13, 2012 11:05 am

      There will be very few JS optimisation tips – there are already a lot of good books on that out there and even more blogs. Check out the materials around jsconf, there is lots of info there. I am about to take off on a plane, so sorry for the short answer.

  16. 31

    This is a very refreshing article. I’d be curious to hear some thoughts on how this relates to the added challenge of dealing with not just differing browsers but also different screen pixel densities, with the advent of the Retina display. I read the recent-ish article regarding serving images and assets for Retina optimization, but I’m curious if there are any thoughts regarding what this article covers and the challenges of dealing with Javascript media queries and double the assets for low-density fallbacks.

  17. 32

    Great post. I would love to see that book.

    I have always been a proponent of “if you don’t need it, don’t use it” approach. I know many web developers who use frameworks (both in PHP or JS) for simple websites. It becomes serious overkill. I rarely use PHP frameworks to build clients websites, as most of them just don’t need it. Same with jQuery. I use jQuery when the client wants websites that have significant effects or “niceties”. But most of the time, one JS script, with some plain ole’ vanilla JS, nicely formed CSS, couple of image sprites and some thought will be plenty.

  18. 33

    Sounds like ‘modularity’ in all forms.

    Of course, one of the cold, hard truths about the obese state of the web (in that the pipe needs to be fat) also hints at the web being outright juvenile in that where one might expect the expertise of a truly professional web developer’s ink, they are instead presented with the crayon of a novice or hobbyist.

    So much of the web is in poor quality simply because the vast amount is ‘developed’ by people who aren’t web developers, and just don’t know any better. So much so, that there is no reasonable chance to expect quality development in every corner of the web.

    And not even that; some entities are professional only in title. Chrome is a great browser, but why is it that to THIS DAY, Google searches do not return and validate? Sure, Facebook is a success story through and through, but by a professional developer’s standards, their development team should be shunned and laughed at.

    It’s not enough to make a product successful by business standards; but to make it progressive by ours. It is not an unreasonable ‘demand’. They are not mutually exclusive features. You are not forced to have this OR that, but as with many things, present a better product, when you have this AND that. A thinner, modular, responsive web, definitely seems like the right place to start.

  19. 34

    I’m in the process of developing web apps and a surrounding business. I’m thinking part of the code standard might be maximum acceptable load times, file sizes, etc. I know developers hate documented standards but it makes written goals that all staff can shoot for and makes for easy benchmarking.

    Definately interested in reading the book or watching a series of Webcasts. GigaOm does some really good round table discussions, maybe a format like that would work.

  20. 35

    This is exactly how I like to code, but I too find myself drifting away from simplicity sometimes.

  21. 36

    Benjamin Allison

    November 13, 2012 5:31 pm

    The irony is that Smashing Magazine’s website is a prime example of what this article is talking about.

    Plug it into W3C MobileOk Checker and it gets a score of 0%. Now, I think that validator is a little unrealistic; what modern website, even for mobile, can be under 20k and offer a rich experience?

    Still, pages sizes here are well over 1MB…

  22. 37

    Secondly, one of the sad fact of the matters is that for aspiring web developers, it’s a lot more possible to learn bad practices via piecemeal searching than it is to find “best practices”.

    How phenomenal would it be to have a website that housed a collective “best practices” for different technologies?

    Best practices for web development, database design, mobile design, etc.

    The faster tech changes, the more difficult it becomes to collate that data into as few as possible reputable resources.

  23. 38

    Ivelin Belchev

    November 14, 2012 1:11 am

    Some of these issues actually really depend on the scope and budget of the project.

    For example the owner of a small business website with a budget of a couple of thousands, that expects no more than a few hundred visitors per day, would much rather have messy code (generated by LESS, full of framework bits they don’t need, etc.) and have their designer spend more time carefully designing each individual page of content.

    On the other side of the spectrum, if a large corporate website doesn’t look consistent across browsers (and more importantly consistent with the brand identity), that hurts the brand.

    Both clean minimalistic code and big bloated frameworks that make things easy have place in our web development toolset. The more the options – the better. Sticking to just one thing regardless of context (as mentioned in this article too) is always a bad thing.

    • 39


      Actually IMO a small business that expects a couple hundred visitors a day has no less need for brand identity than a large multinational corporation. The only difference there is the amount of money they can/will spend on creating that brand.

      What is a bad idea is the thought that brand identity is tied to the website looking and acting identical regardless of the context it is in. Yes – the logo, text, colors should follow the standards of the brand – but the layout needs to follow the context. Layout is a context-dependent attribute, and, as you stated: “Sticking to just one thing regardless of context is always a bad thing.”

  24. 40

    These arguments keep resurfacing after each new technological innovation. I’ve implemented plugins for clients that have taken down my sites and I’ve implemented plugins that bring the development time to almost none – it completely depends upon target audience, budget and time.

    Don’t get me wrong, I love the lean and mean approach, but banging together a workable site is sometimes the priority. Web design and development is give and take, like any business – time, money and resources will best determine the approach.

  25. 41

    Sign. Me. Up.

  26. 42

    “In 99% of cases, the functionality is a nice-to-have and not needed.”
    Couldn’t disagree more.

  27. 45

    I was reading this article on a new Win8 Machine, so I decided to try out the code quickly… the OOCSS example does not work in IE10…
    Works in FF (with fade animation) & Chrome (no transition) on the same machine. IE10 does however support max-height and opacity, so this example is basically unusable to people with brand new machines and default browsers.

  28. 46

    I read this article, and a few thoughts flashed through my mind. While advocating clean, efficent design is always good, you seem to neglect the fact that features like the HTML5 video have come about via looking for a better way to do something that essentially already existed ie, flash, javascript polyfill’s etc.

    Another way to look at it is certain engines or browser developers innovate, they chunk in a feature and people see it, think its cool etc and want to adopt it, but its not standardised so people resort to polyfill’s and slowly over time depending how popular something is it will become a standard and most likely developed across all browsers in a standard fashion as CSS3 is now. By advocating a low fat approach it will stifle the spread of new idea’s and the formulation of new standards.

    Also a completely standardised set of browsers is a pipe dream, every browser developer has their own agenda their own methods of implementation, its a dog chasing its own tail senario, as soon as people think theres one set of standard feature’s to implement something new will come along and then its a rush to implement that which leads to browser engine differences in implementation. Tbh look at the CSS standards and how they’ve been implemented over the past few years CSS4 is now been worked on and CSS3 doesn’t have extremely high coverage. There isn’t really any middle ground its either allow an individual web experience thats dictated by the developer choice to implement what features in what mannner they choose and the users selection of browser. Or go ultra lean and serve up text files to everyone.

    A better approach might be education of users, to what browsers offers them the best experience on the web, as that really is crux of all the strife in web development. But in the end a client is going to want a similar experience for all users. You could always turn the argument on its head and say its those rushing ahead rather than those dragging their feet with browser upgrades that are the cause of issues as they widen the gap far more than those that stay standing still, but that way of thinking ultimately leads back to supporting for the lowest common denominator, someone who’s using a text based browser so you serve up text files.

  29. 47

    YES!!! I wish bosses understood that, instead it lets add this lets add that so when it comes, then they ask you how come my CMS is slow? I like your working style! RESPECT!

  30. 48

    This is especially important when it comes to using javascript. Most people start searching for a jquery plugin to handle their needs rather than rolling their own. These plugins are made to cover a very wide range of scenarios and settings. If you know what you want and you only want it to perform a certain way, writing your own scripts (vanilla js or not) can cut down on bloat tremendously.

    Same with css. Look at Zurb. B-L-O-A-T

  31. 49

    Interesting subject indeed! I’d love to read more about this — maybe even read it for my podcast (Pagebreak Podcast.)

  32. 50

    Browser-specific code cannot be trusted ?

    That’s just rubbish. It won’t break when you know how to use it!

  33. 51


    The advent of broadband made web developers lazy – why be efficient, when you don’t need to be any more.
    The advent of mobile is bringing focus back to efficiencies.

    How about being efficient all the time instead of bowing to the demands of the “I-saw-this-on-another-website-and-I-want-it-on-mine” brigade!

  34. 52

    Kyle A. Matheny

    November 21, 2012 8:25 am

    Great article!

    I’m constantly talking with others about not throwing a framework on the code base without thinking about why it needs to be there, and more importantly, should it be there (this isn’t to say there should never be a framework, but it makes people think)! — but to use HTML where there should be HTML, CSS where there should be CSS, and JavaScript where there should be JavaScript. If there’s a gap that can’t be filled [for one reason, or another], look and see if a framework could assist with what needs to be accomplished.

    I’m a proud vanilla developer; sometimes I fear that framework junkies (yes, I was one, once upon a brief time) are trapped inside the framework box and only innovate within restricted limits. I found that developing my own framework from scratch was a great learning experience as well as a way to wean off from frameworks(!). After my own framework development (personal project, only), I now fully understood most of what was out there and realized I was only utilizing about 5-10% of their capabilities because I could write the other bits in native script without needing the entire library. And then what? I learned how to create that 5-10% in native script and transitioned my sites into much leaner and higher performing applications/sites/pages/etc.

    Once you develop on top of a framework and/or plugins, you now have a lot of testing to do if you ever decide to update that framework — you’ve locked your application into a tech time period, rough. Let’s get back to building from the ground up.

    Use the right tool for the job. Don’t bring your entire workbench out to change a light bulb.

  35. 54

    This article was really great! I hope that the book ends up being written so that I can go out and buy a copy!

    Cross-browser compatibility is a headache for every developer. While I love the open source browsers and the fact that we have a choice among so many browsers, it can be a headache to try and get everything to look the same and to work seamlessly across all browsers. Granted, the top 4: IE, Chrome, FireFox and Safari rule the majority of the roost. But as you mentioned, trying to make a site compatible with those browsers exclusively means that you are edging other browsers out of the equation and therefore, blocking users. The end-user is the point of all of this, right?

    I love the idea of mixing technologies and the continued use of html as the base.

    I also love the idea that “just because you can, doesn’t mean you should”.

  36. 55

    I think you made a really great point when you said that we should embrace differences!
    I remember that few years ago in web community there was a huge movement about making the website really accessible. This seems to be totally forgotten today with all this ajax and beautiful effects. If we followed that simple accessible rule our sites would stay much slimmer :)
    That being said I would like to add for the sake of discussion that Kyle Simpson thinks that we should wrap it all up in another layer of abstraction …

    Great post!

  37. 56

    Good points. Publish the book, please!

  38. 57

    There’s a good page about that made here in Brasil:


↑ Back to top