使用 jQuery Mobile 进行网站编程有风险吗？
jQuery 团队最近推出了 http://jquerymobile.com/ ，旨在为移动设备创建用户界面库设备。
我们的目标是提供构建工具 动态触摸界面将 优雅地适应各种设备 外形因素。该系统将包括 两种布局（列表、详细信息窗格、 覆盖）和丰富的形式 控件和 UI 小部件（切换、 滑块、选项卡）。
总的来说，似乎对该框架的支持真的很低，因为大多数手机都配备了蹩脚的浏览器。我的问题分为两部分。是支持少数具有更丰富体验的浏览器更好，还是为尽可能多的用户提供平庸的体验更好？这与支持 IE 的问题类似，因为问题是我们有多关心使用较差浏览器的用户？
更重要的是，开发人员真正值得花多少时间来构建主要不针对移动用户的网站的移动版本？
The jQuery team recently launched http://jquerymobile.com/ with the intent of creating a user-interface library for mobile devices.
Our aim is to provide tools to build
dynamic touch interfaces that will
adapt gracefully to a range of device
form factors. The system will include
both layouts (lists, detail panes,
overlays) and a rich set of form
controls and UI widgets (toggles,
sliders, tabs).
Overall, it seems support for the framework is really low because most phones ship with crappy browsers. My question, is in two parts. Is it better to support a few browsers with a richer experience or give as many users as possible a merely average experience? This is similar to the question of supporting IE because the question is how much do we care about users with worse browsers?
More importantly, how much developer time is it really worth to build a mobile version of a site that isn't primarily for mobile user?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
嗯，它是 1.0 Alpha 1，所以我想说的风险是：
考虑这些成绩背后的原因也很重要：
“A”级表示浏览器的功能，而不是当前或未来与 jQuery Mobile 的兼容性。
如果您想帮助开发新软件，请开始使用 jQuery Mobile，并贡献反馈、错误报告、代码或以上所有内容。如果没有，该团队希望在 2011 年 1 月看到 1.0 版本，这已经指日可待了。
围绕 jQuery Mobile 的理论是为丰富的浏览器提供丰富的体验，并为更基本的浏览器提供功能体验。我认为这是合理的，特别是考虑到 jQuery Mobile 可以让您快速启动并运行一个非常出色的移动 UI。
我想知道您所说的“并非主要面向移动用户的网站”是什么意思。有些网站针对移动设备进行了优化，有些网站尚未针对移动设备进行优化。只有一些非常具体的利基网站不需要移动体验。
Well, it's 1.0 Alpha 1, so I'd say the risks are:
It's also important to consider the reasoning behind those grades:
An "A" grade is an indication of the browser's capabilities, not any current or future compatibility with jQuery Mobile.
If you want to help develop a new piece of software, start using jQuery Mobile, and contribute feedback, bug reports, code, or all of the above. If not, the team is hoping to see a 1.0 release in January 2011, which is just around the corner.
The theory around jQuery Mobile is providing a rich experience to rich browsers, and a functional experience to the more basic browsers. I think this is reasonable, especially considering how fast jQuery Mobile can get you up and running with a really great mobile UI.
I'd like to know what you mean by "a site that isn't primarily for mobile user." There are sites that are optimized for mobile, and there are sites that aren't yet optimized for mobile. Only some very specific niche sites don't require a mobile experience.
作为席尔沃的后续行动，我想补充一点，对你的问题最有用的答案需要了解你的目标用户群。例如，如果您的目标受众通常不会使用移动浏览器，那么您最好针对特定的移动浏览器并让那些感兴趣的各方采取该路线。但是，如果您的用户希望移动浏览器成为主要界面，那么您可能需要更广泛的功能浏览器选项选择。
举个例子，以所有过去需要使用 IE 的旧 Web 应用程序为例，仅仅是因为他们（开发人员）不想或无法保证在其他浏览器上正常运行。如果此应用程序的目标受众是通常使用 IE 的商业用户，那么这不会是一个明显的限制。然而，在更通用的网络应用程序（网络邮件等）中，将所有用户限制为单一浏览器可能会在竞争环境中陷入困境。
不过，我要声明的是，无论您选择哪个方向，即使没有 JavaScript，也要注意 Silvo 关于确保功能性的建议。许多企业、图书馆等仍然限制 JavaScript 功能。
As a follow up to Silvo, I would add that the most useful answer to your question requires an understanding of your target user-base. For instance, if your target audience will not typically use mobile browsers, then you may be better off targeting a specific mobile-browser and letting those interested parties take that route. However, if your users desire the mobile-browser to be the primary interface, then you'll probably want a broader choice for functional browser options.
As a case-in-point, take all the old web apps that used to require the use of IE, simply because they (the developer(s)) didn't want to or couldn't guarantee the proper functioning on other browsers. If the target audience of this app was business users, who typically use(d) IE anyway, then this wouldn't have been a noticeable restriction. However, in a more general web app (web-mail, etc), then restricting all users to a single browser could be crippling in a competitive environment.
However, I will state that whichever of the direction you take, heed Silvo's advice about ensuring functionality, even without JavaScript. Many businesses, libraries, etc still limit JavaScript functionality.
您应该做的是提供丰富的体验，但同时确保即使客户端上没有 javascript（或已关闭），您的所有核心功能也能正常工作。 Stackoverflow 是在这两种方法之间找到良好平衡的网站的一个很好的例子。
What you should aim to do is provide a rich experience but at the same time ensure that all of your core functionality works even when no javascript is present on the client (or it is turned off). Stackoverflow is a good example of a site that finds a good balance between those two approaches.