Angular.JS与JSF和GWT的比较

  Angular.JS在企业环境中成为一个开发web应用程序的首选框架,传统的后端是建立在Java之上,而基于前端是建立在Java / XML框架如JSF和GWT之上。

JSF和GWT虽然是两个非常不同的方法,但是他们的主要目标之一是抽象的至少一部分的网络,让Web开发能够通过Java / XML web来完成。

但似乎在这个HTML5浏览器时代,JSF / GWT这样的框架比他们正试图抽象的底层平台还要复杂得多。虽然他们可以工作很好,问题是:代价是什么呢?

通常底层浏览器技术会泄漏到开发人员,他们最终不得不还是要知道掌握HTML、CSS和Javascript,这些都是为了能够实现许多实际的需求。抽象泄漏定律

这使得开发人员想知道为什么浏览器技术不能被直接使用,而且不需要太多的约束和中间的抽象层,因为最后真的没有办法避免浏览器技术。

浏览器技术实际上是远比任何Java框架更简单、更广泛。

当然,我们需要了解JSF/GWT当初是用在企业后端基于Java/XML构建,同样的团队开发人员还会开发前端。从项目管理的角度来看,今天看起来还很有道理。

从历史的角度来看,创建JSF / GWT的背景是:,浏览器当时是一个比今天更怪异的平台,没有这么多开发工具。所以这些框架的目标是抽象一些浏览器技术,使其能够让更广泛的开发人员使用。

Angular vs JSF

JSF或多或少是Ajax在web开发爆炸的十年中同时诞生的。JSF的初始版本设计时没有考虑到Ajax,相反它是一个完整的页面请求/响应模型。

在这个模型中,一个类似dom树代表用户界面的组件存在于内存,但这棵树只存在在服务器端。服务器视图就来回被转换成HTML、CSS和Javascript,把浏览器作为渲染平台,没有状态和只能有限对其控制。

服务器视图生成的页面将转换为HTML、CSS和Javascript,在发送给用户的页面之前通过一组特殊的类称为渲染器进行渲染。

用户通过和页面交互,通常通过一个HTTP POST发回一个动作,然后服务器端通过控制器触发JSF生命周期,恢复视图树,将新值应用于新视图和验证,更新域模型,调用业务逻辑,并呈现新的视图。

JSF 2框架进化支持本地Ajax和无状态web开发,但主要的方法还是从服务器端生成HTML。

Angular与其不同的是,MVC( Model, View 和Controller)已经从服务器端移植到浏览器端。

在 Angular中, 浏览器技术不应被看作是回避或隐藏的东西,而是使用它的全部能力,可以构建一些类似于Swing胖客户机而不是简单一个web页面。

Angular通常不很少状态在服务器端,主要是通过REST服务和JSON格式。

而在JSF中Javascript通常是只有JSF库包开发者才需要掌握,一般应用开发无需掌握,类似Primefaces 这样的库包已经包括Jquery等库。但是在真正开发时,开发人员不会细分到这种相当细致的地步,Web开发人员还划分两种开发人员。

Angular vs GWT

两种最主要的区别是是否需要掌握Javascript,GWT提供了一种Java方式来编译输出Javascript,在这种模型下开发,开发人员只需要掌握Java ,构建的代码被编译到Javascript可以在浏览器中执行。

在GWT,HTML和CSS并不是为了对开发者完全隐藏,XML名称空间提供给用户实现页面的布局。 HtmlPanel组件用于直接使用HTML 和 CSS建立页面,这与JSF一样,这两个框架都是力图最大化使用XML尽量避免HTML和CSS。

GWT的编程模型是从面向对象的角度来看web页面,页面在程序中被视为一个相互关联的网络对象,而不是一个文档。文档和元素等概念被框架隐藏起来了。但事实证明,这种额外的间接层虽然开发人员对其比较熟悉,但最终不是很有用。

事实上,页面和元素的概念已经足够简单和强,,他们不需要额外的抽象层。使用面向对象的抽象页面,开发人员往往最终不得不通过无数个类调试简单的事情,这些简单的事情包括发现 添加或删除一个简单的CSS或包装在一个元素在div中。 

超级Dev模式是有所帮助,但感觉整个GWT的对象层次结构有问题,将Java到Javascript的编译器和几个调试模式以及浏览器和IDE插件捆绑在一起的生态系统变得复杂得多,他们其实都是在试图隐藏最先的东西:网络。

 

AngularJS与服务器端MVC比较

Angular.js教程

 

猜你喜欢