5 ms·

Please go check out StackOverflow's source code before bandwagoning on this topic. This is shifting blame to the tools. The problem lies on StackOverflow's lac

by alecco 15y ago

Please go check out StackOverflow's source code before bandwagoning on this topic. This is shifting blame to the tools. The problem lies on StackOverflow's lacking design and not in jQuery. Pushing jQuery to the bottom of the page is trivial if you do proper HTML architecture. Pages should have only HTML. JS files only JS. JS files referenced at the very bottom of the body. Very simple. (if your asp/c#/* framework doesn't make it easy, blame the framework and not jQuery) Inlining JS and even having JS code in the title attributes is ridiculous. Fix your HTML and only then you get the right to say anything. Another telling gem is StackOverflow page doesn't even have a proper encoding declaration. You don't need to use jQuery for everything. This is very typical of developers coming from backend who don't take web development seriously. Use CSS as much as possible. Another misplaced attack is refresh, with proper cache headers it should not take that long. If some browsers are slow and don't keep a pre-parsed cache, blame the browser vendor and not jQuery. jQuery taking 80ms on mobiles is quite OK. If you really care about mobile make a page optimized for mobile and minimize JS rendering and styling. I absolutely love StackOverflow and it's one of the best things to happen to programmers in the last few years. But this self-righteousness attack on a very important tool is very misleading and ungrateful. Edit: the proposed "solution" of catching $.ready and later calling those is insane.

marcofucci 15y ago
Agree, I use Django and I had no idea what they were talking about. They should check out other frameworks before writing posts with generic headlines.
sams99 15y ago
Let's be clear ... I am not attacking jQuery here, just saying it is misuse to chuck it in the header and offering a practical mechanism to get out of a mess you create. I explain the cost of placing it in the header. I am not perfect, I make mistakes daily, I try to learn.
- ehynds 15y ago
  You pointed out a few best-practices, but it's a shame that this article is written in the context of jQuery, rather than recognizing that these "taxes" are true with every script tag you place on your website.
  - sams99 15y ago
    That is absolutely true, was looking at the cnn.com .. http://z.cdn.turner.com/cnn/tmpl_asset/static/intl_homepage/657/js/intlhplib-min.js http://z.cdn.turner.com/cnn/tmpl_asset/static/intl_homepage/... which is in the header chews up 100k of compressed js. This monster must take upwards of 20ms to parse in chrome as well. Way worse in crappy browsers, the CDN network you need to support this is huge.
    - ehynds 15y ago
      Where are you getting these numbers from?
      - sams99 15y ago
        My laptop which could be a bit faster, the cold cache issue is the major issue though. Distributing a file this big in a scalable way without blocking requires a lot of servers.
    - pp19dd 15y ago
      In defense of sloppily composed news websites: they're not run like normal sites. Despite the obvious benefit of optimizing and cleaning up the site markup, it's quite normal and it's even encouraged to sacrifice optimization -- so that something would just work. Two main differences from normal sites are: (1) The sheer size of moving parts: number of hands that have a say in the site's daily operation Before anyone says "duh, well, get a handle on your site" you have to understand that news world is chaotic for the right reason: content flexibility and innovation. You can't put hundreds of ongoing creative and newsworthy projects on small development teams. That kind of open exploration belongs in hands of editors who specialize in their particular beats and are willing to pursue newsworthy projects (vendor or agency partnership, special reports, etc.) These people only understand rudimentary HTML but they have access to be dangerous. That's a good thing. More people that do this sort of thing is good for any news agency: it gives us a collective chance for any random project to be naturally selected by audience for success. Problem is how to corral various implementations, bandaids, and so forth to where it all works flawlessly. However, cutting off editors from being able to write markup is not the solution - and post-optimization regression testing is impossible due to sheer volume of content and creative projects. As long as something works within acceptable limits, it's fine. (2) Politics of how technology intersects with editorial and operations. There are invisible lines of power that outsiders don't see with news. Bureaucracy alone is tough to navigate, but, compartmentalization of editorial, technology, operations teams contributes to the problem. Most news agencies have been transformed over the decades (in some cases, centuries) and are pretty set in their ways. Explosion of internet technology has dramatically sped up this transformation process and it'll take some time to iron out. Good news? Rise of devops in the news biz is happening. Though I'm a fairly adept developer working for a news agency, I cannot update or fix our favicon file or optimize JS on the main page: for one, template control belongs to a different department that will prioritize their projects differently than I. Communication overhead is too large for small matters. In their defense, their lean team is supporting 50 languages, 1000-persons worth of editors and producers at this point. Secondly, even if something is simple to fix and done for the right reasons, navigating this field of artificial obstructions just to reduce page weight or load time doesn't justify me taking time off from working on my latest editorial project: there is a fast approaching relevance deadline on it.
- alecco 15y ago
  "Stop Paying Your jQuery Tax", that's an attention grabbing title with an attack on a free open-source project. It took you at least 20m to write that post, probably over an hour. You can't just say "oops".
  - eropple 15y ago
    I (not really a frontend web developer, though I've done a little bit of it) immediately went "oh, script loading in HEAD?" before even opening the article. Most people, at least in this neck of the woods, use jQuery. Most people also put it in the HEAD and are susceptible to this sort of thing. "jQuery tax" is a succinct way of describing the phenomenon, and nobody's going to suddenly think less of jQuery because of it. "An attack" on jQuery? Histronics.
  - bmelton 15y ago
    1) If it took him a month to write that article, he could still say 'oops'. He's entitled to err. 2) It seems like you're the only one interpreting his post as an attack on jQuery. It isn't. You said in another thread that English isn't your first language. I'd suggest you temper your accusations in light of that knowledge. 3) Even if he were bashing jQuery, and even though it is a good and widely used framework, that's his right to do. Yes, it is your right to cry foul, as it is my right to attempt to set you straight. Simply put, I think you're off the mark here. Your attack on him are more damning than his supposed attack on jQuery, and strikes me as defensive. In with the good air, out with the bad.
    - sequoia 15y ago
      >You said in another thread that English isn't your first language. I'd suggest you temper your accusations in light of that knowledge. As a native English speaker, I would like to point out that alecco is _correct_ when he interprets the article as slinging mud at jQuery; there is nothing wrong with his/her English vis-a-vis his interpretation of this article's title. The fact that you would tell him/her to pipe down because he's not a native speaker is disgusting and xenophobic. As a side note, your comment about alecco being "the only one" interpreting the post as attack on jQuery is completely false. S/he's dead on about it being what I call a DCA, or "deliberately contentious assertion", designed to win more page views than an article merits. Honestly, if alecco were expressing an opinion with which you agreed, would you still be saying s/he 'just doesn't understand the article due to poor language skills'? Or do you reserve this treatment for those foreigners who dare disagree with you? The fact that you dug thru alecco's comments in other threads to find this ad-hominem rock to sling... the reason you had to mention his/her non-native speaking comment from another thread is because alecco's English is good enough that you wouldn't know s/he's a non-native speaker from this thread. Non-English natives are allowed to have opinions at variance with your own, sir or madam. Leave
deleted 15y ago
[deleted]
WayneDB 15y ago
Did we read the same article? I didn't see this as an attack on jQuery at all. Furthermore, he didn't even blame any tools! He blamed the platform because as usual, the web platform itself is indeed the problem. "...developers coming from the backend who don't take web development seriously." That's because client side web development is a joke. It's a really bad one too compared to a nice native kit. The people who come up with all the silly ways of turning a fracking Hyper-TEXT system into an applications platform should be shot. I'm kidding about shooting anyone, but honestly - it's horrible how many hoops you have to jump through. HTML is the worst thing that's ever happened to software development. The Internet is TCP/IP, it's not HTML and personally, I want for something better every day and I know you do to because all you web developers are always, always, always complaining about something. "self-righteousness attack on a very important tool is very misleading and ungrateful" Once again, self-righteous? Sorry, I just don't see it. He wasn't even blaming the jQuery guys for one single thing. This kind of problem could happen with any large Javascript library that runs in the browser. The proposed solution is not insane if you don't want to make your server framework do more work. There's absolutely nothing wrong with making code run in the browser so that you don't have to do something on the server. You need to get off your high horse buddy.
- alecco 15y ago
  I hate the whole web paradigm but it's what's in use and it's definitely improving. And in particular, jQuery makes it less painful so that's what many of us use (or similar JS frameworks). The same problem happens at the low end with the x86 instruction set. Yet we live with it. None of that makes it OK to write a bashful title that should've read "Stop paying your ASP MVC JS tax" or something. It all comes down on how they need to have inlined JS requiring $(document).ready(). That's the problem and not jQuery.
  - astine 15y ago
    'None of that makes it OK to write a bashful title that should've read "Stop paying your ASP MVC JS tax" or something. ' "Bashful" means "shy," not "full of bash," as you seem to think. Actually, I wonder if you speak English natively as you seem to be the only person who interpreted the article the way you did.
pragmatic 15y ago
>> Please go check out StackOverflow's source code before bandwagoning on this topic. Please read the article before replying.
- alecco 15y ago
  If you read my comment you'll see I addressed exactly the topics (document ready and caching).
mhansen 15y ago
Another telling gem is StackOverflow page doesn't even have a proper encoding declaration. They declare the encoding in the HTTP Response. Content-Type:text/html; charset=utf-8 That's totally proper. If you specify it again inside the HTML, are you gaining anything?
- alecco 15y ago
  It's not wrong by itself, but making content encoding implied might become an issue later (e.g. load balancers or CDN, merging content or improving support on east-asian languages). It's likely they've never faced those kind of issues.
  - acdha 15y ago
    Again, it's not implied when you state it categorically in headers. If there's a CDN or load balancer out there which breaks your Content-Type headers it's much, much better to replace it with something which follows HTTP a bit closer.
    - alecco 15y ago
      Very often you don't have control over that. It might be managed by a different team of the organization or might be a poor product purchased by higher management. Or it could be a third party service. You have to code defensively.
      - acdha 15y ago
        Rest assured, I've been in that sort of situation. However I've never found it viable long term to take on additional complexity rather than pushing back against a group which is obstructing progress - ultimately you're accepting more work and risk to help reduce the pressure on them to stop underperforming.
sams99 15y ago
Re "Pages should have only HTML. JS files only JS. JS files referenced at the very bottom of the body. Very simple." I suggest you view the source of http://api.jquery.com/ready/ http://api.jquery.com/ready/ before making that assertion. If it was that simple why is the website providing documentation for jQuery not doing so?

by alecco 15y ago

marcofucci 15y ago

Agree, I use Django and I had no idea what they were talking about. They should check out other frameworks before writing posts with generic headlines.

sams99 15y ago

Let's be clear ... I am not attacking jQuery here, just saying it is misuse to chuck it in the header and offering a practical mechanism to get out of a mess you create. I explain the cost of placing it in the header. I am not perfect, I make mistakes daily, I try to learn.

ehynds 15y ago
You pointed out a few best-practices, but it's a shame that this article is written in the context of jQuery, rather than recognizing that these "taxes" are true with every script tag you place on your website.
- sams99 15y ago
  That is absolutely true, was looking at the cnn.com .. http://z.cdn.turner.com/cnn/tmpl_asset/static/intl_homepage/657/js/intlhplib-min.js http://z.cdn.turner.com/cnn/tmpl_asset/static/intl_homepage/... which is in the header chews up 100k of compressed js. This monster must take upwards of 20ms to parse in chrome as well. Way worse in crappy browsers, the CDN network you need to support this is huge.
  - ehynds 15y ago
    Where are you getting these numbers from?
    - sams99 15y ago
      My laptop which could be a bit faster, the cold cache issue is the major issue though. Distributing a file this big in a scalable way without blocking requires a lot of servers.
  - pp19dd 15y ago
    In defense of sloppily composed news websites: they're not run like normal sites. Despite the obvious benefit of optimizing and cleaning up the site markup, it's quite normal and it's even encouraged to sacrifice optimization -- so that something would just work. Two main differences from normal sites are: (1) The sheer size of moving parts: number of hands that have a say in the site's daily operation Before anyone says "duh, well, get a handle on your site" you have to understand that news world is chaotic for the right reason: content flexibility and innovation. You can't put hundreds of ongoing creative and newsworthy projects on small development teams. That kind of open exploration belongs in hands of editors who specialize in their particular beats and are willing to pursue newsworthy projects (vendor or agency partnership, special reports, etc.) These people only understand rudimentary HTML but they have access to be dangerous. That's a good thing. More people that do this sort of thing is good for any news agency: it gives us a collective chance for any random project to be naturally selected by audience for success. Problem is how to corral various implementations, bandaids, and so forth to where it all works flawlessly. However, cutting off editors from being able to write markup is not the solution - and post-optimization regression testing is impossible due to sheer volume of content and creative projects. As long as something works within acceptable limits, it's fine. (2) Politics of how technology intersects with editorial and operations. There are invisible lines of power that outsiders don't see with news. Bureaucracy alone is tough to navigate, but, compartmentalization of editorial, technology, operations teams contributes to the problem. Most news agencies have been transformed over the decades (in some cases, centuries) and are pretty set in their ways. Explosion of internet technology has dramatically sped up this transformation process and it'll take some time to iron out. Good news? Rise of devops in the news biz is happening. Though I'm a fairly adept developer working for a news agency, I cannot update or fix our favicon file or optimize JS on the main page: for one, template control belongs to a different department that will prioritize their projects differently than I. Communication overhead is too large for small matters. In their defense, their lean team is supporting 50 languages, 1000-persons worth of editors and producers at this point. Secondly, even if something is simple to fix and done for the right reasons, navigating this field of artificial obstructions just to reduce page weight or load time doesn't justify me taking time off from working on my latest editorial project: there is a fast approaching relevance deadline on it.
alecco 15y ago
"Stop Paying Your jQuery Tax", that's an attention grabbing title with an attack on a free open-source project. It took you at least 20m to write that post, probably over an hour. You can't just say "oops".
- eropple 15y ago
  I (not really a frontend web developer, though I've done a little bit of it) immediately went "oh, script loading in HEAD?" before even opening the article. Most people, at least in this neck of the woods, use jQuery. Most people also put it in the HEAD and are susceptible to this sort of thing. "jQuery tax" is a succinct way of describing the phenomenon, and nobody's going to suddenly think less of jQuery because of it. "An attack" on jQuery? Histronics.
- bmelton 15y ago
  1) If it took him a month to write that article, he could still say 'oops'. He's entitled to err. 2) It seems like you're the only one interpreting his post as an attack on jQuery. It isn't. You said in another thread that English isn't your first language. I'd suggest you temper your accusations in light of that knowledge. 3) Even if he were bashing jQuery, and even though it is a good and widely used framework, that's his right to do. Yes, it is your right to cry foul, as it is my right to attempt to set you straight. Simply put, I think you're off the mark here. Your attack on him are more damning than his supposed attack on jQuery, and strikes me as defensive. In with the good air, out with the bad.
  - sequoia 15y ago
    >You said in another thread that English isn't your first language. I'd suggest you temper your accusations in light of that knowledge. As a native English speaker, I would like to point out that alecco is _correct_ when he interprets the article as slinging mud at jQuery; there is nothing wrong with his/her English vis-a-vis his interpretation of this article's title. The fact that you would tell him/her to pipe down because he's not a native speaker is disgusting and xenophobic. As a side note, your comment about alecco being "the only one" interpreting the post as attack on jQuery is completely false. S/he's dead on about it being what I call a DCA, or "deliberately contentious assertion", designed to win more page views than an article merits. Honestly, if alecco were expressing an opinion with which you agreed, would you still be saying s/he 'just doesn't understand the article due to poor language skills'? Or do you reserve this treatment for those foreigners who dare disagree with you? The fact that you dug thru alecco's comments in other threads to find this ad-hominem rock to sling... the reason you had to mention his/her non-native speaking comment from another thread is because alecco's English is good enough that you wouldn't know s/he's a non-native speaker from this thread. Non-English natives are allowed to have opinions at variance with your own, sir or madam. Leave

deleted 15y ago

[deleted]

WayneDB 15y ago

Did we read the same article? I didn't see this as an attack on jQuery at all. Furthermore, he didn't even blame any tools! He blamed the platform because as usual, the web platform itself is indeed the problem. "...developers coming from the backend who don't take web development seriously." That's because client side web development is a joke. It's a really bad one too compared to a nice native kit. The people who come up with all the silly ways of turning a fracking Hyper-TEXT system into an applications platform should be shot. I'm kidding about shooting anyone, but honestly - it's horrible how many hoops you have to jump through. HTML is the worst thing that's ever happened to software development. The Internet is TCP/IP, it's not HTML and personally, I want for something better every day and I know you do to because all you web developers are always, always, always complaining about something. "self-righteousness attack on a very important tool is very misleading and ungrateful" Once again, self-righteous? Sorry, I just don't see it. He wasn't even blaming the jQuery guys for one single thing. This kind of problem could happen with any large Javascript library that runs in the browser. The proposed solution is not insane if you don't want to make your server framework do more work. There's absolutely nothing wrong with making code run in the browser so that you don't have to do something on the server. You need to get off your high horse buddy.

alecco 15y ago
I hate the whole web paradigm but it's what's in use and it's definitely improving. And in particular, jQuery makes it less painful so that's what many of us use (or similar JS frameworks). The same problem happens at the low end with the x86 instruction set. Yet we live with it. None of that makes it OK to write a bashful title that should've read "Stop paying your ASP MVC JS tax" or something. It all comes down on how they need to have inlined JS requiring $(document).ready(). That's the problem and not jQuery.
- astine 15y ago
  'None of that makes it OK to write a bashful title that should've read "Stop paying your ASP MVC JS tax" or something. ' "Bashful" means "shy," not "full of bash," as you seem to think. Actually, I wonder if you speak English natively as you seem to be the only person who interpreted the article the way you did.

pragmatic 15y ago

>> Please go check out StackOverflow's source code before bandwagoning on this topic. Please read the article before replying.

alecco 15y ago
If you read my comment you'll see I addressed exactly the topics (document ready and caching).

mhansen 15y ago

Another telling gem is StackOverflow page doesn't even have a proper encoding declaration. They declare the encoding in the HTTP Response. Content-Type:text/html; charset=utf-8 That's totally proper. If you specify it again inside the HTML, are you gaining anything?

alecco 15y ago
It's not wrong by itself, but making content encoding implied might become an issue later (e.g. load balancers or CDN, merging content or improving support on east-asian languages). It's likely they've never faced those kind of issues.
- acdha 15y ago
  Again, it's not implied when you state it categorically in headers. If there's a CDN or load balancer out there which breaks your Content-Type headers it's much, much better to replace it with something which follows HTTP a bit closer.
  - alecco 15y ago
    Very often you don't have control over that. It might be managed by a different team of the organization or might be a poor product purchased by higher management. Or it could be a third party service. You have to code defensively.
    - acdha 15y ago
      Rest assured, I've been in that sort of situation. However I've never found it viable long term to take on additional complexity rather than pushing back against a group which is obstructing progress - ultimately you're accepting more work and risk to help reduce the pressure on them to stop underperforming.

sams99 15y ago

Re "Pages should have only HTML. JS files only JS. JS files referenced at the very bottom of the body. Very simple." I suggest you view the source of http://api.jquery.com/ready/ http://api.jquery.com/ready/ before making that assertion. If it was that simple why is the website providing documentation for jQuery not doing so?