Hacker News Reader

Comment by redguava | Hacker News Reader

"External JavaScript files in <head> – All of those JavaScript files nested inside the <head> tag, further delaying the start of page rendering."

Sometimes the head is the best place to put the javascript. I didn't look into what javascript they are loading there, but there are times the user experience is improved by it.

View on HN

They could be using http streaming, like the feature introduced in rails 3.1 : http://weblog.rubyonrails.org/2011/4/18/why-http-streaming/

That actually makes <head> the preferred place for loading scripts.

Also, I find it a bit extreme to recommend putting inline javascript in a <script> tag. I'm ok with trying to maximize performances, but please, do not recommend to produce un-seperated and unclean code. Concatenating javascript in a single file (and compressing it) is way enough, having one single request to get all javascript is not so bad.

I think he meant something like:

    <script><%= File.read("file.js") %></script>

Not that they should literally move the script inline.

In which case loading the scripts async would be the right thing to do. Early loading, but non render-blocking http://www.whatwg.org/specs/web-apps/current-work/multipage/...

What's unseparated about it? Maintenance doesn't have to be performed on the rendered final product. Template systems and processing pipelines are pretty common for letting devs keep code structured in useful ways while still allowing for optimal end results.

For example?

What if you are displaying different elements based on the users location/country (eg. currency, contact details), and you use javascript to detect and do this.

You wouldn't want the page to load first and then this appear.

So you would delay the whole page just because of some location specific elements? How about render what you got first so the user has something to look at and then fill in your specific bits later?

Possibly. I am just saying that you might have things that are more important to do before the page loads that might warrant putting it in the head. It's not a set rule that javascript in the head is always bad, you just need to know the tradeoff and make a decision.

@redguava ...but you can't come up with a single example?

@jaffathecake I supplied a single example. Also, you might have a very javascripty web application that the users will have had the files cached 99.9% of the time so retrieving the files isn't an issue.

For example, setting up event delegation on enhanced elements is best done in the HEAD before the elements load. If you setup all your user-event listeners in the bottom of BODY then your users will have a short time when they'll be interacting with elements which A) will do the non-enhanced behaviour B) do nothing whatsoever. Neither A nor B is ideal.

Nah, have a small inline script that records events and replays them to your full script when it loads.

Or, if something only works with js, don't show it until the scripts have loaded, but let plain content load & render in the meantime.

Yeh, both viable solutions. Tbh, I can't think of any other reason to have JS in the HEAD.

Google Analytics is generally the only JS I put in the head. If some code is absolutely required for the page to work though then it may make sense to put it ahead of the content.

Sometimes you render content with JavaScript and want to avoid FOUC(Flash Of Unstyled Content) also sometimes you have JavaScript polyfills that you want loaded as soon as possible.

But I assume that in Apple's case, they are doing it even when they shouldn't be.

Reply on news.ycombinator.com