对于我们的网站,我使用了很多 jQuery——现在我正在查看基础库之上的 340 行 jQuery 代码。多少是太多了?我将添加更多内容,我什么时候开始尝试压缩代码并最终转向 OOP?
9 回答
行数没有任何意义——重要的是你实际在做什么。你可能有 10 行效率极低的代码,这比精心设计的 1000 行代码造成的损害要大得多。
最理想的情况是,您应该尽可能减小脚本大小,但是对于当今的“Web 2.0”网站,您很可能会积累大量 JavaScript 代码。
重要的是,在部署网站之前,请确保对脚本文件进行压缩和 gzip 压缩,以尽可能减小脚本文件的大小。
如果您真的对优化和提高网站性能感兴趣,我强烈建议您看看 Steve Souders 的高性能网站:前端工程师必备知识
多少太多取决于您的应用程序。
您应该力求简洁,但不能以牺牲可读性或用户体验为代价。
我会比代码行更关注脚本加载时间。如果它变得太大,请将文件分解为特定于页面或部分的文件。“太多”仅基于应用程序性能以及您认为用户可以接受的内容。
340 行不算什么,尝试使用一些 Telerik 控件……很快就会达到 15k+ 行!
这取决于您正在从事的项目。你应该保持你的代码高效和可读。部署网站后,只需压缩和 gzip 脚本即可提高性能。
我不会关心你的 JavaScript 的长度。您可以使用多种选项,例如使用Packer压缩 JavaScript 以进行发布(您需要练习一下,因为它确实有一些关于其工作方式的规则)。
专注于确保您的代码易于理解且易于维护。在网站中大量使用 JavaScript 会很快变得棘手。
试图让它变短或变小对你自己的伤害比用户必须等待额外的一秒钟才能加载页面更伤害你。
对于开发来说,将代码分离到单独的 .js 文件中变得绝对必要,否则事情会变得一团糟。
然而,
不要在生产页面中留下大量的脚本引用。大多数浏览器仅限于 2 个同时 HTTP 请求。这些脚本引用将减慢您的页面加载速度,并且远远超过单独缓存组件的任何可能的好处。
您可以使用 JS Builder 将开发文件连接到一个文件中:
http://code.google.com/p/js-builder/
编辑:通过脚本引用我的意思是 <script src="blah.js">。页面加载时,每一个都需要通过 HTTP 加载。
340 行 javascript 不算什么,但是随着您的 javascript 代码库的增长,我会花一些时间研究用于即时压缩和连接 javascript 的框架。如果您使用的是 Java,我建议您使用JAWR,它可以让您在开发模式下的多个引用和生产中的单个缩小脚本之间切换。只需确保在上线之前在生产模式下测试您的应用程序,因为缩小算法可能会在某些晦涩的情况下搞砸您的代码(如果您编写干净的代码并记住以';'结束每一行你应该没问题) .
如果您不在 Java 上,我不知道任何框架,但是您自己实现类似的东西实际上并不难。我想我有一些代码可以在 eZ Publish 中执行,它是用 PHP 编写的。