Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop Paying Your jQuery Tax

samsaffron.com

Post reply on HN
Print view View original

51–60 of 90 posts

Re: Stop Paying Your jQuery Tax

#51

Post by sams99 »

ehynds wrote: post #50
sams99 wrote: post #49

Earlier quoted context omitted.

That is absolutely true, was looking at the cnn.com .. 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.

Where are you getting these numbers from?

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.

Re: Stop Paying Your jQuery Tax

#52

Post by oinksoft »

EGreg wrote: post #2

That is a great point! An interesting question is, why not just put ALL scripts at the end of the tag, after the HTML of the page has loaded and the CSS probably did as well? The only thing I can think of is if you have code ON the page which uses these scripts. But why not just put that code at the end of the page, too?

A strong reason to not do so is when you want some part of the page to be immediately enhanced with JavaScript (like a login form). If the page has many images and other resources, your users will have an awkward experience, with the scripts suddenly engaging at a time that feels arbitrary. While some scripts absolutely belong at the bottom of the page, it is a very good idea to decorate JavaScript widgets immediately after the HTML is rendered, as in:

  
  
      (function() {
          var widget = new Widget({
              el: document.getElementById('widget1234')
          });
          // ...
      })();
Note that the script is also inlined here: Losing the overhead of an HTTP request is beneficial when a widget needs to spring to life immediately: You want it to be active the moment the HTML is finished.

Re: Stop Paying Your jQuery Tax

#53

Post by alecco »

sams99 wrote: post #45
alecco wrote: post #37

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 do…

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.

"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".

Re: Stop Paying Your jQuery Tax

#54

Post by WayneDB »

alecco wrote: post #37

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 do…

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.

Re: Stop Paying Your jQuery Tax

#55

Post by _mfat »

sams99 wrote: post #49
ehynds wrote: post #48

Earlier quoted context omitted.

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.

That is absolutely true, was looking at the cnn.com .. 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.

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.

Re: Stop Paying Your jQuery Tax

#56

Post by sequoia »

I'm very confused... why aren't the scripts in the footer? Because of inline javascript? What problem is this solving? What does this have to do with jQuery in particular? I'm very confused...

Re: Stop Paying Your jQuery Tax

#57

Post by alecco »

WayneDB wrote: post #54
alecco wrote: post #37

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 do…

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…

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.

Re: Stop Paying Your jQuery Tax

#58

Post by untog »

riffraff wrote: post #36
sams99 wrote: post #20

Earlier quoted context omitted.

true, still verbose, but more elegant than the solution in asp.net mvc

out of sheer curiosity, what is the asp.net mvc solution?

It doesn't really have one. Annoying, because it's 90% of the way there- views can insert code into specific "sections" of the template, but sub-views can't.

If they just enabled that then you could make a "JS" section just before and have all your JS inserted there.

Re: Stop Paying Your jQuery Tax

#59

Post by alecco »

bmuon wrote: post #41

I think they're still missing the point. The idea is to stop using jQuery like that. Think of it as another required module of your application and move everything to requireJS. You'll gain speed and peace of mind once you learn to modularize all your JavaScript code.

That's yet another dependency. Not my cup of tea. I'd rather wait for the upcoming light/modularized jQuery rewrite.

Re: Stop Paying Your jQuery Tax

#60

Post by VMG »

bru wrote: post #24
radicalbyte wrote: post #22

If you're looking into these kinds of optimilisations then why not sidestep the problem by moving to a single page application model? Or is it still acceptable to support clients who do not enable javascript?

> Or is it still acceptable to support clients who do not enable javascript? I deeply believe that yes, it is. Making Javascript mandatory on websites where it should only enhance the user experience still seems to me like a very bad practice, and I hope it will stay so. I even want to say that, if your website if correctly designed, offering its content in a Javascript-less way should not be that hard...

> I deeply believe that yes, it is. Making Javascript mandatory on websites where it should only enhance the user experience still seems to me like a very bad practice, and I hope it will stay so. > I even want to say that, if your website if correctly designed, offering its content in a Javascript-less way should not be that hard...

This is problematic when JS is the user experience. Many modern applications are just brower/javascript clients on top of rest APIs.

Post reply on HN