JavaScript 的渐进增强？
大多数人现在谈论的渐进增强是为带有 javascript 的浏览器（增强版）和不带有 javascript 的浏览器（简单版）提供服务。
但是浏览器之间的 javascript 性能存在如此大的差异，因此应用该术语来支持在浏览器之间基于 javascript 的功能之间进行选择可能会很有用。
在具有许多非绝对必要功能（和动画）的复杂 Web 应用程序中，是否值得开始考虑将它们隔离开来，例如，这些功能集应该在所有浏览器中工作，而这些功能集仅在 Chrome 和 Safari 中工作，以及 Firefox、Chrome、Safari 和 Opera 等中的这些，因为在某些浏览器中启用某些功能会太慢。
有时我觉得如果用户无法访问某些非必要功能，用户体验会有所改善。例如，禁止 IE 用户调整 Chrome 用户可以调整的某些面板的大小。
Most people talk about progressive enhancement right now as serving browsers with javascript (enhanced version), and browsers without javascript (simple version).
But there is such a big difference in javascript performance between browsers that it may be useful to apply that term to support for choosing between javascript based features between browsers.
In a complex web app with numerous non-absolutely essential features (and animations), is it worthwhile to start thinking about cordoning them off for say, these sets of features should work in all browsers, and these sets of features only in Chrome and Safari, and these in Firefox and Chrome and Safari and Opera, and so on, because enabling certain features in certain browsers would be too slow.
Sometimes I feel like the user experience would improve if they did not have access to certain non-essential features. For instance disallowing IE users from resizing certain panels that Chrome users would be able to resize.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我自己没有这样做过，但我可以看到，如果您的预算允许的话，这是很有意义的（并且您无法控制用户的浏览器选择）
最终，IE 用户可能会使用缓慢的浏览器浏览器，但他们仍然是您的用户。因此，如果您想为所有用户提供尽可能最佳的用户体验，那么花一些时间为 IE 用户提供不同版本的应用程序以获得更高级别的性能可能是值得的。
对于 99% 的用户来说速度很快的应用程序无疑比对于仅 30% 的用户来说速度快的应用程序要好。唯一的问题是哪个更重要 - 用户体验，还是你的开发时间（并考虑到几年后，普通用户将在更快的计算机上运行更快的浏览器），
但任何此类工作都应该由基准驱动，因为我的经验是，您经常会惊讶于代码的哪些部分很慢，哪些部分很快。
顺便说一句，Lombardi Blueprint 有一个非常有趣的方法，尽管在 GWT 之外可能不切实际。它们具有用 java 编写的布局算法，编写后可以在客户端（通过 GWT）和服务器端（通过标准 jvm）运行。因此，根据浏览器的基准性能，他们能够在客户端布局（对于快速浏览器）与在服务器端布局（对于速度较慢的浏览器）之间动态切换。
I have not done this myself, but i can see that it makes a lot of sense if your budget allows for it (and you can't control your user's browser choice)
At the end of the day, IE users may be using a slow browser, but they are still your users. So if you want to give all your users the best possible user experience, it may be worth it to spend some time giving IE users a different version of the application to give them a higher level of performance.
An application that is fast for 99% of your users is undoubtably better than an application that is fast for only 30% of your users. The only question is what's more important - the user experience, or your development time (and take into account that in a few years, the average user will be running faster browsers on faster computers)
Any such work should be driven by benchmarks though, since my experience is that you will often be surprised by what part of the code is slow and what part of the code is fast.
As an aside, Lombardi Blueprint has a very interesting approach, although likely impractical outside of GWT. They have layout algorithms written in java, written such that they can be run both on the client side (via GWT) and the server side (via a standard jvm). Consequently, based on the benchmarked performance of your browser, they are able to dynamically switch between doing the layout on the client side (for fast browsers) vs doing the layout on the server side (for slower browsers).
这听起来像是一场维护噩梦。
我意识到有些 Web 应用程序拥有 html 版本是没有意义的。也就是说，如果可能的话，我会首先构建每个页面的 html 版本，然后使用 JavaScript 来增强用户体验。
IE 在 JS 方面的性能不如 Safari、Chrome 和 FF ——但是你真的开发过在开启 JS 的 IE 中无法使用的页面吗？我只是还没有看到它 - 在野外我认为各种 JS 实现都足够快。
That sounds like a maintenance nightmare.
I realize that there are some web applications where it just doesn't make sense to have an html version. That said, if it's possible I would start by building an html version of every page first, then use JavaScript to enhance the user experience.
IE is less performant than Safari, Chrome and FF when it comes to JS - but have you really developed a page that is unusable in IE with JS turned on? I just haven't seen it - in the wild I think the various JS implementations are fast enough.
如今浏览器存在两个不同的问题：
速度。我的经验是 IE 7 运行良好，只是比其他浏览器慢得多。我的解决办法是向用户提供更频繁的 UI 进度更新。由于 UI 更新需要时间，因此我尽量减少速度更快的浏览器上的更新。例如，在 IE 上，我在处理另外 50 个事件后用更多反馈更新屏幕。对于其他浏览器，处理 200 个事件后。
缺乏功能。例如画布。但建设多个站点的费用很大。并测试它们。因此，我将预算花在适用于所有当前桌面浏览器的 1 个版本上。并为移动设备（尤其是 iPhone）制作其他网站。
HTH，
拉里
Two different issues with the browsers these days:
Speed. My experience has been that IE 7 works fine, just much slower than the rest. My fix is to give more frequent UI progress updates to the users. Since the UI updating takes time, I minimize the updates on the faster browsers. Eg on IE I update the screen with more feedback after processing another 50 events. For other browsers, after processing 200 events.
Lack of feature. Eg canvas. But it is big expense to build multiple sites. And test them too. So I spend my budget on 1 version for all current desktop browsers. And make additional sites for mobile esp iPhone.
HTH,
Larry
我所做的是编写一个具有通用功能的基本 javascript 文件，达到最低分母 (javascript 1.5)。然后我有其他最新版本的 javascript 文件，这些文件将替换我的 javascript 对象中的函数，以便我可以逐步添加更多支持。
如果我想使用 canvas 标签，那么我可以将其添加到不同的文件中，因为 IE 和 Firefox/Opera/Safari 在创建 canvas 元素的方式上有所不同。
这对于维护来说并不令人愉快，但如果我想使用新的 html/javascript 功能，那么这似乎是最好的模型。
What I do is to write a basic javascript file that has the common functionality, going to the lowest denominator (javascript 1.5). I then have other files for more recent versions of javascript, and those will replace functions in my javascript objects, so that I can progressively add more support.
If I want to use the canvas tag, then I can add that in a different file, since IE and Firefox/Opera/Safari differ in how they create the canvas element.
This is not a joy on maintenance, but if I want to use the new html/javascript features then this seemed to be the best model.
我同意安迪的观点。为不同的浏览器提供不同版本的应用程序是一个潜在的维护问题。我一直发现提供一个适用于所有浏览器的应用程序版本是更好的选择。例如，我尝试避免浏览器嗅探器。该应用程序可能不是最酷的应用程序，但它适用于每个人并且更易于维护。
现在，有了所有漂亮的 Javascript 库，这些东西就变得更容易了，这些库抽象了一些浏览器差异。此外，您可以在旧版浏览器中执行很多操作。只是“以不同的方式”完成了；）
I concur with Andy. Providing different version of an application to different browsers is a potential maintenance problem down the road. I have always found it a better bet to provide one version of an app, that works in all browsers. For example, I try to avoid browser sniffers. The application might not be the coolest one, but it works for everyone and is easier to maintain.
This sort of stuff is easier now with all the nifty Javascript libraries that abstract some of the browser differences away. Besides, you can do a lot of stuff in the older browsers. It's just done "differently" ;)
假设您构建了一个大小合适的应用程序。您可以通过大量的浏览器嗅探来确定哪些功能将打开，哪些功能将关闭。您对 Opera 9.x 很感兴趣，现在（实际上是今天）Opera 10 发布了。您必须去更新每个页面上的每个嗅探器。然后另一个浏览器很快就会出现......还有另一个。您将花费所有时间来确定您支持哪些浏览器以及支持哪些浏览器功能。
我一天使用多个浏览器。因此，当我访问您的网站时，我将看到三个不同的界面。我会感到困惑，因为我期望的功能或我期望的行为不会出现。最终，我会感到沮丧，再也不会访问您的网站。
此外，JavaScript 的运行速度不仅仅与浏览器有关。我还有一台运行 Firefox 3.5 的旧 Pentium。有时，它可能会慢得令人痛苦。
So let's say that you build a decently-sized application. You have browser-sniffing galore to determine what features will be on and which will be off. You sniffed for Opera 9.x, and now (today actually) Opera 10 comes out. You have to go and update every sniffer on every page. And then another browser comes out soon... and another. You are going to spend all your time, determining what browsers you support and what features to support on them.
I use multiple browsers in a day. So when I go to your site, I am going to see three different interfaces. I will be confused, since the features I expected to be there, or the behaviors I expected will not be there. Eventually, I'll get frustrated and never go to your site again.
Also, there is more to how quickly some piece of JavaScript runs than just the browser. I still have an old Pentium running Firefox 3.5. Sometimes, it can be painfully slow.
我认为答案是您需要将代码分类为速度类别，而不仅仅是分类为浏览器功能。
换句话说，为您的网站提供多层功能，第一层是基本 html，第二层是 javascript 可用性改进，第三层是 javascript 动画养眼。
然后进行组合，允许您的用户随时降级，“单击以关闭动画！”、“单击以打开动画！”、“单击以基本 html 格式查看”，并选择默认为出于速度原因，基于浏览器的某些速度类别（例如，如果 IE7 似乎在打开完整动画时出现速度问题，请将其默认为第二个“javascript 可用性改进”层）。
I think the answer is that you need to categorize your code into speed categories, not just categorize into browser capabilities.
In other words, give your site tiers of features, first tier is basic html, second tier is javascript usability improvements, third tier is javascript animation eye candy.
Then do a combination of allowing your users to step down a tier whenever they want to, "Click to turn off animations!", "Click to turn on animations!", "Click to view in basic html", and choosing to default to certain speed categories based on browser for speed reasons (e.g. if IE7 seems to evince speed issues with the full animations on, make it default to the second "javascript usability improvements" tier).