I'm a new player in Meteor, just did some easy examples and I realized that all the script tags are imported in the beginning of the body tag. According to my experience and yahoo's 14 rules, js files should be imported in the end, Why is that? And in what circumstances js files should be imported in the beginning?
In traditional websites, where the HTML is sent as-is from the server, placing external Javascript files near the bottom of the <body> tag speeds up the page rendering and improves user experience because the static page, along with it's included external assets such as images, is loaded and rendered before the scripts finish loading.
In Meteor however, the HTML is built by Javascript in the client's browser, so all the scripts need to be loaded for the page to render anyway. Moreover, usually there is basically nothing other than scripts in the <body> of a Meteor app's HTML source anyway.
Related
I have web application with multiple views that share the same JavaScript but every view also have its own Javascript. It looks something like:
<!-- html up here -->
<script src="/src/js/bundle.js"></script>
<script>
// some view-specific Javascript
</script>
This ended up mixing my view file (HTML, etc) with my javascript and I'm not sure if creating and loading and external javascript file for each view is a better way.
What is the best approach to achieve do this?
A lot of it depends on how big your page specific js files are. If they are fairly small and most of the useful js is in your bundle, just make one bundle for all pages. If you have a lot of page specific js, you can either just include a second file along with your bundle, or you can create a different bundle for each page so that you only have on script tag on each page. Here is another thread on the issue, including a useful gulp script to automate the creation of multiple bundles
I am trying to make my Meteor App work. It needs to use some of the Google libraries. In particular, these two:
https://apis.google.com/js/client.js?onload=loadGooglePlatformLib
https://apis.google.com/js/platform.js
My understanding is that these aren't available as a Meteor package yet. I tried the following approaches:
(1) Putting these in the head section of a layout. However, every time the layout is rendered (which is for all of my templates), these files are reloaded causing latency.
(2) I tried a dynamic load via $.getscript (of Jquery). However, despite using overridable cache options that this can be wrapped with, there's a reload of these files here as well.
Can someone advise what may be the best way to achieve loading of these library files without avoiding the reloads I experience each time?
Thanks
np
What I do is put my head section in a separate file, such as client/main.html, which only contains the head for my app:
<head>
<script src="//apis.google.com/js/platform.js"></script>
</head>
To my knowledge, this method doesn't reload files at every template rendering, only when refreshing the page.
I am new to web development and building a C# web MVC application in Visual Studios. I am using Jquery,AngularJS,Twitter Bootsrap CSS and a bunch of other 3rd party JavaScripts.
I have included reference to all these files on every page which looks very nasty. I am using a master layout page for all the other pages so I thought that referencing everything that is required would resolve my problem but that didnt work out.
How can I store all the required scripts and css in one place and have all web pages get everything from there?
Make sure you have a layout that is used very every page, and make sure that layout is calling a header. Then throw your script files in there.
Although I would suggest against loading ALL your javascript files for ALL of the pages, you might take a performance hit once you scale upward. You can put checks in your header to filter the ones you need.
I recently got into RequireJS and am integrating it into my backbone applications.
I noticed when looking at the source code that all individual javascripts are replaced by the bootstrap file, the line that reads:
<script data-main="js/main" src="js/require.js"></script>
And this line prevents me from viewing the attached files.
Does this mean that users are unable to hack their way into my external source code files if I load all scripts through the bootstrap file?
I am mostly concerned because I use a restful api route in my Backbone collections, and want to keep user data safe.
Thanks.
No, it doesn't mean that. It just means that scripts are loaded dynamically. Anybody can still download your JS files or look at them with any web debugging tool
I've been doing a little JavaScript (well, more like jQuery) for a while now and one thing I've always been confused about is where I should put my scripts, in the <head> tag or in the <body> tag.
If anyone could clarify this issue, that'd be great. An example of what should go where would be perfect.
Best practices from google and yahoo say that, for performance, javascript should always be put in an external file, and linked to your page with a <script> tag located at the bottom of the html, just before the closing of the <body> element.
This allows the browser to render the entire page right away, instead of stopping to evaluate javascript.
You mentioned three places:
In tags;
In the HTML; and
In an external file.
Let me address each of those.
Best practice is to have common Javascript in one or more external files and the less files the better since each JS file loaded will block loading of the page until that JS file is loaded.
The word "common" is extremely important. What that means is you don't want to put page-specific Javascript code in that external file for caching reasons. Let's say you have a site with 1000 pages. Each page has JS code specific to it. That could either be 1000 different files or one really big file that executes a lot of unnecessary code (eg looking for IDs that aren't on that particular page but are on one of the 999 others). Neither of these outcomes is good.
The first gives you little caching boost. The second can have horrific page load times.
So what you do is put all common functions in one JS file where that JS file only contains functions. In each HTML page you call the JS functions needed for that page.
Ideally your JS files are cached effectively too. Best practice is to use a far futures HTTP Expires header and a version number so the JS file is only loaded once by each browser no matter how many pages they visit. When you change the file you change the version number and it forces a reload. Using mtime (last modified time of the JS file) is a common scheme, giving URLs like:
<script type="text/javascript" src="/js/script.js?1233454455"></script>
where that mtime is automatically generated. Your Web server is configured to serve JS files with an appropriate Expires header.
So that mixes external files and in-page scripts in (imho) the best way possible.
The last place you mentioned was in the tag. Here it depends somewhat on what JS libraries and frameworks you use. I'm a huge fan of jQuery, which encourages unobtrusive Javascript. That means you (hopefully) don't put any Javascript in your markup at all. So instead of:
do stuff
you do:
do stuff
with Javascript:
$(function() {
$("#dostuff").click(doStuff);
});