0

Say I have two pages and each of them have their own js file, one of the pages needs some of the functions (maybe just one) that are on the other page's js file.

I'd rather not copy the same functions over. I could include both js files to that page, but is this the right way? Is there another way?

shinzou
  • 5,850
  • 10
  • 60
  • 124

2 Answers2

2

if you are working on javascript ES6, you can modularize your function and use import / export keyword

see doc >> http://exploringjs.com/es6/ch_modules.html

if you are working on older javascript version, you are working on the right way.

Alongkorn
  • 3,968
  • 1
  • 24
  • 41
  • latest chrome version work on ES6 well, you can use import / export – Alongkorn Oct 16 '16 at 08:34
  • @kuhaku: I don't think so, no. If so, that's ***brand***-new, and probably unique to Chrome. Up-to-date Chrome and Firefox support all of ES2015 (aka "ES6") *except* modules last I checked. But there are all kinds of tools for this -- CommonJS, RequireJS, Webpack, Browserify... – T.J. Crowder Oct 16 '16 at 08:38
  • 1
    @kuhaku: Just checked the latest: No, Chrome doesn't natively support ES2015 modules yet. – T.J. Crowder Oct 16 '16 at 08:47
  • from http://kangax.github.io/compat-table/es6/, my chrome support almost 100% feature, and from http://stackoverflow.com/questions/33516906/which-browsers-support-import-and-export-syntax-for-ecmascript-6, they said that Firefox and Chrome can support import / export well. – Alongkorn Oct 16 '16 at 09:01
2

There are a couple of primary approaches to the deployment here (I'm not talking about source files; keep those small, and combine at the build stage):

  1. Have a single JavaScript file you use on all pages, with long cache headers, and a name that changes when you change it.

    Yes, this means there will be functions in that file that won't be used by a given page, but it also means when a user moves from one page to another on your site, they don't have to download the JavaScript on that page. Also, when they come back to the site, because of the long cache headers, they might not have to download the JavaScript again (unless their cache has cycled, which is sadly likely).

  2. Have a "common" JavaScript file that contains the common functions used on your pages, and then have page-specific files for each page that needs its own special functions. Again with long-cache headers and names that change when you change the file, for possible caching benefit.

    This means that going to one of your pages will require loading two JavaScript files instead of one, but it's not a big deal, and by using long-cache headers you'll at least avoid one of those files (the common one) when they navigate around your site (and possibly when they come back, but again, caches cycle quickly).

Community
  • 1
  • 1
T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • What do you mean by "name that changes when you change it"? also, do you mean something like this http://www.askapache.com/htaccess/apache-speed-cache-control/ but for the js files by "long cache headers"? – shinzou Oct 16 '16 at 08:41
  • 1
    @kuhaku: Names: Pretty much what it sounds like. Use a build process that creates a new filename for the file based on, for instance, an MD5 hash or similar (and ensures your HTML uses the new name). Cache headers: There are long articles on this, I won't try to replicate them here, but you set the caching for the .js files so that the browser is allowed to keep it for (say) a year without rechecking with your server. Since you *don't* do that with the HTML (so the latest content is delivered), when they get the updated HTML, it uses a new filename, and they get the latest JS. – T.J. Crowder Oct 16 '16 at 08:50