SitePoint Sponsor

User Tag List

Page 4 of 4 FirstFirst 1234
Results 76 to 78 of 78
  1. #76
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    I don't understand why more blame is put on the developer than the hardware.
    You know, I could REALLY agree with that, except that in the back of my head I'm going "Yeah, but I used to be able to browse the web WITH a lot of this fancy stuff a decade ago on less powerful hardware"...

    There's this whole trend of turning Knuths "premature optimization is the root of all evil" into "optimization is the root of all evil" -- a sort of missing the message; You just have to travel into the PHP section of these forums or look at the majority of stuff written in jquery to see this in action... There's this pervasive attitude of "just throw more hardware at the problem" across all of IT -- Moore's law likely being the biggest contributor; but Moore's law is breaking down as the "clock speeds pushing into microwave frequencies" limit and manufacturing process limits have shown the past five years... where instead of doubling we've seen maybe 40%?

    The use of Moore's "hardware doubles quickly" has been used as an excuse to justify bad coding, bad practices and outright bloated garbage for about a decade now, and it gets worse year by year... to the point where -- again -- I'm a little annoyed that most websites today don't run as well on a 2.93ghz i7 870 with 16 gigs of RAM at 22mbps as they did a decade ago on a 1ghz thunderbird at 3mbps or eighteen years ago on dialup on a 486/66 running Windows 3.1.

    You want to impress me, make your stuff lean and fast -- You want to see me and many others bounce because we're sick of broken/bloated/idiotic crap blowing megabytes on delivering the 4k of plaintext we're actually after... go ahead, put jquery on EVERYTHING, let the PSD jockeys piss all over the page with their fixed widths and fixed heights, continue to use outdated coding methodologies or worse, the re-introduction of that pointless code bloat from HTML 5, and all the other idiotic bull that just gets in the WAY of delivering content to users.

    @itmitica -- you made some good examples of where scripting makes sense and SHOULD be used; I'm ok with it there though again, I still say MOST of that sort of thing would be smaller/faster WITHOUT jquery... That's examples of where scripting makes SENSE. The problem is people seem to be throwing scripting at EVERYTHING for little good reason -- jquery just exacerbates that problem since it's a fat bloated library of crap that by itself is 3/7ths COMPRESSED of what I would allow for an entire page template (HTML+CSS+SCRIPTS+IMAGES)...

    Really if you have a normal page of 4-8k of plaintext, 6 to 8 content images... and that's about it for CONTENT, there is no reason for your total HTML+CSS+SCRIPTS+presentational IMAGES (notice the distinction between content images and presentational here) to break 70k, with 140k being the upper limit I'd ever allow. With an ideal of 70k, that 32k compressed before you even do anything useful piddles away the ability to do anything else useful with the page.

    Which is why I say if you need more than 15k of uncompressed javascript for 'your own stuff' (not counting poorly coded garbage like 'active' social media), and you aren't doing something like google maps or a true application -- you're probably destroying your own site.... and since jquery is by itself double that COMPRESSED...

    But that plays to my attitude in regard to white-space stripping and script compression... 99% of the time it seems to be done to hide garbage code instead of just using minimalist practices in the first place.... true for javascript, double for CSS, quadruple that for HTML. If your page is so piss poor coded that white-space stripping is 'necessary' for bandwidth concerns, you probably screwed up somewhere.... No, make that EVERYWHERE. I love how people sleaze out fat bloated pages any old way, then think some rubbish 'compressor' is going to make things any better for them. Laughably pathetic. Especially on HTML where even after compression many people STILL end up with CtC ratios in excess of 10:1.

    I think one of the reasons all this nonsense grinds my gears is I've been on a retrocomputing kick and thinking back to the past... In the mid 90's I was VP of IT at one of the six corporate offices of a major national insurance chain. (Don't take that vice presidency too seriously, they handed out VP's the way the Army does enlisted ranks.... here's a promotion and a pay increase to try and make sure you re-enlist --- please ignore how badly we abused you at your former rank.... until your military consists of 5 Sergeants to every Private). At that time we had a 500 user license netware 3.12 server, 486/66 handling around 15,000 record requests from ~100 users every fifteen minutes... each record averaging ~3k. Even on that limited hardware it was plenty responsive...

    Think about that -- that was over 1mbps, with a mix of coax (10b2) and twisted pair (10bt), and about half the machines were remote booting off that 486... The database was written in borland paradox so the scripted parts were interpreted...

    So why in blazes does a forums that manages around 100 users active in a 15 minute period (instead of lying about users online by tracking for an hour or more, right Sitepoint?) on mySQL and PHP which are supposedly SO much more advanced with their 32 and/or 64 bit goodness choke out a dual multi-ghz XEON?!?

    Oh, wait... I know...

    http://www.sitepoint.com/forums/forum.php
    693k in 31 files... that's 50k of HTML, 16k of images, 426k of scripts (FOR WHAT?!? that the server has to spend time compressing to 126k), 157k of CSS (FOR WHAT?!?) that the server wastes time compressing to 28k... all to deliver what? What?

    6.41k of plaintext -- RIGHT. Oh, but the problem is likely with the mysql server... RIGHT...

    In other words the job of 10 to 15k of HTML, 16k of images, 30 to 50k of CSS for the entire forums, and even with all the fancy crap being done MAYBE 30 to 50k of javascript... all those figures UNCOMPRESSED. Lord knows I can bring SMF in under those numbers with room to spare.

    Noah: What's going on? How come you want me to do all these weird things?
    God: I'm going to destroy the world!
    Noah: Right.... Am I on Candid Camera?

  2. #77
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    That was an exceptionally great piece DS, and I agree with everything you just said.

    (However, I still like my cached whitespace stripping for jS and CSS, just because it's that little extra inch. =p)

    I definitely think you are right about people getting "premature optimization" and "optimization" mixed up, and are doing neither. I think that's why we see all of these crazy things like 40 separate scripts being loaded for pages. Even if every last character of that Javascript was necessary, there is absolute no reason you can't combine that in to 1 script to reduce all of those extra HTTP requests. It's things like that where you realize people either don't know what they are doing, or just don't care.

  3. #78
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by samanime View Post
    It's things like that where you realize people either don't know what they are doing, or just don't care.
    ... and there's WAY too much of the latter; in particular people calling what has been considered good coding practices of the past three decades to be "an unnecessary waste of time and effort". A lot of the code I'm seeing today feels like it harkens back to the days where coders charged for products by the K-LoC.

    For you kids who've never heard of K-LoC (No, not K-Tel, K-LoC) it means "Thousand Lines of Code" -- back in the days when Cobol and Fortran were bleeding edge languages, DEC programmers were doing everything in DiBol, Clipper/dBase was commonplace and developers even were releasing business apps written in ROM BASIC (no, that's not a joke) developers would actually quote and bill the price of software by the K-LOC. You'd ask "How big a project is that" and the response would be "Oh, that's a 5 to 6 K-Loc project"...

    Which is of course when developers started writing really slow software by putting comments on every other line to pad how much they got paid.

    Such practices were typical of the "back room UNIX geek" and other "big iron" world, and were frowned upon by those involved in what started out as the hobbyist/enthusiast side of things that pretty much BURIED Mainframes by driving the real computer revolution of the 80's and early 90's... I suppose I shouldn't find it too surprising that with *NIXisms having been on the rise the past decade, that sooner or later all the other bad practices and attitudes would follow suit... it's just disturbing to see all the old nonsense back with such a vengeance.

    Now it's like people are just sleazing out the sloppy code any old way not to pad it, but just to get by on as little effort as possible while preying on the ignorance of the suits in the process. At least back when people crapped out code to pad the length artificially they put effort into doing so.

    Off Topic:

    Just remembered my first paycheck for computer work, I took a 10000+ line database system that stored everything as strings, and reduced it to 2000 lines of code that stored strings as strings and numbers as 32 numbers.... breaking the numeric data out to a fixed record/index with pointers to a separate storage for strings. Only 3000 or so lines we're 'unneccessary' comments (which I put in a separate text file with line number references).... Rest of it was just bad code like checking the same condition over and over, performing the same math over and over inside said conditionals, etc, etc... Sped up requests from taking 30 seconds to taking 2 seconds.

    Idiocy like: (to borrow from some PHP I just cleaned up for someone)

    Code:
    if ($row['section']=='balls') && ($row['item']=='bocce') && ($row['count']>$hx-2) {
    	/* do something */
    } elseif ($row['section']=='balls') && ($row['item']=='basketball') && ($row['count']>$hx-2) {
    	/* do something */
    } elseif ($row['section']=='balls') && ($row['item']=='baseball') && ($row['count']>$hx-2) {
    	/* do something */
    } elseif ($row['section']=='balls') && ($row['item']=='soccer') && ($row['count']>$hx-2) {
    	/* do something */
    } elseif ($row['section']=='balls') && ($row['item']=='football') && ($row['count']>$hx-2) {
    	/* do something */
    } elseif ($row['section']=='balls') && ($row['item']=='beach') && ($row['count']>$hx-2) {
    	/* do something */
    }
    and I can hear some people going "what's wrong with that?"

    Code:
    if ($row['section']=='balls') && ($row['count']>$hx-2) {
    	switch ($row['item']) {
    		case 'bocce':
    			/* do something */
    		break;
    		case 'basketball':
    			/* do something */
    		break;
    		case 'baseball':
    			/* do something */
    		break;
    		case 'soccer':
    			/* do something */
    		break;
    		case 'football':
    			/* do something */
    		break;
    		case 'beach':
    			/* do something */
    		break;
    	}
    }
    ... and the person I showed that to called it premature optimization? Not worth the effort? WHISKEY TANGO FOXTROT!?!

    No wonder most of the code out there performs worse that what we had decades ago on less hardware... when even simple 'no effort' optimizations like using single quotes instead of doubles in php or commas instead of string addition on ECHO either aren't taught, explained, or just "Wah, wah, way, it's too much effort" to NOT hit the shift key or slide over one character on the keyboard...


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •