写在前面
年关将近，这年味愈加的浓烈了哈，似乎无心工作，似乎家乡的叨念从远远的方向传进了你的心里，坚持住哈，马上，就回家了。
进入正题，首先，我需要先解释下这个标题所表达的意思，以及它背后引出的具体的问题，前端架构与具体的应用的矛盾 这句话为什么要这么说，相信大部分公司，不论你是创业型公司、外包公司或者是大一点儿的，上市的，在你们的前端技术栈中，react出现的频率应该不低，vue是更甚者吧，基于webpack、glub构建的应用应该很多了，甚至可以说，这些技术已经占领了前端的半个天下，但是笔者在这里呀，不禁要提出一个问题，那就是，你们的技术栈真的带给前端更简单的内容了吗？ 使用这些技术栈的时候，你们的应用是否会变得学习成本高昂、扩展能力差、依赖高阶程序员、文档不齐全、有没有测试用例？
架构的本质
我认为架构的本质应该是什么？ 它应该是基于可能面临的风险构建的一套能够适应当前业务、扩展未来业务、行为可预测的、高可用性的。在能解决这些问题的前提下，架构应该是高度抽象的吧，一个优秀的架构，它一定要足够简单，基于一个或多个抽象的理解上构建出来的。
简单才是本质，spring为什么那么火，它足够简单。一旦你了解了它的抽象思维方式，整个开发极易上手，这就是一个优秀的架构应该有的表现力。如果你正在设计前端架构，我的忠告是，最好结合你的业务实际去实现它而不是去考虑最新的技术栈，盲目的追求渲染速度、组件式等。
前端一定要与业务接轨，一个管理系统，你跟我谈什么渲染速度？一个正常的管理系统前端，它甚至都不需要webpack这样的工具构建，只需要一个裸的vue加上jquery就可以完成，这样的结构要优于大部分。为什么？ 贴合实际嘛！ 后台系统你一个前端能维护多久呢？大部分时间，后台er在维护这个界面，如果你使用的技术太过复杂，增加了学习成本，还更容易使整个架构逆向发展。
再例如，企业官方网站，企业商城，大型公司的门户，宣传网页，这些东西完全不需要用到打包、甚至vue你都要少用， 为什么？最重要的是它们不利于SEO，然后是不利于快速迭代，设计的再复杂些，vue技术栈全部捅上去，那有什么用嘞？除了给你自己的职业生涯添加一笔，对公司来说这就是技术的债务，公司需要招比你更厉害的人才能理解你写的这些高级的代码，而这些代码一旦在无数个迭代中膨胀，最后的选择只有推倒重来，改都没的改。
结合业务再谈技术
什么前端路由系统，SPA 框架，你都要结合业务，后台系统使用SPA就是耍流氓。陡然增加前端的复杂性，让前端变成了一个比后台系统还复杂的系统。这很得不偿失。仅仅是为了前端开发的便利性，忽略的整个系统的复杂度，这样的架构怎么看都是不可取的。
什么时候能够使用这些技术栈？ 当然是业务允许、风险可以控制的情况下。 例如多终端，移动端，在移动端使用打包工具，SPA框架开发是很明智的，它们带来的优势，在渲染速度上，在使用性上，都是一流的。而且真正的实操中，这样的项目一般是重点维护的。
要结合业务的实际选择技术，大部分时候，开发时间是有限的，实现的功能很多，盲目追求技术的新、快、是没有根据的。
一些看法
推荐一些我个人开发时常用的几项前端架构，它们是我结合平时的开发实际，业务适应程度做出的技术栈调整。
首先，如果项目大小一般，时间很紧急，我会毫不犹豫选择裸vue+jquery+bootstrap，快速开发完毕。
如果项目中等的话，时间不多不少，我会看团队中，开发人员的比例，比如这个开发团队只有一两个前端，那么我会选择 require管理我的js模块，使用sass管理我的css模块，足够模块化，也有组件，同时开发速度够快，团队中的其他人理解起来也很快，在项目很赶的时候后台也可以帮一些忙，也不会担心他们破坏架构。具体到业务逻辑，首先了解业务的流程，例如我这个应用，面向的是企业管理人员，可能需要一些大数据展示，一些图形化界面。那么我很可能选择react+react-router+redux。
大型项目需要依靠具体面临的可能风险，你需要调研清楚目标人群，宣传方式，例如使用SEO做搜索宣传，就不能选择打包技术，微信wap，选择vue技术栈是明智的选择等等。
需要注意的是，最终的简单才是王道。
写在最后
希望大家一起探讨这方面的话题，我的观点也许是错误的，或者是有问题的，讨论一下，大家一起提升。