全球彩票平台_全球彩票注册平台|官网下载地址

热门关键词: 全球彩票平台,全球彩票注册平台,全球彩官网下载地址

【全球彩官网下载地址】我的前端之路,前端技

我的前端之路:工具化与工程化

2017/01/07 · 基础技术 · 工具化, 工程化

原文出处: 王下邀月熊_Chevalier   

全球彩官网下载地址 1

前言

近年来,随着浏览器性能的提升与移动互联网浪潮的汹涌而来,Web前端开发进入了高歌猛进,日新月异的时代。这是最好的时代,我们永远在前行,这也是最坏的时代,无数的前端开发框架、技术体系争妍斗艳,让开发者们陷入困惑,乃至于无所适从。

Web前端开发可以追溯于1991年蒂姆·伯纳斯-李公开提及HTML描述,而后1999年W3C发布HTML4标准,这个阶段主要是BS架构,没有所谓的前端开发概念,网页只不过是后端工程师的顺手之作,服务端渲染是主要的数据传递方式。接下来的几年间随着互联网的发展与REST等架构标准的提出,前后端分离与富客户端的概念日渐为人认同,我们需要在语言与基础的API上进行扩充,这个阶段出现了以jQuery为代表的一系列前端辅助工具。2009年以来,智能手机开发普及,移动端大浪潮势不可挡,SPA单页应用的设计理念也大行其道,相关联的前端模块化、组件化、响应式开发、混合式开发等等技术需求甚为迫切。这个阶段催生了Angular 1、Ionic等一系列优秀的框架以及AMD、CMD、UMD与RequireJS、SeaJS等模块标准与加载工具,前端工程师也成为了专门的开发领域,拥有独立于后端的技术体系与架构模式。

而近两年间随着Web应用复杂度的提升、团队人员的扩充、用户对于页面交互友好与性能优化的需求,我们需要更加优秀灵活的开发框架来协助我们更好的完成前端开发。这个阶段涌现出了很多关注点相对集中、设计理念更为优秀的框架,譬如 ReactVueJSAngular2 等组件框架允许我们以声明式编程来替代以DOM操作为核心的命令式编程,加快了组件的开发速度,并且增强了组件的可复用性与可组合性。而遵循函数式编程的 Redux 与借鉴了响应式编程理念的 MobX 都是非常不错的状态管理辅助框架,辅助开发者将业务逻辑与视图渲染剥离,更为合理地划分项目结构,更好地贯彻单一职责原则与提升代码的可维护性。在项目构建工具上,以 GruntGulp 为代表的任务运行管理与以 WebpackRollupJSPM 为代表的项目打包工具各领风骚,帮助开发者更好的搭建前端构建流程,自动化地进行预处理、异步加载、Polyfill、压缩等操作。而以NPM/Yarn为代表的依赖管理工具一直以来保证了代码发布与共享的便捷,为前端社区的繁荣奠定了重要基石。

我的前端之路

2016/07/18 · 前端职场 · 4 评论 · 职场

原文出处: 王下邀月熊   

笔者的Web前端开发文章索引目录

撰写本文的时候笔者阅读了以下文章,不可避免的会借鉴或者引用其中的一些观点与文字,若有冒犯,请随时告知。文列如下:

  • RePractise前端篇: 前端演进史
  • 前端的变革
  • 致我们终将组件化的Web
  • 我感觉到的前端变化
  • 解读2015之前端篇:工业时代 野蛮发展
  • 前端工程化知识要点回顾&思考
  • Thoughts about React, Redux & javascript in 2016

如果你想进行WebAPP的学习,建议先看下我的编程之路:知识管理与知识体系相关内容
顺便推广下笔者总结的泛前端知识点纲要总结:Coder Essential之客户端知识索引(iOS/Android/Web)、Coder Essential之编程语言学习知识点纲要、Coder Essential之编程语言语法特性概论

几年前初入大学,才识编程的时候,崇尚的是一路向下,那个时候喜欢搞Windows、Linux底层相关的东西,觉得那些做网页的太Low了。直到后来偶然的机会接触到HTML、JavaScript、CSS,很长一段时间觉得这种这么不严谨的,毫无工程美学的搭配不过是诗余罢了。后来,深入了,才发现,能够有幸在这片星辰大海里游荡,可以以几乎领先于其他方向的技术变革速度来感受这个时代的脉动,是多么幸运的一件事。这是一个最坏的时代,因为一不小心就发现自己Out了;这也是一个最好的时代,我们永远在前行。繁华渐欲,万马齐鸣!

借用苏宁前端结构师的总结,任何一个编程生态都会经历三个阶段,第一个是原始时期,由于需要在语言与基础的API上进行扩充,这个阶段会催生大量的Tools。第二个阶段,随着做的东西的复杂化,需要更多的组织,会引入大量的设计模式啊,架构模式的概念,这个阶段会催生大量的Frameworks。第三个阶段,随着需求的进一步复杂与团队的扩充,就进入了工程化的阶段,各类分层MVC,MVP,MVVM之类,可视化开发,自动化测试,团队协同系统。这个阶段会出现大量的小而美的Library。当然,笔者以Tools-Frameworks-Library只是想说明我个人感觉的变化。

笔者从jQuery时代一路走来,经历了以BootStrap为代表的基于jQuery的插件式框架与CSS框架的兴起,到后面以Angular 1为代表的MVVM框架,以及到现在以React为代表的组件式框架的兴起。从最初的认为前端就是切页面,加上一些交互特效,到后面形成一个完整的webapp,总体的变革上,笔者以为有以下几点:

  • 移动优先与响应式开发
  • 前端组件化与工程化的变革
  • 从直接操作Dom节点转向以状态/数据流为中心

笔者在本文中的叙事方式是按照自己的认知过程,夹杂了大量个人主观的感受,看看就好,不一定要当真,毕竟我菜。梳理来说,有以下几条线:

  • 交互角度的从PC端为中心到Mobile First
  • 架构角度的从以DOM为中心到MVVM/MVP到以数据/状态为驱动。
  • 工程角度的从随意化到模块化到组件化。
  • 工具角度的从人工到Grunt/Gulp到Webpack/Browserify。

在正文之前,重要的事情说三遍,我是菜鸟!我是菜鸟!我是菜鸟!从来都没有最好的技术,而只有合适的技术与懂它的人。我感谢这些伟大的类库/框架,感恩它们的Contributor,给我呈现了一个何其广阔的世界。虽然2015的前端领域有点野蛮生长,但是也体现了前端一直是开源领域的扛鼎之处,希望有一天我也能为它的繁荣做出自己的贡献。

前端迷思与React.js

前言

纷扰

分久必合,合久必分啊,无论是前端开发中各个模块的分割还是所谓的前后端分离,都不能形式化的单纯按照语言或者模块来划分,还是需要兼顾功能,合理划分。

任何一个编程生态都会经历三个阶段:

  • 第一个是原始时期,由于需要在语言与基础的API上进行扩充,这个阶段会催生大量的Tools。
  • 第二个阶段,随着做的东西的复杂化,需要更多的组织,会引入大量的设计模式啊,架构模式的概念,这个阶段会催生大量的Frameworks。
  • 第三个阶段,随着需求的进一步复杂与团队的扩充,就进入了工程化的阶段,各类分层MVC,MVP,MVVM之类,可视化开发,自动化测试,团队协同系统。这个阶段会出现大量的小而美的Library。

本文的主旨希望能够尽可能地脱离工具的束缚,回归到前端工程化的本身,回归到语言的本身,无论React、AngularJS、VueJS,它们更多的意义是辅助开发,为不同的项目选择合适的工具,而不是执念于工具本身。总结而言,目前前端工具化已经进入到了非常繁荣的时代,随之而来很多前端开发者也甚为苦恼,疲于学习。工具的变革会非常迅速,很多优秀的工具可能都只是历史长河中的一朵浪花,而蕴藏其中的工程化思维则会恒久长存。无论你现在使用的是React还是Vue还是Angular 2或者其他优秀的框架,都不应该妨碍我们去了解尝试其他。

基石与催化剂

    前端技术这几年蓬勃发展, 这是当时某几个项目需要做前端技术选型时, 相关资料整理, 部分评论引用自社区。

二十载光辉岁月

全球彩官网下载地址 2

近年来,随着浏览器性能的提升与移动互联网浪潮的汹涌而来,Web前端开发进入了高歌猛进,日新月异的时代。这是最好的时代,我们永远在前行,这也是最坏的时代,无数的前端开发框架、技术体系争妍斗艳,让开发者们陷入困惑,乃至于无所适从。Web前端开发可以追溯于1991年蒂姆·伯纳斯-李公开提及HTML描述,而后1999年W3C发布HTML4标准,这个阶段主要是BS架构,没有所谓的前端开发概念,网页只不过是后端工程师的顺手之作,服务端渲染是主要的数据传递方式。接下来的几年间随着互联网的发展与REST等架构标准的提出,前后端分离与富客户端的概念日渐为人认同,我们需要在语言与基础的API上进行扩充,这个阶段出现了以jQuery为代表的一系列前端辅助工具。2009年以来,智能手机开发普及,移动端大浪潮势不可挡,SPA单页应用的设计理念也大行其道,相关联的前端模块化、组件化、响应式开发、混合式开发等等技术需求甚为迫切。这个阶段催生了Angular 1、Ionic等一系列优秀的框架以及AMD、CMD、UMD与RequireJS、SeaJS等模块标准与加载工具,前端工程师也成为了专门的开发领域,拥有独立于后端的技术体系与架构模式。而近两年间随着Web应用复杂度的提升、团队人员的扩充、用户对于页面交互友好与性能优化的需求,我们需要更加优秀灵活的开发框架来协助我们更好的完成前端开发。这个阶段涌现出了很多关注点相对集中、设计理念更为优秀的框架,譬如React、VueJS、Angular 2等组件框架允许我们以声明式编程来替代以DOM操作为核心的命令式编程,加快了组件的开发速度,并且增强了组件的可复用性与可组合性。而遵循函数式编程的Redux与借鉴了响应式编程理念的MobX都是非常不错的状态管理辅助框架,辅助开发者将业务逻辑与视图渲染剥离,更为合理地划分项目结构,更好地贯彻单一职责原则与提升代码的可维护性。在项目构建工具上,以Grunt、Gulp为代表的任务运行管理与以Webpack、Rollup、JSPM为代表的项目打包工具各领风骚,帮助开发者更好的搭建前端构建流程,自动化地进行预处理、异步加载、Polyfill、压缩等操作。而以NPM/Yarn为代表的依赖管理工具一直以来保证了代码发布与共享的便捷,为前端社区的繁荣奠定了重要基石。

工具化

我们学习的速度已经跟不上新框架新概念涌现的速度,用于学习上的成本远大于实际开发项目的成本。我们不一定要去用最新最优秀的工具,但是我们有了更多的选择余地,相信这一点对于大部分非处女座人士而言都是喜讯。

工具化是有意义的。工具的存在是为了帮助我们应对复杂度,在技术选型的时候我们面临的抽象问题就是应用的复杂度与所使用的工具复杂度的对比。工具的复杂度是可以理解为是我们为了处理问题内在复杂度所做的投资。为什么叫投资?那是因为如果投的太少,就起不到规模的效应,不会有合理的回报。这就像创业公司拿风投,投多少是很重要的问题。如果要解决的问题本身是非常复杂的,那么你用一个过于简陋的工具应付它,就会遇到工具太弱而使得生产力受影响的问题。反之,是如果所要解决的问题并不复杂,但你却用了很复杂的框架,那么就相当于杀鸡用牛刀,会遇到工具复杂度所带来的副作用,不仅会失去工具本身所带来优势,还会增加各种问题,例如培训成本、上手成本,以及实际开发效率等。

所谓GUI应用程序架构,就是对于富客户端的代码组织/职责划分。纵览这十年内的架构模式变迁,大概可以分为MV与Unidirectional两大类,而Clean Architecture则是以严格的层次划分独辟蹊径。从MVC到MVP的变迁完成了对于View与Model的解耦合,改进了职责分配与可测试性。而从MVP到MVVM,添加了View与ViewModel之间的数据绑定,使得View完全的无状态化。最后,整个从MV到Unidirectional的变迁即是采用了消息队列式的数据流驱动的架构,并且以Redux为代表的方案将原本MV*中碎片化的状态管理变为了统一的状态管理,保证了状态的有序性与可回溯性。 具体到前端的衍化中,在Angular 1兴起的时代实际上就已经开始了从直接操作Dom节点转向以状态/数据流为中心的变化,jQuery 代表着传统的以 DOM 为中心的开发模式,但现在复杂页面开发流行的是以 React 为代表的以数据/状态为中心的开发模式。应用复杂后,直接操作 DOM 意味着手动维护状态,当状态复杂后,变得不可控。React 以状态为中心,自动帮我们渲染出 DOM,同时通过高效的 DOM Diff 算法,也能保证性能。

浏览器的跃进

现在H5已经成为了一个符号,基本上所有具有绚丽界面或者交互的Web界面,无论是PC还是Mobile端,都被称为基于H5。笔者一直认为,H5技术的发展以及带来的一系列前端的变革,都离不开现代浏览器的发展与以IE为典型代表的老的浏览器的消逝。目前浏览器的市场分布可以由如下两个图:

  • 浏览器分布图
    全球彩官网下载地址 3
  • 国际浏览器分布图
    全球彩官网下载地址 4

这里顺嘴说下,如果想要明确某个属性是否可以使用可以参考Can I Use。话说虽然微信内置的某X5内核浏览器连Flexbox都不支持,不过它帮我们屏蔽了大量手机的底层差异,笔者还是非常感恩的。当然了,在有了Webpack之后,用Flexbox不是问题,可以查看这嘎达。

全球彩官网下载地址 5
开始吧:

纷扰之虹

笔者在前两天看到了Thomas Fuchs的一则Twitter,也在Reddit等社区引发了热烈的讨论:我们用了15年的时间来分割HTML、JS与CSS,然而一夕之间事务仿佛回到了原点。
全球彩官网下载地址 6分久必合,合久必分啊,无论是前端开发中各个模块的分割还是所谓的前后端分离,都不能形式化的单纯按照语言或者模块来划分,还是需要兼顾功能,合理划分。笔者在2015-我的前端之路:数据流驱动的界面中对自己2015的前端感受总结中提到过,任何一个编程生态都会经历三个阶段,第一个是原始时期,由于需要在语言与基础的API上进行扩充,这个阶段会催生大量的Tools。第二个阶段,随着做的东西的复杂化,需要更多的组织,会引入大量的设计模式啊,架构模式的概念,这个阶段会催生大量的Frameworks。第三个阶段,随着需求的进一步复杂与团队的扩充,就进入了工程化的阶段,各类分层MVC,MVP,MVVM之类,可视化开发,自动化测试,团队协同系统。这个阶段会出现大量的小而美的Library。在2016的上半年中,笔者在以React的技术栈中挣扎,也试用过VueJS与Angular等其他优秀的前端框架。在这一场从直接操作DOM节点的命令式开发模式到以状态/数据流为中心的开发模式的工具化变革中,笔者甚感疲惫。在2016的下半年中,笔者不断反思是否有必要使用React/Redux/Webpack/VueJS/Angular,是否有必要去不断追逐各种刷新Benchmark 记录的新框架?本文定名为工具化与工程化,即是代表了本文的主旨,希望能够尽可能地脱离工具的束缚,回归到前端工程化的本身,回归到语言的本身,无论React、AngularJS、VueJS,它们更多的意义是辅助开发,为不同的项目选择合适的工具,而不是执念于工具本身。

总结而言,目前前端工具化已经进入到了非常繁荣的时代,随之而来很多前端开发者也甚为苦恼,疲于学习。工具的变革会非常迅速,很多优秀的工具可能都只是历史长河中的一朵浪花,而蕴藏其中的工程化思维则会恒久长存。无论你现在使用的是React还是Vue还是Angular 2或者其他优秀的框架,都不应该妨碍我们去了解尝试其他,笔者在学习Vue的过程中感觉反而加深了自己对于React的理解,加深了对现代Web框架设计思想的理解,也为自己在未来的工作中更自由灵活因地制宜的选择脚手架开阔了视野。

引言的最后,我还想提及一个词,算是今年我在前端领域看到的出镜率最高的一个单词:Tradeoff(妥协)。

工具化的不足:抽象漏洞定理

抽象漏洞定理是Joel在2002年提出的,所有不证自明的抽象都是有漏洞的。抽象泄漏是指任何试图减少或隐藏复杂性的抽象,其实并不能完全屏蔽细节,试图被隐藏的复杂细节总是可能会泄漏出来。抽象漏洞法则说明:任何时候一个可以提高效率的抽象工具,虽然节约了我们工作的时间,但是,节约不了我们的学习时间。我们在上一章节讨论过工具化的引入实际上以承受工具复杂度为代价消弭内在复杂度,而工具化滥用的结局即是工具复杂度与内在复杂度的失衡。

谈到这里我们就会明白,不同的项目具备不同的内在复杂度,一刀切的方式评论工具的好坏与适用简直耍流氓,而且我们不能忽略项目开发人员的素质、客户或者产品经理的素质对于项目内在复杂度的影响。对于典型的小型活动页,譬如某个微信H5宣传页,往往注重于交互动画与加载速度,逻辑复杂度相对较低,此时Vue这样渐进式的复杂度较低的库就大显身手。而对于复杂的Web应用,特别是需要考虑多端适配的Web应用,尽量使用React这样相对规范严格的库。

ECMAScript

2015年是JavaScript诞生的20周年。同时又是ES6标准落地的一年。ES6是迄今为止 ECMAScript标准最大的变革(如果不算上胎死腹中的ES4的话),带来了一系列令开发者兴奋的新特性。从目前es的进化速度来看,es后面应该会变成一个个的feature发布而不是像以前那样大版本号的方式,所以现在官方也在推荐 ES 年份这种叫法而不是 ES 版本。在ES2015中,笔者觉得比较欣赏的特性如下,其他完整的特性介绍可以参考这篇文章ES6 Overview in 350 Bullet Points。

  • Module & Module Loader:ES2015中加入的原生模块机制支持可谓是意义最重大的feature了,且不说目前市面上五花八门的module/loader库,各种不同实现机制互不兼容也就罢了(其实这也是非常大的问题),关键是那些模块定义/装载语法都丑到爆炸,但是这也是无奈之举,在没有语言级别的支持下,js只能做到这一步,正所谓巧妇难为无米之炊。ES2016中的Module机制借鉴自 CommonJS,同时又提供了更优雅的关键字及语法(虽然也存在一些问题)。
  • Class:准确来说class关键字只是一个js里构造函数的语法糖而已,跟直接function写法无本质区别。只不过有了Class的原生支持后,js的面向对象机制有了更多的可能性,比如衍生的extends关键字(虽然也只是语法糖)。
  • Promise & Reflect API:Promise的诞生其实已经有几十年了,它被纳入ES规范最大意义在于,它将市面上各种异步实现库的最佳实践都标准化了。至于Reflect API,它让js历史上第一次具备了元编程能力,这一特性足以让开发者们脑洞大开。

除此之外,ES2016的相关草案也已经确定了一大部分其他new features。这里提两个我比较感兴趣的new feature:

  • async/await:协程。ES2016中 async/await 实际是对Generator&Promise的上层封装,几乎同步的写法写异步比Promise更优雅更简单,非常值得期待。
  • decorator:装饰器,其实等同于Java里面的注解。注解机制对于大型应用的开发的作用想必不用我过多赘述了。用过的同学都说好。

更让人兴奋的是,JavaScript慢慢不再局限于前端开发中,NodeJs的提出让人们感受到了利用JavaScript进行全栈开发的能力,从此大大提高了开发的效率(至少不用多学习一门语言)。JavaScript在物联网中的应用也曾经引起一些追捧与风潮,不过今年物联网社区更加冷静地看待着这个问题,但是并不影响各大厂商对于JavaScript的支持,可以参阅javascript-beyond-the-web-in-2015这篇文章。笔者还是很看好JavaScript在其他领域继续大放异彩,毕竟ECMAScript 6,7已经是如此的优秀。

  • 目前, Web 开发技术框架选型为两种的占 80% 。这种戏剧性的变化持续了近 6 年。
  • 自 2013 年 5 月推出以来,ReactJS 在过去三年中已成为了 Web 开发领域的中坚力量。

工具化

全球彩官网下载地址 7

月盈而亏,过犹不及。相信很多人都看过了2016年里做前端是怎样一种体验这篇文章,2016年的前端真是让人感觉从入门到放弃,我们学习的速度已经跟不上新框架新概念涌现的速度,用于学习上的成本远大于实际开发项目的成本。不过笔者对于工具化的浪潮还是非常欢迎的,我们不一定要去用最新最优秀的工具,但是我们有了更多的选择余地,相信这一点对于大部分非处女座人士而言都是喜讯。年末还有一篇曹刘阳:2016年前端技术观察也引发了大家的热议,老实说笔者个人对文中观点认同度一半对一半,不想吹也不想黑。不过笔者看到这篇文章的第一感觉当属作者肯定是大公司出来的。文中提及的很多因为技术负债引发的技术选型的考虑、能够拥有相对充分完备的人力去进行某个项目,这些特征往往是中小创公司所不会具备的。

React?Vue?Angular 2?

React,Vue,Angular 2都是非常优秀的库与框架,它们在不同的应用场景下各自具有其优势。Vue最大的优势在于其渐进式的思想与更为友好的学习曲线,Angular 2最大的优势其兼容并包形成了完整的开箱即用的All-in-one框架,而这两点优势在某些情况下反而也是其劣势,也是部分人选用React的理由。很多对于技术选型的争论乃至于谩骂,不一定是工具的问题,而是工具的使用者并不能正确认识自己或者换位思考他人所处的应用场景,最终吵的驴唇不对马嘴。

WebAssembly

WebAssembly 选择了跟ES2015在同一天发布,其项目领头人是大名鼎鼎的js之父Brendan Eich。WebAssembly旨在解决js作为解释性语言的先天性能缺陷,试图通过在浏览器底层加入编译机制从而提高js性能。WebAssembly所做的正是为Web打造一套专用的字节码,这项标准在未来应用场景可能是这样的:

  1. 开发应用,但使用任何一门可被编译为WebAssembly的语言编写源代码。
  2. 用编译器将源代码转换为WebAssembly字节码,也可按需转换为汇编代码。
  3. 在浏览器中加载字节码并运行。

全球彩官网下载地址 8

需要注意的是,WebAssembly不会替代JavaScript。越来越多的语言和平台想在Web上大展手脚,这会迫使JavaScript和浏览器厂商不得不加快步伐来补充缺失的功能,其中某些功能通过复杂的JavaScript语义来实现并不合适,所以WebAssembly可以作为JavaScript的补集加入到Web阵营中来。WebAssembly最一开始的设计初衷就是作为不依赖于JavaScript的编译目标而存在,进而获得了主流浏览器厂商的广泛支持。很期待有一天WebAssembly能够发展起来,到那个时候,我们用JavaScript编写的应用也会像现在用汇编语言写出的大型程序的感觉咯~

任何组件与框架都有它的适用场景, 我们应该冷静分析与权衡, 先来看React.js

工具化的意义

工具化是有意义的。笔者在这里非常赞同尤雨溪:Vue 2.0,渐进式前端解决方案的思想,工具的存在是为了帮助我们应对复杂度,在技术选型的时候我们面临的抽象问题就是应用的复杂度与所使用的工具复杂度的对比。工具的复杂度是可以理解为是我们为了处理问题内在复杂度所做的投资。为什么叫投资?那是因为如果投的太少,就起不到规模的效应,不会有合理的回报。这就像创业公司拿风投,投多少是很重要的问题。如果要解决的问题本身是非常复杂的,那么你用一个过于简陋的工具应付它,就会遇到工具太弱而使得生产力受影响的问题。反之,是如果所要解决的问题并不复杂,但你却用了很复杂的框架,那么就相当于杀鸡用牛刀,会遇到工具复杂度所带来的副作用,不仅会失去工具本身所带来优势,还会增加各种问题,例如培训成本、上手成本,以及实际开发效率等。

全球彩官网下载地址 9

笔者在GUI应用程序架构的十年变迁:MVC,MVP,MVVM,Unidirectional,Clean一文中谈到,所谓GUI应用程序架构,就是对于富客户端的代码组织/职责划分。纵览这十年内的架构模式变迁,大概可以分为MV*与Unidirectional两大类,而Clean Architecture则是以严格的层次划分独辟蹊径。从笔者的认知来看,从MVC到MVP的变迁完成了对于View与Model的解耦合,改进了职责分配与可测试性。而从MVP到MVVM,添加了View与ViewModel之间的数据绑定,使得View完全的无状态化。最后,整个从MV*到Unidirectional的变迁即是采用了消息队列式的数据流驱动的架构,并且以Redux为代表的方案将原本MV*中碎片化的状态管理变为了统一的状态管理,保证了状态的有序性与可回溯性。 具体到前端的衍化中,在Angular 1兴起的时代实际上就已经开始了从直接操作Dom节点转向以状态/数据流为中心的变化,jQuery 代表着传统的以 DOM 为中心的开发模式,但现在复杂页面开发流行的是以 React 为代表的以数据/状态为中心的开发模式。应用复杂后,直接操作 DOM 意味着手动维护状态,当状态复杂后,变得不可控。React 以状态为中心,自动帮我们渲染出 DOM,同时通过高效的 DOM Diff 算法,也能保证性能。

小而美的视图层

React 与 VueJS 都是所谓小而美的视图层Library,而不是Angular 2这样兼容并包的Frameworks。任何一个编程生态都会经历三个阶段,第一个是原始时期,由于需要在语言与基础的API上进行扩充,这个阶段会催生大量的Tools。第二个阶段,随着做的东西的复杂化,需要更多的组织,会引入大量的设计模式啊,架构模式的概念,这个阶段会催生大量的Frameworks。第三个阶段,随着需求的进一步复杂与团队的扩充,就进入了工程化的阶段,各类分层MVC,MVP,MVVM之类,可视化开发,自动化测试,团队协同系统。这个阶段会出现大量的小而美的Library。
React 并没有提供很多复杂的概念与繁琐的API,而是以最少化为目标,专注于提供清晰简洁而抽象的视图层解决方案,同时对于复杂的应用场景提供了灵活的扩展方案,典型的譬如根据不同的应用需求引入MobX/Redux这样的状态管理工具。React在保证较好的扩展性、对于进阶研究学习所需要的基础知识完备度以及整个应用分层可测试性方面更胜一筹。不过很多人对React的意见在于其陡峭的学习曲线与较高的上手门槛,特别是JSX以及大量的ES6语法的引入使得很多的传统的习惯了jQuery语法的前端开发者感觉学习成本可能会大于开发成本。与之相比Vue则是典型的所谓渐进式库,即可以按需渐进地引入各种依赖,学习相关地语法知识。比较直观的感受是我们可以在项目初期直接从CDN中下载Vue库,使用熟悉的脚本方式插入到HTML中,然后直接在script标签中使用Vue来渲染数据。随着时间的推移与项目复杂度的增加,我们可以逐步引入路由、状态管理、HTTP请求抽象以及可以在最后引入整体打包工具。这种渐进式的特点允许我们可以根据项目的复杂度而自由搭配不同的解决方案,譬如在典型的活动页中,使用Vue能够兼具开发速度与高性能的优势。不过这种自由也是有利有弊,所谓磨刀不误砍材工,React相对较严格的规范对团队内部的代码样式风格的统一、代码质量保障等会有很好的加成。
一言蔽之,Vue会更容易被纯粹的前端开发者的接受,毕竟从直接以HTML布局与jQuery进行数据操作切换到指令式的支持双向数据绑定的Vue代价会更小一点,特别是对现有代码库的改造需求更少,重构代价更低。而React及其相对严格的规范可能会更容易被后端转来的开发者接受,可能在初学的时候会被一大堆概念弄混,但是熟练之后这种严谨的组件类与成员变量/方法的操作会更顺手一点。便如Dan Abramov所述,Facebook推出React的初衷是为了能够在他们数以百计的跨平台子产品持续的迭代中保证组件的一致性与可复用性。

渐隐的jQuery与服务端渲染

1 从功能开发角度说,React的思路很好。
2 从页面设计角度说,传统的HTML CSS以及同样思路的模板更好。

工具化的不足:抽象漏洞定理

抽象漏洞定理是Joel在2002年提出的,所有不证自明的抽象都是有漏洞的。抽象泄漏是指任何试图减少或隐藏复杂性的抽象,其实并不能完全屏蔽细节,试图被隐藏的复杂细节总是可能会泄漏出来。抽象漏洞法则说明:任何时候一个可以提高效率的抽象工具,虽然节约了我们工作的时间,但是,节约不了我们的学习时间。我们在上一章节讨论过工具化的引入实际上以承受工具复杂度为代价消弭内在复杂度,而工具化滥用的结局即是工具复杂度与内在复杂度的失衡

谈到这里我们就会明白,不同的项目具备不同的内在复杂度,一刀切的方式评论工具的好坏与适用简直耍流氓,而且我们不能忽略项目开发人员的素质、客户或者产品经理的素质对于项目内在复杂度的影响。对于典型的小型活动页,譬如某个微信H5宣传页,往往注重于交互动画与加载速度,逻辑复杂度相对较低,此时Vue这样渐进式的复杂度较低的库就大显身手。而对于复杂的Web应用,特别是需要考虑多端适配的Web应用,笔者会倾向于使用React这样相对规范严格的库。

函数式思维:抽象与直观

近年来随着应用业务逻辑的日益复杂与并发编程的大规模应用,函数式编程在前后端都大放异彩。软件开发领域有一句名言:可变的状态是万恶之源,函数式编程即是避免使用共享状态而避免了面向对象编程中的一些常见痛处。函数式编程不可避免地会使得业务逻辑支离破碎,反而会降低整个代码的可维护性与开发效率。与React相比,Vue则是非常直观的代码架构,每个Vue组件都包含一个script标签,这里我们可以显式地声明依赖,声明操作数据的方法以及定义从其他组件继承而来的属性。而每个组件还包含了一个template标签,等价于React中的render函数,可以直接以属性方式绑定数据。最后,每个组件还包含了style标签而保证了可以直接隔离组件样式。我们可以先来看一个典型的Vue组件,非常直观易懂,而两相比较之下也有助于理解React的设计思想。

在现代浏览器中,对于JavaScript的计算速度远快于对DOM进行操作,特别是在涉及到重绘与重渲染的情况下。并且以JavaScript对象代替与平台强相关的DOM,也保证了多平台的支持,譬如在ReactNative的协助下我们很方便地可以将一套代码运行于iOS、Android等多平台。总结而言,JSX本质上还是JavaScript,因此我们在保留了JavaScript函数本身在组合、语法检查、调试方面优势的同时又能得到类似于HTML这样声明式用法的便利与较好的可读性。

HTML:附庸之徒

前端用于数据展示

在笔者最早接触前端的时候,那个时候还不知道前端这个概念,只是知道HTML文件可以在浏览器中显示。彼时连GET/POST/AJAX这些概念都不甚明了,还记得那个时候看到一本厚厚的AJAX实战手册不明觉厉。笔者阅读过Roy Thomas Fielding博士的Architectural Styles andthe Design of Network-based Software Architectures这篇论文,也就是RESTful架构风格的源处。在这篇文章里,笔者反而感觉最有感触的是从BS到CS架构的跃迁。一开始我觉得网页是典型的BS的,咋说呢,就是网页是数据、模板与样式的混合,即以经典的APS.NET、PHP与JSP为例,是由服务端的模板提供一系列的标签完成从业务逻辑代码到页面的流动。所以,前端只是用来展示数据。

那个时候笔者更菜,对于CSS、JS都不甚明了,一切的数据渲染都是放在服务端完成的。笔者第一次学HTML的时候,惊呆了,卧槽,这能算上一门语言嘛?太简单了吧。。。原来做个网页这么简单啊,然后生活就华丽丽打了脸。那个时候,根本不会以script或者link的方式将资源载入,而是全部写在一个文件里,好吧,那时候连jQuery都不会用。记得那个时候Ajax都是自己手写的,长长的毫无美感的大量重复冗余的代码真是日了狗。

为什么说HTML只是附庸之徒呢,那个时候我们没有把Browser的地位与其他的Client并列,换言之,在经典的Spring MVC框架里,如下所示,用户所有的逻辑操作的核心我们都会放置到Java代码中,根本不会想到用JavaScript进行控制。另一个方面,因为没有AJAX的概念,导致了每次都是表单提交-后台判断-重新渲染这种方式。这样导致了每一个渲染出来的网页都是无状态的,换言之,网页是依赖于后端逻辑反应不同有不同的呈现,自身没有一个完整的状态管理。

全球彩官网下载地址 10
图片来源于《前端篇:前端演进史》

     大家开发前端的思路早已不是当年的 Web page,而是Application。大多数公司不是Facebook,没有那么多全栈高手。团队中擅长写业务的,未必擅长页面布局;擅长页面布局的,未必擅长写业务。这样在团队中必定会有分工,其中会有些人着重实现炫酷的页面效果,而React显然对这种分工不友好。

React?Vue?Angular 2?

全球彩官网下载地址 11

笔者最近翻译过几篇盘点文,发现很有趣的一点,若文中不提或没夸Vue,则一溜的评论:垃圾文章,若文中不提或没夸Angular 2,则一溜的评论:垃圾文章。估计若是笔者连React也没提,估计也是一溜的评论:垃圾文章。好吧,虽然可能是笔者翻译的确实不好,玷污了原文,但是这种戾气笔者反而觉得是对于技术的不尊重。React,Vue,Angular 2都是非常优秀的库与框架,它们在不同的应用场景下各自具有其优势,本章节即是对笔者的观点稍加阐述。Vue最大的优势在于其渐进式的思想与更为友好的学习曲线,Angular 2最大的优势其兼容并包形成了完整的开箱即用的All-in-one框架,而这两点优势在某些情况下反而也是其劣势,也是部分人选用React的理由。笔者觉得很多对于技术选型的争论乃至于谩骂,不一定是工具的问题,而是工具的使用者并不能正确认识自己或者换位思考他人所处的应用场景,最终吵的驴唇不对马嘴。

前后端分离与全栈:技术与人

前后端分离与全栈并不是什么新鲜的名词,都曾引领一时风骚。Web前后端分离优势显著,对于整个产品的开发速度与可信赖性有着很大的作用。全栈工程师对于程序员自身的提升有很大意义,对于项目的初期速度有一定增速。如果划分合理的话能够促进整个项目的全局开发速度与可信赖性,但是如果划分不合理的话只会导致项目接口混乱,一团乱麻。

我们常说的前后端分离会包含以下两个层面:

  • 将原本由服务端负责的数据渲染工作交由前端进行,并且规定前端与服务端之间只能通过标准化协议进行通信。
  • 组织架构上的分离,由早期的服务端开发人员顺手去写个界面转变为完整的前端团队构建工程化的前端架构。

前后端分离本质上是前端与后端适用不同的技术选型与项目架构,不过二者很多思想上也是可以融会贯通,譬如无论是响应式编程还是函数式编程等等思想在前后端皆有体现。而全栈则无论从技术还是组织架构的划分上似乎又回到了按照需求分割的状态。不过呢,我们必须要面对现实,很大程度的工程师并没有能力做到全栈,这一点不在于具体的代码技术,而是对于前后端各自的理解,对于系统业务逻辑的理解。如果我们分配给一个完整的业务块,同时,那么最终得到的是无数个碎片化相互独立的系统。

AJAX与客户端开发

笔者最早的区分CS与BS架构,抽象来说,会认为CS是客户端与服务器之间的双向通信,而BS是客户端与服务端之间的单向通信。换言之,网页端本身也变成了有状态。从初始打开这个网页到最终关闭,网页本身也有了一套自己的状态,而拥有这种变化的状态的基础就是AJAX,即从单向通信变成了双向通信。图示如下:

全球彩官网下载地址 12

为什么需要 React,Why?

    我们需要技术栈提供好用的模块化方式,可以是Web Component,可以是非Web Component的某种机制,不管什么库或者框架,我们需要技术赋予我们完成一个抽象,一次构建,多处复用的能力,并且这个过程不能太麻烦,不能做个很日常的抽象翻半天文档。
    我们需要数据绑定,在各种粒度上真正实现事件驱动,因为这样我们就不用自己重复手写本质上并不依赖场景的从视图到数据从数据到视图的自动更新,否则我们就得自己操作DOM,优化DOM操作,还要自己维护状态,一自己维护状态,就要陷入状态同步的漩涡,浪费大量时间和精力。
    我们需要技术栈隐藏掉平台的微妙差异,写一段代码可以真正实现跨平台,而不用我们自己纠结于那些本不该应用开发纠结的事,我们需要持续稳定的跨平台支持,最好的移植就是不用移植,这在商业上有很大的价值。
我们需要库或者框架好学,好用,从第一天起就能快速开发,而不是不得不经历几个月的学习曲线那种,因为大多数团队的程序员水平都存在梯度,我们不希望因为一个技术栈把初学水平的人挡在门外很久,理想的状态是技术本身能对招聘工作完全透明,同样的工期,同样的项目,随时找人都可以,招人的时候不用写得过于具体,只要会JavaScript就能快速上手,我们需要概念负担尽量少的技术栈,真正理解了Simplicity的技术。
    我们希望技术栈有非常好的性能,性能的水平和垂直扩展性都很好,这样我们就不用项目写到一半回头去纠结应用开发团队很难解决的性能问题,我们需要在快速开发和基础性能之间平衡得很好的工具,而不是因为要强调某一方面而对另一方面关注太少的那些工具。
    我们需要使用的工具有专业的团队或者社区持续地跟进,最好这些团队和社区自己就把自己的东西投入生产使用的技术,这样至少对我们来说风险就有起码的控制。我们不需要那些心血来潮,永远不成熟因为永远没有专门投入的技术。
    我们需要那些普通人喜欢用,也用得好的技术。
    React满足上面的一些方面,不满足另一些方面,和其他工具一样。你需要React,是因为两点
    第一,你充分评估了你的项目,理解你要解决的问题是什么,是快速开发,性能,团队的人类工程学,多数情况下要解决的问题是多个要素的平衡
    第二,你充分评估了React这个栈,理解它是解决你的具体问题的最佳工具,你真的理解了自己的场景中非用React不可的那些事情

    如果你觉得React快所以需要,事实是React并没有那么快,尤其是大型应用,小型应用里快是不重要的,所有的框架都足够快。
    如果你觉得React开发快所以需要,事实是React并一定是最好用的,尤其是当你考虑了团队的构成。

    如果你觉得React是Facebook开发的所以需要,我的揣测是经历过一个社区adoption的高峰以后,Facebook未必能解决剩下的那1%的问题。
    如果你觉得React Native很火所以需要,这或许是一个理由,但RN也不是唯一选择,从各方面评估,NativeScript这样的栈并不比RN坏多少,也许还稍微好一点。如果是大预算的商业开发,RN甚至不应该成为首选。

    大部分人在用 React 的时候,用到的是两个特性:

    1. 虚拟 DOM

    2. 组件化

   至于其他的伪特性,我认为是有些同学「一瓶子不满,半瓶子咣当」,意淫出来的。这些伪特性包括:

    1. 跨平台。虽然 ReactNative 可以在多个平台上使用,但是 ReactNative 并没有封装不同系统的 API。从这方面来说,这货甚至连 weex 都不如。
    2. 更易于组织逻辑。这明显是 flux/redux 做的事情。而且 redux 已经明确说明了,不仅仅适用于 React,其他框架也可以用 redux。

本文由全球彩票平台发布于全球彩官网下载地址Web前端,转载请注明出处:【全球彩官网下载地址】我的前端之路,前端技

TAG标签: 全球彩票平台
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。