首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >只有HTML/JavaScript的web应用程序的优缺点

只有HTML/JavaScript的web应用程序的优缺点
EN

Software Engineering用户
提问于 2012-05-05 23:04:57
回答 5查看 15.7K关注 0票数 35

我来自ASP.NET窗体背景,过去发现服务器端编码非常强大。然而,最近,我一直希望逐步取消前端的服务器端代码,并将其替换为纯HTML/JavaScript,后者通过JSON out服务访问数据。我在这方面没有真正的经验,所以我想知道这是否是一个经过试验和测试的模型。还有,围绕着它的陷阱是什么?

我发现ASP.NET用户控件非常有用,所以我希望通过将标记模板存储在服务器上的单独的HTML文件中来保持理论基础。它们将分别通过jQuery AJAX和jQuery HTML插件检索和使用。

如有任何意见,将不胜感激。

对不起,这类Web体系结构被称为web-2.0,还是我完全偏离了轨道?

EN

回答 5

Software Engineering用户

回答已采纳

发布于 2012-05-06 01:52:23

我已经将这种技术专门用于我们正在开发的一个web应用程序。我的后端使用Java托管在Google上,我的前端使用HTML、CSS和JavaScript (与jQuery一起使用)。

这个项目是一个较小的项目,只有我和一个网页设计师,我们都觉得这种方法帮助我们工作得更快,并得到一些更快的市场。

优势:与网页设计师合作

这种技术的主要优点是,了解一些PHP但不认为自己是程序员的Web设计人员可以在HTML和CSS中不受限制地工作,而不必费力地浏览无数行JSP、taglib标记和其他服务器端标记,这些都是我们多年来一直被告知的,应该可以使前端开发人员的生活变得轻松得多。

如果没有所有的服务器端标记,我们就会变得更加灵活。网页设计师已经直接更换和修改他的原始设计3或4次,很少改变在我的部分。

他对我的评论是,他觉得HTML是活的,因为他可以编辑它,然后立即用动态数据看到机器上的变化。我们都从中受益,因为集成大多是自动的。

服务器端代码和

/CSS切换

在过去的项目中,他不得不将HTML和CSS切换给Java开发人员,然后Java开发人员会使用他的HTML和CSS并使用JSP技术彻底重写它们。这将花费大量时间,并且通常会导致页面的实际呈现和W3C验证器中的验证存在微妙而重要的差异。

总的来说,我们都很满意这种技术,而且我的HTML页面中仍然没有JSP页面或服务器端代码。

REST/JSON技术的

缺陷

也许最大的陷阱是那些我们还没有遇到的。我完全希望与经验更丰富的Java开发人员有一些分歧,他们被Apache基金会和Spring团队告诉他们的关于标记库如何使前端开发人员更容易地处理代码的问题洗脑了。我完全期望随着这个项目的扩展,会有一个学习曲线,并且我们会雇用更多的开发人员,他们可能不得不取消这些过时的技术,根据我的经验,这些技术就是使网页设计师的工作更加困难

另一个缺陷是JavaScript代码变得非常庞大。这可能是一个更大的问题,因为我第一次使用这种技术,也因为我们在快速发布的过程中引入了一些轻微的技术缺陷。也许选择一个更好的框架将有助于减轻大量代码。在我看来,所有这些都不是一个展示,我被鼓励继续使用这一技术,并完善我在这一领域的技能。

优势:其他应用程序可以构建在平台

最后,我应该提到一个隐藏的优势。因为我的后端RESTful服务和我的前端之间有很好的分离,所以我还创建了一个可以轻松扩展的平台。

我们的一个操作人员希望在另一个应用程序中尝试概念的证明,由于我的RESTful服务,我们能够为应用程序创建一个完全不同的前端,以解决一个完全不同的问题。快速发展的概念证明使用了它自己的HTML、CSS和JavaScript,但它使用RESTful服务作为后端和数据源。

最后,另一位项目经理看到了我所做的事情,很快就清楚了,这个特性需要的不仅仅是一个概念的证明,所以他的团队实现了它。

无论是在应用程序级别还是在HTML/CSS/JavaScript级别,我都不能充分强调这个体系结构的可重用性,我肯定会鼓励您在下一个项目中尝试这一点。

票数 31
EN

Software Engineering用户

发布于 2012-05-06 14:14:52

这当然是一个可行的策略,但它不是一颗灵丹妙药。

Pros

  • 如果操作正确,以这种方式开发的应用程序具有很强的响应性。
  • 逻辑(在服务器上)和表示(在客户机上)有一个清晰的分离;服务器根本不必关心应用程序的表示方面。
  • 可能更有效地利用网络带宽(您只发送原始数据,没有表示样板)
  • 更容易开发类似桌面的GUI,因为您不太依赖请求/响应范式

Cons

  • 您必须用Javascript编写客户端代码,或者编写一种可以编译为Javascript的语言,因为这是浏览器中唯一可用的东西
  • 客户端上的资源使用可能更高,因此应用程序在不合格的设备(例如移动浏览器等)上可能不能很好地工作。
  • 在禁用javascript的情况下,它根本不起作用;如果它有一个面向公众的网站,那么您必须认真考虑是否愿意承担这种风险(特别是考虑到SEO和可访问性-javascript式的方法通常在这两个方面具有破坏性)。
  • 许多逻辑必须写两次:一次在客户机上,一次在服务器上(因为您永远不能信任客户端)
  • 并发性可能非常糟糕,因此您需要非常仔细地设计客户端代码,并为各种并发问题做好准备。
票数 12
EN

Software Engineering用户

发布于 2012-05-05 23:23:42

缺点之一是需要复制JavaScript和ASP.net中的一些逻辑。根据应用程序的不同,这对您来说可能不是什么大问题。这通常是因为您不想让服务器检查每件小事(“在这种情况下,用户是否允许按此按钮或选择此选项?”)但是,您也不希望依赖客户端作为唯一进行验证的客户端,因为用户可以控制客户端。

票数 1
EN
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://softwareengineering.stackexchange.com/questions/147423

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档