SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 78

Hybrid View

  1. #1
    SitePoint Evangelist cgacfox's Avatar
    Join Date
    Feb 2005
    Location
    Colorful Colorado
    Posts
    412
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Just read this....place JS code before footer instead of in head tag...

    Now don't say OMG where have you been and you call yourself a web designer?!?!?

    I am constantly trying to improve my skills and read lots of different books....including a lot from here and different forums and lots of different sites on the subject! I am currently working on a WP site for a client and I am not too familiar with WP yet. It seems pretty straight forward...create the page in HTML and CSS and then cut it up for WP using PHP. However, I am also reading that for SEO and general purposes it is best to put any JS running on the page down before the footer or maybe it was just before the closing body tag instead of at the top in the head tag. Is this really true and how to do others feel about this? If I have an image slider that will be in the header section, will this still be something I should consider doing?

  2. #2
    SitePoint Guru bronze trophy TheRaptor's Avatar
    Join Date
    Jul 2011
    Location
    New York
    Posts
    710
    Mentioned
    40 Post(s)
    Tagged
    0 Thread(s)
    Most front end developers are advocating this practice. Me included!

    In theory it speeds up your page by allowing the content to load first and the JS later. I've found that in the tests I've done, my pages render noticeably faster with JS at the bottom.

    There really is no need to have any JS load before the content anyways.
    TheRaptor - Joe

  3. #3
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,314
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)

  4. #4
    SitePoint Evangelist cgacfox's Avatar
    Join Date
    Feb 2005
    Location
    Colorful Colorado
    Posts
    412
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Cool thanks for the info. I will place the JS at the bottom of the page that will have the image slider. Good to know this for future sites as well. See you CAN teach an old dog new tricks!

  5. #5
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    In terms of actual load times, it does NOT make it faster; it's a placebo effect because SOME browsers will render the DOM as it becomes available, so you'll see content rendering sooner... sad part is, it actually takes LONGER because if you put it in HEAD the script can start loading in the background... but that delays how long it takes for the page to start rendering in some browsers.

    It's much akin to how Opera feels slow to some people despite actually finishing loading the page faster... This illusion occurs because Opera doesn't redraw the window arbitrarily after every piece of information, but instead waits for certain things to finish (DOM complete, all CSS) or for a timer to expire (Tools -> preferences -> advanced -> browsing, under "loading" there's a SELECT, typically set to 'every one second') before attempting a reflow/redraw... so while it's physically faster, the lack of showing you it's doing anything makes it feel like it takes longer. (this was more true when Opera's default for that was every three seconds!). It's funny in that case because if you set Opera to a high 'redraw' delay like every 5 seconds, the page loads significantly faster, but it feels like it takes forever because you don't actually see it doing anything.

    Perception is everything.

    Though really, if you have enough script for being in <head> or being right before </body> makes a difference, you probably have too much scripting... like say some idiotic framework like jQuery or mooTools.

    There is one REALLY good reason though for running scripts manually right before </body> -- the DOM is completely built at that point so if you run any scripts that would change the DOM, those changes can occur before CSS is applied to the page... this reduces the "flash of unstyled content" (aka FOUC) that can occur if you want for "onload" to fire... doing this I usually load the script in head, then manually call a 'startup' function right before </body>. Actually loads faster while reducing FOUC.

  6. #6
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,314
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    In terms of actual load times, it does NOT make it faster; it's a placebo effect because SOME browsers will render the DOM as it becomes available
    You're correct that total load times generally won't be faster, but the majority of what your users came to see -- your content -- will be available sooner. That's a good thing. Plus, let's not disregard the placebo. If users perceive faster performance, they'll have a better experience. e.g., http://stevesouders.com/hpws/move-scripts.php

    Also, your emphasis on "some" browsers is misleading. The overwhelming majority of the browser market share -- IE, Firefox, Chrome and Safari -- will render the DOM as it becomes available. Opera may be the only exception, at a mere 2% market share.

    Quote Originally Posted by deathshadow60 View Post
    sad part is, [scripts at the bottom] actually takes LONGER because if you put it in HEAD the script can start loading in the background... but that delays how long it takes for the page to start rendering in some browsers.
    Sorry, but this part is flatly untrue. The total load times will be largely the same.

    I'm assuming you're thinking that the time taken to redraw the page is what would make scripts at the bottom slower. But either the process doesn't play out like you think, or the redraw time just isn't significant enough to matter, because when you actually measure load times, scripts at the bottom comes out equally fast or faster.

    Quote Originally Posted by deathshadow60 View Post
    Though really, if you have enough script for being in <head> or being right before </body> makes a difference, you probably have too much scripting... like say some idiotic framework like jQuery or mooTools.
    The best JavaScript programmers around -- such as those at Mozilla, Yahoo, and Google -- advocate JS libraries. So at minimum, you should tone down the inflammatory rhetoric. And if you choose to go a step further... when the best JavaScript programmers disagree with you, it's probably worthwhile to reconsider your opinion. Make sure you can explain the opposing arguments just as its advocates would.

  7. #7
    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 Jeff Mott View Post
    You're correct that total load times generally won't be faster, but the majority of what your users came to see -- your content -- will be available sooner. That's a good thing. Plus, let's not disregard the placebo. If users perceive faster performance, they'll have a better experience.
    I wasn't necessarily saying it was a bad thing... as I said, perception is EVERYTHING... and if that means making it slower while people THINK it's faster, more power. User feedback is all important, part of why X11 and most *nix desktops running atop it are so uselessly crippled -- you can't even get the cursor to update when a program is loading, so by the time you figure out it actually did start loading something you've launched five copies.

    Quote Originally Posted by Jeff Mott View Post
    Also, your emphasis on "some" browsers is misleading. The overwhelming majority of the browser market share -- IE, Firefox, Chrome and Safari -- will render the DOM as it becomes available. Opera may be the only exception, at a mere 2% market share.
    Actually FF and Chrome will start trying to download them too -- but they won't process them until everything else is done OR (and here's the kicker) you call a function from inside them. Moment you call a function the browser doesn't know, it starts fishing through all the available scripts or those you've tried to load.

    Quote Originally Posted by Jeff Mott View Post
    Sorry, but this part is flatly untrue. The total load times will be largely the same.
    Depends on how many files you have and their sizes -- browsers can download four to eight files from each server referenced on a page -- the earlier you start those extra downloads, the sooner you'll have all the files downloaded.

    Though, eys -- gecko and trident still have their heads wedged up their backsides about starting those extra downloads as soon as they can -- which is why they both are where FOUC is the biggest headache.

    Quote Originally Posted by Jeff Mott View Post
    The best JavaScript programmers around -- such as those at Mozilla, Yahoo, and Google -- advocate JS libraries.
    Yeah, and they're pissing all over the Internet in the process with fat bloated slow rubbish sites filled with needlessly cryptic and harder to maintain code. jQuery in particular has reached epic proportions of idiocy in it's use on just about every site that does so -- which is why the Internet IMHO is less useful to me today than it was a decade ago.

    From 10k + the library to do what 5k of script without the library could accomplish, to websites with half a megabyte of scripting just to make the page HARDER to use -- it's time for the various little js kiddies out there to be reminded scripting should be used to enhance functionality, not replace it. When we have people vomiting up megabyte sized websites where the images are only a quarter of that just to deliver 2k of plaintext and a dozen content images, it's time to just say NO to frameworks.

    Off Topic:


    This is your site:


    This is your site on jQuery:


    Any questions?

  8. #8
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,314
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    ...and if that means making it slower while people THINK it's faster, more power.
    The important distinction in this case, however, is that scripts at the bottom can actually make your page faster. Not just perceptively, but also objectively. This decision should be a no-brainer.

    Quote Originally Posted by deathshadow60 View Post
    [load times will be largely the same] Depends on how many files you have and their sizes -- browsers can download four to eight files from each server referenced on a page -- the earlier you start those extra downloads, the sooner you'll have all the files downloaded.
    No, it doesn't depend on any of those things. You're talking as if the browser will sit around and wait unless the scripts are at the top. That doesn't make any sense. If your scripts are at the top, then the scripts will download first. And if your scripts are at the bottom, then your images and content will download first. At no point are you delaying downloads.

    Quote Originally Posted by deathshadow60 View Post
    Yeah, and they're pissing all over the Internet in the process with fat bloated slow rubbish sites filled with needlessly cryptic and harder to maintain code. jQuery in particular has reached epic proportions of idiocy in it's use on just about every site that does so -- which is why the Internet IMHO is less useful to me today than it was a decade ago.

    From 10k + the library to do what 5k of script without the library could accomplish, to websites with half a megabyte of scripting just to make the page HARDER to use -- it's time for the various little js kiddies out there to be reminded scripting should be used to enhance functionality, not replace it. When we have people vomiting up megabyte sized websites where the images are only a quarter of that just to deliver 2k of plaintext and a dozen content images, it's time to just say NO to frameworks.
    Several issues here:

    1. You're putting too much emphasis on file size. The great thing about performance research is that it tells us where the bottlenecks are, and HTTP requests are the biggie. It's pretty common for the browser to spend 80% of its time just waiting for a connection, and only 20% actually downloading data.

    2. You consider jQuery cryptic and hard to maintain... that's fine, that's a valid opinion. All I can say here is that almost everyone disagrees. They think jQuery makes code incredibly easy to write and read. That's why it's caught on.

    3. You seem to be thinking of websites with either annoying or poorly implemented features, and casting the blame on jQuery. I think that blame is misdirected. If I found a junky website that didn't use jQuery, should I conclude that JavaScript is to blame? Of course not. There exists, and always will exist, bad programmers, and bad programmers will write bad code whether they use jQuery or not. But good programmers who use jQuery do so because it lets them write simpler, shorter code.

    It's probably fair to say that libraries like jQuery make good programmers better, and bad programmers worse.

  9. #9
    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 Jeff Mott View Post
    No, it doesn't depend on any of those things. You're talking as if the browser will sit around and wait unless the scripts are at the top. That doesn't make any sense. If your scripts are at the top, then the scripts will download first. And if your scripts are at the bottom, then your images and content will download first. At no point are you delaying downloads.
    Unless you are running something in the scripts that manipulate the DOM or add/remove content/classes, etc... which most scripting nowadays tends to do... I think that's the difference... if you're just loading scripts for... well, the sake of loading scripts, then maybe. Splitting hairs really -- if it feels faster to users to put them in BODY, we should put them in BODY for that reason alone.

    Quote Originally Posted by Jeff Mott View Post
    1. You're putting too much emphasis on file size. The great thing about performance research is that it tells us where the bottlenecks are, and HTTP requests are the biggie. It's pretty common for the browser to spend 80% of its time just waiting for a connection, and only 20% actually downloading data.
    Preaching to the choir on that one. 200ms 'real world' average per file request, only 4 to 8 at a time for overlap, and on crappy connections it can be as much as two seconds; Trust me, I regularly visit Coos County NH where 33.6 dialup is the fastest connection available at ~1200ms ping times. Can't even get wireless phone coverage. It's why I advocate NOT using endless mutliple scripting files and combining them down before deployment, and using image recombination techniques like the incorrectly named "CSS Sprites".
    Off Topic:


    Always feels like a dream when I get home to 22mbps at 100ms ping to most of Europe and 500ms+ to chicagoland. (that whole new england backbone divide thing -- faster 3000+ miles across the pond and to all of Canada than I am to Boston which is only 110 miles away).


    Quote Originally Posted by Jeff Mott View Post
    2. You consider jQuery cryptic and hard to maintain... that's fine, that's a valid opinion. All I can say here is that almost everyone disagrees.
    Yup, and it makes me wonder just what the devil is in that kool aid.... Maybe it's that three decades plus of writing software, much of it in interpreted languages that drilled home the concept that libraries in an INTERPRETED language, much less one reliant on a narrow pipe, is a REALLY BAD IDEA.

    Off Topic:

    Or that I'm a Wirth language fan, and as such HATE unnecessarily cryptic code. Why I think Rust, Ruby, and a whole host of other languages are idiotic nonsense; Hell, I'd rather hand assemble 8k of RCA 1802 machine language and enter it 8 bits at a time on toggle switches than deal with 100 likes of C code for the same reason; pointlessly and needlessly cryptic... and when it's pointlessly cryptic compared to machine language, why bother even having the high level one?


    Quote Originally Posted by Jeff Mott View Post
    But good programmers who use jQuery do so because it lets them write simpler, shorter code.
    Which is funny because I've rarely actually seen that -- usually it's bigger with jquery, but that's typically because the people who use it then rant and rave about nonsense like "don't use WITH" or "objects for EVERYTHING". Either that or it's stupid annoying animooted nonsense that shouldn't even be on the website in the first blasted place and just pisses me off as a user. Really that's about the only thing jquery allows coders to do faster/smaller; annoying animated nonsense that just gets in the way of delivering CONTENT.

    Quote Originally Posted by Jeff Mott View Post
    It's probably fair to say that libraries like jQuery make good programmers better, and bad programmers worse.
    I'd say it makes them both worse -- because I've yet to see a website not made worse by it's very presence.

  10. #10
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,904
    Mentioned
    74 Post(s)
    Tagged
    6 Thread(s)
    Why not use the wealth of tools which are available to visually see the results of including stuff in the header or just before </body>

    Also use a subdomain for loading particular scripts or images - this has the effect of displaying the page then filling in the blanks.

    http://tools.pingdom.com/
    Learn how to be ready for The New Move to Discourse

    How to make Make Money Now with a *NEW* look

    Be sure to congratulate Wolfshade on earning Member of the Month for August 2014

  11. #11
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,314
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by John_Betong View Post
    Why not use the wealth of tools which are available to visually see the results of including stuff in the header or just before </body>

    Also use a subdomain for loading particular scripts or images - this has the effect of displaying the page then filling in the blanks.

    http://tools.pingdom.com/
    A very good suggestion.

    http://tools.pingdom.com/fpt/#!/e6Ld...pws/js-top.php

    http://tools.pingdom.com/fpt/#!/B8w8.../js-bottom.php

    Scripts at the bottom is both perceptively faster and objectively faster.

  12. #12
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,904
    Mentioned
    74 Post(s)
    Tagged
    6 Thread(s)
    @Jeff Mott

    Thank you and also for enlightening me as to how to use the image expire. Maybe now I will be able to match your "Perf grad". Yours is 100% - pure magic

    HTML Code:
     <img src="/bin/sleep.cgi?type=gif&sleep=2&expires=-1&last=0&imagenum=2&t=1331922946" height=20>
    Learn how to be ready for The New Move to Discourse

    How to make Make Money Now with a *NEW* look

    Be sure to congratulate Wolfshade on earning Member of the Month for August 2014

  13. #13
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    I have to agree with Jeff on this one.

    I've defended jQuery many times (primarily against DS), but here it goes again. Yes, there are a tons of bad developers that include jQuery into projects that are other 10KB of code because it's the cool thing to do (or something). That is ridiculous.

    However, if you are writing a lot of Javascript (like for a web app), jQuery can tremendously cut down on the amount of code you have to write.

    For example, take these:
    [code]
    // Normal JS - 33 characters
    document.getElementById('book');

    // jQuery - 12 characters
    $('#book');
    [code]

    With just that simple operation, jQuery saved me 11 characters. jQuery is currently 31KB compressed and gzipped. That's roughly equivalent to 31,000 characters. It'd only take 1477 of these calls to make jQuery be a file size saver.

    Yes, you wouldn't do 1477 of this type of operation normally, but there are tons of different ways that jQuery makes things shorter. In a library that would normally be something like 100KB, that could be cut in half by using jQuery, with the added benefit of very reliable cross-browser functions.

    As for Javascript being in the body, from all the tests I've seen it is definitely a good idea. It may cause your Javascript to finish up a bit slower, but your clients will see the page sooner. Hopefully you aren't using much Javascript to change appearance of things, so most people will never notice. If you needed, you could also split it up so you load the DOM-changing stuff in the header and the interaction in the body.

    As for Yahoo, while I've never been a fan of their site, they're developer stuff seems to be pretty good (at least the high-performance research stuff... I'm not sold on the YUI or OOCSS).

  14. #14
    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
    I'm not sold on the YUI or OOCSS.
    Two examples of which would convince me to not even LOOK at anything else they offer... one being more fat bloated idiocy, both boiling down to the use of presentational markup and completely missing the entire point of HTML and CSS.

  15. #15
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    I actually agree with that. There is no "accessible" animation. If an animation is accessible, it's accessible because it was accessible before the animation, and the animation just happens to not break it. Likewise, most decorative animations are more annoying then helpful.

    I'm not as hard lined. There are a few animations that are fine (a 200ms sliding animation isn't horrible). Some can even be good for user interaction (for example, a slide show which animates the slides as sliding lets the user know which direction they're going). But they do add a lot of JS fluff that could otherwise be avoided. On a typical website, they're usually like using a rocket launcher to go deer hunting... overkill.

    Also, with the high performance stuff from YDN... I verified the effects more myself by tracking the data as we made changes. =p They're all pretty good, and most are common sense.

  16. #16
    SitePoint Wizard
    Join Date
    Dec 2003
    Location
    USA
    Posts
    2,582
    Mentioned
    29 Post(s)
    Tagged
    0 Thread(s)
    I've not heard of jQuip before. I think I'll look into it. It's true that jQuery has been bulking up a bit since it's initial releases. It'd be nice to see a modular approach. I've noticed that outside of the selectors, I use only a very very small portion of the jQuery library. I'd wager I use less than 10KB of it (uncompressed).

    13ms is a really small number, and probably unrealistic for most people. I'm smack dab in the middle of Silicon Valley and I can get those speeds, even on my phone. But even still, it's sometimes spotty (we have really good 4G in some places, but go walk a couple of blocks and you're lucky to have net at all). I know that not everyone has those kinds of speeds. They are improving, but we aren't there yet. Using "well it's fast" as an excuse for not keeping sites as small as responsibly possible is a weak excuse.

    (That said, I am still a big fan of jQuery and I think it's actually a space saver in many necessarily JS-heavy projects.)

  17. #17
    <title class="lol"> bronze trophy TehYoyo's Avatar
    Join Date
    Feb 2012
    Location
    Northeast Chicago Suburbs
    Posts
    806
    Mentioned
    18 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by samanime View Post
    13ms is a really small number, and probably unrealistic for most people. I'm smack dab in the middle of Silicon Valley and I can get those speeds, even on my phone. But even still, it's sometimes spotty (we have really good 4G in some places, but go walk a couple of blocks and you're lucky to have net at all). I know that not everyone has those kinds of speeds. They are improving, but we aren't there yet. Using "well it's fast" as an excuse for not keeping sites as small as responsibly possible is a weak excuse.
    Exactly. Just because you can doesn't mean you should. I think what we're all saying is that jQuery should be used effectively and sparingly, and always with good cause.

    ~TehYoyo

  18. #18
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Some unrealistic thoughts in this thread, as far as jQuery is regarded.

    About resource demand
    Mobile use number one is media. As in movie clips, music, games. I think it's safe to say jQuery is far less demanding and it's better suited for mobile then those. For reluctant spirits, there are efforts to cater the mobile even further: http://jquerymobile.com/.

    About download size
    jQuery, as file size, is no bigger than a regular small image. There is no real gain in restraining this download.

    About bandwidth
    There are repositories, like Google's, that make caching jQuery a viable solution across the globe. Download once from a site and you're good to go for thousands more.


    It's in the hands of the developers, and in the minds of the potential adopters. It has nothing to do with ISPs, mobile devices, cables, malware (BTW Mallory, you should check for that). jQuery exists, it is used extensively, and it doesn't hurt anyone when used, human or electrical device. Unless you get a headache from a stubborn piece of code and you smash the device apart.

    DISCLAIMER No user will be hurt during your use of jQuery.


    PS There are those claiming jQuery is overkill: "I can make what you want w/o jQuery and in 2.6 lines of code". Who cares? Who needs your Norton Commander clone for DOS anymore? Everybody else is using Total Commander, xplorer2 and such. Efficient and productive code will always be codependent. It's not about reinventing the wheel each time you want to go for a ride.

  19. #19
    <title class="lol"> bronze trophy TehYoyo's Avatar
    Join Date
    Feb 2012
    Location
    Northeast Chicago Suburbs
    Posts
    806
    Mentioned
    18 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by itmitică View Post
    DISCLAIMER No user will be hurt during your use of jQuery.
    That's an absolute statement and highly inadvisable to use at any point in your life.

    I could hurt a user with my use of jQuery. What if I went jQuery crazy and started animating everything so that each word was actually an image in a slideshow? That would kill accessibility and usability.

    ~TehYoyo

  20. #20
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,761
    Mentioned
    12 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TehYoyo View Post
    That's an absolute statement and highly inadvisable to use at any point in your life.

    I could hurt a user with my use of jQuery. What if I went jQuery crazy and started animating everything so that each word was actually an image in a slideshow? That would kill accessibility and usability.

    ~TehYoyo
    I don't know why the nitpick is occuring but it depends on what kind of "hurt" he meant. Physical harm over Jquery is impossible.
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  21. #21
    <title class="lol"> bronze trophy TehYoyo's Avatar
    Join Date
    Feb 2012
    Location
    Northeast Chicago Suburbs
    Posts
    806
    Mentioned
    18 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by RyanReese View Post
    I don't know why the nitpick is occuring but it depends on what kind of "hurt" he meant. Physical harm over Jquery is impossible.
    Maybe there's so much jQuery that your computer overheats and catches on fire!

    ~TehYoyo

  22. #22
    billycundiff{float:left;} silver trophybronze trophy RyanReese's Avatar
    Join Date
    Oct 2008
    Location
    Whiteford, Maryland, United States
    Posts
    13,761
    Mentioned
    12 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TehYoyo View Post
    Maybe there's so much jQuery that your computer overheats and catches on fire!

    ~TehYoyo
    That's fire harming you. Not Jquery. Jquery is just pixels/binary code. Virtual.

    Oddz basically summed up what my reply to you was going to be though .
    Always looking for web design/development work.
    http://www.CodeFundamentals.com

  23. #23
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,194
    Mentioned
    17 Post(s)
    Tagged
    4 Thread(s)
    jQuery is a tool just like HTML, CSS or plain JavaScript. Everything can be misused. Blaming worthless animation on jQuery is like bashing someones face with a hammer and blaming it all on the hammer. That is how ridiculous and misinformed that statement is!
    The only code I hate more than my own is everyone else's.

  24. #24
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,194
    Mentioned
    17 Post(s)
    Tagged
    4 Thread(s)
    So much jQuery… geesh you really need to have some experience with JS before commenting about how useless it and various libraries are…

    There a lot of problems with JavaScript in it's purest form. Just about all libraries help to close that gap and actually make it elegant to work with. Repeating the same normalization logic over and over and over is not an efficient way to program. Libraries make it so you don't have to do that. Yeah, they throw some extra bells and whistles but the advtanges far outweigh the disadvantages in my opinion and apparently a lot of other people agree…

    You'll understand once you need to deal with heavy AJAX, event driven, dom manipulation applications which yes – gracefully degrade.
    The only code I hate more than my own is everyone else's.

  25. #25
    <title class="lol"> bronze trophy TehYoyo's Avatar
    Join Date
    Feb 2012
    Location
    Northeast Chicago Suburbs
    Posts
    806
    Mentioned
    18 Post(s)
    Tagged
    1 Thread(s)
    I didn't want to get into a flame war :P I was just taking the side that was less defended for fun.

    ~TehYoyo


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
  •