在更大的项目上处理 javascript 的方法?

发布于 2024-10-19 01:33:45 字数 521 浏览 5 评论 0原文

几年前发现 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

掩于岁月 2024-10-26 01:33:45

Backbone.js 和 JavascriptMVC 都是使用框架以合理的方式组织大型项目的绝佳示例(SproutCore卡布奇诺也不错)。我绝对建议您选择一种标准方法来处理来自服务器的数据、处理来自 DOM 的事件和来自服务器的响应以及视图创建。否则,这可能是一场维护噩梦。

除了 MVC 框架之外,您可能还应该为这些问题选择一个解决方案:

  • 依赖管理:如何以正确的顺序编译和加载 javascript 文件?我的建议是 RequireJS
  • 测试:测试 UI 代码从来都不是一件容易的事,但是 jQuery 的人已经做了一段时间了,他们的测试工具 QUnit 有详细记录/测试。
  • 缩小:在部署到生产环境之前,您需要缩小代码,RequireJS 内置了此功能,但您也可以使用 Closure Compiler 如果你想获得疯狂的小源代码。
  • 构建系统:所有这些工具都很棒,但您应该将它们全部集中在一个主构建系统中,以便您可以在命令行上运行简单的命令并调试或生产应用程序。使用的具体工具取决于您选择的语言 - Ruby => Rake,Python ->编写您自己的 NodeJS 作为构建工具(我最喜欢这个选项)-> Jake

除此之外,请注意是否有些东西感觉笨重或缓慢(无论是工具还是框架)并进行重构。

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:

  • Dependency management: how will you compile and load javascript files in the right order? My suggestion would be RequireJS.
  • Testing: testing UI code is never easy but the guys over at jQuery have been doing for a while and their testing tool QUnit is well documented/tested.
  • Minification: you'll want to minify your code before deploying to production RequireJS has this built in but you could also use the Closure Compiler if you want to get crazy small source.
  • Build System: All these tools are great but you should pull them all together in one master build system so you can run a simple command on the commandline and have you debug or production application. The specific tool to use depends on your language of choice - Ruby => Rake, Python -> Write your own, NodeJS as a build tool (i like this option the most) -> Jake

Beyond that just be aware if something feels clunky or slow (either tooling or framework) and refactor.

只有一腔孤勇 2024-10-26 01:33:45

我想推荐以函数式风格使用 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.)

不爱素颜 2024-10-26 01:33:45

我的建议是将尽可能多的 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文