Again, that's what people actually visit websites for -- "designers" often seem to lose sight of that with it becoming more important being flashy, than offering anything of substance... .It's like the "rage of the flashtards" from a few years ago where everyone and their brother seemed to be putting stupid flash animations on their pages as banners, or worse using flash to make menus, or even WORSE using flash to build the entire site and navigation. THANKFULLY that nonsense seems to be slowly going the way of the dodo, with the only holdouts being the ultimately useless video game title websites that usually are so useless, you just go to gamespot, ign, some fan run forums, etc... with the only other useless flash sites being a few brick and mortars for whom their web presence is an afterthought.
After all, there's a reason it's called Flash and not substance.
Though as you said, all the fancy stuff can either enhance the 'experience, or be detrimental to it. It's based on how much you use.
It's why I actually set 'target limits' on my code. Too many files ends up delaying the page regardless of said files sizes -- excessively large amounts of scripting slow down pageloads -- scripts that don't work until onload often make the page useless until they work, or WORSE just start the whole process of waiting for more crap to load start over again...
Simple limits... For the past eight years I've said "72k in 16 files ideal, 144k in 32 files maximum" as the 'limits' for templates I make -- without counting content images or objects (which if you're going to go over, that's where to do it!). That's for HTML+CSS+IMAGES+SCRIPTS total! If you can't make your template and text content fit those limits, there's probably something flawed with what you are trying to do.
There's a formula I also use for figuring out if a page's code 'sucks or not'. HTML on the whole SHOULD be predictable in it's file sizes; you only need so many tags for x amount of content, if you practice separation of presentation from content those tags average a certain size; the size of a well formed <HEAD> area should be relatively uniform and within certain limits, as well as the 'stock bits' of most sites in relation to the text content, number of content images, objects, etc...
I've been tweaking the formula for a while, making adjustments, and have slowly been putting together a PHP tool to try and automatically rank the markup of a website... Basically though it all comes down to the 'content to code' ratio.
A simplified version of which is simply:
2.5k + content plaintext*1.5 + 128 bytes per form element (INPUT, TEXTAREA, BUTTON) + 256 bytes per content image or object/video/whatever.
So for example, if you took JUST the text (without the tags) from a page that ends up 8k, and it has say... three actual content images (as opposed to presentational images, which have no business in the markup), and no videos or other objects... 2.5+12+1.5 == 16k. So such a page should only use 16k of HTML, give or take... which is why if it uses 50k of markup, something is WRONG.
For example, take the forum index here at sitepoint -- it's a vBulletin 4 skin so we KNOW the markup is rubbish... but really, how bad could it be?
Well, currently it's 143k... for plaintext I just load the page in Opera, hit CTRL-A, CTRL-C, open up notepad 2 and paste... and it says there's 15.7k of plaintext... counting through it I see 10 images I would consider content, ONE input (search), and no videos or objects (though my adblock might be omitting those)... by our formula:
2.5 + 15.7*1.5 + 2.5 + 0.25 = 28.8k -- so if it were coded with semantic markup and proper separation of presentation from content, there is little legitimate excuse for it to be more than that... Even if there's stuff we're not seeing, there is NO reason for it to be lowing an ungodly FIVE TIMES that!!!
Until you view source and see list abuse on tabular data, unneccesary wrappers, ENDLESS classes for nothing, and the whole host of other things that basically boil down to some back end coder thinking they knew anything about writing HTML/CSS. Even if I couldn't come close to my 'target' numbers above, I doubt I'd need more than 40k of code to deliver the exact same page with the same or better functionality.
Probably better since the menu dropdowns are broken. (though that could just be a problem with my user.css).
Now, if I ran my hokey little [EWI USB website through the same formula... it's homepage isn't quite as complex, but it's not exactly simple either given all the tricks used to pull off it's main header -- based on a [url=http://www.ewiusb.com/images/EWIUSBpromo.jpg]picture of the musical instrument](http://www.ewiusb.com) the site is about.
It has 4.3k of plaintext, and six content images. No form elements, objects or videos... So:
2.5 + 4.3*1.5 + 1.5 == 10.45k... so that's our ideal target. How big is the actual markup for that page?
10.7k -- only a hair over the estimate... and that hair over is from my using a dummy DIV to use opacity to create the shadow instead of just using box-shadow, because when I wrote that theme some... three years ago, I didn't consider CSS3 real world deployable yet.
A position I've since changed my opinion on.
In any case, it's why I laugh at the people who have the massively bloated markup, and then do idiotic nonsense like whitespace stripping/minification to it instead of fixing the rubbish markup; I'd ballpark that 90%+ of the time you see people wasting time and adding headaches to maintaining the page with methods like stripping out all the spaces, tabs, carriage returns and comments (something my formula generally allows for to), it's just to hide how bad their code really is -- rather than getting off their collective backsides and fixing it.