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.
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.
Comments
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:
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.