友好的开发框架-Asta4D（1）：为什么Asta4D

公司去年开源了一个WEB框架－Asta4D，这个框架用来支撑公司的服务网站，经过一年的开发，已经基本达到成熟的阶段了。问题是，在WEB框架汗牛充栋的今天，我们为什么还要开发一个新的框架呢？

我们本来是用Scala开发的，选择的开发框架是著名的Lift，因为种种原因，我们决定回到Java上来，公司的开发人员对Scala和Java本身没有太大的情绪，觉得各有优劣而已，但却一致同意Lift是我们用过的最好用的框架，没有之一，回到Java没有问题，但没有Lift却是个大问题。

我们向自己提问，是什么让我们觉得无法离开Lift？总结起来主要有两点：

1. View First，View First的开发模式对开发效率的提升是非常显著的，在这一点上，Java世界流行的MVC框架绝对是完败的，我们的开发人员一致认为，Java不会让我们厌烦，但如果只能选择MVC的话，那就不如停留在scala了。

2. 纯粹的HTML模板，不在页面嵌入任何动态渲染代码，页面渲染通过独立的Scala类来完成，这个最大的好处在于后端和前端开发可以在相当大的程度上分离开独立进行。前端人员的工作不会受到任何动态渲染代码的干扰，我们的实践证明，这种分离的模式，可以削减至少90%的页面重构的工作量。而另一方面，后端开发人员也无需学习新的模板语言，直接用Scala代码就可以完成任意复杂度的渲染逻辑，这是任何号称强大的模板语言都无法做到的。另外，在Scala代码中通过CSS Selector引用页面元素进行操作，让人感觉非常自然和舒服，当然，也是非常强大的。

这两点其实是联系在一起的，所谓的View First，说白了就是传统的PHP的开发方式，写到哪儿算哪儿，在html页面中需要输出数据的地方嵌入代码，查询数据，然后输出，从写代码的角度来说，这种做法是非常高效率的，从html文件的第一行滚动到最后一行，把需要动态输出的地方嵌入代码，工作就算完成了，但显然，这样的代码从维护的角度来说，基本上就是垃圾，这也是为什么MVC架构得以流行的原因。LIft给出了不同的解决方案，通过将模板的渲染逻辑分离，使得我们既可以获得View First模式的开发效率，又不至于陷入魔鬼代码的泥潭。

接下来的问题就很明瞭了，我们要么找到一个已有的基于Java的View First框架，要么停留在Scala上，或者最后的选择，自己做个新轮子。

Java的View First的框架几乎没有，我们找到的只有一个Apache Wicket，严格的讲，他并不是view first，而是更重视模板和代码的分离，但他的思路和我们预想的不太一样，Wicket把html组件映射成Java对象，然后用C／S的模式编程，我们觉得，lift通过CSS Selector直接操作DOM元素显然更加直观，也更为简洁。

看上去，我们必须作出决定，是否要自己做个新轮子，但从头开发一个新框架的工作量是可观的，我们事实上最多只有两个全职开发人员可以投入进来不超过两个月的时间，我提议我们可以把我们的框架构建在一个既有的Java框架之上，比如Spring MVC就不错，通过对既有的MVC框架的扩展来实现我们需要的核心功能，将剩下的功能可以暂时交给依赖的MVC框架去完成，于是，我花了一个礼拜的时间，在Spring MVC的基础上，构建了一个概念验证的原型，证明了在Sping MVC的基础上构建一个完全View First的框架是可行的，团队内的开发人员一致同意，我们得到的原型虽然因为Java语言的原因没有LIft那么简洁，但绝对是一个可以接受的 Lift Java Port。

于是，我们有了Asta4D，Asta来源于公司的名字：astamuse， 而4D，我们将其解释为：

For Desinger：Asta4D极度关注设计友好度，我们希望，网页设计师可以最大程度的发挥他们的创造力而无需浪费精力在他们永远不可能精通的后端技术上。现在，他们只需要面对他们熟悉的HTML和CSS就够了。

For Developer：Asta4D同时也希望帮助开发人员更好的完成工作。从模板分离的渲染逻辑使开发人员不必为了复杂的渲染逻辑而头痛，他们可以用Java轻松完成任意复杂度的渲染逻辑。另一方面，View first将开发人员从MVC的桎梏中解脱出来，现在，他们可以有更多的时间喝咖啡了。

4 Dimension：我们希望Asta4D能够成为跨越第四维度的虫洞，帮助开发人员更快的在现实的三维空间移动，想象一下，5名前端和设计人员对页面进行了一整天的大规模重构的同时，后端开发人员却在做性能优化，他们之间甚至几乎没有交流的必要，只是应前端的要求，进行了不超过5次，每次不超过5分钟的代码修改，来应对前端重构导致的逻辑不整合。这就是我们的网站最近一次页面重构的真实情况，这是我们从来没有在其他框架上享受到的快捷和舒适，削减90%的页面重构工作量，绝对不是广告而已。

虽然我们最初是因为希望有一个View First和模板代码分离的Java框架而决定开发Asta4D，但当我们真正开始开发的时候，有了更多的想法，并决定要尽快开源Asta4D，因为我们认为，Asta4D所解决的问题，是极具代表性的。

在过去十年，基于Java的MVC框架如同雨后春笋一般层出不穷，但都不愿意面对或者解决的问题是，它对前端设计师极不友好，而且，开发效率及其低下，互联网企业鲜有基于Java，尤其是基于MVC来构建自己的网站，是有深刻的原因的：

1. 对前端设计师极不友好。MVC模式下，可编程的模板语言成为非常重要的角色，而以视觉创造为主要工作的前端设计师，他们熟悉的是HTML和CSS，而嵌入模板文件的各类动态代码，对他们来说即使不是如同天书，也是及其让人及其困惑的，当然，他们必然要面对这些内容，因此，传统的PHP必然成为他们的最佳，因为，这个至少是比较容易让人理解的。

2. 开发效率低下。互联网企业的开发通常是快速迭代的，并没有明确的需求一说，传统的PHP开发模式之所以受到青睐，就在于它易于变更，开发速度快，MVC模式的开发在这一点基本完败，因此，很少有互联网企业会基于Java来构建自己的前端页面，即使有，也通常是基于JSP的自有框架。

更进一步的，在过去将近10年的MVC历史中，我们其实一直都被下面的问题困扰着：

1. 前端设计师和工程师一直在抱怨嵌入到页面的动态代码让他们很难对页面进行大规模的重构，而另一方面，后端开发人员也经常抱怨他们要花很大的精力才能修复前端对页面的重构带来的问题。

2. 开发人员经常还会因为模板语言贫乏的功能而饱受折磨。一些特殊的复杂渲染逻辑经常需要富有经验的开发人员才能写出极具技巧性的代码来实现。而这样的代码，通常会成为谁也无法理解的魔术代码。

3. 开发人员对MVC低下的开发效率极度不满，我们一直在渴望可以有一个更加高效的开发模式。

我们认为，Asta4D提供了对上述问题的完美答案，Asta4D通过分离的模板和渲染逻辑向前端工程师提供了最为友好的工作环境，而另一方面，后端开发人员再也不必受到模板语言的折磨，Java将成为他们手中最趁手的武器。更为重要的是，通过分离模板使得前后端工程师可以独立的工作而不会互相干扰，这极大的提高了开发效率，前面已经提高过，我们因此而削减了大约90%页面重构的成本。

 

另外，Asta4D的View First机制，提供了远远超过传统的MVC模式的开发效率，并且使得变更更加容易。

更进一步的，Asta4D引入了函数式编程的“副作用”的概念，通过对副作用的隔离，使得页面的渲染逻辑变得极富弹性，在Asta4D中，多线程页面渲染是基本的内置功能，开发人员可以轻松的选择多线程渲染模式而无需担心线程安全问题。

 

最后需要说明的是，经过一年的开发，我们已经完全移除了对Spring MVC的依赖，现在Asta4D是一个可以完全独立使用的框架，但是，因为我们最初是基于Spring MVC来构建的框架的基础，因此，Asta4D和Spring的结合是非常完美的，事实上，我们自己的网站，也是使用Spring来做bean的依赖管理的。更进一步的，asta4d-spring包提供了如何将外部的bean容器集成到Asta4D中的例子，因此，参照asta4d-spring的实现，可以很容易的集成其他bean容器。