现代的仅限Intranet的Web应用程序是否仍应使用框架？

Question

我想问一下在仅用于Intranet的现代Web应用程序中使用框架的问题。 当然，在现代互联网Web应用程序中使用或可能不使用框架有几个原因。 但是，当涉及Intranet Web应用程序时（考虑财务应用程序）呢？

考虑一下应用程序中大多数时候始终可见的部分（例如工具栏，菜单，标识等），其中框架可以是做事的简单/快速解决方案？ 当考虑使用PPR之类的东西时，这些优势是否在当今已经很重要？

我很好奇，也都很感谢您对此的看法。

Answer 1

框架并不是从本质上讲是邪恶的，但是它们确实带来了其他方法所没有面对的挑战。 由于您在谈论Intranet，因此您可能不必担心：

• 框架的搜索索引含义
• 可用性/可访问性问题
• 支持截然不同的浏览器（移动，基于文本的浏览器等）

总的来说，可能没有一个很好的理由来躲避它们。 但是，我认为您没有提供令人信服的理由来使用它们。

但是：我可能会看到您遇到的一个功能丰富的 Internet应用程序的一个问题是，您不同的页面/组件可能需要彼此对话。 框架可能是脚本编写的头疼事，仅出于这个原因，我才避免使用它们。

Answer 2

CSS，ASP.NET母版页以及大量其他技术使框架变得不必要，更不用说难看了。

并不是说您不能使用框架，而是应该避免使用框架，因为它们看起来有些不专业。 对我来说，帧与gif动画处于同一级别。

Answer 3

我认为没有必要在现代Web应用程序中使用框架。 即使不是更容易维护，当代的标记技术也一样，可以解决某些框架的烦恼（您永远无法为任何书签添加书签，很难设置页面标题等）。 镜框的大多数缺点都可以解决，但是为什么要打扰呢？

Answer 4

就像其他人所说的，框架已经成为过去。 一个主要的例外是处理文件时，如果您希望获得类似ajax的体验并让用户上传文件，则iframe是目前唯一的方法。

Answer 5

框架无论如何都令人沮丧。 使用AJAX只是刷新您要更改的页面部分怎么样？ 假设您没有被IE6困扰。

Answer 6

绝对不应将框架用于工具栏或菜单。 当DOM在页面之间完全匹配时，浏览器会缓存DOM，从而使iframe最好无用，而在坏处则有害（双重包含JS库等）。

也就是说，有一些特定的框架用例使其成为必需。 但是，直到遇到它们，您才不需要它们。

Answer 7

主啊 是否内部使用，为什么要使用框架，框架又旧又陈旧，并且需要死亡呢。

相反，如果您觉得自己无法打破范例，请使用<iframe> 。

不要误会我的意思，宇宙不会崩溃，如果你决定使用框架，但他们没有真正的标准支持了，你可能会踢成IE怪癖模式，并与更多的头疼结束。 更不用说您最终将使您的用户与上下文冲突，并且该网站将完全不支持智能手机 。

Answer 8

CSS绝对可以克服基于框架和表格的布局。 （->否）