为什么使用 JavaScript 路由？
似乎有许多库和包（Crossroads.js 等）支持此 javascript 路由功能，但我无法理解这是有价值的场景。
有人愿意详细了解这有用的情况吗？
我的背景是 ASP.NET（网络表单）编程和一些业余的 javascript/jquery。
There seem to be many libraries and packages (Crossroads.js, etc.) which support this javascript routing functionality, but I'm having trouble understanding a scenario where this is valuable.
Anyone care to go soup-to-nuts on situations where this is useful?
My background is with ASP.NET (web forms) programming and some amateur javascript/jquery.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
它为您提供了处理客户端行为的选项，而无需重新加载整个页面，就像处理路由服务器端的情况一样。
它为更具响应性和交互性的设计提供了可能性，因为您可以仅重新渲染针对给定路线更改的网站部分，而不是每次路线更改时重新加载整个页面。同时，它有助于减少服务器上的负载，因为您可以减少客户端服务器通信，只发送显示页面所需的数据以供客户端处理（渲染视图等）。
感谢使用backbone.js或其他mvc(类似）框架，您可以减少服务器，仅公开用于处理和接收数据的 REST API，而无需处理渲染，并且您可以将一些（有时甚至是大部分）逻辑传递给客户端。
如今，大多数网络应用程序都在利用客户端路由——从 GMail 到 Twitter 的任何内容。
It gives you option to handle client behavior without having to reload whole page as if with cases when you'd be handling routing server side.
It opens up possibilities for way more responsive and interactive designs as instead of reloading whole page each time route changes you are able to rerender only the portion of the website that changs for a given route. At the same time it helps reducing the load on the server as you reduce the client server communication to sending only the data required to display a page for client to handle it (render views etc.)
Thanks to using backbone.js or other mvc(-like) frameworks you are able to reduce your server to expose just the REST API for working with and receiving data without having to handle the rendering and you are passing some - or even most at times - of the logic to the client.
Most of the web apps nowadays are taking advantage of client-side routing - anything from GMail to twitter.
好吧——我想我现在理解得更好了。它只是函数调用者和被调用者之间的一个抽象层。您可以引入一个路由系统，该系统将根据某些配置连接两者，并提供附加功能，例如验证或将多个被调用者绑定到调用者，而不是在调用者和被调用者之间附加硬编码依赖项。然后，您可以使用静态句柄（例如“/getCoffee/decaf”）引用您的操作，这些句柄也可以动态构造（因为它们只是字符串）。
我仍在考虑路由方案与创建自定义事件的相对优势。
OK- I think I understand it better now. It's just a layer of abstraction between a function caller and callee. Instead of attaching a hardcoded dependency between the caller and callee, you can introduce a routing system which will connect the two based on some configuration and provide additional functions like validation, or binding multiple callees to a caller. Then you can reference your actions with restful handles (eg "/getCoffee/decaf") which can also be dynamically constructed (since they're just strings).
I'm still pondering the relative benefits of a routing scheme vs creating a custom event.