我正试图围绕 jQuery Mobile。我的目标是构建一个非常快速的应用程序，其外观和感觉尽可能接近原生应用程序（至少对于现代设备而言）。
我了解在页面之间导航有两种方式：
将每个页面加载为单独的页面，并使用常规 html 锚链接到其他页面。
将所有（或多个）页面放在一个网页上，并通过 javascript（$.mobile.changePage（方法）和类似的 api 函数）在它们之间导航。
第一种方法应该适用于所有浏览器，但性能很差，因为每个页面转换之间存在延迟。
第二个看起来应该快得多，所以我肯定更喜欢这种方法。但是，对于没有 javascript 支持的移动设备浏览器，这将如何工作呢？这显然违背了 jQuery Mobile 为 C 级浏览器提供优雅降级体验的目标。
在我看来，我需要实现我的应用程序两次，一次针对支持 javascript 的浏览器进行优化，一次针对不支持的浏览器进行优化？使用可能是另一种选择，但这看起来更加混乱。
解决这个困境的推荐方法是什么？有什么我没有注意到的吗？
谢谢，
阿德里安
首先：你的观点是错误的。
请参阅此处的本地内部链接“页面”并仔细阅读。链接href="#pageelementid"可以正常工作，并且也可以在任何支持 HTML4 的浏览器中工作[<a name="pageelementid">在某些情况下可能需要，我不再确定]，唯一的区别是所有页面都是一次可见的。
第二件事是，如果您使用 1 号方式，它看起来也会很漂亮。是的，它会加载，但在支持 javascript 的浏览器中，它加载了 AJAX，并且页面之间没有令人讨厌的闪烁。此外 - 出现“加载”弹出窗口。
jQuery Mobile 应该可以让你创建一个没有任何 JS 的纯粹简单的 html 应用程序。JQM 本身对页面进行了增强，使其看起来不错并使用 AJAX。尝试创建一个可以在所有浏览器中运行的应用程序（我的灵感：lynx）并为此使用 JQM 标记。您愿意编写的任何 javascript 都应该作为一种增强功能 - 让它变得更好，而不是让它工作。
祝你好运！
当前支持较小浏览器的想法不是优雅地降级，而是增强。如果您从头开始构建网站以在没有 javascript 的情况下工作，然后对其进行增强，那么您几乎知道该网站将正常工作（而不是必须修复它或构建辅助站点）。
至于您指定的两个选项，如果我的带宽有限并且很多人每月的下载量有限，那么我作为移动用户的首选是第一个。
将所有页面集中到一个大文件中似乎是个好主意（已经下载），但您可能会遇到某些手机的内存限制。如果他们只想访问两个页面怎么办，为什么要强迫他们下载整个网站呢？