No noscript, m’kay?

To generalize, there are three different standpoints web developers usually take when it comes to implementing JavaScript in a web page.

Make it JavaScript dependant
This usually means making the web site and important functionality of it dependant on the visitor having JavaScipt activated alternatively a web browser that supports JavaScript. Bad.
Have a noscript fallback
Often, in this case, the web site’s functionality is still dependant on JavaScript, but includes a noscript tag with a text explaining for those who don’t have JavaScript that they can’t use it. Better.
Not JavaScript dependant and no noscript tag
This is the ultimate scenario. JavaScript is used to progressively enchance the functionality of the web site, but all the main functionality will work without it. When it comes to the noscript tag, it’s redundant. Instead, include the necessary elements or warning texts in the code that’s initially loaded, and then use JavaScript to hide them. Best!

So, no noscript, m’kay?


Related reading



  • Robert Nyman says:

    If you find yourself using noscript, you should take a step back and consider if there really is no other way.

    Then we agree on that at least! 🙂

  • Tommy Olsson says:

    I don't know if I'd agree with you categorically, but in essence you're right. (Funny how this topic seems to pop up in several places right now.)

    If you find yourself using <code>noscript</code>, you should take a step back and consider if there really is no other way.

  • Tom Greuter says:

    I don't see the difference between the second and third approach. Why should you use javascript to hide alternatives for javascript, when we have an excellent element that will in fact do the same: <code>noscript</code>?

    Of course, you won't use the <code>noscript</code>-element to display just text alternatives, but instead to provide a serious non-javascript alternative.

    If javascript must be unobtrusive, then why use javascript at all? If your unobtrusive javascript nevertheless improves (progressive enhances) your site, then why not try to provide an (more or less) equal improvement with <code>noscript</code>?

    I know these discussions run elsewhere too, but I'm curious to your point of view.

  • Robert Nyman says:


    Thanks for the questions! 🙂

    They're valid and I guess I have to say that, to me, it comes down to development time and maintenance. Most web site visitors have a web browser that supports JavaScript and have it enabled.

    Hence, you want to use JavaScript to enhance their experience, but you still don't want to loose any major functionality so you use unobtrusive JavaScript.

    What this means is that even if you do cater to the people where JavaScript isn't an option, the fallback is normally not as advanced as the JavaScript alternative, usually just some text or so.

    Normally, the percentage of visitors without JavaScript are as small part of it, so it's hard to justify the time and money needed to include an equally advanced improvement.

    I hope my answer was satisfactory! 🙂

  • Tom Greuter says:

    Robert, I do agree with you on the small amount of people not using javascript, and I think it's valid to ask yourself if you have to put much time in satifying this small group extensively (good can be good enough).

    However, I don't see any argument in favour of not using the <code>noscript</code> tag. 😉

  • Robert Nyman says:


    You're putting pressure on me here! 🙂

    Why not use the <code>noscript</code> tag?

    Basically, it's a matter of approach. I personally think the best way is to handle it from an external script, as opposed to having an extra element in the source code.

    I guess it might also be a matter of changing it later on, if you have many different pages. Instead of removing <code>noscript</code> tags in several places, you just change the script.

  • Tom Greuter says:

    If it's a question of maintainability, in some cases you may be right, in others maybe not. Anyway, I will consider your approach when I'll face this problem. Thank you for your quick response!

  • Robert Nyman says:

    No problem!

    Thanks for making me explain my standpoint more thoroughly!

  • […] dat ze regelmatig een zwart-wit stelling poneren en iedere nuance missen. Al eerder had ik ruzie met een Zweed die het geldige HTML-element noscript wilde afschaffen.Nu stuit op ee […]

  • Ray says:

    What about this scenario (very simple example):

    I manipulate the DOM to insert, say, a paragraph with some "help" text at a certain position. That is, the paragraph is not part of the original source, but is created and added when the user clicks on a certain link/button ("Click here for help blabla").

    All this is done nicely without inline JavaScript. So far, so good.

    But if the user/client has no JS, I want that paragraph to be there. The only solution I see is: put it in <code>noscript</code>.

    Note: The link/button that triggers the creation of the element is itself also a creation of DOM scripting. That way, with JS on, this works as expected and with JS off the user still sees the paragraph (and doesn't see the trigger link/button, which would obviously be useless).

    How could one pull something like this off without <code>noscript</code>? I totally agree with the basic statement in your post, but in a case like this example, it seems to make sense. Unless I'm doing something wrong :).

  • Robert Nyman says:


    If I'm not totally missing something here, why don't just have the paragraph that's intended there for non-JavaScript users in the original source (without <code>noscript</code> tags), and then just replace that with JavaScript for those with the necessary support?

  • Ray says:

    Duh.. OK, I'm convinced. That's obviously the right way to solve this elegantly. Thanks for the hint!

  • Robert Nyman says:


    No problem. 🙂

  • Tom Taylor says:

    Bit tricky when you want top use noscript tags for an alternative image tracking how many hits your site receives.

    Easily overcome though by making the DOM attack it, remove it, and replace with javascript instead 😉

  • Robert Nyman says:


    Yes, just some DOM replacement will do the trick.

  • Jonathan Prugh says:

    Another argument against using the tag is that some user agents may have partial support for JavaScript.

    So, these agents will not display the content, but may choke on more advanced dom scripting techniques.

    Best to display the alternate content then hide it with javascript after testing for object compatiblity.

  • Yet another argument against using <code>noscript</code> is that if you have javascript turned on and for some reason don't get the requested .js-file, you'll end up with neither the noscript-content, nor the js-generated content. Reasons for this might be an error on the server preventing the js-file to be delivered, or if you're located behind a firewall blocking certain files.

    So doing as Robert says, putting the content in regular <code>P</code>'s and <code>DIV</code>'s and hiding it with javascript will prevent this.

  • These are all valid points. However, I'd like to throw in my two cents.

    Our jobs as web developers are made more difficult with every technology update that rolls around, which is quite often. I don't see any reason we need to cater to every 0.02% of users that have some fluke of a scenario destroy out web pages. Sure, it's a scary thought… but from a time/money/productivity standpoint, even us perfectionists have to let good be good enough.

    As far as the noscript tag, there's one reason not to use it, and one reason when it's very useful.

    The reason not to use the noscript tag would be when the JS dependent feature is part of the functionality of the page. In that case, simply displaying text is (in my opinion) a bad idea. When coding your pages initially, you should code for the lower percentage of non-js users. Although this percentage is low, it's big enough to account for. Then, code your JS around the HTML/CSS as it is. JS is very good for this.

    The scenario the noscript tag works well with is when using JS for display/effects. If your user doesn't have JS enabled, the effects wont show…hence, you could benefit from linking to a style sheet inside a noscript tag with styles comparable to the JS styles and effects.

    Well, I'm getting a bit busy now, but I'm glad I toss my opinion out there.


  • Loque says:

    I completely agree with this article although what happens when you want to animate items on and off the page *and* you dont want it to flicker on load (whilst JS waits for the dom to be ready before then hiding your elements for use with JS)…

    One (bad) method would be to hide the elements using 'display none' in the CSS doc and then reveal the items when required but then this wouldnt work for non JS users, not atleast without a noscrpt tag to make sure these elements werent hidden with no JS.

    sooo….. :¬)

  • Loque says:

    Just found a solution, thanks to

    which linked me through to

    It also highlighted to me that you could fire off an event before the dom is ready anyway… and that this is probably the safest method for doing this(?). I love jQuery :¬

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.