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开发人员还划分两种开发人员。

两种最主要的区别是是否需要掌握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插件捆绑在一起的生态系统变得复杂得多，他们其实都是在试图隐藏最先的东西：网络。