One aspect that hasn't been addressed in previous responses is the impact on developer productivity. When it's more convenient to include code inline and there are no pressing performance issues, opting for simplicity can provide substantial business benefits. Prioritizing ease of development over potential future performance gains is a wise strategy. Avoid premature optimization.

One of the benefits of using linked JS files is that they can be stored in the browser's cache and loaded from local storage or memory for future pages.

On the other hand, inline JS offers the advantage of potentially reducing the number of network requests per page.

A good compromise would be to have a small amount of linked JS files (one or two) that are minified and combined to create as few and as small files as possible.

The advantages gained from local caching usually outweigh the inconvenience of parsing a little bit of unused JS on certain pages.

In cases where embedded JS is necessary (despite having most of the JS in linked files), it should be limited to setting a few specific variables that pertain to the current page. This data is typically unique to each page, generated dynamically on the server, and not easily cacheable. However, it should generally be kept minimal and tailored to each individual page.

When you include a script directly within your HTML document, it avoids the extra request to the server that comes with linking an external script file. This can lead to faster loading times for your page in some cases. It is advisable to inline your code if:

• it is very small
• it is dynamically generated, as caching benefits may not apply in this scenario

In the case of websites like Google and Facebook, you may notice inline JavaScript being used because it is being generated by server-side code.

Previous responses have touched on the benefits of caching with external JS files. I typically lean towards this approach for any library or framework functionality that will be utilized by multiple pages. It's important to avoid redundancy whenever possible.

I wanted to address the distinction between "inline" and "embedded".

For me, "inline" involves mixing JS within the HTML, potentially using multiple separate <script> blocks that may or may not reference each other. This often includes setting event handlers directly in HTML element properties like <div onclick="..."/>. While I generally discourage this practice, there are exceptions where it may be more convenient - but overall, it's best to avoid it as much as possible to streamline development.

On the other hand, I define "embedded" as having a single <script> block either in the head or at the end of the body, with event handlers assigned within that block using functions like document ready or onload. This method is suitable for page-specific functions, especially if only a small amount of script is needed and caching isn't a concern. Additionally, when dealing with dynamically generated pages, keeping the script embedded can simplify server-side scripting tasks.

A quick reminder about external files: be cautious of Internet Explorer's tendency to "over cache" during development. It can be frustrating to make changes to an external file and have them not reflect in the browser due to caching. Stay vigilant and remember to clear your cache to prevent unnecessary headaches caused by outdated script versions.

All the responses above provide valuable insights, but I would like to share my perspective based on 15 years of experience in web development.

It is essential to always utilize linked resources for CSS and ECMAScript rather than inline code. Linked content is cached by most browsers, making it accessible across numerous pages within a domain over extended periods of time. The benefits of this approach are significant:

1. Significant bandwidth savings are achieved by delivering less script data over the wire, resulting in a better user experience as the cache can be utilized for weeks.
2. Linked stylesheets offer better cascading capabilities compared to embedded or inline styles, avoiding confusion among designers.
3. Duplicate scripts are avoided, reducing redundancy and potential issues that may arise with inline scripts.
4. Reusing libraries across multiple pages is made possible, while also enabling cache control through versioning and querystrings.
5. Preloading all resources before initializing scripts and styles in the DOM ensures smoother user interactions, preventing issues caused by users interacting with content before it's fully processed.
6. This approach provides more control over script and CSS libraries, helping maintain consistency across a project and avoiding unnecessary custom scripting.
7. Updating libraries becomes easier, allowing for seamless implementation of new versions for users.
8. External script libraries from providers like Google can be easily integrated, enhancing functionality and performance.
9. Cached client-side resources result in faster processing speeds, offering better performance compared to on-demand resources.
10. Linked scripts contribute to consistent styling and layout across pages, promoting a flash-free browsing experience.

By incorporating linked resources in the initial request/response cycle on a domain, users benefit from fast loading times and stable page layouts even during multiple interactions across the site. Custom embedded resources can be added sparingly at a page level, complementing the cached linked stack of libraries as needed for specific customizations. This methodology streamlines website maintenance and enhances overall performance without the need to track individual library usage per page.

The Role of Google Angular

Google often leverages Angular's sophisticated modular cache systems for managing single-page applications efficiently. However, a notable drawback lies in their heavy reliance on preloading large amounts of ECMAScript alongside HTML and CSS directly into the webpage, leading to redundant code injection and wasted resources.

This excessive approach to caching through inline content retrieval via XMLHTTPRequest calls creates inefficiencies in bandwidth utilization and browser processing power. Opting for linked resources instead of bloating pages with duplicate scripts aligns with simpler, more efficient web development practices, emphasizing speed and minimal code overhead for content display.

In light of recent trends moving towards local inline styles and scripts, it's crucial to remember the benefits of utilizing linked resources for optimized performance and streamlined development workflows. Embracing these established principles fosters a more sustainable and effective approach to web development, steering clear of outdated methodologies that compromise efficiency and user experience.

• Stokely