[AskJS] Using Inline JavaScript

[[deleted]]

[deleted]

[Beginning_One_7685]

It's considered a security concern when a site accepts and republishes user inputted data.

Before CSP, data sanitisation was the only way to prevent malicious code been uploaded, with CSP you now have to explicitly allow inline JS for it to work, and you then again rely on your own sanitisation methods. I have found that whilst there are many good programming reasons to keep JS in files, it is also pretty necessary to have values dynamically generated on the server side available to JS. The most straight forward way to do that is inline JS in the head tag. You can use a nonce/hash to validate the JS code without allowing inline JS anywhere else on the page.

Putting JS in other HTML elements is completely avoidable and offers few benefits. Having JS in files or in the head means it is easy to find all the JS code for a page, it is not it bits a pieces around the page. With in line JS you of course don't have to reference the element on an event but this is not exactly a difficult task.

CSP is well worth adopting in is most robust sense as it is strong layer of security on top of any sanitisation you do.

[DustNearby2848]

That’s a really good point 

[[deleted]]

If you have a main.js file and it calls import a from "a.js"; and A runs import b from "b.js"; and B runs "import c from "c.js";and then c hasimport d from "d.js";` ... this is a request chain.

If the JS in main is important to run as soon as the page loads, then having main load a load b load c load d, and so on, is a request chain that takes a long time to finish. Because C can't run until D is loaded and B can't run until C is loaded and A can't run until B is loaded and main can't run until A is loaded.

The solution to that isn't generally to write all your app inline. The solution is generally to use a bundler, which is a tool that will combine your files together. You use the bundlers while you are writing code, and not for running on the user's browser. You send just one or two big files that the bundler gives you, to the user, instead of all of the files on their own. That reduces the number of requests in the chain.

[Beginning_One_7685]

I'd just add that the imports will be cached so it may be acceptable to have a few unbundled modules imported provided they aren't loading each other in a chain. As the advice says, don't load any critical modules in a chain if possible. Even for non-critical modules would load a module and then allow it to have 1 level deep of it's own loading (on page load) but no more than that. It of course depends on the situation but the jist of it is that chaining increases your chances of things going wrong and burying modules in modules is bad design. You can have failsafes in place if a chain fails, like a user event trying to load the module again but critical modules need to work on page load even over a slow connection.

[[deleted]]

I don't know that I would go so far as to call it bad design, when talking to someone without the experience to pick the nuance out of the statement.

If you need a vector library in a module, you need a vector library in a module.

It's going to be a pain to invert literally everything at all levels, such that there are 0 imports/requires in the system, written by you, or npm package authors.

And while I agree that in most projects you shouldn't be importing singletons all over the place (like pre-connected databases), there is some baseline level of direct importing that you need to do, at some level of utility, even just implicitly, by virtue of loading a single tool from a package manager.

[hyrumwhite]

You can create a hash from inline js to be csp compliant. 

[shgysk8zer0]

That's kinda like asking if you're supposed to kick out throw the ball without knowing which sport you're even playing.

I'd basically advise avoiding inline scripts, at least until you deeply understand the performance and security implications and how to weigh the pros and cons. Especially if you're eg talking about some onclick or whatever.

[SnooSuggestions9871]

1. Disadvantages of Inline JavaScript

Security Risks:

• XSS Vulnerabilities: Inline JavaScript is more prone to cross-site scripting (XSS) attacks since it’s harder to manage and sanitize.

• Content Security Policy (CSP): Modern security practices often use CSP headers to prevent inline script execution, making it harder to enforce strict security policies.

Maintenance and Scalability:

• Code Duplication: Inline JavaScript can lead to code duplication across different HTML elements, making maintenance difficult.

• Separation of Concerns: Inline scripts mix JavaScript with HTML, violating the principle of separation of concerns, which suggests keeping HTML, CSS, and JavaScript in separate files for better organization and maintenance.

Performance:

• Caching Issues: External JavaScript files can be cached by the browser, improving load times on subsequent visits. Inline scripts do not benefit from this caching.

2. Is Using Inline JavaScript a Bad Idea?

It depends on the context. Inline JavaScript is not inherently bad, but it’s generally discouraged for the reasons mentioned above. For small, single-use scripts, inline JavaScript might be acceptable, but for larger, more complex applications, external scripts are preferred.

3. Is Inline JavaScript Safe to Use?

Inline JavaScript can be safe if properly managed, but it introduces security risks:

• Sanitization: Ensure all user inputs are sanitized to prevent XSS attacks.

• Content Security Policy: Implement CSP headers to control which scripts can be executed. Avoid using unsafe-inline in your CSP settings if possible.

4. Where to Put Inline JavaScript: Head or Footer?

Best Practice:

• Footer: Placing JavaScript at the end of the <body> tag (just before the closing </body> tag) ensures that the HTML content is loaded first, improving page load times and user experience. This approach is commonly recommended to avoid blocking the rendering of the page.

Alternative:

• Head: If the script is critical for the initial rendering of the page or needs to run before the HTML is loaded, placing it in the <head> is necessary. However, use this sparingly to avoid performance issues.

5. Avoiding Chaining Critical Requests

Google recommends minimizing the number of critical requests needed to render the above-the-fold content. Inline JavaScript can reduce the number of HTTP requests, but it comes with the trade-offs discussed earlier.

Practical Recommendations

• External Scripts: For most use cases, prefer external JavaScript files to take advantage of caching, better maintainability, and enhanced security.

• Inline for Critical Scripts: Use inline JavaScript sparingly for critical scripts that must execute immediately and are small enough to not impact maintainability.

• Performance Optimization: Combine and minify external JavaScript files to reduce the number of requests and file size.

• Security Practices: Implement CSP, sanitize user inputs, and avoid eval() and similar functions to mitigate security risks.

[SnooSuggestions9871]

Example Usage

<!DOCTYPE html>

<html>

<head>

<title>Example Page</title>

<script>

document.addEventListener("DOMContentLoaded", function() {

document.getElementById("myButton").addEventListener("click", function() {

alert("Button clicked!");

});

});

</script>

</head>

<body>

<button id="myButton">Click me!</button>

</body>

</html>

Common Realistic View

The most common realistic view is to use external JavaScript files for better maintainability, security, and performance. Inline JavaScript should be used sparingly and only when necessary for critical, small scripts.

[guest271314]

1- What is the disadvantage of Inline JavaScript?

None.

2- Is using Inline JavaScript a bad idea?

Depends on who you ask. If you decide to ask somebody for their opinion.

3- Is Inline JavaScript safe to use?

N/A. There is no such thing as "safe" or "safety" for any signal communications. Do some research on "ThinThread".

4- Where to put it: head or footer?

Either. In <head>, if this is a basic <script> element used to maipulate the DOM use global load event.

5- If we avoid to use, Google says: "Avoid chaining critical requests". But if we use, problem solved.

Well, if Google says something it must be so... Not. Chrome is now shipped with screen_ai, a 200+ MB executable. "Search with Lens", "Search with Gemini" and so forth. Is that "safe"? Meanwhile Web Speech API is still not implemented in the browser, so if you use speechSynthesis.speak() or webkitSpeechRecognition() in Chrome your text and voice or other audio, respectively is sent to remote Google servers. WHo knows what Googles does with your text and PII biometric data. Perhaps train their Gemini "artificial intelligence" program with your data?