处理大型 JavaScript 应用程序
我们的文件结构非常好，将功能组织在单独的文件夹中。我的问题是其他人如何处理涉及超过 500 个 JavaScript 文件的应用程序。
我们编写了一个 Maven 插件来将这些文件连接在一起（还运行 YUI 压缩器）。然而，每次更改都需要 3-10 秒的编译时间。
这一步对于组织大型应用程序是必要的吗？我觉得一个结构良好的 HTML 文件提取所有这些资源每天可以节省我 45 分钟的时间。
Our file structures is pretty good, organizing functionality in separate folders. My question is how do others work on applications that involves upwards of 500 JavaScript files.
We have written a maven plugin to concatenate these files together (also runs YUI compressor). However, this involves 3-10seconds of compiling for every change.
Is this step necessary for organization of a large application, I feel like a well structured HTML file pulling in all these resources would save me 45minutes every day.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于我自己的框架项目，通常是监视、测试或页内服务来编排其他工具包（但是不像您的文件数量那么高），我的方法是在开发过程中针对单个文件和动态加载的文件。为了进行测试，我将运行一个构建来压缩各个文件并对其进行版本控制，然后再次测试各个文件，因为根据串联顺序、压缩技术和浏览器，我可能会遇到脚本错误，并且很痛苦从一份怪物档案中挖出来。第三，我将连接在一起并再次测试。
在 HTML 参考中，我将定位加载指定依赖项的未压缩文件或复合文件。单独的引导文件命名依赖项，这些依赖项要么包含在复合文件中，要么根据需要动态加载。
这样我就可以添加或更改文件，并开始开发和测试而无需重建。
For my own framework projects, typically monitoring, testing, or in-page services to orchestrate other toolkits (but not as high as your file count), my approach has been to target the individual and dynamically loaded files during development. For test, I'll run one build to compress and version the individual files, and test the individual files again because, depending on the concatenation order, compression technique, and browser, I may wind up with a script error and it's a pain to dig it out of one monster file. Third, I'll concatenate together and test once more.
In the HTML reference, I'll either target the uncompressed file, which loads specified dependencies, or the compound file. A separate bootstrap file names the dependencies, which are either included in the compound file, or loaded dynamically as needed.
This way I can add or change a file, and start developing and testing without rebuilding.
该解决方案可能仅为用户测试和生产而连接和压缩。
对于开发来说，最好将它们全部导入到 HTML 文件中。它加快了开发过程，并简化了调试。它还允许浏览器缓存其中一些文件。
当您不能依赖缓存副本（对于 500 个文件，我认为这种情况不会经常发生）时，它会减慢加载时间。
The solution is likely to concatenate and compress for user testing and production only.
For development, it's probably best to simply import them all into the HTML file. It speeds up the dev process, and also simplifies debugging. It also allows the browser to cache some of those files.
When you can't rely on cached copies (which, with 500 files, I don't think will be very often), it will slow down load times.
仅在生产中运行压缩机可能会节省大量时间。 YUI 压缩器是出了名的慢，因为它使用 Java Rhino 解释器来实际解析 JavaScript 并对其进行分析等。
You can likely save a lot of time by only running the compressor in production. The YUI compressor is notoriously slow, because it uses Java Rhino interpreter to actually parse the JavaScript and analyze it etc.