码迷,mamicode.com
首页 > 其他好文 > 详细

天哪,我只是想吃顿红烧肉啊

时间:2016-07-14 22:09:13      阅读:326      评论:0      收藏:0      [点我收藏+]

标签:

前言

今天突然想吃红烧肉了,然后问大厨朋友怎么做,大厨哥们见你学艺诚意蛮高,于是扔过来两本书:

技术分享 技术分享

还能好好做朋友吗?你心里万马奔腾,但还没等吐槽出来,大厨哥们就很专业的分析:肉质是口感的关键,酱油是色味的保证,你基础不牢怎么能做出好的红烧肉呢?

技术分享

站在前人的肩膀上

HTML、CSS、JavaScript是前端的根基,这是无可否认的事实。正如一辆车当然都是由一堆钢板和螺钉组成的,但是现在还有人拎着个锤子敲敲打打的造车吗?李书福说过,“汽车不过是四个轮子加两个沙发”,去一趟家具城和轮胎店,车不就造出来了吗?(好吧,我承认夸张系数有点大)
码农的世界里面经常会提到造轮子,也就是你为了造车而先拿扳手大锤去敲一个车轮出来,然后再用你做出来的车轮你做出来的座椅去组装成车。这种方式绝对的私人订制,但是这都是大团队干的事,小团队和独立开发者这么干估计只能造一辆小孩子的玩具车,还是给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层上实行按需加载,所以在代码精简和性能上都有不错的表现。

WeX5的缺点

任何事物都是两面性的,一方面WeX5的大而全可以帮助我们搭建一个优秀的开发环境、提供了封装良好的大量组件,但另一方面加大了平台本身的体积,而且目前由于平台更新较快,相应的技术文档更新速度跟不上平台更新速度。不过与优点相比,这点缺点还可以接受。还在苦苦寻找好用的组件库、纠结于各种框架选择的同学不妨试试WeX5,体验一把大轮子的快感!

下载地址: http://www.wex5.com/downloads/

天哪,我只是想吃顿红烧肉啊

标签:

原文地址:http://blog.csdn.net/justeptech/article/details/51909528

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!