I've just started moving my blog to Gatsby but have run in to a problem.
I have many markdown pages where I have javascript demos and I need to include the javascripts using <script src="..."> tags.
These don't seem to work which I'm guessing is because of the way Gatsby renders things.
Any ideas how I could make this work? It's going to be too much effort to go back and modify all these too much. They all require different versions of loads of different libraries.
For instance in one markdown post I need to include JQuery, part of three.js and two other scripts.
I did work out how to get the inline scripts working (https://stackoverflow.com/a/50336890/170239) but would be nice to be able to load externally too.
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'm using jquery and some ordinary javascript on my site and I've been told that I'd be better off loading all the javascript in a minimized form at the closing body tag of my pages rather than in the header as they are now.
I've also been told that I should clump all my JS together into one file to keep the number of requests down, although I've also been told there's some of my javascript which won't be able to be included in this mega file because it's needed by FB (for example).
So now I'm totally confused. For a start,
1) I use jquery and the jquery.ui, can these be lumped into the mega file and loaded at the end?
2) Can I just stick everything which currently appears in my page source surrounded by script tags into this file?
3) What must I leave out?
It's all a bit over-whelming when you're a learner
the site is at http://www.traditionalirishgifts.com/ as you can see I load:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/jquery-ui.min.js"></script>
as well as a heap of other javascripts
As the comments point out, the answer depends on many variables.
Are you using any server side web framework? Any web framework worth it's money will offer you options for javascript and css concatenation. Typically these options allow you to define how exactly you want the concatenation to happen. Certain js files will change infrequently, example jquery, jquery ui. Whereas certain other files will change frequently, example your own application scripts. All these can be taken into consideration when deciding on what to concatenate.
If you could share which server side technology and what web server are you using, I can help you find specific solutions.
With regards to your three questions, its all about managing your dependencies. If your application scripts or "whatever currently appears in my page source surrounded by script tags" depend on jQuery or any other library, then they will need to included AFTER jquery or said library.
Dependency could also exist wrt the DOM. If your scripts output html directly using document.write then you will not be able to move them around easily.
I went through the html of the homepage of the site you linked to. The js code in that file can be moved to just before the end of the body, though you will need to ensure they appear in the same order. All the plugins you have included they seem to initialize themselves on document.ready which occurs only after all the html/js/css is parsed.
You are already referencing jquery/jqueryui from a CDN, so don't add them to the concatenated file.
I did not notice any code that you wouldn't be able to concatenate (on account of using FB). That said you could ask the person, who told you that, to explain why.
Finally, you can read more about optimizing front-end load times on YSlow (http://developer.yahoo.com/performance/rules.html) and Google Page Speed (https://developers.google.com/speed/docs/best-practices/rules_intro)
Personally, I would suggest you go ahead and move everything to just before the end of body. If something breaks, then ask questions on SO specific to the errors you receive.
In my grails app, we use jquery. I include jquery on the necessary pages with
<g:javascript library="jquery"/>
If we decide to change javascript libraries, I need to update every page. I know I can include this in the layout, but the library is not needed on every page, so that seems wasteful.
Is there a typical way in grails to specify in one place what the default javascript library should be and then to just include that default one without specifying that it is jquery (or whatever it is) on every page?
Since most browsers heavily cache things like JavaScript libraries, putting the library include into the layout is probably better than putting it in each individual page. The heavy caching that browsers do means that users will only load the library from the server once for your whole site (or at least their browsing session), and by having it be handled in the layout you are drastically reducing your maintenance load (which you alluded to)
In general, your JavaScript libraries should be highly cached, and in many cases it's preferable to pull them from a highly used CDN, like Google's. Your "local" (ie. from your server) library should only get requested if the CDN provider goes down and the browser can't get to their library. (Take a look at the HTML5Boilerplate project for how this is done)
Because of that, I wouldn't worry about the very minimal performance hit that putting the library into the layout page would incur. Even if you don't use a well-used CDN for your library, any browser that people actually use today will only load your JavaScript library once (the first page it gets that includes it) and will simply use it's cached copy for the rest of the pages on your site.
So, in a nutshell, put it in the layout page and don't worry about it. It will only be requested on the first page load, and will come from the cache for all subsequent loads, and your codebase will be DRYer.
You could also create an external JS file that selectively loads the file(s) you specify. Something like this:
//FILENAME: jselector.js
if ( [conditions] ) {
var fileref=document.createElement('script');
fileref.setAttribute("type","text/javascript");
fileref.setAttribute("src", filename); //reference your Jquery file here
document.getElementsByTagName("head")[0].appendChild(fileref);
}
Then put a reference to this file (jselector.js) in each of the pages that need it.
<script type="text/javascript" src="jselector.js"></script>
If your jQuery file ever changes, you update this single external JS (jselector.js), and all of the pages will automatically point to the new jQuery.
Do you localize your javascript to the page, or have a master "application.js" or similar?
If it's the latter, what is the best practice to make sure your .js isn't executing on the wrong pages?
EDIT: by javascript I mean custom javascript you write as a developer, not js libraries. I can't imagine anyone would copy/paste the jQuery source into their page but you never know.
Putting all your js in one file can help performance (only one request versus several). And if you're using a content distribution network like Akamai it improves your cache hit ratio. Also, always throw inline js at the very bottom of the page (just above the body tag) because that is executed synchronously and can delay your page from rendering.
And yes, if one of the js files you are using is also hosted at google, make sure to use that one.
Here's my "guidelines". Note that none of these are formal, they just seem like the right thing to do.
All shared JS code lives in the SITE/javascripts directory, but it's loaded in 'tiers'
For site-wide stuff (like jquery, or my site wide application.js), the site wide layout (this would be a master page in ASP.net) includes the file. The script tags go at the top of the page.
There's also 'region-wide' stuff (eg: js code which is only needed in the admin section of the site). These regions either have a common layout (which can then include the script tags) or will render a common partial, and that partial can include the script tags)
For less-shared stuff (say my library that's only needed in a few places) then I put a script tag in those HTML pages individually. The script tags go at the top of the page.
For stuff that's only relevant to the single page, I just write inline javascript. I try to keep it as close to it's "target" as possible. For example, if I have some onclick js for a button, the script tag will go below the button.
For inline JS that doesn't have a target (eg: onload events) it goes at the bottom of the page.
So, how does something get into a localised library, or a site-wide library?.
The first time you need it, write it inline
The next time you need it, pull the inline code up to a localised library
If you're referencing some code in a localized library from (approximately) 3 or more places, pull the code up to a region-wide library
If it's needed from more than one region, pull it up to a site-wide library.
A common complaint about a system such as this, is that you wind up with 10 or 20 small JS files, where 2 or 3 large JS files will perform better from a networking point of view.
However, both rails and ASP.NET have features which handle combining and caching multiple JS files into one or more 'super' js files for production situations.
I'd recommend using features like this rather than compromising the quality/readability of the actual source code.
Yahoo!'s Exceptional Performance Team has some great performance suggestions for JavaScript. Steve Souders used to be on that team (he's now at Google) and he's written some interesting tools that can help you decide where to put JavaScript.
I try to avoid putting javascript functions on the rendered page. In general, I have an application.js (or root.js) that has generic functionality like menu manipulation. If a given page has specific javascript functionality, I'll create a .js file to handle that code and mimic the dir structure on how to get to that file (also using the same name as the rendered file).
In other words, if the rendered page is in public/dir1/dir2/mypage.html, the js file would be in public/js/dir1/dir2/mypage.js. I've found this style works well for me, especially when doing templating on a site. I build the template engine to "autoload" my resources (css and js) by taking the request path and doing some checking for the css and js equivalents in the css and js directories on the root.
Personally, I try to include several Javascript files, sorted by module (like YUI does). But once in a while, when I'm writing essentially a one-liner, I'll put it on the page.
Best practice is probably to put it on Google's servers.
(Depends what you mean by "your" javascript though I suppose :)
This is something I've been wrestling with, too. I've ended up by using my back-end PHP script to intelligently build a list of required JS files based on the content requested by the user.
By organizing my JS files into a repository that contains multiple files organized by purpose (be they general use, focused for a single page, single section, etc) I can use the chain of events that builds the page on the back-end to selectively choose which JS files get included based on need (see example below).
This is after implementing my web app without giving this aspect of the code enough thought. Now, I should also add that the javascript I use enhances but does not form the foundation of my site. If you're using something like SproutCore or Ext I imagine the solution would be somewhat different.
Here's an example for a PHP-driven website:
If your site is divided into sections and one of those sections is calendar. The user navigates to "index.phhp?module=calendar&action=view". If the PHP code is class-based the routing algorithm instantiates the CalendarModule class which is based on 'Module' and has a virtual method 'getJavascript'. This will return those javascript classes that are required to perform the action 'view' on the 'calendar' module. It can also take into account any other special requirements and return js files for those as well. The rendering code can verify that there are no duplicates of js files when the javascript include list is built for the final page. So the getJavascript method returns an array like this
return array('prototype.js','mycalendar.js');
Note that this, or some form of this, is not a new idea. But it took me some time to think it important enough to go to the trouble.
If it's only a few hundred bytes or less, and doesn't need to be used anywhere else, I would probably inline it. The network overhead for another http request will likely outweigh any performance gains that you get by pulling it out of the page.
If it needs to be used in a few places, I would put the function(s) into a common external file, and call it from an inline script as needed.
If you are targeting an iphone, try to keep anything that you want cached under 25k.
No hard and fast rules really, every approach has pros and cons, would strongly recommend you check out the articles that can be found on yahoo's developer section, so you can make informed decisions on a case by case basis.