<ol start="">     <li> <p>JavaScript 应用范围广泛，静态类型语言 TypeScript 会继续得到更多开发者的青睐。</p> </li>     <li> <p>组件成为前端最基本的物料，CSS 融合在组件中(CSS in JS)的方案日趋成熟。</p> </li>     <li> <p>前端的“端”越来越多， API 查询语言 GraphQL 会继续保持高速增长 。</p> </li>    </ol>    <h2>JavaScript 应用范围广泛，TypeScript 更受青睐</h2>    <p>在 github 2018 调查报告的中，JavaScript 连续多年稳居第一，成为最受欢迎的开发语言。从 Stack Overflow 的调查报告中，我们可以看到更详细的数据，任意两个开发者中至少有一个会 JavaScript，并且这个比例还在持续增长，从 2016年的 55.4%，到 2017年的 62.2% ，到 2018 年的 69.8%。在 npm 的调查报告中，JavaScript 生态圈也是非常繁荣，module 的数量继续保持高速增长，将其他语言远远的甩在了后面。</p>    <p>图一： npm 2018 调研报告 - Module Counts</p>    <p><img src="https://simg.open-open.com/show/4adfa6f6047434c200ab47e5a81b2e47.jpg" alt="2019 年前端的 3 个趋势" width="500" height="361"></p>    <p>从使用范围上看，JavaScript 可以写前端、服务端、移动端，甚至还可以写物联网应用。在 npm 2018 的调研报告中，大多数 JavaScript 开发者*写 web 前端应用(93%)和 node.js 服务端应用(70%)。在 stateofjs 2018 的调研报告中，还有相当数量的 JavaScript 开发者*写移动或桌面应用，例如 Electron(19.6%)、React Native(18.7%)、Native Apps(10.6%)， Flutter 、Weex、PWA 都在 1% 以内。</p>    <p>备注：npm 和 stateofjs 的调研用户群体特征类似，统一归类为 JavaScript 开发者。</p>    <p>图二： npm 2018 调研报告 - The JavaScript I write runs on...</p>    <p><img src="https://simg.open-open.com/show/9f6c788c10634f2d170fb493d4349b64.jpg" alt="2019 年前端的 3 个趋势" width="500" height="384"></p>    <p>值得注意的是，TypeScript 在 2018 年得到更多开发者的青睐。在 github 语言排行版中，TypeScript 上升了 3 名，排到了第 7 的位置。在 stateofjs 2018 的调研报告中， JavaScript 开发者有  86.3% 愿意继续使用 ES6，有 46.7% 愿意继续使用 TypeScript。排在第三、四的是 非死book 的 Flow 和 Reason 语言，但是占比都不高。</p>    <p>图三：stateofjs 2018 调研报告- JavaScript Flavors</p>    <p><img src="https://simg.open-open.com/show/61315a08e561ce4174a8da63b2b85c80.jpg" alt="2019 年前端的 3 个趋势" width="550" height="238"></p>    <p>从互联网的发展历史的角度看，2010 年 3G (国内)开始普及，2014 年 4G 全面铺开，拉开移动互联网的序幕。互联网从传统的内容提供者，转变成了服务提供者。前端应用也发生的本质的转变，从传统互联网时代的内容展示，转变成了拥有复杂交互的逻辑的服务提供窗口。随着前端应用变得越来越复杂，和 JavaScript 应用的领域越来越广泛，传统 JavaScript(ES5) 已经适应复杂的开发需求，因此功能更加强大的 ES6 孕育而出。</p>    <p>在 JavaScript 应用复杂度不断增加的背景下，预计 2019 年，静态类型语言 TypeScript 会继续得到更多开发者的青睐。TypeScript 属于 ES6 的超集，一方面它可以很好的兼容 ES6 语法，另一方面它又提供了可选的静态类型检查和 接口(interface)的功能。在开发复杂度高、需要大规模合作的 JavaScript 应用时，TypeScript 相对 ES6 不妨是一种更好的选择。</p>    <h2>组件成为最基本的前端物料，CSS in JS 让组件化更彻底</h2>    <p>在 stateofjs 2018 的调研报告中， JavaScript 开发者有 64.8% 愿意继续 React，有 28.8% 愿意继续 Vue。但根据个人观察，在国内 Vue 开发者会比 React 多一些，这可能是因为 Vue 上手简单并且有完善的中文文档。Angular 方面，有超过一半使用 Angular 框架的开发者表示，不愿意继续使用 Angular 进行开发了。而其他开发框架 Preact、Ember、Polymer、JQuery 的使用量都很少。现在，React 和 Vue 已经成为前端开发框架的双雄，不会 React 或 Vue 可能连工作都不好找。</p>    <p>图四：stateofjs 2018 调研报告 - Front-end Frameworks</p>    <p><img src="https://simg.open-open.com/show/a463de29a69e8bf02f421a8c55ee6369.jpg" alt="2019 年前端的 3 个趋势" width="550" height="257"></p>    <p>组件是 React 和 Vue 最强大的功能之一。在 Vue 中一个 <code>.vue</code> 文件就是一个组件，包含 Template、JS、CSS 三个部分，其中 CSS 部分是可选的，开发者也可以将 CSS 独立出去。在 React 中一个 <code>.jsx</code> 文件就是一个组件，但是 JSX 只能包含 Template、JS 两个部分，组件的 CSS 部分必须 <code>import from 'xxx.css'</code> 进来。</p>    <p>无论是 React 还是 Vue，都改变不了 CSS 全局作用域的问题。开发者可以在一个组件中，通过 Selector，如 <code>.class</code> <code>.id</code> ，取到本该属于其他组件的 CSS 样式。组件本应是一个独立的作用域，但是它的 CSS 竟然是全局的！在应用复杂度低、单人开发的情况下 CSS 全局作用域不算大问题。但是在多人合作开发的场景下，可能会因此导致样式冲突。比如，因为引入了 B 开发者的组件，A 开发者的组件样式错乱了，这就导致了较高的联调成本。</p>    <p>图五：CSS document level V.S. component level</p>    <p><img src="https://simg.open-open.com/show/058c9945bbbe789f03b56dcae5577a1c.jpg" alt="2019 年前端的 3 个趋势" width="550" height="332"></p>    <p>解决的思路就是，使用 CSS in JS 的工具，使得 CSS 只对它归属的组件生效。CSS in JS 的方案有很多，主流的有：styled-components、emotion、css-modules、aphrodite、glamor、glamorous、radium、react-jss。styled-components 方案使用人数最多，emotion 方案排第二并且增长势头凶猛，而 css-modules 方案在两年前已经停止维护了，不再推荐。styled-components 的写法太反直觉，个人更喜欢 emotion。从下载量的增长势头来看 emotion 比 styled-components 更快。因此，如果有 CSS in JS 需求的项目，更加推荐 emotion。相信在 2019 年，CSS in JS 方案会更加成熟，我们不妨期待吧。</p>    <p>图六： npmtrends.com CSS in JS 方案下载量对比</p>    <p><img src="https://simg.open-open.com/show/edf9b783a14f490c61578c1c0d3cad83.jpg" alt="2019 年前端的 3 个趋势" width="550" height="251"></p>    <h2>“端”越来越多，GraphQL 继续保持高速增长</h2>    <p>在移动互联网时代来临之前，传统意义上的前端只有浏览器的 PC 端。移动互联网兴起后，出现了浏览器的 H5 端、iOS 端、Android 端。再后来一些平台级 App ，比如微信、QQ，推出了自己的 JS-SDK，Hybird 也成为了新的端。近两年，微信、支付宝、百度、头条也推出了自己的小程序平台，小程序也成为了新的端。</p>    <p>每个端都有自个儿的个性，不存在一种大统一的方案，可以适配所有的端。这导致了同一个业务，需要在 6 个端，开发 6 次、联调 6 次。</p>    <p><img src="https://simg.open-open.com/show/87ffc1036e16bf0887bca0f92aa00e1b.jpg" alt="2019 年前端的 3 个趋势" width="550" height="71"></p>    <p>我们假设有一个这样的 API，它包含了该业务在各个端上所有的数据，这不就解决了多次联调的问题了嘛。虽然还是需要开发 6 次，但是现在因为只有 1 个 API，所以联调次数变成了 1 次。但是该方案的背后的代价是，加载慢、维护成本高。任意 1 个端，都要获取其他 5 个端的上差异化的数据，加载能不慢嘛。如果 API 有改动，可能会影响到 6 个端的代码，维护起来也费劲。</p>    <p>稍作改变，现在我们假设，前端可以通过一种标准的 API 查询语法，精确地获取任意自定义的数据，在服务端通过解析前端查询语句，返回其自定义的查询数据。虽然还是 6 个端，1 个 API，但是每个端可以只获取自己的数据，不就解决了加载慢的问题了嘛。如果某个端需要增改获取的数据，只需要修改这个端的查询语句即可，这不就解决了维护成本高的问题了吗。通过定义一种标准的 API 查询语法，可以使得前端获取 API 数据，就像从数据库获取数据一样方便和灵活。</p>    <p>GraphQL 就定义一套标准的 API 查询语法，在保持灵活性和可维护性的前提下，极大的降低了联调成本。</p>    <p>备注：GraphQL 官方使用的例子是，一个业务要请求多个 REST 规范的 API 。但是，国内通常使用的不是准守标准的 REST  API ，他们的痛点在国内不那么痛，所以改用多端多 API 联调成本高来举例。</p>    <p>图七：@helferjs 从REST到GraphQL</p>    <p><img src="https://simg.open-open.com/show/b32cc0afac98bbb53221182b86f51edc.jpg" alt="2019 年前端的 3 个趋势" width="550" height="308"></p>    <p>因为使用 API 查询语言 GraphQL 获取的方法太简单了，所以连数据管理的事省了。也就是说，使用 GraphQL 可以把 Redux、Mobx 干的活给省了。我们可以看到，在 stateofjs 2018 调研报告中， 把 GraphQL 和 Redux、Mobx 都归类为一类 —— 数据层(Data Layer)。报告中指出，有 47.2% 的 JavaScript 开发者表示会继续使用 Redux，20.4% 会继续使用 GraphQL， 5.6% 会继续使用 Mobx。需要留意的是，有 62.5% 表示对 GraphQL 感兴趣，因此 GraphQL 获得 stateofjs 的最感兴趣奖(Highest Interest)。</p>    <p>图八：stateofjs 2018 调研报告 - Data Layer</p>    <p><img src="https://simg.open-open.com/show/47db4e0dc2d65450f10162d32b112765.jpg" alt="2019 年前端的 3 个趋势" width="550" height="244"></p>    <p>预计 2019 年，GraphQL 会继续保持高速增长，被更多的开发者使用。在 npm 2018 调研报告中，特意指出了 GraphQL 的客户端库 Apollo 的下载量保持着高速的增长。</p>    <p>图九：npm 2018 调研报告-GraphQL continues hyper-growth</p>    <p><img src="https://simg.open-open.com/show/ba4e76d7c0582c4bca1c2a75763a104d.jpg" alt="2019 年前端的 3 个趋势" width="500" height="374"></p>    <p> </p>    <p>来自： <a class="cut cut70" href="https://mp.weixin.qq.com/s/wwB_gCrMx2EhwueVYKbemA?utm_source=tuicool&utm_medium=referral" style="display:inline-block;">https://mp.weixin.qq.com/s/wwB_gCrMx2EhwueVYKbemA</a></p>