在服务端实时生成客户端脚本是否可行？
It is feasible to generate client-side scripts on the server in realtime?
我正在开发一个应用程序，其中有许多可用资源每小时都不同，并且在客户端加载所有排列会导致非常非常大的脚本。
我强烈考虑让服务器动态生成一个缩小的脚本，结合所有当前最佳资源，预加载配置和用户特定的凭据（当然只有在登录时才加载），实时。在用户与页面交互之前不需要该脚本，因此可以安全地在客户端加载 defer 允许服务器执行其操作所需的毫秒数，以及网络上的往返时间。我已经考虑过这确实会阻止缓存脚本，而且我不确定这是一个问题，因为它目前是如何构建的。换句话说，像这样：
<script defer type="text/javascript" src="/dynamically-generated-script.js"></script>
我认为这是在 Stack Overflow 上向社区提问的完美问题类型，因为我从未尝试过像这样生成实时动态脚本，而且我可以肯定地看到它已经过尝试和测试（并且可能失败）练习，我只是不知道。
这样做合理吗？
这是可行的，但我强烈建议不要这样做，原因如下：
- 脚本动态生成后，您将失去很多优化层，从浏览器缓存脚本开始，一直到在 CDN 上托管脚本。
- 无法缓存脚本这一事实意味着您正在远离 Web 开发的最新趋势：渐进式 Web 应用程序 (PWA) 和加速移动页面 (AMP)
- 客户端的错误处理成为一个极其困难的问题，因为基本上每个用户都有一个脚本。像 sentry 这样的错误报告服务将无法识别相同的错误（因为每个错误都会从不同的文件中生成）
- 安全性、性能，甚至一般代码质量都将难以衡量和控制，因为您同样拥有大量不同的代码。
- 您将无法对这些生成的文件进行任何静态分析，因此您无法访问许多可帮助开发人员编写更好代码的工具 - 您可能仍然可以对生成这些文件的代码进行静态分析动态脚本，但这是另一回事。
- 使用情况分析也可能会受到影响，具体取决于您想要进行的分析的高级程度。
综上所述，我会强烈考虑其他解决方案。我不知道确切的要求，所以很难说清楚，但是我注意到两件事：
- 您说您想将凭据和配置移到客户端，这是一种不好的做法，即使客户需要大量不同的配置和凭据 - 尤其是凭据。这些应该保存在服务器端，一旦客户端基于一个凭据被授权——通常是存储在 cookie 中的令牌，客户端就可以访问它们。您可能会说我需要这些凭据来执行从客户端到 3rd 方服务的一些请求，如果是这种情况，那么您应该从服务器端执行这些请求，并且客户端应该调用服务器端而不是调用这些 3rd派对服务直接。
- 代码通常不是动态的，因为代码本身使您能够控制流程——代码与之交互的数据通常是动态的。我在这里想说的是，很难想象要求您需要为每个不同的用户使用不同的代码——在某些情况下，您可能希望拥有不同版本的代码，但这是另一回事。
为了扩展上一点，我认为您的问题的解决方案是加载包含所需所有代码的脚本，然后根据不同的条件执行特定路径的代码。您可能仍然希望根据动态条件加载动态数据，这可以通过调用服务器来完成。即使你真的必须为每个用户做一些真正动态的功能，那么这样的功能也应该暴露在一个 api 后面，它将被客户端调用。
我正在开发一个应用程序，其中有许多可用资源每小时都不同，并且在客户端加载所有排列会导致非常非常大的脚本。
我强烈考虑让服务器动态生成一个缩小的脚本，结合所有当前最佳资源，预加载配置和用户特定的凭据（当然只有在登录时才加载），实时。在用户与页面交互之前不需要该脚本，因此可以安全地在客户端加载 defer 允许服务器执行其操作所需的毫秒数，以及网络上的往返时间。我已经考虑过这确实会阻止缓存脚本，而且我不确定这是一个问题，因为它目前是如何构建的。换句话说，像这样：
<script defer type="text/javascript" src="/dynamically-generated-script.js"></script>
我认为这是在 Stack Overflow 上向社区提问的完美问题类型，因为我从未尝试过像这样生成实时动态脚本，而且我可以肯定地看到它已经过尝试和测试（并且可能失败）练习，我只是不知道。
这样做合理吗？
这是可行的，但我强烈建议不要这样做，原因如下：
- 脚本动态生成后，您将失去很多优化层，从浏览器缓存脚本开始，一直到在 CDN 上托管脚本。
- 无法缓存脚本这一事实意味着您正在远离 Web 开发的最新趋势：渐进式 Web 应用程序 (PWA) 和加速移动页面 (AMP)
- 客户端的错误处理成为一个极其困难的问题，因为基本上每个用户都有一个脚本。像 sentry 这样的错误报告服务将无法识别相同的错误（因为每个错误都会从不同的文件中生成）
- 安全性、性能，甚至一般代码质量都将难以衡量和控制，因为您同样拥有大量不同的代码。
- 您将无法对这些生成的文件进行任何静态分析，因此您无法访问许多可帮助开发人员编写更好代码的工具 - 您可能仍然可以对生成这些文件的代码进行静态分析动态脚本，但这是另一回事。
- 使用情况分析也可能会受到影响，具体取决于您想要进行的分析的高级程度。
综上所述，我会强烈考虑其他解决方案。我不知道确切的要求，所以很难说清楚，但是我注意到两件事：
- 您说您想将凭据和配置移到客户端，这是一种不好的做法，即使客户需要大量不同的配置和凭据 - 尤其是凭据。这些应该保存在服务器端，一旦客户端基于一个凭据被授权——通常是存储在 cookie 中的令牌，客户端就可以访问它们。您可能会说我需要这些凭据来执行从客户端到 3rd 方服务的一些请求，如果是这种情况，那么您应该从服务器端执行这些请求，并且客户端应该调用服务器端而不是调用这些 3rd派对服务直接。
- 代码通常不是动态的，因为代码本身使您能够控制流程——代码与之交互的数据通常是动态的。我在这里想说的是，很难想象要求您需要为每个不同的用户使用不同的代码——在某些情况下，您可能希望拥有不同版本的代码，但这是另一回事。
为了扩展上一点，我认为您的问题的解决方案是加载包含所需所有代码的脚本，然后根据不同的条件执行特定路径的代码。您可能仍然希望根据动态条件加载动态数据，这可以通过调用服务器来完成。即使你真的必须为每个用户做一些真正动态的功能，那么这样的功能也应该暴露在一个 api 后面，它将被客户端调用。