What's wrong with YOUR website - Part 3, JavaScript
3.1 JavaScript Libraries
Being an interpreted language that is bandwidth restricted, the use of massive code libraries to 'simplify' writing pages is the antithesis of efficient coding.
Worse, so much of what people outright waste JavaScript on destroys accessibility, or is simply stupid animated nonsense that makes sites harder to use or take longer to load, longer to use, and just in general get in the way of users.
The "king" of this type of nonsense is of course jQuery -- the laugh being that most of the stuff people do with jQuery really has no business on a website, and the rest tends to be stuff that would be smaller and more efficiently coded WITHOUT IT. Much as I see no benefits to HTML 5, the handful of tiny benefits offered by jQuery are vastly outweighed by the disadvantages of extra file handshakes, slow page loads, processing overhead and delayed rendering of the page, and taking something simple -- delivery of content -- and making it several times more complicated than need be. By itself COMPRESSED jquery is half the size I allow for an entire page template -- that's HTML + CSS + SCRIPTS + IMAGES... and uncompressed it is many times larger than that. When you end up with 50 to 200k of code on a website before you even start plugging content into it, YOU'RE DOING IT ALL WRONG!!!
... and that goes for most every page that uses jQuery, Mootools, protalicious, etc, etc... they are all pointless bloated trash that does more to destroy the usability of a website than to help it. Some make it even worse by combining CSS frameworks with it -- like YUI does. That's even dumber since not only do you have pointless JavaScript bloat, you're also defeating the entire purpose of using CSS in the first place. (as CSS frameworks by their very nature rely on presentational classes).
3.2 Javascript for Nothing
.js for nothing and your scripts for free. That ain't working, that's not how you do it. Lemme tell you these guys ARE dumb. I want my... I want my... I want my PHP.
Quite often these days I'm seeing people wasting tens or even hundreds of K of scripting on pages where I'm stuck asking "FOR WHAT?!?" -- sometimes it's for things I wouldn't waste more than two or three lines of CSS on, sometimes just "pageloads are evil" idiocy, other times it boils down to outright ignorance of what should be handled server-side and what should be handled client-side... More often than not as I said under Section 3.1, it is just for goofy animated crap that does NOTHING to make the page easier to use.
3.3 AJAX replicating frame behaviors
There is this crazy idea right now we're seeing of people being obsessed with the idea of 'pageloads being evil' and how AJAX is being used for things like tabbed navigation or to avoid redrawing/resending markup. MAYBE if your markup wasn't a fat bloated steaming pile of crap it wouldn't be an issue.
Almost universally the people pulling this particular stunt have that fat bloated code I mentioned above with endless pointless wrapping div, endless pointless unnecessary classes, scripting libraries, and a whole host of other things that really should be pitched in the trash. THEN they go and throw even MORE pointless code at it to... wait?!? SAVE BANDWIDTH?!? Sorry, when you have a fat bloated slow poorly written website, THROWING MORE CODE AT It IS NOT THE ANSWER!!!
AJAX can be really useful, but it is NOT the be-all end-all solution and quite often pisses all over accessibility, functionality, ability to be indexed properly by search engines, and a whole host of other shortcomings. If you are writing a genuine application akin to Google Maps or Google Docs, knock yourself out. Same goes for things like convenient submits of posts to forums or responses to blog topics. But if you're just writing a flat website of normal content, all you are doing is wasting code on a total non-issue and destroying the accessibility, functionality and speed of your website.
Really if you have so much 'extra markup' around your content that wasting a hundred K or more on AJAX and scripting is 'saving' you anything over a full page-load, your code is absolute rubbish that probably needs to be started over from scratch. It's the equivalent of treating someone who jumped on top of a live grenade with Band-aids and Bactine.
Admittedly, I say the same thing about whitespace stripping and script compression -- if you see measurable benefits from it, you've probably got rubbish code. At best it's a lame way to squeeze performance out of bad code, at worst it's sweeping deep rooted issues under the rug.
3.4 JavaScript doing CSS' job!
One of the best examples of this is generated by my favorite punching bag -- Dreamweaver. Specifically I'm referring to the mm_swap javascript that uses a mess of scripting, typically inlined in the markup, that is basically a presentational effect -- a hover state... this is something CSS can do without any script, and typically does BETTER since you can use things like the incorrectly named "CSS Sprites" to reduce the number of handshakes.
Another example is dropdown menus... as 'cool' as javascripted animations might seem at first glance, the fact is it just gets in the way of the user getting to the options, and it's a mess of code for something that CSS can again do without any scripting assistance. (or at most a bit of scripting assist for IE6/lower). This is made all the worse by most scripted menus (much like their flash counterparts) are an accessibility train wreck when scripting is unavailable -- be it from device capabilities or from intentionally having it blocked.
... and a LOT of users are intentionally blocking scripts, see the popular 'noscript' plugin or Opera's in-built per-page script blocking.
There are a great number of things that people seem to throw javascript at that CSS or even just HTML on it's own can accomplish, making such code nothing more than pointless bloat.
3.5 Static scripts inlined in the markup
If a script is the same on every page of your site, putting it in the markup means it has to be transmitted every time you access a page -- even the same page if the contents are updated frequently (like on a forum index). Putting it into an external file allows it to be cached across page loads reducing the bandwidth and loading faster overall, even if it does introduce a minor delay during first-load. Usually that first-load penalty is better addressed by NOT using a dozen separate script files, a dozen separate CSS files, or dozens and dozens of images to do the job of a fraction that.
3.6 Tracking Scripts
The past five to six years really people have become ridiculously obsessed with tracking information. Much like the nonsense spewed forth by SEO scam artists, it often ends up the equivalent of pouring shellac over a pile. No matter how much you polish it...
The biggest problem comes about when people start running MULTIPLE tracking scripts -- I've seen several times now people who go "why does my site load so slow" when the problem was that they were running three, four or even five different tracking packages. What makes that truly laughable is that the majority of information these tracking systems provide should already be available from tools that go through your server logs. That's why I don't run JavaScript based tracking packages and do not advise others to waste their time doing so.
If you REALLY want more information, use just ONE -- probably Google Analytics -- but to be frank, if you are worrying about more information than can be gleaned from log analysis tools like Webalizer or Analog, you're probably wasting time worrying about data that has NOTHING to do with the health of your website... and that's time better spent making unique content of value so there's a REASON for people to visit.
3.7 Supplanting form functionality
This is the biggest no-no you'll find, and you see people doing it all the time. There is RARELY any legitimate excuse for a form to not function when javascript is disabled. Done properly for things like forms or even navigation, javascript should enhance your functionality, NOT replace it! If you have become so reliant on javascript that your forms don't work without it, you've probably also not built them all that securely with the proper checks server side. Make it work without scripting FIRST, then decide if you want to add any scripted "gee ain't it neat" stuff on top of it.
Vary from that and you're pissing away any chance of accessibility, probably opening security holes if you're not paying enough attention to server side handling, and possibly making it take MORE bandwidth (despite wild claims to the contrary made by script-tards) as you spend more bandwidth sending the extra code than you would if the form was built properly and clearly labeled.
Counterpoint
Now keep in mind I'm NOT saying don't use javascript -- but like most of the things you can add to a website it should be used with an eyedropper, not a firehose. Don't use it for nothing, don't use it just to be 'flashy and cool', and don't use it to replace functionality you can provide without it... You'd think that would be common sense, but apparently it isn't.
