web前端框架是什么意思

前端架构师必须懂得真正的编程知识，而这正是很多自封为前端架构师的人所缺乏的。我的意思不是能够剪切粘贴改进代码就行了，而是能够跟老练的工程师商讨如何能够最好地结合前端。
这就是说，前端架构师需要真正理解结构遭遇商业逻辑的问题。如果工程师说某些东西使用ASP.Net DataGrid是不可能实现的，前端架构师必须能够解释如何与为何要使用DataList或Repeater取代，解释为何DataGrid在该情景下是个错误的选择……
这只是个例子，问题还在于仅知道客户端编程也是不够的。能够使用与工程师相同的术语，能够讨论（前后端）关键集成的最佳解决方案，这是绝对必须的。
断线的风筝
我们今天正处在一个不妙的处境中，原因在于几乎没有人能够为前后端的沟壑搭桥。一般工程师不会有兴趣或实践标记，CSS, 或DOM脚本编程，大部分客户端开发者也没有与后端技术协作的经验。几周入门PHP不会成为程序员，几周入门XHTML也不会成为真正的客户端开发者。
罪魁祸首
我首先想到的十足例子是，ASP.Net完全漠视Web标准，同样地，web氛围（我们指表格和占位gif）让Web标准郁闷。企业项目的大多数框架输出的标记，即使使用1999年的标准来衡量，都是糟糕无比的。
如此巨大和“专业”的产品怎么能才够不忽视，按理说是整个项目最简单的方面？只有静态代码。理由是，基于技术的立场衡量产品，结构，CSS和其他客户端技术都是“事后诸葛亮”。表现逻辑，结构和行为混杂，压根无助于无障碍，Web标准，或者前端技术干净的分离。抬起你的头来，就在2006，这些都成受欢迎的惯例了。
总结
如果这个世界上姿态最鲜明的产品和项目都如此低劣的方式来处理事情，其他的还有什么好说？毫无疑问，我们需要前端架构师，而且就在昨天。
归结于归结，我们有一堆相互关联的技术，很少人能够埋头钻研它们之间的关系，这很不幸。正确做事的真正价值在于容易的维护和长期的适应性。虽然在关键时刻，有些方式更容易选择其他的方法和拼凑起另外的东西。对某些人来说，这可能是可接受的做事方式。但是，对我们大部分人来说，这是拙劣的抉择，也非常不专业。
我交给你去想了。我假设你把车交给技工修理，修好了时候，瞧瞧引擎罩内大量的输送管，我不知道你对技工作何感想？