在更大的项目上处理 javascript 的方法？
几年前发现 jQuery 后，我意识到无需编写代码书籍即可真正创建交互式且用户友好的网站是多么容易。随着项目规模的增加，进行任何调试或可能实现更改或新功能所需的时间也随之增加。
通过阅读各种博客并保持一定的更新，我读到了类似于 Backbone.js 和 < a href="http://www.javascriptmvc.com/" rel="nofollow">JavascriptMVC 听起来都是不错的选择，可以使代码更加模块化和分离。
然而，由于距离 Javascript 或 jQuery 专家还很远，我并不是真的不适合告诉一个项目中什么是一个好的基石，在这个项目中，未来的可维护性、调试和开发的简易性是优先考虑的。
考虑到这一点 - 在开始一个项目时，常识是什么，其中 Javascript 和 jQuery 代表了用户的大部分用户体验和数据呈现？
非常感谢
After discovering jQuery a few years ago, I realized how easy it was to really make interactive and user friendly websites without writing books of code. As the projects increased in size, so did also the time required to carry out any debugging or perhaps implementing a change or new feature.
From reading various blogs and staying somewhat updated, I've read about libraries similar to Backbone.js and JavascriptMVC which both sound like good alternatives in order to make the code more modular and separated.
However as being far from an Javascript or jQuery expert, I am not really not suited to tell what's a good cornerstone in a project where future ease of maintainability, debugging and development are prioritized.
So with this in mind - what's common sense when starting a project where Javascript and jQuery stands for the majority of the user experience and data presentation to the user?
Thanks a lot
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Backbone.js 和 JavascriptMVC 都是使用框架以合理的方式组织大型项目的绝佳示例（SproutCore 和卡布奇诺也不错）。我绝对建议您选择一种标准方法来处理来自服务器的数据、处理来自 DOM 的事件和来自服务器的响应以及视图创建。否则，这可能是一场维护噩梦。
除了 MVC 框架之外，您可能还应该为这些问题选择一个解决方案：
除此之外，请注意是否有些东西感觉笨重或缓慢（无论是工具还是框架）并进行重构。
Both Backbone.js and JavascriptMVC are great examples of using a framework to organize large projects in a sane way (SproutCore and Cappuccino are nice too). I definitely suggest you choose a standard way of deal with data from the server, handling events from the DOM and responses from the sever, and view creation. Otherwise it can be a maintenance nightmare.
Beyond an MVC framework, you should probably choose a solution for these problems:
Beyond that just be aware if something feels clunky or slow (either tooling or framework) and refactor.
看看这本书，主要是第10章 http://jqfundamentals.com/book/index.html #第10章
Check out this book, mainly chapter 10 http://jqfundamentals.com/book/index.html#chapter-10
我想推荐以函数式风格使用 javascript，这可以通过像 coffeescript 这样的抽象来帮助和 underscore.js。
此外，最大限度地减少跨模块交互并依赖事件驱动代码是保持整个项目井井有条的好方法。我非常喜欢 backbone.js 通过让视图绑定来处理模块视图弱耦合的方式更改模块上的事件。
基于函数事件的代码非常适合宏观结构。我还建议将 javascript 耦合到 DOM。 （再次 backbone.js 有一个很好的例子，说明模型如何完全独立于 dom，甚至视图不依赖于 dom。对于您所关心的视图可以通过 WebSocket 发送数据）
我个人也喜欢拥有一个中央文件管理器，而不是在每个页面上使用复杂的 require/include 结构。根据逐页功能检测从中央加载器加载 javascript 模块。 （请参阅此处的示例中央文件管理器）。
我还想提倡通过 node.js 实现良好重用的可能性越来越大。有相当多的人致力于将浏览器代码逐字移植到 Node.js 或将 Node.js 代码逐字复制到浏览器。 （参见在nodejs上运行的YUI3，浏览器中的node.js，浏览器中的commonJS 诚然，其中大多数都是 WIP 并且不稳定。）
I would like to recommend using javascript in a functional style which can be helped by abstractions like coffeescript and underscore.js.
Also minimising the cross module interaction and relying on an event driven code is a great way to keep your entire project organized. I defiantly like the way that backbone.js handles the module-view weak coupling by having view's bind the change events on modules.
Functional event based code is great for macro structure. I would also advice coupling javascript to the DOM. (Again backbone.js has a great example of how the model is completely dom independant and even the views aren't dependant on the dom. For all you care the views could be shooting data down a WebSocket)
I'm personally also a fan of having one central file manager rather then having a complicated require/include structure on every page. Load javascript modules from your central loader based on a page by page feature detection. (See here for an example of a central file manager).
I would also like to advocate the growing possibility of good re-use through node.js. There are quite a few people working on porting browser code verbatim to node.js or copying node.js code verbatim to the browser. (see YUI3 running on nodejs, node.js in the browser, commonJS in the browser Admittedly most of these are WIP and not stable.)
我的建议是将尽可能多的 javascript 隔离到视图之外的外部 js 文件中，并在标头中简单地引用它们。这不仅允许从一个页面到另一个页面重复使用 javascript，而且它在一个公平的水平上分离了你的关注点，分散你的代码以允许更容易的调试（无论如何我的信念更容易）。此外，这使您的 js 更加安全，因为它不会直接呈现到浏览器页面上。诚然，这种安全性是相当可以忽略不计的，因为像 firebug 或 IE 的开发工具这样的工具可以访问分层的 javascript 文件。
其次，我建议使用像 compress.msbuild 这样的工具（在最终编译部署时）将所有自定义编写的 javascript 压缩到无论其名称如何-min.js。将所有内容压缩到一行不仅实际上减少了代码的负载和运行时间，而且还使其变得更加安全。当所有代码都是一行时，分解 -min 文件要困难得多，更不用说找到任何特定函数了。
My suggestion would be is to isolate as much javascript as possible into external js files, outside of your views, and simply reference them in the headers. Not only does this allow javascript re-use from page to page, but it separates your concerns on a fair level, spreading out your code to allow for easier debugging (easier by my beliefs anyway). In addition, this makes your js a little bit more secure as it is not rendered directly onto the browser page. Granted, that security is fairly negligible since tools like firebug or IE's Developer Tools can access layered away javascript files.
Second, I would suggest using a tool like unto compress.msbuild to (at final compile for deployment) compress all your custom-written javascript to whatevertheirnameis-min.js. Not only does compacting everything to a single line actually reduce load and run-times for your code, it also obfuscates it into more secure. It is significantly more difficult to take apart a -min file, much less find any specific functions when all the code is a single line.