最近对Web前端有很多想法，刚好看到这篇文章，跟我想法不谋而合，所以翻译出来与大家分享。许久没翻译了，里面多少还是有些我没能完全理解，意译过来，如果错误，请务必指出和修改，谢谢。
原文The Time is Now for Front-End Architects， 来自：Garrett Dimon，感谢作者的许可。
去年，我在YTS发表了前端架构师的想法，之后花更多时间来思考，现在更坚信这是一个不可或缺的角色。
当后端技术伴随.Net, Rails和Java之类的框架发展得越来越抽象和强大，前端技术的潜在发展也日益复杂。在束缚前端技术潜在好处的差劲实现之前， Web需要更多的前端架构师。
多亏了诸如跨浏览器支持的先进技术的发展，用户体验、更多有意义的主题比如无障碍都拨云见日，这个世界再也不仅仅就HTML和CSS如此简单，因此，绝大部分的团队都需要一个真正理解和实践涉及到前端的一切的人。
角色
这并不是一个扼要和简单的清单，对于下面的主题／技术，前端架构师也不能仅仅满足于了解一下里里外外而已，而是需要足够的深入研究，并有自己出色的见解。
- XHTML
- CSS(1, 2, 3)
- 跨浏览器和跨平台
- DOM脚本编程
- AJAX
- Flash
- 渐进增强和适度降级
- 无障碍
- 可用性
- 信息架构
- 界面设计
- 视觉设计
- 表现层逻辑（ASPX, Rails视图等）
- 商业规则和逻辑
作为一个前端架构师，必须拥有这些领域的绝对执行力。例如，前端架构师能够决定某个特性是使用AJAX还是传统的页面刷新。哪个更便于使用？对无障碍的影响如何？改用Flash有意义吗？
拨乱反正
表现，结构，行为和商业逻辑的混杂，导致不必要的复杂，导致难以维护的怪胎解决方案。就如后端需要正确地划分为数据层，商业逻辑，表现逻辑等，前端开发复杂到是时候调整其架构了。
编写良好结构或者说避免使用表格布局是远远不够的。这是第一步，前端架构的哆咧咪而已。现在是时候关注DOM脚本编程，AJAX, 无障碍等，该升级了。
非编程不可
我主张前端架构师必须懂得真正的编程知识，而这正是很多自封为前端架构师的人所缺乏的。我的意思不是能够剪切粘贴改进代码就行了，而是能够跟老练的工程师商讨如何能够最好地结合前端。
这就是说，前端架构师需要真正理解结构遭遇商业逻辑的问题。如果工程师说某些东西使用ASP.Net DataGrid是不可能实现的，前端架构师必须能够解释如何与为何要使用DataList或Repeater取代，解释为何DataGrid在该情景下是个错误的选择……
这只是个例子，问题还在于仅知道客户端编程也是不够的。能够使用与工程师相同的术语，能够讨论（前后端）关键集成的最佳解决方案，这是绝对必须的。
断线的风筝
我们今天正处在一个不妙的处境中，原因在于几乎没有人能够为前后端的沟壑搭桥。一般工程师不会有兴趣或实践标记，CSS, 或DOM脚本编程，大部分客户端开发者也没有与后端技术协作的经验。几周入门PHP不会成为程序员，几周入门XHTML也不会成为真正的客户端开发者。
罪魁祸首
我首先想到的十足例子是，ASP.Net完全漠视Web标准，同样地，web氛围（我们指表格和占位gif）让Web标准郁闷。企业项目的大多数框架输出的标记，即使使用1999年的标准来衡量，都是糟糕无比的。
如此巨大和“专业”的产品怎么能才够不忽视，按理说是整个项目最简单的方面？只有静态代码。理由是，基于技术的立场衡量产品，结构，CSS和其他客户端技术都是“事后诸葛亮”。表现逻辑，结构和行为混杂，压根无助于无障碍，Web标准，或者前端技术干净的分离。抬起你的头来，就在2006，这些都成受欢迎的惯例了。
总结
如果这个世界上姿态最鲜明的产品和项目都如此低劣的方式来处理事情，其他的还有什么好说？毫无疑问，我们需要前端架构师，而且就在昨天。
归结于归结，我们有一堆相互关联的技术，很少人能够埋头钻研它们之间的关系，这很不幸。正确做事的真正价值在于容易的维护和长期的适应性。虽然在关键时刻，有些方式更容易选择其他的方法和拼凑起另外的东西。对某些人来说，这可能是可接受的做事方式。但是，对我们大部分人来说，这是拙劣的抉择，也非常不专业。
我交给你去想了。我假设你把车交给技工修理，修好了时候，瞧瞧引擎罩内大量的输送管，我不知道你对技工作何感想？
October 27th, 2006
by 冷韵
很荣幸，能在第一时间读到lazy的译作。比之之前提供的英文资料容易接受多了。
读了一遍，有些兴奋但更多的是疑豫。如何理解前端架构师这个概念呢？似乎是加强版的网站策划，需要更多应用层面的技术。
分工越来越细，要做到这个层次可能就是一个高度吧。
对自己信心越来越少了：（
October 27th, 2006
by Kiefer
要掌握这么多东西，才能对整个构架有个良好的把握，看来还要努力了！
October 27th, 2006
by tenlin
今天一来读到这么好的文章，其它的好话废话不说，realazy的译文都说的很详细，非常感谢在我极度迷茫的时候给我职业人生一个准确的定位，也坚定了我的发展方向。very thank～
October 27th, 2006
by 夏天
个人认为这应该是一个团队~~一个人有时候很难胜任~而且如果只是一个人来做的话有时候很难验证自己，如果是团队可以更好的校正方向。所谓前端架构师，我个人认为不如叫作信息构架更合适一些。这个人物是团队的领导人物，团队的组成会涉及多个方面，这样可能更好。
October 27th, 2006
by realonlyjj
如果这样,就等于就是现在的前台设计师做的事情,而近年才好不容易分出了UI UE部门,是要把这些重新划给一个人做?他和项目经理的关系又如何互动?
再说现在好一些的设计和前台人员做的就是这些了,这里只是更强调了程序的重要性.这对老板们来说毫无意义,最后顶多就是多一个时髦的称呼.
October 27th, 2006
by realazy
The Author
夏天和realonlyjj或许对文章的本意有些许误会，这并不是说前端架构师包办一切，而是领导整个前端团队，这个团队当然包括分化出来的UI,UE, IA等部门。何谓领导，就如文中所说，需要绝对执行力，能够决定用什么不用什么，决定怎么用等。在作出决定之前，如果没有相应的知识把关，很难想象能够作出优秀的产品。
其实我是对目前国内，更严格说，我所经历过的团队的失望。前后端的沟壑很严重，产品往往只要功能，至于前端的实现，完全交给后端工程师，很多后端工程师的前端解决方案让我非常不能接受的，但是，我没有任何话语权更不用说执行权。
我认为，现在中国的产品经理都必须往这个方向靠，我们才会有希望。
October 27th, 2006
by 司马易风
要想做一个出色的前台设计师,好难啊~~要加强学习啊
October 27th, 2006
by realonlyjj
回的真快
觉得如果这个是技术部门的头,那还是需要整体协调策划部门与技术部门或还有设计部门的头吧.
认同产品经理需要懂这些,包括技术也包括设计和UE，还应该有市场方面的，但应该不需要懂的太具体，强调某一方面都是不正确的（不过现实中肯定是会某方面强些），产品经理是应该是个使各部门充分发挥各自特长,并使各自特长高效结合产生结果的人.
October 27th, 2006
by jhoo
总是会有矛盾的，前端后端衔接一直是一个问题。团队作战的意义在于每一个冲锋陷阵的人做好自己的工作就可以了。决策上的事情的确是由专门动脑子的人来想的。就像美国总统不一定要会做原子弹一样。他知道怎么做出来的就可以了。不知道我理解的对不对~我是搞设计的，专心做我的设计就好了。怎么样把握项目把握客户，用理念来影响客户，用视觉来震撼客户。至于实现的问题 就完全交给技术人员来做。我还是相信一句话，没有做不到的 只有想不到的。看一看只要我们能想到的东西 几乎不也都实现出来了么。
October 27th, 2006
by 白鸦
这篇文章非常棒~
October 27th, 2006
by 天牢囚犯
好文~~~非常棒~
October 27th, 2006
by realonlyjj
同意jhoo的
October 27th, 2006
by Semon
确实现在缺少这样一个明显的职位，应用的概念已经从后台扩展到包含前台应用，虽然有很多工作互动开发（一般掌握flash编程和html/js相关技术的人）能够按照经验和一些给出想法，但是其地位是不太被重视的。实际的需求上，对前台代码的要求和整体的把握是需要有不同技术背景，能融会贯通宏观考虑问题的人。这个未必就一定是技术部的头，他需要配合后台应用构架进行整体技术上的规划，更清楚用户需求中的使用者定位，更关心用户体验。
October 27th, 2006
by Semon in Node
[好文]是时候了，前端架构师…
…
October 28th, 2006
by 温泉
其实职称到无所谓，关键是现在这么多前端的工作面前，的确需要有一个角色来负责来统筹和协调工作
October 29th, 2006
by blog中文翻译 » 是时候了，前端架构师
[...] 感谢realazy的投稿，欢迎访问他的blog [...]
November 12th, 2006
by Aether
我习惯的说法是Web Architect，后台到程序则属于Site Architect的范畴。
土豆这里有一个好处，就是前端目前都被两个人包办了，虽然人力紧缺，但是至少架构却被顽强地构建了起来，等待应用和扩展的时刻。
November 12th, 2006
by Aether
亲爱的楼主，我觉得你现在的排版很适合阅读但是不适合导航-.-
连上一个和下一个我都找不到，也找不到近期新文章列表……
有什么特殊的理由吗？
November 12th, 2006
by realazy
The Author
@Aether
读者只会找她／他感兴趣的文章阅读，我怎么知道我当前文章的上一篇或者下一篇她／他还感兴趣？所以我不考虑在每一篇加上这些东西。首页右上角有每一页的目录，可以方便跳转到感兴趣的文章上。最新文章？我的读者绝大部分是RSS订阅……
December 6th, 2006
by summer
分工的确是越来越细的，目前web前端程序的设计师很少，最开始web展现力有限的时候不需要javascript，不需要很多的css，而且以前从事web的工程师很多都是转行来的，页面上的展现很少关注，只考虑把数据拿出来丢给UI去展示就OK了。
随着web技术的细分，市场越来越重视web程序，Qzone的javascript就很多很多。那个做Qzone的小伙子Blog地址不记得了，他就是专门搞前台web程序的，javascript脚本优化，性能调优等等。
April 2nd, 2007
by babani
不错啊，请问架构师的年薪是多少啊？现在有多少家企业在招聘架构师呢？
April 19th, 2007
by liminany
你说得很对.优秀的团队是应该把前端与后端区分开来,不管是前端还是后端都应该对各自的领域有所了解,这样沟通起来才更加容易,当然做为合格的架构师决策能力是必须的.项目经理也必须了解前端,他是中间桥梁,起作协调与沟通的作用.
那我提一个问题:那在前端与后端还有必要增加一个缓冲与协调的中间层吗?
June 11th, 2007
by sniper
看了以后非常受起发啊，其实我一直在做这样的工作，但在公司里却得不到太多认同，虽然帮公司解决了不少问题，可到头来得到的评价只是解决问题的能力比较强，在大部分的时间里我只能不停的为别人擦屁股。
我也一直在想我这个产品经理的位置坐的非常奇怪，因为我所关注的东西与其他产品经理总是不太一样，他们总是关心这个好不好看，而我总是关心合不合理，今天看了你的文章，终于明白我要找的是什么了。
目前我正在做3G方面的工作，对于手机上的界面设计正在不断的尝试，在拜读了你的一些文章后，感确很深，其实我也是从技术转到产品的，对于设计和美学方面比较欠缺，希望以后能够和你多交流，也希望再看到你的好文章。
July 16th, 2007
by wherefor
看了你的网站，以前对于网站文字认为14px就够了
在16px下，也不是很糟糕
不过那个提交真的太大了点
July 16th, 2007
by TerranC
从 b3’s哪里看到你的“共饭”，从而开始关注你的blog，正好现在我已下定决心朝“前端架构师”努力，看了你几篇文章后，更加鉴定了我的选择。
和你一样，同样是设计，程序，市场，用户体验，人性心理等有着浓厚的兴趣，确都不专，不过我非常享受这样的全能感觉。
如果你有幸认真的看过我的留言，我非常想和你交个朋友，虽然看上去你好像在我不太喜欢的北京，不过这将不是问题，因为我们有共同话题。
谈谈这篇文章，有两点让我在最下面一屏还能记起的上面的关键词是2006和真正的编程语言，确实，回想2006年，互联网有了巨大的变化，不论从市场的泡沫，还是技术的革新，让我迷茫过，也让我重新找到了适合我的方向；然后我非常庆幸我做了这么久的后台开发后转而奔向前端开发的选择，这是一种放弃，也是一种重生，碰巧的是我2007年的现在同样开始走上了PHP的道路，在PHP上找回了四年前开始写第一行代码时的那种快感，非常享受。
PS：我的MSN即email
July 27th, 2007
by jskin
哈哈，一不小心又看到你的bolg，也很高兴看到你翻译的这篇文章，真的让不少人受到到启发，包括我在内，前端架构师–这个名词挺好，终于能让做前端开发的人崭露头角了，我想大多前端做开发的人都是有做后台转过来的，这样他们更熟悉前后台的结合，但是名词好听，不是随便套在每个人的身上的，懂后台，但不用去开发，知道怎么让前台和后台更好的衔接，懂设计，但不去设计，指导怎样设计最合理，懂视觉，但不去调色，知道什么样的色系更顺应用户的需求，懂体验，让产品更加尊重用户！……分析了一下感觉太全能了，没有十年，八年的工作经验看来很难胜任，因为要的不只是会，而是精，按在每个职位上工作两年来计算那都不敢想了！话又说回来，事在人为，的确这篇文章让我有了自己的发展方向，有了自己的奋斗目标，俱往矣，数飞速网络，还看今朝。
August 3rd, 2007
by 蜘蛛精
似乎说的很有道理，但这些东西同时一个人光学会都不容易，更何况是精
构架师 真牛！
学习中。。。。。。。。。
September 5th, 2007
by dotnet
又要有相当好的技术，又要有很好的大局观，又要有强硬的执行力……………..这个基本上很难！
September 5th, 2007
by Jin.Qin
感触颇深啊.
ASP.Net确实是最大的罪魁祸首,
现在后端数据层,业务层的界定倒越来越成熟了,Data–>Entity–>Rules–>Flow 逐步形成成熟的企业业务架构体系.
但是前端架构和实现依旧混乱,表现和行为以及UI还是混杂在一起, 这里存在一个客观的事实,除了缺乏资深的前端架构师外, 通常web应用系统的Developer并不擅长处理前端的开发,企业招聘人员时也更多的是考察你的OO, NET Framework, ASP.NET, SQL Development方面的能力.
前端架构师,任重道远啊.
October 14th, 2007
by Yellow
这些天恰好想类似文章，却没了头绪，能看到这篇译文真好！
December 26th, 2007
by uncosy
好文章，给我在迷茫的时候指引了一条出路。
谢谢。
转载了！
April 5th, 2008
by marsidea
什么是渐进增强和适度降级？