• 前端自动化构建原理入门

      在现代前端工程开发中,自动化构建已经成为一个必不可少的部分,本节我们就来讨论一下前端自动化构建方面的知识。   目前的构建工具多种多样,设计的思路也略有不同,但是整体的实现原理却是基本一致的。这里我们仍以讲述构建工具和流程原理性的内容为主,目的是希望你不仅掌握如何使用现在的构建工具,同时也能了解构建工具自动完成构建的过程。   提到前端自动化构建工具,我们可以追溯到软件开发时代的IDE(Integrated Development Environment,集成开发环境)。IDE在软件编译运行阶段将软件所需要的代码、资源、图片等打包成一个可以独立运行的软件安装包,然后在不同平台上安装运行。前端开发中是没有这样的IDE的,因为前端代码不需要软件编译。举一个简单的例子,我们在一个页面中使用了多个背景图片,但是想把这几个背景图片请求合成一个图片(俗称雪碧图),以前我们可能会手动把这些图片放在一个大背景图片中,然后通过元素的背景图偏移量来实现多个元素对它的引用。后来,页面又添加了一个图片,我们就在这个原有合成的大图片中新添加了一个图片。很多人应该有过这样的经历,这样很麻烦,于是我们希望能有一个像软件IDE这样的工具,对代码进行分析,把引用的各种资源打包统一处理,自动输出成为理想的结构。合并多个背景图片只是其中一个场景,这一类问题就是前端构建工具需要解决的,某种意义上,前端构建工具很像软件开发IDE的编译打包处理模块。 5.3.1 自动化构建的目的   前端构建工具的作用可以认为是对源项目文件或资源进行文件级处理,将文件或资源处理成需要的最佳输出结构和形式。在处理过程中,我们可以对文件进行模块化引入、依赖分析、资源合并、压缩优化、文件嵌入、路径替换、生成资源包等多种操作,这样就能完成很多原本需要手动完成的事情,极大地提高开发效率。 5.3.2 自动化构建原理   主流的构建工具虽然种类较多,但原理相通。下面我们来看看目前主流的构建工具的实现原理和过程。首先要明确的是,自动化构建是基于项目代码文件级的分析处理,下面以一个通用构建工具实现的文件处理流程为例向大家介绍。   如图5-3所示,构建的流程主要分成7个基本步骤(不同的构建工具各有差异,但基本原理是类似的):读取入口文件→分析模块引用→按照引用加载模块→模块文件编译处理→模块文件合并→文件优化处理→写入生成目录。 图5-3 构建原理流程 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <!-- index.html --> <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title> <!--style--> </head> <body> <mod-A></mod-A> <mod-B></mod-B> <script src="main.js"></script> <!--script--> </body> </html>...


  • 前端一站式异常捕获方案(全)

    一、前端异常监控的重要性   软件异常监控常常直接关联到软件本身的质量,完备的异常监控体系常常能够快速定位到软件运行中发生的问题,并能帮助我们快速定位问题的源头,提升软件质量。   在服务器开发中,我们常常使用日志来记录请求的错误和服务器异常问题,但是在前端开发中,前端工程师按照需求完成页面开发,通过产品体验确认和测试,页面就可以上线了。但不幸的是,产品很快就收到了用户的投诉。用户反映页面点击按钮没反应而且能复现,我们试了一下却一切正常,于是追问用户所用的环境,最后结论是用户使用了一个非常小众的浏览器打开页面,因为该浏览器不支持某个特性,因此页面报错,整个页面停止响应。在这种情况下,用户反馈的投诉花掉了我们很多时间去定位问题,然而这并不是最可怕的,更让我们担忧的是更多的用户遇到这种场景后便会直接抛弃这个有问题的“垃圾产品”。这个问题唯一的解决办法就是在尽量少的用户遇到这样的场景时就把问题即时修复掉,保证尽量多的用户可以正常使用。   首先我们需要在少数用户使用产品出错时知道有用户出错,而且尽量定位到是什么错误。由于用户的运行环境是在浏览器端的,因此可以在前端页面脚本执行出错时将错误信息上传到服务器,然后打开服务器收集的错误信息进行分析来改进产品的质量,下面我们主要讨论下错误的捕获方案。。 二、现有的异常监控方案 window.onerror全局异常捕获   目前前端捕获页面异常的方式主要有两种:try…catch和window.onerror。   window.onerror的方法可以在任何执行上下文中执行,如果给window对象增加一个错误处理函数,便既能处理捕获错误又能保持代码的优雅性了。window.onerror一般用于捕捉脚本语法错误和运行时错误,可以获得出错的文件信息,如出错信息、出错文件、行号等,当前页面执行的所有JavaScript脚本出错都会被捕捉到。 1 2 3 4 5 6 7 8 9 10 window.onerror = function (msg, url, line){ // 可以捕获异步函数中的错误信息并进行处理,提示Script error. console.log(msg); // 获取错误信息 console.log(url); // 获取出错的文件路径 console.log(line); // 获取错误出错的行数 }; setTimeout(function() { console.log(obj); // 可以被捕获到,并在onerror中处理 }, 200);   然而,使用onerror要注意,在不同浏览器中实现函数处理返回的异常对象是不相同的,而且如果报错的JavaScript和HTML不在同一个域名下,错误时window.onerror中的errorMsg全部为script error而不是具体的错误描述信息,此时需要添加JavaScript脚本的跨域设置。 1 <script src="//www.domain.com/main.js" crossorigin></script>...


  • 前端性能优化(三) 移动端浏览器前端优化策略

      相对于桌面端浏览器,移动端Web浏览器上有一些较为明显的特点:设备屏幕较小、新特性兼容性较好、支持一些较新的HTML5和CSS3特性、需要与Native应用交互等。但移动端浏览器可用的CPU计算资源和网络资源极为有限,因此要做好移动端Web上的优化往往需要做更多的事情。首先,在移动端Web的前端页面渲染中,桌面浏览器端上的优化规则同样适用,此外针对移动端也要做一些极致的优化来达到更好的效果。需要注意的是,并不是移动端的优化原则在桌面浏览器端就不适用,而是由于兼容性和差异性的原因,一些优化原则在移动端更具代表性。 一、网络加载类 1.首屏数据请求提前,避免JavaScript文件加载后才请求数据   为了进一步提升页面加载速度,可以考虑将页面的数据请求尽可能提前,避免在JavaScript加载完成后才去请求数据。通常数据请求是页面内容渲染中关键路径最长的部分,而且不能并行,所以如果能将数据请求提前,可以极大程度上缩短页面内容的渲染完成时间。 2.首屏加载和按需加载,非首屏内容滚屏加载,保证首屏内容最小化   由于移动端网络速度相对较慢,网络资源有限,因此为了尽快完成页面内容的加载,需要保证首屏加载资源最小化,非首屏内容使用滚动的方式异步加载。一般推荐移动端页面首屏数据展示延时最长不超过3秒。目前中国联通3G的网络速度为338KB/s(2.71Mb/s),所以推荐首屏所有资源大小不超过1014KB,即大约不超过1MB。 3.模块化资源并行下载   在移动端资源加载中,尽量保证JavaScript资源并行加载,主要指的是模块化JavaScript资源的异步加载,例如AMD的异步模块,使用并行的加载方式能够缩短多个文件资源的加载时间。 4.inline首屏必备的CSS和JavaScript   通常为了在HTML加载完成时能使浏览器中有基本的样式,需要将页面渲染时必备的CSS和JavaScript通过1 <script>或1 <style>内联到页面中,避免页面HTML载入完成到页面内容展示这段过程中页面出现空白。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>样例</title> <meta name="viewport" content="width=device-width,minimum-scale=1.0, maximum-scale=1.0,user-scalable=no"> <style> /* 必备的首屏CSS */ html, body{ margin: 0;...


  • 前端性能优化(二) 桌面浏览器前端优化策略

      通过性能测速和分析,我们基本可以获取收集到页面上大部分的具体性能数据,如何根据这些数据采取适当的方法和手段对当前的页面进行优化呢?目前来看,前端优化的策略很多,如YSlow(YSlow是Yahoo发布的一款Firefox插件,可以对网站的页面性能进行分析,提出对该页面性能优化的建议)原则等,总结起来主要包括网络加载类、页面渲染类、CSS优化类、JavaScript执行类、缓存类、图片类、架构协议类等几类,下面逐一介绍。 一、 网络加载类 1.减少HTTP资源请求次数   在前端页面中,通常建议尽可能合并静态资源图片、JavaScript或CSS代码,减少页面请求数和资源请求消耗,这样可以缩短页面首次访问的用户等待时间。通过构建工具合并雪碧图、CSS、JavaScript文件等都是为了减少HTTP资源请求次数。另外也要尽量避免重复的资源,防止增加多余请求。 2.减小HTTP请求大小   除了减少HTTP资源请求次数,也要尽量减小每个HTTP请求的大小。如减少没必要的图片、JavaScript、CSS及HTML代码,对文件进行压缩优化,或者使用gzip压缩传输内容等都可以用来减小文件大小,缩短网络传输等待时延。前面我们使用构建工具来压缩静态图片资源以及移除代码中的注释并压缩,目的都是为了减小HTTP请求的大小。 3.将CSS或JavaScript放到外部文件中,避免使用1 <style>或1 <script>标签直接引入   在HTML文件中引用外部资源可以有效利用浏览器的静态资源缓存,但有时候在移动端页面CSS或JavaScript比较简单的情况下为了减少请求,也会将CSS或JavaScript直接写到HTML里面,具体要根据CSS或JavaScript文件的大小和业务的场景来分析。如果CSS或JavaScript文件内容较多,业务逻辑较复杂,建议放到外部文件引入。 1 2 3 <link rel="stylesheet" href="//cdn.domain.com/path/main.css"> <script src="//cdn.domain.com/path/main.js"></script> 4.避免页面中空的href和src   当1 <link>标签的href属性为空,或1 <script>、1 <img>、1 <iframe>标签的src属性为空时,浏览器在渲染的过程中仍会将href属性或src属性中的空内容进行加载,直至加载失败,这样就阻塞了页面中其他资源的下载进程,而且最终加载到的内容是无效的,因此要尽量避免。 1 2 3 <!-- 不推荐 --> <img src="" alt="photo"> <a href="">点击链接</a> 5.为HTML指定Cache-Control或Expires   为HTML内容设置Cache-Control 或Expires可以将HTML内容缓存起来,避免频繁向服务器端发送请求。前面讲到,在页面Cache-Control或Expires头部有效时,浏览器将直接从缓存中读取内容,不向服务器端发送请求。 1 2 <meta http-equiv="Cache-Control" content="max-age=7200" /> <meta http-equiv="Expires" content="Mon, 20 Jul...


  • 前端性能优化(一) 前端性能分析

      前端性能优化是一个很宽泛的概念,本书前面的部分也多多少少提到一些前端优化方法,这也是我们一直在关注的一件重要事情。配合各种方式、手段、辅助系统,前端优化的最终目的都是提升用户体验,改善页面性能,我们常常竭尽全力进行前端页面优化,但却忽略了这样做的效果和意义。先不急于探究前端优化具体可以怎样去做,先看看什么是前端性能,应该怎样去了解和评价前端页面的性能。   通常前端性能可以认为是用户获取所需要页面数据或执行某个页面动作的一个实时性指标,一般以用户希望获取数据的操作到用户实际获得数据的时间间隔来衡量。例如用户希望获取数据的操作是打开某个页面,那么这个操作的前端性能就可以用该用户操作开始到屏幕展示页面内容给用户的这段时间间隔来评判。用户的等待延时可以分成两部分:可控等待延时和不可控等待延时。可控等待延时可以理解为能通过技术手段和优化来改进缩短的部分,例如减小图片大小让请求加载更快、减少HTTP请求数等。不可控等待延时则是不能或很难通过前后端技术手段来改进优化的,例如鼠标点击延时、CPU计算时间延时、ISP(Internet Service Provider,互联网服务提供商)网络传输延时等。所以要知道的是,前端中的所有优化都是针对可控等待延时这部分来进行的,下面来了解一下如何获取和评价一个页面的具体性能。 5.4.1 前端性能测试   获取和衡量一个页面的性能,主要可以通过以下几个方面:Performance Timing API、Profile工具、页面埋点计时、资源加载时序图分析。 一、Performance Timing API   Performance Timing API是一个支持Internet Explorer 9以上版本及WebKit内核浏览器中用于记录页面加载和解析过程中关键时间点的机制,它可以详细记录每个页面资源从开始加载到解析完成这一过程中具体操作发生的时间点,这样根据开始和结束时间戳就可以计算出这个过程所花的时间了。   图5-4为W3C标准中Performance Timing资源加载和解析过程记录各个关键点的示意图,浏览器中加载和解析一个HTML文件的详细过程先后经历unload、redirect、App Cache、DNS、TCP、Request、Response、Processing、onload几个阶段,每个过程开始和结束的关键时间戳浏览器已经使用performance.timing来记录了,所以根据这个记录并结合简单的计算,我们就可以得到页面中每个过程所消耗的时间。 图5-4 performance API关键时间点记录 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27...


  • whistle工具全程入门

      接触过前后端开发的同学应该都了解网络请求代理工具fiddler(mac下面常用的是Charles),可以用来拦截分析请求、包装请求、本地调试和移动端代理开发调试等。多多少少,fiddler和Charles使用起来还是有些区别,不过还好都是可视化的界面使用配置起来也都比较方便。   先说下使用体验。对于一个追求高效的开发者来说,总是觉得要经常切换两个工具的使用比较麻烦,但是配置规则不通用,fiddler+willow组合的使用很不错,但也总是让电脑比较慢,而且规则配置需要点击输入显得不那么高效;Charles是mac上一款不错的网络代理工具,不过是收费的,价格不便宜(当然你可以找破解),但是路径替换功能使用起来比较麻烦,这点体验很不好。在两个平台上都折腾过,而且要经常切来切去(自己的电脑是windows),后来决定尝试入坑whistle(由avenwu@tencent开发),发现非常高效易用,解决了困扰多年的问题。这里总结梳理下常用的功能和使用方式。   whistle文档入口在这里,安装入门使用和原理介绍略过,执行下面命令,然后打开 http://127.0.0.1:8899 就可以了。 1 2 npm i -g whistle #需要配代理的自己配 w2 start   一看就懂,当然文档是比较基础的,内容全,但也比较多,不适合快速入门,所以这里为大家梳理下实际开发中常用的一些规则配置,快速入门,大家可以对应fiddler或Charles的使用对号入座。 使用一键代理切换   安装启动whistle后,通常浏览器需要设置代理指向whistle Server地址127.0.0.1:8899,为了方便切换,chrome下推荐安装使用proxyOmega插件来提高切换效率,这样就可以一键切换代理。      打开界面我们主要关注Rules菜单项,点击create就可以在规则集合里面书写规则了。    1. host映射和特定子路径的host映射,whistle不仅支持传统的host配置,还支持子路径和端口的host转发配置 1 2 3 10.125.36.59 ke.qq.com # 直接的host配置 127.0.0.1:8086 ke.qq.com www.qq.com # 对全部域名路径替换host 10.125.36.59 ke.qq.com/ads # 对特定的路径替换host 2. 本地文件或文件路径替换,协议头可以加也可以不加,不加表示匹配所有协议,否则只对某个协议生效。类似willow的路径替换。 1 2 3 4 5 6 ctc.i.gtimg.cn/qzone/biz/gdt/atlas/mod/message.html C:\Users\ouvenzhang\Desktop\edit.html #...


  • 前端一站式异常解决方案

    一、前端异常监控的重要性   软件异常监控常常直接关联到软件本身的质量,完备的异常监控体系常常能够快速定位到软件运行中发生的问题,并能帮助我们快速定位异常的源头,提升软件质量。   在服务器开发中,我们常常使用日志来记录请求的错误和服务器异常问题,但是在客户端,前端应用直接部署运行在用户的浏览器中,如果发生错误,应该怎样去捕获并传送给服务器呢?前端错误日志传送给服务器很简单,在异常发生时直接发请求就可以了,下面我们主要讨论下错误的捕获方案。 二、现有的异常监控方案 window.onerror全局异常捕获   目前前端捕获页面异常的方式主要有两种,window.onerror捕获整个页面中运行的错误,它的局限是对于跨域的JavaScript脚本需要添加跨域支持,也就是需要涉及服务器的修改成本,否则无法获取到运行时具体的堆栈错误信息,而是”script error”的信息,不利于我们定位问题。 1 2 3 4 5 6 7 8 9 10 11 window.onerror = function(msg, file, row, column, errorObj) { console.log(msg); // script error. console.log(file); // console.log(row); // 0 console.log(column); // 0 console.log(errorObj); // {} setTimeout(function() { // 发送请求上报日志信息 errorReport(e.name, e.message + e.stack); },...


  • 现代前端技术解析

      前端技术发展很快,要学习的东西越来越多,通常我们需要阅读不同很多资料书籍才能了解。比如针对某种技术或框架我们都要去购买一本书籍去了解,久而久之,我们对前端的了解依然局限于点点面面,而无法对前端有一个体系化的认识。这是件很令人烦恼的事情。   2017年很快又过去了几个月,在过去的一年里,前端技术迅猛发展,前端各类技术都在优化升级,”大前端”的概念进一步体现,前端人才需求量进一步扩大,但优秀的前端工程师却如大海捞针,一将难求。那么在未来一年里我们应该做好怎样的准备才能成为一名优秀(不仅仅是合格)的前端工程师呢? 一 、现代前端技术知识体系   我们先看看2017~2018前端技术知识体系图,这也是现代前端技术体系结构图的第二版。 下载大图   大家也可以对比2016年的知识技术体系来看看:2015-2016前端知识体系。在这次更新中,主要完善了原有的部分知识内容的原理解析,增加了新的领域内容。   可能大家觉得体系图中内容还是过于抽象,没有有经验的人带,仍不能在实践中深入学习,或者需要自己花更多的时间搜索资料才能了解,亦或是网上的学习资料不够全面深入。   幸运的是,对于现代前端技术知识体系图,现在已经推出了《现代前端技术解析》一书,针对2017年~2018年前端技术知识体系内容深入原理,展开剖析,体系化、全面地帮助前端读者们解决了这些问题。我们不妨先来看看本书目录(打不开看这个链接),再回头来看。 二、《现代前端技术解析》适读人群   前端入门极其简单,但要学习提升成为一名优秀的前端的工程师又极其不易,因为涉及的技术点很多,我们往往需要阅读很多书籍才能理解前端技术的知识体系。这本书在前端知识体系上做了很好的总结和梳理,涵盖了现代前端技术绝大部分的知识内容,起到一个启蒙作用,能帮助读者快速把握前端技术的整个脉络,培养更完善的体系化思维,掌握更多灵活的前端代码架构方法,能够帮助读者获得成为前端高级工程师或架构师所必须具备的思维和能力。   同时,本书是来自一位腾讯一线前端工程师的工作经验和技术成长梳理总结,于2017年4月底正式发售,是一本全部由阿里、腾讯前端团队多位技术管理和技术专家一起审稿推荐完成的前端思维体系成长进阶必读书,融合了业内极其全面的前端知识技术实践经验。如果您不确定买不买,也可以先看看本书目录(打不开看这个链接)。          (折后约 ¥ 50 ~ ¥ 65)   进入京东购买   进入淘宝购买   进入亚马逊购买   《现代前端技术解析》适合以下几类读者阅读: 针对想进入阿里、腾讯工作的求职者。项目做过很多,但面试总是悲剧,因为面试官一言不和就问你实现原理和解决方案,但你最擅长的可能是编代码。那么这本书能全面帮助你了解前端各方面的技术原理和实现机制,深入底层细节,让你对前端的理解不只是停留在代码层面面,更加轻松通过阿里、腾讯的技术面试。当然校招应届生更应该买来看看,提升竞争力。 针对刚入门的初学者。前端学习入门非常简单,但是进阶的道路非常漫长,不是折腾了几个框架就能深入学习的,入门后没有明确的方向指导,将可能一直停留在初级阶段。那么这本书能以一个更高的层面引导刚入门的学习者,应该具有怎样的前端视野和学习范畴。 针对想要进一步学习前端进阶技能的职业者,例如框架设计原理、架构设计原理等,想要报班学习或购买视频课程,但是培训报名费过极其昂贵(例如一般一套前端进阶课程一般在¥15000元以上)。前端技术发展很快,但是万变不离其宗。现在只需要低价购买这本书籍,自己静心学习,理解其中的原理,就能在学习时触类旁通各类相关技术,知识内容性价比高出几十倍百倍。 在前端开发上具有一定基础和开发经验,但是对现代前端技术知识体系认识不够前面,不够深入的开发者。也可以通过此书快速了解主流技术框架和架构的设计原理,加速前端的学习过程,让学习的时间事半功倍。 对于进阶培训班的讲师或企业前端培训讲师。每节课程都需要去开发整理课件,很花时间,但是课件又过于抽象,如果没人讲解,不易于重复学习和传播。那么这本书就能很有用地帮助你规划教学路径,让您更轻松、更详细地展开进阶教学内容,也能帮助学员们有书可读,有书可依。   当然,如果你还是刚要入门的学习者,还没接触过前端,但是想要学习前端。那么,我也推荐你先学习另一个前端基础知识体系结构图来开始,加上一两个的项目实践,再来进阶学习2017年~2018年前端技术知识体系内容。查看前端基础知识结构图   新手推荐基础参考资料:www.w3cschool.cn,而不是 http://www.w3school.com.cn/ 哦。 三、对于此书,看看腾讯、阿里的大牛怎么说   近几年前端技术发展迅猛,前端人才的需求急剧增加。本书从一名一线专业前端从业者的角度,面面俱到地给大家剖析了当前Web前端所需要具备的各种现代技术。无论是从网络、浏览器还是从工程化、团队协作的角度都给出了非常好的呈现,非常值得大家阅读。 --郭学亨(Henry),腾讯前端IMWeb团队负责人   近几年前端的书籍很少有全面而且深入介绍前端技术思想与理论相关的,大部分都是独立拆分介绍前端单点领域的技术栈。这本书以现代前端技术思想与理论为主,详细而且深入,但又通俗地向读者阐述了现代前端技术栈。不管对初学者还是中级者都是值得一读的好书,读者们可以通过本书快速领略到前端领域的深度和广度,把握整个前端技术领域所涵盖的绝大多数知识技术要点和发展方向,为未来深入学习前端知识提供指导和方向。 -- 大漠,W3cplus.com 站长   现如今前端已经不再是一种“新兴职业”,对技术系统且全面的追求愈显重要,但繁杂的技术体系及各种旁支经常让初学者无所适从;本书能从全局和主流的视野介绍前端职业工程师几乎涉猎的所有知识,并将前端工作中涉及到的解决方案分门别类,抽象成易于理解的思路;相信对前端感兴趣的读者能够借助这本难得的好书触类旁通,一帆风顺地推开通往前端界的神秘大门,快速地成为一位优秀的前端工程师。 --许诺(Darksnow),阿里巴巴前端无线开发专家   本书从一名前端工程师的角度,梳理了现代前端所涉及的基础知识体系和原理性技术解析,包括开发方式的变更、前端框架的演进、前端跨栈技术以及未来的VR等等,契合当前流行的“大前端”概念,非常适合读者们扩宽个人知识面。另外作者本人在前端方面有很深的造诣,对目前的一些前端问题有深入的研究和个人独特的见解。相信读者朋友们一定能从本书中收获颇多。 --邓海龙(Helon),腾讯前端IMWeb团队成员   前端技术日新月异且涉及的知识面较广泛。对于初学者,可能有不知从何学起、所学的东西是否已经过时的困惑;对于中级者,可能对某些知识的了解不够全面和深刻。本书从前端技术的发展历程到整体架构体系逐层展开,基本涵盖了现阶段的前端技能树,为前端学习者指明了方向;同时本书注重从原理的层面进行知识点的解析,万变不离其宗,各种框架或技术之间其很多思想是相通的,把握住这点,将对读者们后续的学习会更有帮助。 ---李双双(Lissa),腾讯前端工程师    申明:本文为半知识总结类文章,融合了知识技术体系总结,也向大家推荐了书籍,大家可以根据需要选择购买。对于前端学习者来说,相对于买一套昂贵的前端学习课程,购买一本课程内容的书更加实用,且可以用于反复学习,慢慢研究领悟,推荐买来看看,最后衷心祝各位前端learner们学有所成。 京东点击购买...


  • react+redux+koa技术栈实现小结

      虽然别人整理的入门知识资料已经挺多的了,但不一定适合自己,还是重新整理下,理一理React的开发生态。 一、React 安装使用   使用react,只需要引入react.min.js(React 的核心库)和react-dom.min.js(提供与 DOM 相关的功能)即可。 1 2 3 4 5 6 7 8 9 10 11 <script src="../js/lib/react.min.js"></script> <script src="../js/lib/react-dom.min.js"></script> <div id="example"></div> <script type="text/babel"> ReactDOM.render( <h1>Hello, world!</h1>, document.getElementById('example') ); // 这段代码将一个h1标题,插入id="example"节点中 </script> 通常为了使用JSX语法,我们需要在文件打包时使用插件将含有JSX语法的文件解析成普通的JavaScript语法,例如fis3-parser-react;如果使用到了ES6的写法,也需要将其转为ES5的格式,例如使用fis3-parser-babel。(现在前端已经不用ES6了,babel太慢影响效率,ES6在Node上使用) 二、React JSX   React使用JSX来替代常规的 JavaScript,以为JSX执行时进行了优化,含有错误检测而且方便我们书写模板。 1 2 3 4 5 6 7 8 9 10 11...


  • 聊聊未来的前端时代

      2016年结束了,前端技术的发展也将进入到一个新的阶段,那么未来又会给我们带来什么呢?这里就个人发表下意见,不喜勿喷。   就前端主流技术框架的发展而言,过去的几年里发展极快,在填补原有技术框架空白和不足的同时也渐渐趋于成熟。未来前端在已经趋向成熟的技术方向上面将会慢慢稳定下来,并进入技术迭代优化阶段,例如语言标准、前端框架等。但这并不代表前端领域技术就此稳定了,因为新的技术方向已经出现,并在等待着下一个风口的到来。那么什么是下一个风口?虚拟现实?人工智能?或者其它的?不管未来如何,就前端应用开发方向来讲,MVVM、Virtual DOM和同构的技术解决方案依然会延续发展一段时间。而且这段时间内前端框架技术的变化将不会像原来一样具有颠覆性。   当 MVVM、Virtual DOM或同构等技术实践都有很成熟高效的框架和方案去实现了。那么对于移动端应用,前端要重点发展的下一步可能就是MNV的原生NativeView开发,例如使用通用的MNV前端技术实现方案来降低移动端Native和前端Web交互的开发成本,让前端既可以通过Native编译开发出稳定的原生应用外壳,也可用来开发快速迭代、高性能的移动端MNV*应用,最终形成一套移动端上高效率的前端开发生态体系。   另一方面,新领域的Web化思路也会给前端带来新的技术革新和发展机遇,例如Web VR(Virtual Reality,虚拟现实)、物联网(Physical Web,顾名思义,就是将物体连入网络的一种理念)Web化或者网站人工智能等,这些方向的开发者早已跃跃欲试,目前国外也能找到少数这样的应用站点。 1. 未来前端趋势   经过近几年的发展,现代前端已经发展到跨端、跨界面的革新阶段,目前主流以基于MVVM、Virtual DOM、移动端MNV*思路和前后端同构技术进行开发的项目居多,实现的方向也多种多样,这些我们前面对应的章节也均有讲到。当然除了这些,关于未来,还有一些我们前端工程师需要了解的,那我们就一起来看下未来前端具体可能会发展成怎样的呢。 1.1 新标准的进化与稳定   前端新标准和草案在不断更新,HTML、CSS、JavaScript标准也在渐渐完善,尽管这些新的规范最终会淘汰旧标准的使用,新的项目也会以最新的标准作为开发依据,但要完全停止旧标准的使用并完成企业级旧项目的升级,依然需要一段时间。例如原有CoffeeScript的项目不可能一次性的做出迁移重构,但我们的项目仍需要维护,我们不能脱离实际项目去谈技术,这就需要一段时间来慢慢修改;再如Web Component现在也不会马上作为唯一标准大力推广。但可以肯定的是,新的语言或技术标准一定会被推广使用,只是还需要时间。   同时基于标准也会出现一些衍生的脚本语法和规范来适应特定的应用场景,这些非标准的规范除了解决具体业务技术问题之外,极有可能进化成下个标准的一部分或被新的标准借鉴。例如CoffeeScript虽然最终没有形成JavaScript开发标准,但EcmaScript 6却借鉴了其中很多优秀的特性;或者目前生成Virtual DOM的衍生脚本语法,未来也是有可能被列入到JavaScript标准当中的。   经过大版本的更新稳定,目前前端三层结构实现已经形成了HTML5、CSS3、EcmaScript 6+标准规范结合的阶段,后面标准的新变化也会越来越小,至少迄今为止,我们无法预见HTML6的到来、CSS4的特性目前也令人担忧、EcmaScript 7的特性更新也并不明显,这都显示出,目前前端项目实践规范将会相对稳定一段较长的时间,后面的修改不会像之前一样具有颠覆性,这也是技术标准发展到一定成熟阶段会发生的事情。 1.2 应用开发技术趋于稳定并将等待下一次革新   从前端应用开发框架上来看,先后经历了DOM API、MVC、MVP、MVVM、Virtual DOM、MNV*阶段,逐步解决了前端开发效率、设计模式、DOM交互性能的问题。这些问题处理完成后,相关的框架也会进入稳定发展、版本有序迭代的时期。也就是说前端的交互框架不会像以前那样变化频繁,相对于之前前端框架的频繁更换到现在主流框架的稳定升级,我们可以看出这点。但目前前端可能还有一件需要去做的事情,那就是使用前端技术栈独立开发Native应用的能力,如果做到这点,前端开发者就可以结合MNV开发模式独立进行Native应用开发并快速实现高性能的移动端应用了。因为目前的MNV框架的设计实现依然依赖已有少数几个成熟Native应用的运行环境,还做不到在通用的APP上用前端技术栈直接调用移动设备原生API。但如果前端技术栈具备了通用的Native开发能力,技术上也就意味着,JavaScript脚本(或是衍生的其它脚本)可以将任何一个普通的移动端应用编译打成为Native包,并能使用MNV*模式直接与移动设备原生API进行交互。目前也有框架实现在做这方面的尝试,但还不是很理想,仍需要更多的改进完善。但无论如何,前端技术栈的Native开发实现技术必将成为前端的下一个实践核心。 1.3 持续不断的技术工具探索   前端技术效率和性能的提升当然不是仅靠前端框架都能解决的,还需要其他各方面辅助工具的支持,例如高效的调试工具、构建自动化工具、自动发布部署工具等。所以未来前端发展过程中各种高效工具的探索仍会不断地出现,来解决特定场景下的问题,最后进行一个优胜劣汰的过程。 1.4 浏览器平台新特性的应用   就浏览器端应用而言,以Chrome为代表的浏览器版本和特性发展迭代极其迅速,经过多版本的迭代,浏览器上已经可以实现较多的增强和实用特性,例如Web Component、Service Worker、IndexDB、WebAssembly、WebRTC、EcmaScript 6+的支持等等,但由于浏览器的种类和版本的多样性,我们还不能在业务中直接推广使用这些新的特性,但这些却仍然给了我们很多未来技术实现的可能,并且未来较多技术也会在这些新特性的基础上优化或改进产生。 1.5 更优化的前端技术开发生态   贯穿浏览器、服务端和移动端,前端正朝着多端、多技术实现的方向发展。这意味着前端这套技术栈能做的事情可能更多,涉及的平台更广,但作为整套技术开发生态的一部分,每一项技术的出现都必不可少的要去考虑开发效率、维护成本、性能、扩展性这几个方面的问题,所以寻找并发展更优的开发生态体系仍是前端未来的大方向,对于新技术的出现,我们也会从下面几个方面去评价它的意义。 开发效率。通常提高开发效率的方式就是使用开发框架。例如DOM编程框架的实现,简化了脚本API的使用、提高了代码复用性,选择好的框架常常能够让我们的工作事半功倍。 维护成本。使用框架提高了项目的开发效率,但却并不能解决代码维护性的问题。这就需要借助合适的模式来管理项目开发的代码,降低项目的维护成本,例如提取公共业务基础库、模块化、组件化等。目前可能最佳的实践就是组件化了,让业务模块的实现和管理有章可循,同时这也是Web标准未来发展的需要。 性能。从前端开发框架的演进来说,可以总结为先专注于解决前端的开发效率问题,然后解决前端的交互性能问题,再去尝试打通Native开发的能力。所以性能将作为未来评价任何一个框架或技术优劣性的重要标准而存在,同时性能也将是一个无法避开的永久性话题。 扩展性。其实扩展性不只是讲框架的方便定制和扩展特性,还要做到能与原来的技术框架相兼容并解耦合。很实际的场景,例如要使用某个新技术对原有的业务做改造,我们不可能马上就替换掉所有的业务模块,那么就不能因为新增加的技术框架实现而导致旧的模块运行出现问题。所以在新技术的应用中,除了保证原有业务层的扩展兼容,实现功能的平滑过渡也是一个必须考虑的问题。 1.6 前端新领域的出现 除了目前浏览器、服务器、移动端上的应用开发技术变革和探索外,未来前端也会出现新的应用场景。例如VR、物联网Web化、Web人工智能等。这些虽然听着比较远,但一旦到来就会很快被使用,所以前端不仅自身发展快,推广使用也极其迅速,例如移动互联网Web的普及也就两三年时间。 近几年,Web VR和物联网Web化的概念渐渐出现,国外甚至出现了以人工智能为支撑的Web应用。...

公众号

加我赏红包,哈哈哈

公众号

欢迎关注 极限前端 公众号