We Keep Coding

one external JavaScript file combine with multiple html pages

I'm working on a project that needs to have a header in all pages, I decided to use php for that and I have an external one JavaScript file. My problem is when the changed content on the html page page JavaScript start running function on that page, but it should not. I am interested how using one JavaScript file on multiple html pages, but there is no conflict. There is a solution to get around this, but it's not good. Plus I have light and dark mode on html pages, so I do not think it's good to create more JavaScript files with the same code :) thanks

minifying js & css with one min file for each jsp page

I have around 5 major JSPs in my website. Each jsp includes multiple js and css files. I want to minify both the js and css, with one js&css per JSP.
All the plugins which are available speaks about one js & css for entire website, but I would rather want is to have one js/css per JSP. Otherwise on home page loading itself, it would download the full js/css which I donot want.
Can any one please suggest any solution for the same.
Thanks,
Harish

If those files are just static, then it's better to just pack them into one CSS and one JS. That way, the next few pages will only load the cached versions. But yes, you can still do packing per JSP for ligher pages especially for mobile.
As for tools, there are a lot. YUI Compressor and Google Closure Compiler are usually top picks.

Include separate CSS and JS files into the header OR all code in one CSS and one JS file?

I'm trying to optimize my website. I have a few plugins to include (jquery plugins with CSS), and my own javascript code.
Now I have the CSS in separate files for different plugins, as I downloaded them. And if I need one on the actual page, I generate code to include that. The same with the JS files. But when it comes to render a complex page with a lot of stuff, 9 CSS files can be called and 7 or 8 JS files, each of which are HTTP requests.
Should I put the CSS into one big file to reduce the number of included CSS files? But then everything will be interpreted by the browser even if the current page doesn't need so much stuff.
I've thought of a third way: generate CSS and JS files with PHP. Then it'll be always one JS and one CSS file, and only with the things which are needed. Or is it an absurd way?
What do you say, which to use to reduce page load time?

It is better to include all CSS in a file and all JS in a file and the minify them using many online services that minify and compress CSS and Javascript. this will reduce the number of http requests as well as volume of data to be downloaded.
If you generate CSS with php then the CSS and JS should be downloaded with every page and generating them takes some time, but if you pack them in one file it downloads once and the browsers caches it.
if your site has many different sections and packing all css in a file makes a huge file then you can pack CSS in two or three file and in each section load the related one.
reducing number of http request is very important.

I think your last solution is the best one.
Generate one js file and one css file from php, and don't forget to minimized/gziped them :)
Here is a very good article about optimization : http://developer.yahoo.com/performance/rules.html

This depends largely on how your users use your page. If most of the users just view one page then it makes sense to only send them the stuff that they need to display that one page (combining everything into as few requests as possible). On the other hand if most of users view multiple pages then it makes sense to send them more than they need so they will already have the CSS&JS on the next page view. But in this case you have to make sure that you are always generating the same CSS&JS with the same URI, so that the browser will not re-download the same content under a different name. You also have to setup proper HTTP caching.
What I usually do is split JS/CSS in two parts. Every page has a "common.css" and "common.js", which has stuff that every page needs (header/footer/... styles for CSS, and then jquery/common js/... for JS). Then every subpage has it's own JS&CSS that has just the stuff you need for that page (if required).

For me, the best way is somewhere in the middle - for CSS files, you better grab them all, join and compress to one file. For JS code - make for example 3+ files: one with compressed and joined external libs, one with your common stuff, and maybe next files for each bigger section - but I dont think its needed. Maybe splitting your JS code on part needed before user login, and after user login.
Remember to minify and consider asynch loading (with LAB.js for example).
Oh, and this php script... I dont think it is good idea - better use/write some script which joins and minifies your statics on compile (or deploy, or even run by hand), so there is no need to generate everythin over and over again.

How to setup a dynamic website with javascript only (no serverside)

Here's my problem: I want to build a website, mostly static but with some dynamic parts (a little blog for news, etc..).
My webserver can only do static files (it's actually a public dropbox directory!) but I don't want to repeat the layout in every html page!
Now, I see two possible solutions here: either I create an index.htm page that emulates site navigation with javascript and AJAX or I create all the different html pages and then somehow import the layout bits with javascript..
From you I need ideas and suggestions on how to implement this, which libraries to use, or maybe there exists even something tailored exactly for what I need?
Thanks!!

I would define the site layout in your index.html file, and then use JavaScript and Ajax to load the actual content into a content div on the page. That way your content files (fetched by Ajax) will be more or less plain HTML, with CSS classes defined in index.html. Also, I wouldn't recommend building a blog in pure HTML and JavaScript. It wouldn't be very interactive; no comments, ratings, etc. You could store your blog content in XML and then fetch and display it with Ajax and JavaScript, however.
While on the subject of XML, you could implement all your site content in XML. You should also store the list of pages (for generating navigation) as XML.

Just another one way. You can generate static HTML in your computer and upload result to dropbox. Look at emacs muse.

jQuery allows you to easily load a section of one page into another page. I recommend loading common navigation sections into the different pages, rather than the other way around to avoid back/forward problems. Layout can be done with a separate CSS file rather than with tables to minimize the amount of repeated code. For the blog, you could put each blog entry in a separate file and load each section individually.
However, I would just use something already available. TiddlyWiki, for example, is a self-contained wiki that is all in one file. It's very customizable, and there's already a blog plug-in available for it. You can work on the site on your hard drive or USB drive, and then you can upload it to the web when done. There's nothing more to it.

Have you considered using publishing software on your computer to combine your content with a template, resulting in a set of static pages that you can then upload to the dropbox?
Some options in this regard come to mind:
Movable Type - can output static HTML which can then be uploaded to the server
Adobe Dreamweaver
Apple iWork Pages
To handle comments, you can use Disqus. It inserts a complete comment system into your site using just JavaScript.

You can use the Google Closure templates. It's one of the fastest and most versatile javascript templating solutions around.

Where do you put your javascript?

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.