网页设计领域经常会遇到一些坑爹项目，明明几百个页面需要几个人做2个月完成的项目，而经费就只够一个人的，市面上这种项目还不少，而且都在快乐的生长。。。

网页设计如何做到这样低的成本？这还要从最基本的原理讲起。

网页开发不同于传统的程序开发，主要归结一个字就是“乱”。如果仅开发一个页面还好，多个页面的话，难受一点。如果是个巨型工程，比如1000+个页面，好吧，代码的混乱程度可想而知。

为什么会产生这种情况？难道网页设计不是程序设计吗？

一切的一切，需要从计算机原理讲起

电脑是什么？可以理解为CPU+存储，你可以通过输入设备，如：键盘，u盘，网络等等，把需要处理的数据放在存储设备中，然后CPU按照存储设备上的指令一条一条的向下执行。其实就这么简单，写好一段程序，放在存储中，然后CPU就会严格的按照你的指令去执行。而这些指令集，是程序员预先编制好的，我们把它叫做“软件”。

好啦，说到这里会不会觉得电脑很简单，软件也就那么回事？其实真的就是这么回事也。

那么问题就来了，现在电脑的运算速度是很快很快滴，有多快呢？比如我们用的笔记本电脑，假设你的CPU是i7的（别告诉我你不知道什么是i7），那么每秒钟，记住是每秒钟哦，你的本本会处理100亿条指令。100亿条啊，这是什么概念呢？一个程序员一天如果写1000行代码（这个是业界平均水平啦），那么他需要两万七千多年才可以为您展示1秒钟的内容。

看来貌似简单的问题复杂化了，这就好比是愚公移山，没错，挖土很简单，运土也很简单，但要挖掉一整座山，况且无良的老板需要你1周内完成工作，那么你需要想别的办法了，至少靠铁锹是不行滴。

怎么才能实现100亿条指令的产量呢？

其实从上世纪70年代开始，或者说更早从第一台电子计算机开始（1946年），人类就不断的在如何提高代码产量的道路上探索前进。

最开始的办法叫做“编译”，什么是编译呢？简单来讲就是把一组计算机指令用1条计算机指令来代替。这样程序员写100行的代码，也许实际上会编译出1000行甚至10000行代码。

哇塞，那比起写机器代码简直就是飞跃啊，写代码的速度比原来提高了10-100倍啊。

到这步恭喜你，原来需要27000年的任务，一下子缩短到了270年，但这还不够，我们继续......

随着电脑运算速度的提高，电脑对软件的需求量急剧增长，软件的“尺寸”也越来越大，我记得1990年的时候，一个300k尺寸的软件就可以算是巨大的软件工程，而仅仅靠“编译”那已经接近于软件开发的极限了。为什么呢？软件不可以叠加吗？答案是不可以。

随着软件体积的逐渐增大，里面的函数就会越来越多，所使用的公共变量也会越来越多。这就好比是草原上的野草，每根都长在同一个平面上（地面），如果让你立即按照特征找出其中一根来，几乎是不可能的。

那怎样才能突破这个极限呢？前辈们想到了一个绝佳的办法，那就是对代码采用树状的管理体系，简单来讲就是把所有的代码分门别类，放在树状目录下面。这样程序员就可以根据分类快速的定位代码的位置，同时由于代码区间的划分，外部或者是全局变量也得到了很好的解决。这就类似于把草原上的草分门别类的装到了一堆箱子里，然后把这些箱子再按照分类以树状的形式摆放。

这种设计思路就是鼎鼎大名的“面向对象”程序设计。

这个设计思路源自于上世纪70-80年代，在上世纪90年代得到了广泛应用。

一直沿用至今沿用至今沿用至今！！！

我们生活在21世纪耶，iphone都快到10了，难道我们的软件设计采用的还是上世纪老掉牙的技术？！

也许是面向对象过于超前或者是现在的技术无法突破，总之总之，事实就是这样，面向对象仍旧是软件设计领域的唯一（不是第一也不是第二也不是之一）选择。

说了这么多，这和Web开发有啥关系呢？既然已经完美了，还有什么好说的？

好吧，我继续讲故事。。。

话说程序界已经进入了完美阶段，至少目前是无法找到更完美的设计思想，这时飞来了一只巨大的苍蝇，这只苍蝇打破了原有的完美格局，这就是web应用开发。说的土一点就是做网页呗。

自从上世纪90年代互联网的兴盛开始，当时没有任何一个人能预计到小小的网页能发展到今天如此规模的应用（至少微软没想到），于是乎程序前辈们在网页设计架构上犯了一个致命的错误，那就是部分（不是全部）抛弃了经典已久的“面向对象”程序设计思想，而这个致命的错误随着互联网的高速发展被不断的扩大至今，几乎已经达到了不可弥补的程度。

当然了，这也不能全怪先辈们，因为Web应用和传统的软件是不太一样的，传统的软件在一台电脑上运行，而Web应用是在2台电脑（客户端和服务端）之间跳来跳去的执行。而近几年的所谓CSS架构更是让Web应用走向了远离“面向对象”程序设计思想。

另外一个原因是在上世纪，Web应用规模都还很小，没有人能预计到20年后的大规模应用，所以Web应用在创立它的最初就走上了一条奇怪的路线。

那么目前的Web应用开发形式都存在哪些实际意义的问题呢？

首先就是开发语言无法统一：比如前端采用的都是html+js+css的形式，而后端采用的却是C#,java,php等。

其次就是代码从宏观角度讲都在一个层面上，在大型项目应用中，代码之间的相互干扰是以指数级增长的。

最后，竟然没有一个可视化的设计平台（全世界都木有啊，都木有，都木有），目前vs,eclipse, dreamweaver等都号称可以进行可视化开发，但用过的人都知道，只要可视化不能做到1：1，那么提供的可视化开发环境就是一个笑话。

我记得还是上世纪的90年代，设计windows窗体程序就可以做到1：1可视化，全面向对象程序设计，统一的语言和代码风格......

为什么我们进入了人类大发展的21世纪，这些反而都没有了呢？这不科学啊

其实超大规模的Web应用在我们的这个时空还是存在的，比如金蝶用友的系统，都不会少于10000个web页面（再次强调，1万个啊），他们怎么做到的？

凭借传统的VS和eclipse，我就告诉你，别想了，就像愚公拿个铁锹挖山一样，除非你感动老（tou）天（zi）爷（shang），给你追加100倍的投资。

答案是：金蝶和用友都具有自己内部的中间件平台，o，yeah，好厉害。

问题又来了，人家的中间件是公司内部用，不对外开放滴。当然了你也可以跑到人家内部偷偷的考出来一份自己用，但是我要告诉你，这些中间件的通用性是有问题的，也就是说拿这些中间件做个管理系统是没问题的，做点别的......你想多了。

当然了，任何困难都挡不住人类前进的脚步，于是ePage横空出世了！ePage横空出世了！ePage横空出世了！

下面说说本人使用ePage做项目的感受吧。

受够了20年的Web设计残缺，ePage的出现将带出一个开发Web应用的完美解决方案

首先，ePage解决了前后端开发不对等的问题，在前端和后端都同时采用了js设计语言，从源头上统一了代码，为后续的代码封装铺平了道路。

其次，ePage沿用面向对象的程序设计思想，对所有代码及页面进行了树状封装，避免了代码和页面之间的项目串扰，也避免了页面内部各元件之间的代码串扰，甚至对客户端与服务端之间的交互过程进行了封装。

最后就是1：1可视化设计，你在设计界面看到的就是浏览器看到的，完全一样。这个是目前VS和eclipse等主流工具永远无法做到的。

有了以上三点，页面的制作速度可想而知。带来更大的好处是维护的工作量也降低到原来的1/10至1/100。

一个“编译”让程序员的开发效率提高了10-100倍，而一个面向对象再次将效率提高了10-100倍，同时可以开发超大规模应用。由于目前的web应用开发还停留在1/2面向对象阶段，所以ePage利用了这个机会，把刻度向前推进了1/2的距离。别小看这1/2，它带来的产量是惊人的，也许会推动下一次的Web设计开发领域的大变革，让我们拭目以待。

在使用ePage做项目的过程中还有很多感受和心得，后续的文章我会慢慢讲解，希望大家多多支持我哦。