除非你是BAT,前端开发中最好少造轮子

　　前言

　　今天忽然想吃红烧肉了，而后问大厨朋友怎么作，大厨哥们见你学艺诚意蛮高，因而扔过来两本书：

　　

 　　还能好好作朋友吗?你内心万马奔腾，但还没等吐槽出来，大厨哥们就很专业的分析：肉质是口感的关键，酱油是色味的保证，你基础不牢怎么能作出好的红烧肉呢?我竟无言以对。

　　站在前人的肩膀上

　　HTML、CSS、JavaScript是前端的根基，这是无能否认的事实。正如一辆车固然都是由一堆钢板和螺钉组成的，可是如今还有人拎着个锤子敲敲打打的造车吗?李书福说过，“汽车不过是四个轮子加两个沙发”，去一趟家具城和轮胎店，车不就造出来了吗?(好吧，我认可夸张系数有点大)

　　码农的世界里面常常会提到造轮子，也就是你为了造车而先拿扳手大锤去敲一个车轮出来，而后再用你作出来的车轮你作出来的座椅去组装成车。这种方式绝对的私人订制，可是这都是BAT干的事，其余团队和开发者这么干估计只能造一辆小孩子的玩具车，仍是给3岁如下儿童用的这种：

　　

　　大部分团队要作的是尽可能使用现成的东西组装，而不是所有本身开发，就像如今网上卖的家具同样，一套组件寄过来组装一下就成了一张漂亮的桌子。工程上对于规模较大的产品，必需要用组件化的思惟去开发，将项目分解成一个个小组件分给各个小组去开发，各个小组之间相互独立，最后将全部组件拼成一个完整的成品。而不少小部件实际上是通用的，也有不少组织或者我的将本身作好的组件共享出来，直接使用这些现成的组件，显然是能大大加快开发进度的。

　　另外，一个显而易见的事实是，随着科技的日益进步，终端设备的多样化、页面可视化技术的发展，前端技术已经愈来愈复杂了，不再是3岁小孩的玩具水平了。好比说用户交互的加强，好比说终端的多样化，这些都大大增长了前端开发的复杂度。这个时候从最底层从0开始开发，跟放着现成的打火机不用而去钻木取火同样，元谋人都笑了。

　　一套Web代码，多平台应用

　　众所周知，目前移动设备有安卓、苹果两大阵营，而国内微信的恐怖占有率也让咱们不得不开发微信公众号版本，也就是一个应用至少须要android、iOS、Web App三个版本。3个版本使用彻底不一样的技术开发，相互之间不能共用代码，也就是说至少须要3班人马去开发。固然你们都但愿直接用一套代码跑在3个平台上，具备这个能力的就只有Web App技术了，由于他本质上是一个网页，而网页是不分平台的。

　　但纯Web App有两个问题，一是对硬件的操做能力较弱(原生只有HTML5的一些硬件API)，二是性能比原生差。为了提升对硬件的操做能力，可使用phoneGap、Titanium这种底层中间件来调用底层硬件，并且能够经过插件的形式扩展，能够说在调用硬件的能力上，这种方式跟原生已经没什么差别了。这种开发方式与开发Web App无异，目前多数hybrid App都是用这种方式开发的。另外一方面，性能方面因为HTML5技术的发展，结合CSS3的话，性能上也有了明显的提高。这里你可能会说，Web App在安卓版微信上很是容易卡顿呀。这里要科普一下，Web App是经过Web View渲染的，若是Web View的渲染能力不行，就会有明显的卡顿现象，而安卓微信的Web View用的是10cent的X5内核，国产虽好，仍需努力!做为对比，能够将一样的Web App放到iOS版微信去看看，性能基本不输原生，由于iOS版微信用的是与Safari一样的Web View内核!在谷歌火狐等移动浏览器上，性能也至关高，并且随着技术发展能够预见，在不久的未来Web App和原生App在性能上的差别基本能够忽略了。

　　前端好热闹

　　由于设备的进化太快、多平台也须要web开发的需求旺盛，因此如今前端变得史无前例的热闹。各大互联网巨头都推出了本身的前端框架，但框架虽多，核心思想都只有一个：组件化开发。

　　何为组件化开发呢?搭过积木吗?组件化就是讲一个个页面功能体作成一个个的积木块，开发的时候再将各个部分拼接出一个页面，以下每一个框就是一个组件：

　　

 

　　一个网站由多个页面组成，一个页面由多个组件组成，而后大组件又能够由小组件组成，将小组件拼成大组件，将大组件拼成大组件，再拼成页面模块，这就是组件化开发。

　　So Easy?Too Naive!

　　这里看到的组件化只是UI表现层的组件化，完整的组件化还包括交互事件、展示样式、数据交互，也就是说组件拥有本身的属性、方法以及数据交互能力。好比常见的搜索提示列表，用户输入信息传到服务器上，服务器根据用户输入词查找后将数据返回前端，再由前端展现，效果以下：

　　

 

　　经常使用的UI库如Bootstrap实现了样式和动画的封装，可是数据交互方面还要本身处理。本身写也是能够的，服务器将数据返回来，而后前端用字符拼接或者DOM模板技术合成HTML放入网页中，这一步俗称渲染。固然渲染能够在前端作，也能够在服务器端完成。简单的字符串拼接大概是这样的：

　

<input type="text" id="" value="红烧肉" />
<input type="button" id="" value="搜索" />
<ul id="test-ul"> </ul>
<script type="text/javascript">
var temp = '',
list = ['红烧肉 罐头', '红烧肉 调料', '红烧肉 猪肉', '红烧肉 包邮'], 
listNode = document.getElementById('test-ul');
for (let n = 0, len = list.length; n < len; n++) {
temp +='<li>' + list[n] + '</li>';
}
listNode.innerHTML = temp;
</script>

　　

　　上面只是示例，实际工程中用的更多的是模板技术，如今模板技术多如牛毛，好比模板的Dust.js、doT.js，MVVM框架级的Angularjs、Knockoutjs等，王婆们都说本身瓜最甜了，选择困难症患者们大家准备好了吗?

　　        

　　组件完成以后，还须要一套底层框架来将组件们有机组织起来，根据场景调度出不一样的组件来实现需求。这就是路由模块，之前路由模块都放在服务器端，如今还须要前端路由来实现单页应用。在应用比较复杂的状况下，除了须要用路由模块实现跳转以外，也还须要根据路由去按需加载每一个场景所需的资源，同时保证各个资源的调度不发生冲突，这个资源加载器也算一个框架。

　　从上面来看，为了实现组件化开发，咱们至少要使用几个框架来组织代码，若是业务负责弹性较大的话，这样一套底层架构可不是随随便便简简单单就能作出来的。而若是本身制做UI的话，那工做量起码还得翻几倍，在人员不增的状况下，也就意味着开发周期翻几倍。想想如今的互联网发展速度吧，等你花几周时间作出一套还算精致的UI，你那本来价值几百亿美刀的idea可能已经被10cent、100du这些公司作了，泪流满面之际你终于想起了火云邪神说的：

　　天下武功，惟快不破。

　　快，就是互联网行业的葵花宝典(妹子们放心、程序猿叔叔们都不看第一页的)。

　　选择一个好用的开发环境

　　为了实现组件化开发，咱们通常会用到UI库、MVVM框架、模块加载器、项目管理和配置工具等一套东西，这个时候一个好的的开发环境就比较重要了，单纯用编辑器敲代码的刀耕火种时代已经成为历史了。前端开发环境上，有些公司会用大而全的IDE，有些公司会用各类轻量化的工具组合，这个要看公司技术水平和技术架构的设定。另外，每一个公司的开发都会或多或少引入一些现有的框架和类库，也就是俗称的轮子。近些年前端空前繁荣，各类框架层(qun)出(mo)不(luan)穷(wu)，如何找到最适合你的项目的框架也不是一件容易的事情。如今前端框架的更新很是快，一个框架火起来到退出人们视野，可能就只有短短两三年时间。显然，追随热门的风险至关大，特别是一些我的贡献的框架，由于精力有限，后续的技术支持其实很难保证。要选择适合公司业务并且稳定的主流的框架技术，这须要有至关的技术积累才能敲定，不然就是带着开发的小伙伴们去踩坑，等你把坑填好，忽然发现这条路已经out了……

　　在开发工具上，前端界比较火是sublime text(这只是一个编码器)和webstorm，这两个定制性很强，换句话说就是你要安装不少插件或者搭配不少工具才好用，好比好用的编码插件、调试必备的chrome、精致的UI组件库、合适的自动化部署工具、顺手的测试工具、规范的工程管理插件等等。对于初学者或者技术积累不足的开发人员来讲，这些框架/工具的筛选都至关困难，这须要有大牛才能够定技术选型。另外大牛下面的小伙伴们十八种武艺也都要能耍一下才行，所以，对于技术架构并没那么完整的团队，这种技术套装显然不太明智。

　　那何不选择一个大而全的开发环境呢?好比说Eclipse，关于Eclipse就很少介绍了，这里想说的是基于Eclipse开发的WeX5。首先，Wex5是基于Eclipse开发的，而Eclipse无需多言，IBM出品Java开发首选IDE，也就意味着WeX5能够作到先后端无缝结合。另外，WeX5选用的框架都是很是稳定流行的bootstrap、jquery、phonegap，再加上起步的技术支持，不再用夜深人静时独自对着大坑默默流泪了。

　　组件化方面，WeX5中集成了很是多的Boostrap组件，并使用knockout框架将组件属性和数据绑定起来，样式、用户交互、数据交互这几方面都完整的封装好了。数据绑定以后，改动前端的数据会自动反映到数据库中，数据库中的数据改动也会自动反映到前端展现，不须要考虑太多数据与表现关联的实现问题。使用的方法也很是简单，直接在属性页设置便可，管理起来也很是方便。

　　并且除了组件，WeX5中更有意思的是他提供了不少现成的应用模板，大到一个站点(电商、旅游等业务)，小到好比一个登录页这样的模板，这个真的不要太贴心。咱们开发的不少组件均可以从上面直接套用，或者加点小改就能够达到想要的效果，好好利用这些现成的东西，把精力花在业务逻辑上，这才是快速开发的王道啊。　　

     

　　WeX5中的可视化开发

　　一听到可视化开发，同窗们第一反应就是C#的WinForm界面或者PS中的图片编辑效果吧，鼠标指哪，效果就去哪。然而，并非这样的，前端开发跟桌面软件开发不一样，也就是必需要符合W3C标准。最简单的例子：你选择一个按钮，而后在设计视图上绘制按钮，按钮并不在你鼠标指定的位置出现，而是按照W3C标准文档流来肯定位置。你也不能随意拖动组件到任意位置，组件的布局和样式都仍是要符合标准文档流的要求。固然你能够指定绝对定位来脱离文档流，这样就能够指定位置了，这些都是符合W3C标准的作法。本质上WeX5只是提供了一个界面来方便地添加组件和修改样式，并非可让你天马行空地设计界面的做弊器。你要实现一个布局，其实跟直接在编辑器里面写代码同样，还要要指定定位、浮动、边距这些，只是WeX5中能够更直观的实现而已。固然不少同窗都想到了Dreamweaver的可视化设计，DW的可视化设计作出来的代码会有不少垃圾代码，只能作原型开发用，并不能直接用于线上发布的，而WeX5生成的是符合W3C标准的代码，这是两个不一样的概念。

　　WeX5上开发App用的也是调用底层中间件的方式，用的是phoneGap的内核Cordova框架，UI体系则彻底基于W3C的HTML5+CSS3+js;引入jQuery和Bootstrap并对移动作了底层优化，效率和性能接近原生应用。因此，用Wex5开发出来的应用能够打包成安卓App或者iOS App，也能够以Web App的形式运行在微信公众号上，固然PC端也是OK的。回到你们关心的性能和体积上，因为WeX5是以插件的形式调用Cordova框架，UI层上实行按需加载，因此在代码精简和性能上都有不错的表现。