2019前端3大趋势：JavaScript应用广泛，静态类型语言TypeScript将继续受到更多开发者的青睐。组件已经成为前端最基础的素材，CSSincomponents（CSSinJS）的解决方案也越来越成熟。前端“端”越来越多，API查询语言GraphQL将继续保持高速增长。JavaScript应用广泛，TypeScript更为流行。在github2018年调查报告中，JavaScript连续多年位居第一，成为最佳开发语言。从StackOverflow的调查报告中，我们可以看到更详细的数据，任意两个开发者中至少有一个会JavaScript，而且这个比例还在增长，从2016年的55.4%增长到2017年的62.2%，再到2018年的69.8%。npm调查报告显示，JavaScript生态系统也非常繁荣，模块数量持续高速增长，将其他语言远远甩在后面。图1：npm2018研究报告——模块数从使用范围来看，JavaScript可以用来编写前端、服务器端、移动端，甚至物联网应用。在npm2018调查报告中，大多数JavaScript开发者*编写Web前端应用程序(93%)和node.js服务器端应用程序(70%)。在stateofjs2018研究报告中，仍然有相当数量的JavaScript开发者*编写移动或桌面应用程序，例如Electron（19.6%）、ReactNative（18.7%）、NativeApps（10.6%）、Flutter、Weex、PWA都在1%以内。备注：npm和stateofjs的研究用户群体具有相似的特征，统称为JavaScript开发者。图2：npm2018研究报告——我写的JavaScript运行在...值得注意的是，TypeScript在2018年受到了更多开发者的青睐，TypeScript在github语言排名中上升了3位，达到第7位。在stateofjs2018调查报告中，86.3%的JavaScript开发者愿意继续使用ES6，46.7%愿意继续使用TypeScript。排在第三和第四位的是Facebook的Flow和Reason语言，但占比都不高。图3：Stateofjs2018研究报告-JavaScriptFlavors从互联网发展史来看，2010年3G（国内）开始普及，2014年4G全面铺开，拉开了移动互联网的序幕。互联网已经从传统的内容提供者转变为服务提供者。前端应用也发生了本质的变化，从传统互联网时代的内容展示，变成了交互逻辑复杂的服务提供者窗口。随着前端应用越来越复杂，JavaScript应用越来越广泛，传统的JavaScript（ES5）已经适应了复杂的开发需求，于是更强大的ES6诞生了。在JavaScript应用日益复杂的背景下，预计在2019年，静态类型语言TypeScript将继续受到更多开发者的青睐。TypeScript是ES6的超集。一方面，它很好地兼容了ES6语法。另一方面，它提供可选的静态类型检查和接口函数。在开发高复杂度、大规模协作的JavaScript应用时，TypeScript可能是比ES6更好的选择。组件已经成为最基本的前端素材，JS中的CSS让组件化更加彻底。在stateofjs2018的研究报告中，64.8%的JavaScript开发者愿意继续React，28.8%愿意继续Vue。但据个人观察，国内Vue开发者比React多，可能是因为Vue简单易用，中文文档完善。在Angular方面，超过一半的使用Angular框架的开发者表示不愿意继续使用Angular进行开发。Preact、Ember、Polymer、JQuery等其他开发框架很少用到。现在，React和Vue已经成为前端开发框架的双雄。如果你不知道React或Vue，你可能连工作都找不到。图4：Stateofjs2018研究报告——前端框架组件是React和Vue的最大特性之一。在Vue中，一个.vue文件就是一个组件，包括Template、JS、CSS。CSS部分是可选的，开发者也可以将CSS分开。在React中，一个.jsx文件就是一个组件，但是JSX只能包含Template和JS两部分，组件的CSS部分必须从xxx.css中导入。React和Vue都无法改变CSS全局作用域的问题。开发者可以使用Selector，比如.class.id，来获取组件中本应属于其他组件的CSS样式。组件应该有一个独立的作用域，但它的CSS是全局的！在应用复杂度不高，单人开发的情况下，CSSglobalscope问题不大。但是在多人合作开发的场景下，可能会导致风格冲突。比如因为引入了开发者B的组件，导致开发者A的组件样式乱了，导致联调成本高。图5：CSS文档级别V.S.组件级解决方案是在JS工具中使用CSS，让CSS只对所属的组件生效。JS解决方案中的CSS有很多，主流的有：styled-components,emotion,css-modules,aphrodite,glamour,glamorous,radium,react-jss。styled-components方案用户量最大，emotion方案排名第二且增长势头强劲，css-modules方案已于两年前停止维护，不再推荐使用。styled-components的写法太反直觉了，我个人更喜欢情感。从下载量的增长势头来看，emotion比styled-components快。所以，如果有项目需要用到JS中的CSS，还是比较推荐emotion。相信在2019年，CSSinJS的解决方案会更加成熟，不妨多多期待。图6：npmtrends.com的CSSinJS方案相比“端”下载量越来越大，GraphQL继续保持快速增长在移动互联网时代到来之前，传统的前端只是浏览器的PC端。移动互联网兴起后，出现了浏览器的H5端、iOS端、Android端。后来，一些平台级的应用，比如微信、QQ，推出了自己的JS-SDK，Hybrid成为了一个新的终端。近两年，微信、支付宝、百度、今日头条也相继推出了自己的小程序平台，小程序也成为了新的终端。每个终端都有自己的个性，没有一个统一的解决方案可以适应所有终端。这就导致同一个业务，需要在6个端开发6次，联调6次。我们假设有这样一个API，包含了两端业务的所有数据，解决了多路联调的问题。虽然还是需要开发6次，但是现在因为只有1个API，所以联调次数变成了1次。但这种解决方案背后的代价是加载缓慢和维护成本高。对于任何一端，都需要获取其他五端的差异化数据。加载不是很慢吗？如果改了API，可能会影响到6个终端的代码，而且维护起来也很费力。稍作改动，现在我们假设前端可以通过标准的API查询语法准确获取任意自定义数据，并在服务端解析前端查询语句返回其自定义查询数据。虽然还是6个终端，1个API，但是每个终端只能获取自己的数据，解决了加载慢的问题。如果某一端需要增加或修改获取的数据，只需要修改该端的查询语句即可，解决了维护成本高的问题。通过定义标准的API查询语法，前端可以像从数据库中获取数据一样方便灵活地获取API数据。GraphQL定义了一套标准的API查询语法，在保持灵活性和可维护性的同时，大大降低了联调成本。备注：GraphQL的一个官方例子是一个业务需要请求多个REST兼容的API。但是国内通常使用不符合标准的RESTAPI，其痛点在国内也没有那么痛，所以以成本高昂的多终端、多API联调为例。图7：@helferjs从REST到GraphQL因为使用API查询语言GraphQL的方法过于简单，省去了数据管理的麻烦。也就是说，使用GraphQL可以省去Redux和Mobx的工作。我们可以看到，在stateofjs2018研究报告中，GraphQL、Redux、Mobx都归为一类——DataLayer。报告显示，47.2%的JavaScript开发者表示会继续使用Redux，20.4%会继续使用GraphQL，5.6%会继续使用Mobx。需要注意的是，有62.5%的人表示对GraphQL感兴趣，因此GraphQL获得了Stateofjs最感兴趣奖（HighestInterest）。图8：Stateofjs2018研究报告——数据层预计2019年，GraphQL将继续保持快速增长，并被更多开发者使用。在npm2018研究报告中，特别指出GraphQL的客户端库Apollo的下载量一直保持快速增长。图9：npm2018年研究报告——GraphQL持续高速增长
