portia79

There's a tab in Chrome's developer tools that does it, but it's only per page - https://developers.google.com/web/tools/chrome-devtools/coverage

You can append a version number to the end of the file path to force the browser to fetch a new copy. Some people use a current timestamp for this but I recommend not doing that otherwise the file will never be cached. You actually want it to be cached as much as possible, and only force a new download if the file has changed.
file.css?1.0.0
file.js?1.0.0
If you're using PHP this is simple enough to do automatically by getting the file modified time with filemtime.
If you're using WordPress you can use the above function when enqueueing files too https://wordpress.stackexchange.com/questions/269736/add-last-modified-time-as-version-to-css-and-js/293493.

It's a bit messy but this should be roughly what you're after.
https://codepen.io/jackpallot/pen/xxwZZvq

I think there's only one site I've built at work in the last few years that I wish I built as a full SPA. For me, the signs are usually:
You have a lot of JS everywhere already and it's getting difficult to manage Managing state on the frontend is getting hard and more bugs are creeping in The user experience is suffering as a result of traditional full page reloads (ajax can solve this but then go back to point 1 and 2) It's getting difficult to reinitialise state once the user has left the page, usually this involves setting data in session or local storage and retrieving it again. Web applications typically have all of the above problems, and you get to them much faster. If you think of something like Google Docs or Google Sheets, there's a lot of JS needed for that, and a tonne of in-app state to keep track of at a given time. Even Gmail when you compose an email in the small pop-up, is keeping track of all your text formatting, cursor position etc, as well as watching for incoming email and notifications.
 
Most traditional sites don't deal with this level of state, though, and most don't need the benefits of client side routing where a traditional full page refresh has no impact on user experience. The reason why I tend to sprinkle in JS components instead (not necessarily small components) is because there are also problems with SPA's and web apps in general, and it's a trade-off you really have to consider:
Your app is rendered in client-side JS unless you explicitly look at server-side rendering. It doesn't sound like a big deal, but for a website that requires search engine visibility, you will have issues that your competitors likely won't. Most start-ups have a marketing site that links to an SPA, for example asana.com uses a CMS called Statamic and a traditional site to manage the core marketing pages. They have approached this well, keeping it simple when it needs to be, so they can focus on the core product.
Non-server rendered apps can have performance issues, both on initial load and after. You generally have to make a lot more considerations and rely on tooling more to avoid sending megabytes of JS down the wire.
Single page apps are harder to build correctly, and can be difficult to maintain if you start making incorrect decisions. Un-doing something in an SPA, or web app in general, can have a huge knock-on effect to how the rest of it behaves. This is why automated tests really are required when you start wiring components together. I haven't really found the same to be true for websites because so much is handled by a CMS for you.
You would need to factor in a higher maintenance cost to your clients for keeping the app dependancies up-to-date. You don't want to have something like React fall a few major versions behind, because you will spend days refactoring the code again to plug the new API changes. This goes for other frameworks too, even ones in PHP land, like Laravel. Websites on a CMS usually take a few minutes to update, and have been designed to take the hard work out of it. Over engineering is not a good thing, it can be extremely costly to businesses and stressful for the maintainer. Similarly, under engineering or over simplifying can cause issues too, so use your best judgement to pick the right fit for a project, whatever that might be. If something feels like it needs to be a full SPA from the brief, then go for it. If you're doing it just to use and practice React, I'd avoid it on client projects, build something for yourself instead.

I think you should try to avoid hardcoded references in your JS file. Instead you should pass the references as parameters to abstract functions. The actual calls to the fuctions that you want to use could be called from a load event on every page. If you really need hardcoded references they should be encapsulated in functions. That way you would not end up with undefined elements.
 
Example:
 
functions.js:
someFunctionWithHardCodedReferences (){ var myParagraphs = document.getElementByTagName('p'); var myString = document.getElementById('heading').innerHTML; //Do something } someReuseableFunction (element1, element2){ var myCanvas = document.getElementById(element1); var myDiv = document.getElementById(element2); //Do something } On every page you include your functions.js but you only call the functions you want to use
<html> <head> </head> <body> <canvas id="myCanvas"></canvas> <div id="myDiv"></div> <script src="functions.js"></script> <script> // Pageload window.addEventListener("load", function load(event) { //Call only the functions you want to use on this page here //and pass the elements as parameters if you use abstract functions someReuseableFunction('myCanvas','myDiv'); }); </script> </body> </html>

I haven't really used a tutorial on gulp, I just used the documentation which is pretty good https://github.com/gulpjs/gulp
 
Ideally you want to automate all your repetitive tasks, it saves a lot of time when you add things together for instance I automate
Image compression SVG sprite generation & compression Sass compilation, minification and linting, JavaScript linting, (ES6) to ES5 transpilation, concatenation of files, minification Favicon generation Then it puts all static assets into a build folder and reloads the page via live reload.

Hi, welcome to the forum
 
I will try to answer some of your questions as good as I can:
 
1. Node, ember and backbone are js (javascript) libraries for building web applications. They are basically ready made javascript functions, so you (the developer) don't need to write the whole code again. Like pre-defined CSS styles, but js, well, a bit more complicated than that, hope that makes sense
 
2. I haven't worked with Jango, but I do agree it might be not needed, if you only want to create a static site. There a lot of CMS aimed at simple static sites that won't require much maintenance and updating. We have a topic about "static" site CMS here. Hope that helps a bit.
 
3. HTML5 is pretty much safe. Of course IE9 and below don't fully support HTML5, but there is a workaround that you can use to force HTML5 on older versions of IE - here.
 
4. I would prefer to code everything from scratch, or use a blank starter template, like HTML5 boilerplate or similar. I wouldn't use a site generator, they might produce a bloated code.
 
5. Yes, jQuery is great, I would definitely use it for a gallery / slideshow. If you prefer to make a gallery from scratch, great, but if not, there are a lot of jQuery gallery plugins, just google them : link.
 
Hope that helps a bit, surely ask any question, everyone on the forum would be happy to help