2022-05-19 18:59:45
今天是个特殊的日子，十年前的这个时候我根本无法想像我可以在一家公司呆十年，坚持做一样工作十年之久。于是我就想要写点儿东西来回顾一下这十年的发生在我身上的事情。工作、学习、编程、生活。
我接触电脑的时间比较早，大约在小学五、六年级的时候就有了微机课。似乎是邓小平爷爷的一句「计算机要从娃娃抓起」的原因，学校采购了一批微机。每周都有一节课，大家都很期待。课堂上老师会教我们打字，在漆黑的屏幕上敲击 DOS 命令。
那个时候只感觉电脑很神奇，似乎就是电视机和游戏机的合体。
直到后来上了初中，有了互联网，有了网上聊天，有了局域网对战游戏。似乎电脑的用处又多了很多。
我人生中的第一台电脑是上高中时我三伯从深圳带回来的。上面装的是 Windows 98，后来有了 XP。但是我发现那台电脑太旧了硬件根本不支持安装 XP。这让我很失望，因为当时的 XP 看起来非常赏心悦目，比起 98 那种棱角分明的黑白灰风格漂亮多了。
直到现在我还记得，当时我专门进了一趟城，买了两张 3.5 英寸软盘。打算去网吧下载几首歌曲用软盘复制回家里的电脑上面。因为那时候家里面的电脑还没联网。因为3.5寸软盘容量只有 1.44MB，一首 mp3 格式的歌至少 3M 起，完全放不下。后来专门下载了另外一种音乐文件格式叫 wma，比 mp3 有更高的压缩率。一张软盘可以复制差不多两首歌曲。虽然那时候已经有能放 mp3 的随身听了但是折腾这个还挺有意思的。
接着就是玩 QQ 空间，那时候比较流行空间装扮。网上有很多看不懂的代码，复制到 QQ 空间的自定义模块里面去就会有很多神奇的效果。Flash 动画，一首动听的音乐，一张漂亮的图片。每当我去看别人的空间时总感觉：人家的空间怎么装扮的这么漂亮。
高中毕业后我就从城里买了一本年度版本的《电脑报》，用来排解那段无聊的夏日。当然我看完后，其实真正懂的只有一半不到，很多专业的用词，根本不知道是什么意思。当时就觉得会安装操作系统就已经非常利害了。
也就是由于这本电脑报的启蒙，让我在放假期间报志愿时选择了计算机软件这个领域。我几乎是很轻易的就做出了这个选择，选什么专业这个问题上家人们并没有强行给我建议。我当时只知道一点：世界首富比尔盖茨是干这个的，所以我觉得我要是做这个应该也不会太差。
上了大学就开始学软件专业相关的知识，实际上真正学起来的时候也是很枯燥，理论上的东西对于我来说总是让我感到望而生畏。但是好在我因为我是这个专业的，所以还保持了这个专业的一些基本操守。比如：我喜欢写博客、搭网站、倒腾服务器什么的。写博客是因为当时也流行这个，当年韩寒和徐静蕾博客就很出名。我觉得自己也可以写写，但是毕竟咱是搞计算机的，怎么着也得弄个专业一点的，完全是自己设计的网站那种。而不是用新浪博客这种托管的博客站点。最重要的一点是：托管的博客站点他们提供的控制博客主题样式的功能限制太大，而且也没法自定义域名。这就让我觉得没意思，因为我就想做一点和别人不一样的事情。
然后专业课上也学习了网页制作相关的技术。用 Dreamweaver 拖图片到表格布局中去，拼成一个网页，这是当时书上教的。但是我上网上查过之后发现这种模式已经过时了，当时流行一个网站重构的概念，使用 CSS 来进行页面设计，会让你的页面更加炫酷。
当时我就知道有一个网站叫做 CSS Zen Garden，它的主题思想就是提供一套 HTML 代码，然后只允许你使用 CSS 对页面的元素进行布局、设计。上面有很多非常棒的设计作品，只是你很难想像这是基于同一个 HTML 设计出来的。这也是 CSS 的魅力所在，限制你的并不是技术，而是你的创意和想法。
我大概就是这样进入到前端这个领域的。
大学还没毕业，就赶上了当时互联网的一股浪潮 —— 电子商务，其实就是网上卖东西。那些年几乎每年都有一样新的互联网概念出世：论坛、聊天室、博客、微博、团购、电商。似乎是中国互联网百花齐放的时代。哦，对了。那时候社交网络是 MySpace，Twitter 还没流行起来。不一样的是当时这些网站都可以访问。
通过写博客、逛论坛。我被一些创业的老板盯上了，还没毕业就联系我想让我去北京上班。我当时想的是先毕业再说。只是当时其它同学好像都很着急找工作了，但是我一点都不急，最后一个学期了我还常常自己玩自己的游戏，自己学自己的东西。好像在我的意识里从来就没有找不到工作这种设定。后来我才知道当时一些同学早早的去找工作，在西安一个月七八百块钱就不错了，还不管吃住的那种。
后来毕业后我就来到了北京，这个让人充满向往的城市。先后呆了两家公司后，来到了现在的公司。基本上我换工作的原因只有一个，就是我做的事情限制了我的成长。我感觉学不到什么新东西了我就会离职。
刚开始都是只写 HTML/CSS，小公司一般会这个就够了。但是稍大一点的公司，就需要我会写 JavaScript，那时候才感觉至少水平到了 JS 这一层才有了编程的概念。会 JS 就能去大公司、正规公司，也能学到很多未知的技术。
后来在公司一直做了大概有4年的前端工程师，那段时间里是我写代码频率最高的一段时间，因为业务需求多，前端要做的事情也很多。那时候流行模块化、组件化、工具自动化这些概念。慢慢的 Node.JS 也出现了，前端有了要开始要跨越和后端之间的那条界线的趋势。整个行业中前端工程师的整体素质也有了很大的提升。再后来你会发现很多做后端的同学转做前端，反而做的更好了。因为大家认识到了前端的重要性，前端不再是一些表层的东西。前端变成了一种和用户沟通的形式。
此时我也发现了自身的一些瓶颈，很多东西无法深入下去。有的概念几乎全是空白，于是我就去看一些更专业领域的书箱资料。学习了 Python, 了解了 Ruby，补上了操作系统相关知识点。后端可以说也入门了，此时我只需要一个实践的机会。
也是机缘巧合，由于公司变动调整，我转做了一年的 Java 工程师。这让我对于无论是编程语言层面，还是系统框架层面都有了新的认知，把我之前学习的零散的东西都建立成了一种体系。并且当我维护过十万行级别的代码的时候，我才对技术有了更加深刻的认识，对技术才产生了敬畏之心。
我在考虑问题的时候不再只看到我自己的那一面。而是技术上从系统层面看，功能上从产品层面看，管理上从项目的层面多角度的去理解一个软件产品生命周期。因此，我似乎具有了一种跨跃式的思维模式，从技术层面看清产品的本质，从产品层面理清楚技术的突破点。
直到现在，虽然我冠有前端工程的虚名。但事实上这并没有限制我做的事情。因为我从来不给我自己打标签。相对于这些名义上的东西来讲我更关心我正在做的具体的事情，是我做的这些事情定义了我是一个怎么样的人，而不是那些标签。
现在回看这十年间的我。北漂、地下室、租房、买房、成家、养育，这些关键词都成为了我经历中的一部分。我从来都没有想像过我能在北京这座城市实现这一切。
从感情上讲我是很讨厌北京这个城市的，因为他没有生活，只有拼搏。但是从理性上讲，我现在拥有的几乎所有世俗意义上的成就都是北京这个城市给我的。因为她公平，所以我才有机会。
我在公司这十年里面，几乎每年都会晋升。我和公司的关系已经不是简单的雇佣和被雇佣关系。而是相互成就、相互欣赏。
虽然不知道未来的路还能走多长，但是有句话说得好：
但行好事，莫问前程。
许多人都会因为自己工作或者职位的原因而给自己画个圈圈。我是一个程序员，程序员就是怎样、怎样的。
我在刚开始的时候，出于一种自恋式的骄傲我自己也这么认为。我觉得程序员是不善言辞的、有思想的、专注的一个群体。当我尝试用一些美好的词语去描绘他们的时候，我发现这并不完整，之于我自己更是如此。
但事实上程序员也是普通人。
他们有细腻、感性的一面
他们也有果敢、理性的一面
他们有或专业或普通的能力
他们有或高雅或低俗的需求
他们豪放、他们矜持
他们独一无二
…
不为别的，只因为他们是芸芸众生中所有普通人中的某一个完整的人而已。
如果说非要我总结几句身为程序员的行事格律，那我觉得应该是以下几句话：
2022-05-15 17:59:45
昨夜雨疏风骤，浓睡不消残酒。试问卷帘人，却道海棠依旧。知否，知否？应是绿肥红瘦。
—— 李清照〔宋〕
开头两句「昨夜雨疏风骤，浓睡不消残酒」是交代场景。昨天晚上下着稀疏小雨，伴着大风。睡了一觉醉意仍然没有消退。浓睡不消残酒，此处用「浓」字形容沉睡，浓本来是形容液体的，「浓睡」，「残酒」等字眼这就已经奠定了一大早她本身内心还未化解开的某种忧怨。她这才意识到院子里面的海棠花经历了风雨交加的夜晚，不知道情况如何了。
于是有了对话「试问卷帘人，却道海棠依旧」。这两句中的「试」、「却」被认为是最为精妙的内心情景描写。
「试」是因为李清照还不确定海棠花全部凋谢了，她内心还暂存了一点希望，哪怕只是一点点，就是这一点点支撑着她一大早醒来就急切地想知道院子里的情况。
「却」是因为「海棠依旧」肯定是不可能的，李清照读了很多书，经历了多少春夏秋冬，她不可能不知道春去夏来之时，下雨会带走海棠花。
虽然李清照不情愿承认海棠花凋零的事实，但是理智让她发出了对卷帘人的嗔叹：
「知否，知否？应是绿肥红瘦」。知道吗，知道吗？这个时节，现在的院子里应该是绿叶茂盛，红花凋零的时候。「绿肥红瘦」是全词最为绝妙的四个字，绿代表着夏天、树叶，红代表着春天、花开。「绿肥红瘦」则表达的是春去夏来海棠花凋零，青春、时光即逝的伤感。
通常多数人认为在这首词中，卷帘人只是不走心的说了一句「海棠依旧」。但是恰恰相反，我觉得在这首词里面「卷帘人」才是点睛之笔。
卷帘人的回答「海棠依旧」充满了智慧，卷帘人有着极高的情商，或许只有她懂李清照。
我们从「试问卷帘人」这句开始分析，此刻李清照很想知道风雨过后院子里面的情况。
卷帘人回答「海棠依旧」有两种可能：
其一，李清照当时问的就是「院子里面的海棠花怎么样了？」，卷帘人说：「海棠依旧」 其二，李清照的院子里面几乎全是海棠花，她问院子里的情况，卷帘人自然知道她问的是海棠花，于是说：「海棠依旧」
这两种可能，无论是哪种都至少说明了李清照非常关心海棠花如何了，她关心海棠花是因为她不想看见海棠花凋零而因此伤感，但是理智又告诉他时间（海棠花凋零的）到了，再美的东西都熬不过时间。只是她心里面还有那么一点点念想，或许还有那么几支还未凋零呢？
可以想象，此时如果卷帘人告诉他院子里的真实情景，那该有多残酷。难道卷帘人要告诉她：你那些心爱的海棠花都被昨天夜里的大雨打的凋零不堪、破败不堪、全部死掉了。那李清照岂不要哭死？
所以说卷帘人很懂李清照为何尽兴、为何伤感。卷帘人天天和李清照在一起，她的一个表情、一个神态、一颦一笑一忧愁都在卷帘人的眼里...
如果我是那个卷帘人，我是段不忍心告诉李清照真实情况的，那将是无比残忍、无比无情的人才说的出来的。
试问没有卷帘人「知否」何在？
试问没有卷帘人「绿肥红瘦」又将何在？
事实上如果没有卷帘人的存在，这首词似乎也能讲得通。我们理解的「试」和「却」两个字之间存在一种矛盾感。「试」表示不确定，心存的期许。「却」表示确定的转折对比，事实的无奈。
此语境更像是一位说梦的痴人被「海棠依旧」点醒了一般，又好像是一种痴人说梦般的暗自言语。
这首词音律是那么的完美，没有一个多余的字。节奏时急时缓、时快时慢、时抑时扬、时而押韵、时而叙述，如绵绵细流一般任意思绪流淌。如此只可能是一个人的自言自语，才能一气呵成。
所以其实根本没有卷帘人，只是李清照自言自语罢了。因为孤独的人都喜欢旁若有人般的暗自言语~
那么「海棠依旧」究竟意味着什么？
你难道不觉得「海棠依旧」这四个字充满了智慧吗？智慧到根本不像是由卷帘人口中说出来的。要么是李清照自己杜撰的，要么就是上面分析的那种可能——卷帘人有着超人的智慧。
或许李清照只想到了当下的绿肥红瘦，伤感于青春、时光的即逝。还在伤感困惑的她被卷帘人口中的「海棠依旧」所点化。
卷帘人淡淡地说道：「明年海棠花依旧会开，你又何必如此的感伤。春去春会回来，又有谁人绕过了时光？」
「海棠依旧」的真正意思不就是所谓的天之道吗？客观规律，不以人的意志为转移的道。
不管你信不信，海棠花每年都会开，不会因为你的怜惜海棠花就晚几日凋谢，也不会因为你的期许海棠花就提前开放。
此时，「海棠依旧」到底是出自谁口已经不重要了。
因为明天太阳照常升起，因为明年海棠依旧。
悟
悟道休言天命，
修行勿取真经。
一悲一喜一枯荣，
哪个前生注定？
袈裟本无清净，
红尘不染性空。
幽幽古刹千年钟，
都是痴人说梦。
2021-10-25 10:20:04
是的，我今天就想批判一下那些披着「设计（系统/语言）」外衣的研发工程师。
设计系统（Design system）这个概念应该是从国外最先有的。它的定义是：
A Design System is a set of interconnected patterns and shared practices coherently organized
设计系统是被统一组织起来的一系列紧密关联的模式和可重用的实践。
国内的组件库只有 Antd 在推出的时候声称自己是 一个 UI 设计语言，虽然当时我还不知道什么叫做设计语言，什么是设计系统。但是从工程师的角度我知道它就是 一套组件库。
一直到近两年，越来越多的前端团队以设计系统为排面推出自己的组件库的时候，我就觉得有些不对劲儿了。
哪里不对劲儿了？我在想我们实际上做的事情不就是设计了一套组件库吗，为什么要把设计放在前面。这似乎传达给我们一种信号：
我们应该是设计先行？我们应该优先做设计角度取舍。
相反的，工程层面实现那就应该向设计方向妥协？
我想并不是这样的，或者说不应该是这样的。
设计 永远是最上层的，它们关注的用户的外在、外观感受，它是感性的、多变的，没有唯一标准的。你很难想象用一套设计系统满足所有人的需求对吧？因为我喜欢蓝色，你喜欢红色这是不需要解释的。
工程 永远是最底层的，它关注事物内在的东西、自身属性，它是理性的、不变的，有迹可循的。所以工程层面追求的是一致、复用和效率。没人喜欢一个相同的组件在不同的实现上有不一样的 API。
在「前端工程师」这个职位名字中，「前端」是个形容词，「工程师」才是名词。
我们得先是工程师再是前端对吧。当我们不由自主地和设计靠拢时，思维模式也受到了影响，似乎只有设计思维才会关注到那些形容词。
当我们在设计一套组件库的时候会遇到很多不一致的情况，在我的经验里面：
来自与设计和实现的不一致要多于纯粹实现层面的不一致。
当我们设计的组件库需要考虑到跨端情况的时候，我们的组件库应该有一套一致的 API、一致的命名规则。但是从设计角度去决策的时候这件事情变得非常困难。
比如说：日期选择 这个组件，移动端通常叫做 DatePicker，这个词强调的是用户的动作（pick），在 PC 端通常叫做 Calendar，这个词强调的是组件本身的特征。
但是我们在工程实现层面真他妈不需要这种差别，它就是一个日期选择组件而已。
还有：按钮 组件的类型属性，有的是表形的：default/info/warning/error，有的是表义的：primary/secondary/danger
再一次，我们在工程实现层面真他妈不需要这种差别。它就是一个简单的按钮而已。
造组件库的人没有想清楚这件事情，用组件库的人却得承受这种不一致。那什么组件库的设计者们没想清楚这件事情？
因为他们的思维也被设计系统带偏了。一味的追求设计上的形式化的一致，却忽略了工程上逻辑的一致。
当这股邪风吹来，没人会在意组件库的工程化设计，没人在意它好不好用，每个人都想复制粘贴快速实现一套组件库，然后再披上设计系统的外衣，为自己的似锦前程添砖加瓦...
2021-05-09 10:20:04
我们先来看看官方的定义：
Fabric.js is a framework that makes it easy to work with HTML5 canvas element. It is an interactive object model on top of canvas element. It is also an SVG-to-canvas parser.
Fabric.js 是一个可以让 HTML5 Canvas 开发变得简单的框架 。 它是一种基于 Canvas 元素的 可交互 对象模型，也是一个 SVG 到 Canvas 的解 析器（让SVG 渲染到 Canvas 上）。
Fabric.js 的代码不算多，源代码（不包括内置的三方依赖）大概 1.7 万行。最初是 在 2010 年开发的， 从源代码就可以看出来，都是很老的代码写法。没有构建工具，没有 依赖，甚至没使用 ES 6，代码中模块都是 用 IIFE 的方式包装的。
但是这个并不影响我们学习它，相反正因为它没引入太多的概念，使用起来相当方便。不需 要构建工具，直接在 一个 HTML 文件中引入库文件就可以开发了。甚至官方都提供了一个 HTML 模板代码：
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<script src="https://rawgit.com/fabricjs/fabric.js/master/dist/fabric.js"></script>
</head>
<body>
<canvas id="c" width="300" height="300" style="border:1px solid #ccc"></canvas>
<script>
(function() {
var canvas = new fabric.Canvas('c');
})();
</script>
</body>
</html>
这就够了不是吗？
从它的官方定义可以看出来，它是一个用 Canvas 实现的对象模型。如果你需要用 HTML Canvas 来绘制一些东西，并且这些东西可以响应用户的交互，比如：拖动、变形、旋转等 操作。 那用 fabric.js 是非常合适的，因为它内部不仅实现了 Canvas 对象模型，还将一 些常用的交互操作封装好了，可以说是开箱即用。
内部集成的主要功能如下：
如果你之前没有过 Canvas 的相关开发经验（只有 JavaScript 网页开发经验），刚开始 入 门会觉得不好懂，不理解 Canvas 开发的逻辑。这个很正常，因为这表示你正在从传统 的 JavaScript 开发转到图形图像 GUI 图形图像、动画开发。 虽然语言都是 JavaScript 但是开发理念和用到的编程范式完全不同。
这两种开发方式各有各的优势，比如：
Canvas 开发的本质其实很简单，想像下面这种少儿画板：
Canvas 的渲染过程就是不断的在画板（Canvas）上面擦了画，画了擦。
动画就更简单了，只要渲染 帧率 超过人眼能识别的帧率（60fps）即可：
<canvas id="canvas" width="500" height="500" style="border:1px solid black"></canvas>
<script>
var canvas = document.getElementById("canvas")
var ctx = canvas.getContext('2d');
var left = 0
setInterval(function() {
ctx.clearRect(0, 0, 500, 500);
ctx.fillRect(left++, 100, 100, 100);
}, 1000 / 60)
</script>
当然你也可以用 requestAnimationFrame，不过这不是我想说明的重点。
fabric.js 的模块我大概画了个图，方便理解。
fabric.js 在初始化的时候会将你指定的 Canvas 元素（叫做 lowerCanvas）外面包裹上一 层 div 元素， 然后内部会插入另外一个上层的 Canvas 元素（叫做 upperCanvas），这两 个 Canvas 有如下区别
| 内部叫法 | 文件路径 | 作用 |
|---|---|---|
| upperCanvas | src/canvas.class.js | 上层画布，只处理 分组选择，事件绑定 |
| lowerCanvas | src/static_canvas.class.js | 真正 绘制 元素对象（Object）的画布 |
上图中，灰色的模块对于理解 fabric.js 核心工作原理没多大作用，可以不看。其它核心 模块我按自己的理解来解释一下。
所有模块都被挂载到一个 fabric 的命名空间上面，都可以用 fabric.XXX 的形式访问。
fabric.util 工具包工具包中一个最重要的方法是 createClass ，它可以用来创建一个类。 我们来看看这
个方法：
function createClass() {
var parent = null,
properties = slice.call(arguments, 0);
if (typeof properties[0] === 'function') {
parent = properties.shift();
}
function klass() {
this.initialize.apply(this, arguments);
}
// 关联父子类之间的关系
klass.superclass = parent;
klass.subclasses = [];
if (parent) {
Subclass.prototype = parent.prototype;
klass.prototype = new Subclass();
parent.subclasses.push(klass);
}
// ...
}
为什么不用 ES 6 的类写法呢？主要是因为这个库写的时候 ES 6 还没出来。作者沿用了
老 式的基 于 JavaScript prototype 实现的类继承的写法， 这个方法封装了类的继承、
构造方法、 父子类之前的 关系等功能。注意 klass.superclass 和
klass.subclasses 这两行， 后面会讲到。
添加这两个引用关系后，我们就可以在 JS 运行时动态获取类之间的关系，方便后续序列化 及反序列化操 作，这种做法类似于其它编程语言中的反射机制，可以让你在代码运行的时 候动态的构建、操作对象
initialize() 方法（构造函数）会在类被 new 出来的时候自动调用：
function klass() {
this.initialize.apply(this, arguments);
}
fabric.Canvas 类上层画布类，如上面表格所述，它并不渲染对象。它只来处理与用户交互的逻辑。 比如： 全局事件绑定、快捷键、鼠标样式、处理多（分组）选择逻辑。
我们来看看这个类初始化时具体干了些什么。
fabric.Canvas = fabric.util.createClass(fabric.StaticCanvas, {
initialize: function (el, options) {
options || (options = {});
this.renderAndResetBound = this.renderAndReset.bind(this);
this.requestRenderAllBound = this.requestRenderAll.bind(this);
this._initStatic(el, options);
this._initInteractive();
this._createCacheCanvas();
},
// ...
})
注意：由于 createClass 中第一个参数是 StaticCanvas，所以我们可以知道 Canvas
的父类 是 StaticCanvas。
从构造方法 initialize 中我们可以看出：
只有 _initInteractive 和 _createCacheCanvas 是 Canvas 类自己的方法，
renderAndResetBound，requestRenderAllBound，_initStatic 都继承自父类
StaticCanvas
这个类的使用也很简单，做为 fabric.js 程序的入口，我们只需要 new 出来即可：
// c 就是 HTML 中的 canvas 元素 id
const canvas = new fabric.Canvas("c", { /* 属性 */ })
fabric.StaticCanvas 类fabric 的核心类，控制着 Canvas 的渲染操作，所有的画布对象都必须在它上面绘制出来 。我们从构造函数中开始看
fabric.StaticCanvas = fabric.util.createClass(fabric.CommonMethods, {
initialize: function (el, options) {
options || (options = {});
this.renderAndResetBound = this.renderAndReset.bind(this);
this.requestRenderAllBound = this.requestRenderAll.bind(this);
this._initStatic(el, options);
},
})
注意：StaticCanvas 不仅继承了 fabric.CommonMethods 中的所有方法，还继承了
fabric.Observable 和 fabric.Collection，而且它的实现方式很 JavaScript，在
StaticCanvas.js 最下面一段：
extend(fabric.StaticCanvas.prototype, fabric.Observable);
extend(fabric.StaticCanvas.prototype, fabric.Collection);
requestRenderAll() 方法从下面的代码可以看出来，这个方法的主要任务就是不断调用 renderAndResetBound 方
法 renderAndReset 方法会最终调用 renderCanvas 来实现绘制。
requestRenderAll: function () {
if (!this.isRendering) {
this.isRendering = fabric.util.requestAnimFrame(this.renderAndResetBound);
}
return this;
}
renderCanvas() 方法renderCanvas 方法中代码比较多：
renderCanvas: function(ctx, objects) {
var v = this.viewportTransform, path = this.clipPath;
this.cancelRequestedRender();
this.calcViewportBoundaries();
this.clearContext(ctx);
fabric.util.setImageSmoothing(ctx, this.imageSmoothingEnabled);
this.fire('before:render', {ctx: ctx,});
this._renderBackground(ctx);
ctx.save();
//apply viewport transform once for all rendering process
ctx.transform(v[0], v[1], v[2], v[3], v[4], v[5]);
this._renderObjects(ctx, objects);
ctx.restore();
if (!this.controlsAboveOverlay && this.interactive) {
this.drawControls(ctx);
}
if (path) {
path.canvas = this;
// needed to setup a couple of variables
path.shouldCache();
path._transformDone = true;
path.renderCache({forClipping: true});
this.drawClipPathOnCanvas(ctx);
}
this._renderOverlay(ctx);
if (this.controlsAboveOverlay && this.interactive) {
this.drawControls(ctx);
}
this.fire('after:render', {ctx: ctx,});
}
我们删掉一些不重要的，精简一下，其实最主要的代码就两行：
renderCanvas: function(ctx, objects) {
this.clearContext(ctx);
this._renderObjects(ctx, objects);
}
clearContext 里面会调用 canvas 上下文的 clearRect 方法来清空画布：
ctx.clearRect(0, 0, this.width, this.height)
_renderObjects 就是遍历所有的 objects 调用它们的 render() 方法，把自己绘制
到画布上去：
for (i = 0, len = objects.length; i < len; ++i) {
objects[i] && objects[i].render(ctx);
}
现在你是不是明白了文章最开始那段 setInterval 实现的 Canvas 动画原理了？
fabric.Object 对象根类型虽然我们已经明白了 canvas 的绘制原理，但是一个对象（2d元素）到底是怎么绘制到
canvas 上去的，它们的移动怎么实现的？具体细节我们还不是很清楚。 这就要从
fabric.Object 根类型看起了。
由于 fabric 中的 2d 元素都是以面向对象的形式实现的，所以我画了一张内部类之间的继 承关系，可以清楚的看出它们之间的层次结构
不像传统的 UML 类图那样，这个图看起来还稍有点乱，因为 fabric.js 内部实现的是多重 继承，或者说类似于 mixin 的一种混入模式实现的继承。
从图中我们可以得出以下几点：
底层 StaticCanvas 继承了 Collection 对象和 Observable 对象，这就意味着
StaticCanvas 有两种能力：
所有的 2d 形状（如：矩形、圆、线条、文本）都继承了 Object 类。Object 有的属
性、方法，所有的 2d 形状都会有
所有的 2d 形状都具有自定义事件发布/订阅的能力
下面的注释中，边角控制器 是 fabric.js 内部集成的用户与对象交互的一个手柄，当 某个对象处于激活状态的时候，手柄会展示出来。如下图所示：
常用属性解释：
// 对象的类型（矩形，圆，路径等），此属性被设计为只读，不能被修改。修改后 fabric 的一些部分将不能正常使用。
type: 'object',
// 对象变形的水平中心点的位置（左，右，中间）
// 查看 http://jsfiddle.net/1ow02gea/244/ originX/originY 在分组中的使用案例
originX: 'left',
// 对象变形的垂直中心点的位置（上，下，中间）
// 查看 http://jsfiddle.net/1ow02gea/244/ originX/originY 在分组中的使用案例
originY: 'top',
// 对象的顶部位置，默认**相对于**对象的上边沿，你可以通过设置 originY={top/center/bottom} 改变它的参数参考位置
top: 0,
// 对象的左侧位置，默认**相对于**对象的左边沿，你可以通过设置 originX={top/center/bottom} 改变它的参数参考位置
left: 0,
// 对象的宽度
width: 0,
// 对象的高度
height: 0,
// 对象水平缩放比例（倍数：1.5）
scaleX: 1,
// 对象水平缩放比例（倍数：1.5）
scaleY: 1,
// 是否水平翻转渲染
flipX: false,
// 是否垂直翻转渲染
flipY: false,
// 透明度
opacity: 1,
// 对象旋转角度（度数）
angle: 0,
// 对象水平倾斜角度（度数）
skewX: 0,
// 对象垂直倾斜角度（度数）
skewY: 0,
// 对象的边角控制器大小（像素）
cornerSize: 13,
// 当检测到 touch 交互时对象的边角控制器大小
touchCornerSize: 24,
// 对象边角控制器是否透明（不填充颜色），默认只保留边框、线条
transparentCorners: true,
// 鼠标 hover 到对象上时鼠标形状
hoverCursor: null,
// 鼠标拖动对象时鼠标形状
moveCursor: null,
// 对象本身与边角控制器之间的间距（像素）
padding: 0,
// 对象处于活动状态下边角控制器**包裹对象的边框**颜色
borderColor: 'rgb(178,204,255)',
// 指定边角控制器**包裹对象的边框**虚线边框的模式元组（hasBorder 必须为 true）
// 第一个元素为实线，第二个为空白
borderDashArray: null,
// 对象处于活动状态下边角控制器颜色
cornerColor: 'rgb(178,204,255)',
// 对象处于活动状态且 transparentCorners 为 false 时边角控制器本身的边框颜色
cornerStrokeColor: null,
// 边角控制器的样式，正方形或圆形
cornerStyle: 'rect',
// 指定边角控制器本身的虚线边框的模式元组（hasBorder 必须为 true）
// 第一个元素为实线，第二个为空白
cornerDashArray: null,
// 如果为真，通过边角控制器来对对象进行缩放会以对象本身的中心点为准
centeredScaling: false,
// 如果为真，通过边角控制器来对对象进行旋转会以对象本身的中心点为准
centeredRotation: true,
// 对象的填充颜色
fill: 'rgb(0,0,0)',
// 填充颜色的规则：nonzero 或者 evenodd
// @see https://developer.mozilla.org/zh-CN/docs/Web/SVG/Attribute/fill-rule
fillRule: 'nonzero',
// 对象的背景颜色
backgroundColor: '',
// 可选择区域被选择时（对象边角控制器区域），层级低于对象背景颜色
selectionBackgroundColor: '',
// 设置后，对象将以笔触的方式绘制，此属性值即为笔触的颜色
stroke: null,
// 笔触的大小
strokeWidth: 1,
// 指定笔触虚线的模式元组（hasBorder 必须为 true）
// 第一个元素为实线，第二个为空白
strokeDashArray: null,
drawObject() 对象的绘制方法drawObject() 方法内部会调用 _render() 方法，但是在 fabric.Object 基类中它
是 个空方法。 这意味着对象具体的绘制方法需要子类去 实现。即子类需要 重写
父 类的空 _render() 方法。
_onObjectAdded() 对象被添加到 Canvas 事件这个方法非常重要，只要当一个对象被添加到 Canvas 中的时候，对象才可以具有 Canvas
的引用上下文， 对象的一些常用方法才能起作用。比如：Object.center() 方法，调用
它可以让一个对象居中到画布中央。 下面这段代码可以实现这个功能：
const canvas = new fabric.Canvas("canvas", {
width: 500, height: 500,
})
const box = new fabric.Rect({
left: 10, top: 10,
width: 100, height: 100,
})
console.log(box.top, box.left) // => 10, 10
box.center()
console.log(box.top, box.left) // => 10, 10
canvas.add(box)
但是你会发现 box 并没有被居中，这就是因为：当一个对象（box）还没被添加到 Canvas
中的时候，对象上面 还不具有 Canvas 的上下文，所以调用的对象并不知道应该在哪个
Canvas 上绘制。我们可以看下 center() 方法的源代码：
center: function () {
this.canvas && this.canvas.centerObject(this);
return this;
},
正如上面所说，没有 canvas 的时候是不会调用到 canvas.centerObject() 方法，也就
实现不了居中。
所以解决方法也很简单，调换下 center() 和 add() 方法的先后顺序就好了：
const canvas = new fabric.Canvas("canvas", {
width: 500, height: 500,
})
const box = new fabric.Rect({
left: 10, top: 10,
width: 100, height: 100,
})
canvas.add(box)
console.log(box.top, box.left) // => 10, 10
box.center()
console.log(box.top, box.left) // => 199.5, 199.5
「为什么不是 200，而是 199.5」—— 好问题，但是我不准备讲这个。有兴趣可以自己研究 下。
toObject() 对象的序列化正向的把对象序列化是很简单的，只需要把你关注的对象上的属性拼成一个 JSON 返回即可 ：
toObject: function(propertiesToInclude) {
var NUM_FRACTION_DIGITS = fabric.Object.NUM_FRACTION_DIGITS,
object = {
type: this.type,
version: fabric.version,
originX: this.originX,
originY: this.originY,
left: toFixed(this.left, NUM_FRACTION_DIGITS),
top: toFixed(this.top, NUM_FRACTION_DIGITS),
width: toFixed(this.width, NUM_FRACTION_DIGITS),
height: toFixed(this.height, NUM_FRACTION_DIGITS),
// 省略其它属性
};
return object;
},
当调用对象的 toJSON() 方法时会使用 JSON.stringify(toObject()) 来将对象的属性
转换成 JSON 字符串
fromObject() 对象的反序列化fromObject() 是 Object 的子类需要实现的反序列化方法，通常会调用 Object 类的默
认方法 _fromObject()
fabric.Object._fromObject = function(className, object, callback, extraParam) {
var klass = fabric[className];
object = clone(object, true);
fabric.util.enlivenPatterns([object.fill, object.stroke], function(patterns) {
if (typeof patterns[0] !== 'undefined') {
object.fill = patterns[0];
}
if (typeof patterns[1] !== 'undefined') {
object.stroke = patterns[1];
}
fabric.util.enlivenObjects([object.clipPath], function(enlivedProps) {
object.clipPath = enlivedProps[0];
var instance = extraParam ? new klass(object[extraParam], object) : new klass(object);
callback && callback(instance);
});
});
};
这段代码做了下面一些事情：
Object 的子类 fromObject 中指定）找到挂载在
fabric 命名空间上的对象的所属类噫，好像不对劲？反序列化入参不得是个 JSON 字符串吗。是的，不过 fabric.js 中并没 有在 Object 类中提供这个方法， 这个自己实现也很简单，将目标 JSON 字符串 parse 成 普通的 JSON 对象传入即可。
Canvas 类上面到是有一个画布整体反序列化的方法：loadFromJSON()，它做的事情就是
把一段静态的 JSON 字符串转成普通对象 后传给每个具体的对象，调用对象上面的
fromObject() 方法，让对象具有真正的渲染方法，再回绘到 Canvas 上面。
序列化主要用于
持久存储，反序列化则主要用于将持久存储的静态内容转换为 Canvas 中可操作的 2d 元素，从而可以实现将某 个时刻画布上的状态还原的目的如果你的存储够用的话，甚至可以将整个在 Canvas 上的绘制过程进行录制/回放
一些绘制过程中常见的功能也是通过序列化/反序列化来实现的，比如：撤销/重做
混入类（mixin）通常用来给对象添加额外的方法，通常这些方法和画布关系不大，比如：
一些无参方法，事件绑定等。 通常混入类会通过调用 fabric.util.object.extend() 方
法来给对象的 prototype 上添加额外的方法。
混入类里面有一个很重要的文件：canvas_event.mixin.js，它的作用有以下几种：
__onMouseMove() 可以说是一个核心事件，对象的变换基本上都要靠它来计算距离才能实
现，我们来看看它是如何实现的
__onMouseMove: function (e) {
this._handleEvent(e, 'move:before');
this._cacheTransformEventData(e);
var target, pointer;
if (this.isDrawingMode) {
this._onMouseMoveInDrawingMode(e);
return;
}
if (!this._isMainEvent(e)) {
return;
}
var groupSelector = this._groupSelector;
// We initially clicked in an empty area, so we draw a box for multiple selection
if (groupSelector) {
pointer = this._pointer;
groupSelector.left = pointer.x - groupSelector.ex;
groupSelector.top = pointer.y - groupSelector.ey;
this.renderTop();
}
else if (!this._currentTransform) {
target = this.findTarget(e) || null;
this._setCursorFromEvent(e, target);
this._fireOverOutEvents(target, e);
}
else {
this._transformObject(e);
}
this._handleEvent(e, 'move');
this._resetTransformEventData();
},
注意看源码的时候要把握到重点，一点不重要的就先忽略，比如：缓存处理、状态标识。我
们只看最核心 的部分，上面这段代码里面显然 _transformObject() 才是一个核心方法
。我们深入学习下。
/**
* 对对象进行转换（变形、旋转、拖动）动作，e 为当前鼠标的 mousemove 事件，
* **transform** 表示要进行转换的对象（mousedown 时确定的）在 `_setupCurrentTransform()` 中封装过，
* 可以理解为对象 **之前** 的状态，再调用 transform 对象中对应的 actionHandler
* 来操作画布中的对象，`_performTransformAction()` 可以对 action 进行检测，如果对象真正发生了变化
* 才会触发最终的渲染方法 requestRenderAll()
* @private
* @param {Event} e 鼠标的 mousemove 事件
*/
_transformObject: function(e) {
var pointer = this.getPointer(e),
transform = this._currentTransform;
transform.reset = false;
transform.shiftKey = e.shiftKey;
transform.altKey = e[this.centeredKey];
this._performTransformAction(e, transform, pointer);
transform.actionPerformed && this.requestRenderAll();
},
我已经把注释添加上了，主要的代码实现其实是在 _performTransformAction() 中实现
的。
_performTransformAction: function(e, transform, pointer) {
var x = pointer.x,
y = pointer.y,
action = transform.action,
actionPerformed = false,
actionHandler = transform.actionHandler;
// actionHandle 是被封装在 controls.action.js 中的处理器
if (actionHandler) {
actionPerformed = actionHandler(e, transform, x, y);
}
if (action === 'drag' && actionPerformed) {
transform.target.isMoving = true;
this.setCursor(transform.target.moveCursor || this.moveCursor);
}
transform.actionPerformed = transform.actionPerformed || actionPerformed;
},
这里的 transform 对象是设计得比较精妙的地方，它封装了对象操作的几种不同的类 型，每种类型 对应的有不同的动作处理器（actionHandler），transform 对象就充当了一 种对于2d元素进行操作 的 上下文，这样设计可以得得事件绑定和处理逻辑分离，代码 具有更高的内聚性。
我们再看看上面注释中提到的 _setupCurrentTransform() 方法，一次 transform 开始
与结束 正好对应着鼠标的按下（onMouseDown）与松开（onMouseUp）两个事件。
我们可以从 onMouseDown() 事件中顺藤摸瓜，找到构造 transform 对象的地方：
_setupCurrentTransform: function (e, target, alreadySelected) {
var pointer = this.getPointer(e), corner = target.__corner,
control = target.controls[corner],
actionHandler = (alreadySelected && corner)
? control.getActionHandler(e, target, control)
: fabric.controlsUtils.dragHandler,
transform = {
target: target,
action: action,
actionHandler: actionHandler,
corner: corner,
scaleX: target.scaleX,
scaleY: target.scaleY,
skewX: target.skewX,
skewY: target.skewY,
};
// transform 上下文对象被构造的地方
this._currentTransform = transform;
this._beforeTransform(e);
},
control.getActionHandler 是动态从 default_controls.js 中按边角的类型获取的：
| 边角类型 | 控制位置 | 动作处理器（actionHandler） | 作用 |
|---|---|---|---|
| ml | 左中 | scalingXOrSkewingY | 横向缩放或者纵向扭曲 |
| mr | 右中 | scalingXOrSkewingY | 横向缩放或者纵向扭曲 |
| mb | 下中 | scalingYOrSkewingX | 纵向缩放或者横向扭曲 |
| mt | 上中 | scalingYOrSkewingX | 纵向缩放或者横向扭曲 |
| tl | 左上 | scalingEqually | 等比缩放 |
| tr | 右上 | scalingEqually | 等比缩放 |
| bl | 左下 | scalingEqually | 等比缩放 |
| br | 右下 | scalingEqually | 等比缩放 |
| mtr | 中上变形 | controlsUtils.rotationWithSnapping | 旋转 |
对照上面的边角控制器图片更好理解。
这里我想多说一点，一般来讲，像这种上层的交互功能，做为一个 Canvas 库通常是不会封 装好的。 但是 fabric.js 却帮我们做好了，这也验证了它自己定义里面的一个关键词：** 可交互的**，正 是因 为它通过边角控制器封装了见的对象操作，才使得 Canvas 对象可以 与用户进行交互。我们普通开发者不需要关心细节，配置一些通用参数就能实现功能。
fabric.js 中内置了很多自定义事件，这些事件都是我们常用的，非原子事件。对于日常开 发来说非常方便。
明白了上面这几个核心模块的工作原理，再使用 fabric.js 来进行 Canvas 开发就能很快 入门， 实际上 Canvas 开发并不难，难的是编程思想和方式的转变。
2020-08-15 10:18:33
此篇文章实际上就是《前端开发的瓶颈与未来》的番外篇。主要想从实用的角度给大家介绍下 Deno 在我们项目中的应用案例，现阶段我们只关注应用层面的问题，不涉及过于底层的知识。
我们从它的官方介绍里面可以看出来加粗的几个单词：secure, JavaScript, TypeScript。简单译过来就是：
一个 JavaScript 和 TypeScript 的安全运行时
那么问题来了，啥叫运行时（runtime）？可以简单的理解成可以执行代码的一个东西。那么 Deno 就是一个可以执行 JavaScript 和 TypeScript 的东西，浏览器就是一个只能执行 JavaScript 的运行时。
Mac/Linux 下命令行执行：
curl -fsSL https://deno.land/x/install/install.sh | sh
也可以去 Deno 的官方代码仓库下载对应平台的源（可执行）文件，然后将它放到你的环境变量里面直接执行。如果安装成功，在命令行里面输入：deno --help 会有如下输出：
➜ ~ deno --help
deno 1.3.0
A secure JavaScript and TypeScript runtime
Docs: https://deno.land/manual
Modules: https://deno.land/std/ https://deno.land/x/
Bugs: https://github.com/denoland/deno/issues
...
以后如果想升级可以使用内置命令 deno upgrade 来自动升级 Deno 版本，相当方便了。
Deno 内置了丰富的命令，用来满足我们日常的需求。我们简单介绍几个：
直接执行 JS/TS 代码。代码可以是本地的，也可以是网络上任意的可访问地址（返回JS或者TS）。我们使用官方的示例来看看效果如何：
deno run https://deno.land/std/examples/welcome.ts
如果执行成功就会返回下面的信息：
➜ ~ deno run https://deno.land/std/examples/welcome.ts
Download https://deno.land/std/examples/welcome.ts
Warning Implicitly using latest version (0.65.0) for https://deno.land/std/examples/welcome.ts
Download https://deno.land/[email protected]/examples/welcome.ts
Check https://deno.land/[email protected]/examples/welcome.ts
Welcome to Deno 🦕
可以看到这段命令做了两个事情：1. 下载远程文件 2. 执行里面的代码。我们可以通过命令查看这个远程文件里面内容到底是啥：
➜ ~ curl https://deno.land/[email protected]/examples/welcome.ts
console.log("Welcome to Deno 🦕");
不过需要注意的是上面的远程文件里面没有 显示的 指定版本号，实际下载 std 中的依赖的时候会默认使用最新版，即：[email protected] ，我们可以使用 curl 命令查看到源文件是 302 重定向到带版本号的地址的：
➜ ~ curl -i https://deno.land/std/examples/welcome.ts
HTTP/2 302
date: Fri, 14 Aug 2020 01:53:06 GMT
content-length: 0
set-cookie: __cfduid=d3e9dfbd32731defde31eba271f19933b1597369985; expires=Sun, 13-Sep-20 01:53:05 GMT; path=/; domain=.deno.land; HttpOnly; SameSite=Lax; Secure
location: /[email protected]/examples/welcome.ts
x-deno-warning: Implicitly using latest version (0.65.0) for https://deno.land/std/examples/welcome.ts
cf-request-id: 048c44c2dc000019dd710cc200000001
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 5c270a4afd5719dd-SIN
header 头中的 location 就是实际文件的下载地址：
location: /[email protected]/examples/welcome.ts
这就涉及到一个问题：实际使用的时候到底应不应该手动添加版本号？一般来说如果是生产环境的项目引用一定要是带版本号的，像这种示例代码里面就不需要了。
上面说到 Deno 也可以执行本地的，那我们也试一试，写个本地文件，然后 运行它：
➜ ~ echo 'console.log("Welcome to Deno <from local>");' > welecome_local.ts
➜ ~ ls welecome_local.ts
welecome_local.ts
➜ ~ deno run welecome_local.ts
Check file:///Users/zhouqili/welecome_local.ts
Welcome to Deno <from local>
可以看到输出了我们想要的结果。
这个例子太简单了，再来个复杂点的吧，用 Deno 实现一个 Http 服务器。我们使用官方示例中的代码：
import { serve } from "https://deno.land/[email protected]/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
req.respond({ body: "Hello World\n" });
}
保存为 test_serve.ts，然后使用 deno run 运行它，你会发现有报错信息：
➜ ~ deno run test_serve.ts
Download https://deno.land/[email protected]/http/server.ts
Download https://deno.land/[email protected]/encoding/utf8.ts
Download https://deno.land/[email protected]/io/bufio.ts
Download https://deno.land/[email protected]/_util/assert.ts
Download https://deno.land/[email protected]/async/mod.ts
Download https://deno.land/[email protected]/http/_io.ts
Download https://deno.land/[email protected]/async/deferred.ts
Download https://deno.land/[email protected]/async/delay.ts
Download https://deno.land/[email protected]/async/mux_async_iterator.ts
Download https://deno.land/[email protected]/async/pool.ts
Download https://deno.land/[email protected]/textproto/mod.ts
Download https://deno.land/[email protected]/http/http_status.ts
Download https://deno.land/[email protected]/bytes/mod.ts
Check file:///Users/zhouqili/test_serve.ts
error: Uncaught PermissionDenied: network access to "0.0.0.0:8000", run again with the --allow-net flag
at unwrapResponse (rt/10_dispatch_json.js:24:13)
at sendSync (rt/10_dispatch_json.js:51:12)
at opListen (rt/30_net.js:33:12)
at Object.listen (rt/30_net.js:204:17)
at serve (server.ts:287:25)
at test_serve.ts:2:11
PermissionDenied 意思是你没有网络访问的权限，可以使用 --allow-net 的标识来允许网络访问。这就是文章开头特性里面提到的默认安全。
默认安全就是说被 Deno 执行的代码会默认被放进一个沙箱中执行，代码使用到的 API 接口都受制于 Deno 的宿主环境，Deno 当然是有网络访问、文件系统等能力的。但是这些系统级别的访问需要 deno 命令的 执行者 授权。
这个权限控制很多人觉得没必要，因为当我们运行代码时提示了受限，我们肯定手动添加上允许然后再执行嘛。但是区别是 Deno 把这个授权交给了执行者，好处就是如果执行的代码是第三方的，那么执行者就可以主动拒绝一些危险性很高的操作。
比如我们安装一些命令行工具，而一般命令行工具都是不需要网络的，我们就可以不给它网络访问的权限。从而避免了程序偷偷地上传/下载文件。
执行一段 JS/TS 字符串代码。这个和 JavaScript 中的 eval 函数有点类似。
➜ ~ deno eval "console.log('hello from eval')"
hello from eval
安装一个 deno 脚本，通常用来安装一个命令行工具。举个例子，在之前的 Deno 版本中有一个命令特别好用：deno xeval 可以按行执行 eval 命令，类似于 Linux 中的 xargs 命令。后来这个内置命令被移除了，但是 deno 的开发人员编写了一个 deno 脚本，我们可以通过 install 命令安装它。
➜ ~ deno install -n xeval https://deno.land/[email protected]/examples/xeval.ts
Download https://deno.land/[email protected]/examples/xeval.ts
Download https://deno.land/[email protected]/flags/mod.ts
Download https://deno.land/[email protected]/io/bufio.ts
Download https://deno.land/[email protected]/bytes/mod.ts
Download https://deno.land/[email protected]/_util/assert.ts
Check https://deno.land/[email protected]/examples/xeval.ts
✅ Successfully installed xeval
/Users/zhouqili/.deno/bin/xeval
➜ ~ xeval
xeval
Run a script for each new-line or otherwise delimited chunk of standard input.
Print all the usernames in /etc/passwd:
cat /etc/passwd | deno run -A https://deno.land/std/examples/xeval.ts "a = $.split(':'); if (a) console.log(a[0])"
A complicated way to print the current git branch:
git branch | deno run -A https://deno.land/std/examples/xeval.ts -I 'line' "if (line.startsWith('*')) console.log(line.slice(2))"
Demonstrates breaking the input up by space delimiter instead of by lines:
cat LICENSE | deno run -A https://deno.land/std/examples/xeval.ts -d " " "if ($ === 'MIT') console.log('MIT licensed')",
USAGE:
deno run -A https://deno.land/std/examples/xeval.ts [OPTIONS] <code>
OPTIONS:
-d, --delim <delim> Set delimiter, defaults to newline
-I, --replvar <replvar> Set variable name to be used in eval, defaults to $
ARGS:
<code>
[]
-n xeval 表示全局安装的命令行名称，安装完以后你就可以使用 xeval 了。
举个例子，我们使用 xeval 过滤日志文件，仅仅展示 WARN 类型的行：
➜ ~ cat catalina.out | xeval "if ($.includes('WARN')) console.log($.substring(0, 40)+'...')"
2020-08-12 13:37:39.020 WARN 202 --- [I...
2020-08-12 13:37:39.020 WARN 202 --- [I...
2020-08-12 13:37:39.019 WARN 202 --- [I...
2020-08-12 13:34:42.822 WARN 202 --- [o...
2020-08-12 13:34:42.822 WARN 202 --- [o...
2020-08-12 13:34:42.814 WARN 202 --- [o...
2020-08-12 13:34:42.805 WARN 202 --- [o...
$ 美元符表示当前行，程序会自动按行读取让执行 xeval 命令后面的 JS 代码。
catalina.out 是我本地的一个文本日志文件。你可能会觉得这样挺麻烦的，直接 | grep WARN 不香嘛？但是 xeval 的可编程性就高很多了。
deno 内置了一个简易的测试框架，可以满足我们日常的单元测试需求。我们写一个简单的测试用例试试，新建一个文件 test_case.ts，保存下面的内容：
import { assertEquals } from "https://deno.land/std/testing/asserts.ts";
Deno.test("1 + 1 在任何情况下都不等于 3", () => {
assertEquals(1 + 1 == 3, false)
assertEquals("1" + "1" == "3", false)
})
使用 test 命令跑这个测试用例：
➜ deno test test_case.ts
Check file:///Users/zhouqili/.deno.test.ts
running 1 tests
test 1 + 1 在任何情况下都不等于 3 ... ok (3ms)
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (3ms)
可以看到测试通过了。
还有其它很多好用的命令，但是在我并没用太多的实际使用经验，就不多介绍了。
上面说了这么多基础知识，终于可以讲点实际应用场景了。我们在自己的一个 SDK 项目中使用了 Deno 来做自动化单元测试的任务。整个流程走下来还是挺流畅的。代码就不放出来了，我只简单的说明下这个 SDK 需要做哪些事情，理想的开发流程是什么样的。
如果你的场景和上面的吻合，那么就可以使用 Deno 来开发。本质上讲我们开发的时候写的还是 TypeScript，只是需要我们在发布 NPM 包的时候稍微的进行一下处理即可。
我们以实现一个 fetch 请求的封装方法为例来走通整个流程。
➜ ~ mkdir mysdk
➜ ~ cd mysdk
➜ mysdk npm init -y
建立好文件夹目录，及主要文件：
➜ mysdk mkdir src tests
➜ mysdk touch src/index.ts
➜ mysdk touch src/request.ts
➜ mysdk touch tests/request.test.ts
如果你使用的是 vscode 编辑器，可以安装好 deno 插件（denoland.vscode-deno），并且设置 deno.enable 为 true。你的目录结构应该是这样的：
├── package.json
├── src
│ ├── index.ts
│ └── request.ts
└── tests
└── request.test.ts
index.ts 为对外提供的导出 API。
使用 tsp --init 来初始化项目的 typescript 配置：
tsc --init
更新 tsconfig.json 为下面的配置：
{
"compilerOptions": {
"target": "ES5",
"lib": ["es6", "dom", "es2017"],
"declaration": true,
"outDir": "./build",
"strict": true,
"allowUmdGlobalAccess": true,
"forceConsistentCasingInFileNames": true
},
"include": [
"src/**/*.ts"
]
}
注意指定 outDir 为 build 方便我们将编译完的 JS 统一管理。
为了演示，这里就简单写下。request.ts 代码实现如下：
export async function request(url: string, options?: Partial<RequestInit>) {
const response = await fetch(url, options)
return await response.json()
}
调用端封闭好 GET/POST 请求的快捷方法，并且从 index.ts 文件导出：
import {request} from "./request.ts";
export async function get(url: string, options?: Partial<RequestInit>) {
return await request(url, {
...options,
method: "GET"
})
}
export async function post(url: string, data?: object) {
return await request(url, {
body: JSON.stringify(data),
method: "POST"
})
}
在 tests/request.test.ts 目录写上单元测试用例：
import { assertEquals } from "https://deno.land/std/testing/asserts.ts";
import {get, post} from "../src/index.ts";
Deno.test("request 正常返回 GET 请求", async () => {
const data = await get("http://httpbin.org/get?foo=bar");
assertEquals(data.args.foo, "bar")
})
Deno.test("request 正常返回 POST 请求", async () => {
const data = await post("http://httpbin.org/post", {foo: "bar"});
assertEquals(data.json.foo, "bar")
})
最后在命令行使用 deno test 命令跑测试用例。注意添加 --allow-net 参数来允许代码访问网络：
➜ mysdk deno test --allow-net tests/request.test.ts
Check file:///Users/zhouqili/mysdk/.deno.test.ts
running 2 tests
test request 正常返回 GET 请求 ... ok (632ms)
test request 正常返回 POST 请求 ... ok (342ms)
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (974ms)
我们可以看到测试都通过了，下面就可以安心的发布 NPM 包了。
需要注意一点 Deno 写 TypeScript 的时候严格要求导入的 文件路径 必须添加 .ts 后缀。但是 TS 语言并不需要显式的添加这个后缀，TS 认为引入（import）的是一个 模块 而不是文件。这一点 TS 做的比较极端，tsc 要求你必须删除掉 .ts 后缀才能编译通过，这个我个人认为是非常不合理的。但是 Deno 有它的考虑，因为没有严格的文件名后缀引起程序 BUG 我自己也遇到过。
上面的几步都相对流畅，唯独到发布 NPM 包这一步就比较麻烦。因为本质上讲 Deno 只是 TypeScript/JavaScript 的运行时，并不兼容 NPM 这种包管理工具。而且 NPM 是为 Node.JS 设计的，它也没有办法直接发布 TypeScript 的包，我们只能把 TypeScript 编译成 JavaScript 再进行发布。
发布这里我们的需求有两点：
window.MySDK 访问到第二个简单，我们直接使用 tsc 的命令就可以完成：
tsc -m esnext -t ES5 --outDir build/esm
这时你会发现我上面提到的问题，tsc 报错了：
➜ mysdk tsc -m esnext -t ES5 --outDir build/esm
src/index.ts:1:23 - error TS2691: An import path cannot end with a '.ts' extension. Consider importing './request' instead.
1 import {request} from "./request.ts";
~~~~~~~~~~~~~~
说我不能使用 .ts！
这就尴尬了，deno 要求我必须添加，TS 又要求我不能添加。你到底想让人家怎么样嘛？
而且还有一个问题，我们现在实现的功能还很简单，引入的文件很少，可以手动修改下。但是以后功能多了怎么办？文件很多手动修改肯定不是办法啊。实在不行还是算了，不用 Deno 了？
其实嘛，解决方法还是有的，上面我们不是介绍过 Deno 安装脚本功能了吗。我们自己写个脚本放在 NPM Script 里面，每次编译发布前这个脚本自动把 .ts 去掉，发布完再自动改回来不就好了。
于是乎我自己写了一个 Deno 脚本，专门用来给项目的文件批量添加或者删除引用路径上面的 .ts 后缀：
源代码我就不全部贴出来了，简单讲就是用正则匹配出每个 ts 文件中的头部的 import 语句，按命令传入的参数去处理后缀就可以了。代码我放到了 gist 上，有兴趣的可以研究下：
https://gist.github.com/keelii/d95492873f35f96d95f3a169bee934c6
你可以使用下面的命令来安装并使用它：
deno install --allow-read --allow-write -f -n deno_ext https://gist.githubusercontent.com/keelii/d95492873f35f96d95f3a169bee934c6/raw/9736099cb47ef706e6c184e83c78fdfc822810dd/deno_ext.ts
使用 deno_ext 命令即可：
~ deno_ext
✘ error with command.
Remove or restore [.ts] suffix from your import stmt in deno project.
Usage:
deno_ext remove <files>...
deno_ext restore <files>...
Examples:
deno_ext remove **/*.ts
deno_ext restore src/*.ts
工具告诉你如何使用它，remove/restore 两个子命令+目标文件即可。
我们配合 tsc 可以实现发布时自动更新后缀，发布完还原回去，参考下面的 NPM script：
{
"scripts": {
"proc:rm_ext": "deno_ext remove src/*.ts",
"proc:rs_ext": "deno_ext restore src/*.ts",
"tsc": "tsc -m esnext -t ES5 --outDir build/esm",
"build": "npm run proc:rm_ext && npm run tsc && npm run proc:rs_ext"
}
}
我们使用 npm run build 命令就可以完成打包 ESModule 的功能：
➜ mysdk npm run build
> [email protected] build /Users/zhouqili/mysdk
> npm run proc:rm_ext && npm run tsc && npm run proc:rs_ext
> [email protected] proc:rm_ext /Users/zhouqili/mysdk
> deno_ext remove src/*.ts
Processing remove [/Users/zhouqili/mysdk/src/index.ts]
Processing remove [/Users/zhouqili/mysdk/src/request.ts]
> [email protected] tsc /Users/zhouqili/mysdk
> tsc -m esnext -t ES5 --outDir build/esm
> [email protected] proc:rs_ext /Users/zhouqili/mysdk
> deno_ext restore src/*.ts
Processing restore [/Users/zhouqili/mysdk/src/index.ts]
Processing restore [/Users/zhouqili/mysdk/src/request.ts]
最终打包出来的文件都在 build 目录里面：
build
└── esm
├── index.d.ts
├── index.js
├── request.d.ts
└── request.js
接下来我们还需要将源代码打包成单独的一个 UMD 模块，并展出到全局变量 window.MySDK 上面。虽然 TypeScript 是支持编译到 UMD 格式模块的，但是它并不支持将源代码 bundle 到一个文件里面，也不能添加全局变量引用。因为本质上讲 TypeScript 是一个编译器，只负责把模块编译到支持的模块规范，本身没有 bundle 的能力。
但是实际上当你选择 --module=amd 时，TypeScript 其实是可以把文件打包 concat 到一个文件里面的。但是这个 concat 只是简单地把每个 AMD 模块拼装起来，并没有 rollup 这类的专门用来 bundle 模块的高级功能，比如 tree-shaking 什么的。
所以想达到我们目标还得引入模块 bundler 的工具，这里我们使用 rollup 来实现。什么？你问我为啥不用 webpack？别问，问就是「人生苦短，学不动了」。
rollup 我们也就不搞什么配置文件了，越简单越好，直接安装 devDependencies 依赖：
npm i rollup -D
然后在 package.json 中使用 rollup 把 tsc 编译出来的 esm 模块再次 bundle 成 UMD 模块：
"scripts": {
"rollup:umd": "./node_modules/.bin/rollup build/esm/index.js --file build/umd/index.bundle.js --format umd --name 'MySDK'"
}
然后可以通过执行 npm run rollup:umd 来实现打包成 UMD 并将 API 绑定到全局变量 MySDK 上面。我们可以直接将 build/umd/index.bundle.js 的代码复制进浏览器控制台执行，然后 看看 window 上有没有这个 MySDK 变量，不出意外的话，就会看到了。
我们在 index.ts 文件中 export 了两个 function：get/post 都有了。来试试看能不能运行起来
注意：有的浏览器可能还不支持 async/await，所以我们使用了 Promise 来发送请求
到此，我们所有的需求都满足了，至少对于开发一个 SDK 级别的应用应该是没问题了。相关代码可以参考这里：https://github.com/keelii/mysdk
需要注意的几个问题：
.ts 的后缀这个操作是比较有风险的，如果你的项目比较大，就不建议直接这么处理了，这个脚本目前也只在我们一个项目里面实际用到过。正则匹配换后缀这种做法总不是 100% 安全的2020-05-11 10:18:33
前端开发的瓶颈到底在哪里，前端技术是否已经走到一个十字路口，全栈化的系统架构是否能改变目前的窘境？本文将根据作者自身的开发经历谈谈当下前端开发中遇到的一些问题和想法。
近两年我一直在思考的一个问题：
如果前端不用考虑性能问题、不用考虑终端兼容性、不用考虑历史遗留问题，甚至不用考虑具体技术实现...
如果我们假设自己有丰富的技术储备，同时不用考虑上面的问题，那么前端究竟 能 做出什么样有价值的东西？
我们把时间拉到 5 年前...
如果你「那时」还是前端开发的话。上面的问题肯定是你不得不面临的典型问题。甚至是当时前端开发的意义所在。
但是随着时间的推移，前端技术的更新迭代，以及互联网的发展。你会发现这些曾经的问题似乎已经不再是问题，或者说在能预见的未来 可能 不再是问题。
页面加载性能可能不再是问题，技术上有了 HTTP2，基建上有了 5G，硬盘也越来越快。
兼容性问题慢慢淡出大家的视角，Chrome 一家独大，微软也不得不向它靠拢。
很多前端开发已经具备了后端（或者说多端）的技术能力，技术储备也可能不是问题，当然前提是你能招到人。
到底什么是前端开发，前端与后端的界限在哪里？我在三年前对它的定义是：
前端为 界面、交互展示负责； 后端为 数据、业务逻辑负责;
不过现在看来似乎已经过时了，我越来越觉得不应该有这样一个清晰的界限把前后端分割开来，尤其是技术层面（除了职能层面的界限有利于协作以外）。这就好比说：如果你不能打破规则，那就必将被规则束缚。
我一直认为程序员应该对新的技术、工具、理念有比平常人更快的适应能力。举个简单的例子，我以前写代码通常使用 tab 缩进，后来大家都建议使用空格，刚开始尝试换成空格肯定是拒绝的，因为让人改变习惯是一件很难的事情。但是当你真正为了改变做出实践的时候，往往就会发现一条新大路。同样还有加不加分号的问题。
现在回过头来再看，前端在整个系统层面担任的角色至少应该是整个视图 View 层面的。视图层面的技术更接近软件系统的上层，更感性。感性的东西就是说一个颜色，我觉得好看，他觉得不好看，完全属于个人情感诉求。所以前端更注重与UI、交互 以及整个产品层面需要解决的问题。优秀的前端必然要具备敏锐的产品洞察能力。
当然这还只是前端最基础的职责所在。同时前端做为最接近产品的技术角色，技术才是前端真正的硬实力。
大约在去年一年的时间，我的岗位从前端转向了后端 Java 程序员的角色。虽然只做了一年的 Java 程序员，但是对我自身的技术提升而言是最多的一年。大家可能普遍的认为后端转前端比较容易，前端转后端会有门槛，实际上根据我自己的体验来讲并非如此。
Java 这门语言是商业化、成熟度特别高的语言。无论是语言本身，还是周边框架、工具都有一套非常成熟且层次分明的系统化抽象。如果你有两、三年的编程经验，突然让你上转写 Java 是非常容易的一件事情，尤其是写 Java web。Spring 框架已经为程序员屏蔽了很多复杂问题，而且已经事实上成为了各大互联网公司的主流框架选型。
我特意按我自己的学习线路绘制了一张 Java 版的程序员学习线路，仅供参考：
我们可以清楚的看出来 Java 构建的整个体系最大的特点：它是渐进式的，一步一步地给开发者建立正向的引导。
当我处在在应用层阶段的时候，我需要关心的只是一些概念，方法，具备基础了以后就可以借助 Spring 框架入门，入门后就可以研究源码，你会发现 Spring 的本质核心类 DispatchServlet，从此 Servlet 就出现在了你的视野。我以前上学时理解不了 java 中 Servlet 的概念，后来参加了工作又学些了 Python，再次看到 Java 中的 Servlet 的时候瞬间就明白了它就是 Python 中的 uwsgi，就是一种接口，将编程语言和服务器网关链接起来的一种规范。
然后你就可以顺利进入下一环节，服务器/通信。这里你会发现整个网络编程的核心 Socket，同样以前上学的时候没理解 Socket 的概念，继续学习后你就会明白 Socket 其实就是操作系统提供给编程语言的一种能力，有了它就可以建立服务器与客户端之间的通信。在这一环节中你会学习到网络层 TCP/IP 协议，明白了 TCP/UDP 的区别，while (true) { socket.listen() } 建立 Socket 监听会有性能问题，此时你便进入下一个抽象层次，操作系统和计算机原理。
为了解决「while true」监听连接的性能问题，你会去学习多线程技术，了解并发的概念。你可能总会听到别人讨论并发和并行的区别。继续学习后，慢慢的你就会明白：并发多用来解决网络IO（硬盘）的效率问题，而并行则是为了更好的利用多/核处理器（CPU）的问题。这时你会发现这个阶段涉及到了很多的计算机硬件知识。内存分配、CPU计算、IO 复用等等。
像 Spring 这种框架才能真正意义上被称做 框架，因为它不仅仅解决了软件开发的问题，更重要的是 AOP/IoC 这类概念可以完全改变编程的一些理念。使用 Spring 开发 web 应用，联合 Java 构建出来的生态，整个开发流程就像呼吸一样自然。
Java 构建出来的软件开发体系就像是把程序员放进了一个一个的层次分明的小柜子里面，进去了以后你根本不需要关注外界是怎么样的，做好自己那部分工作就可以了。如果你对外界有兴趣可以一点点的顺藤摸瓜，跳出你原来的小柜子。即保证精力专注的同时又建立起一套有秩序的提升曲线。这一点是别的语言体系没有的。
实际上我在转 Java 之前对 Java 有着不小的误解，甚至转 Java 本身也不是我自己的想法。但当你真正转型成 Java 程序员后。看懂了数以百万行记的代码仓库、维护过每秒好几十万的 QPS 项目、见识过百行的 SQL 的时候，你才会对 Java 和软件开发产生一种敬畏之心，才会对技术才有了更深层次的理解。
这时候再回过头来看前端，看 JavaScript，才会发现它们之间的区别与特点。很多之前争论的东西也就有了结论。
我相信从事前端工作稍微长一点（5年以上）的人近两年都会有一种感觉：前端似乎没什么东西可以玩出花样了。这是因为很多东西都已经成为了前端事实上的主流，以前前端没有的基建慢慢的被完善。语言、框架、可视化、跨端、游戏、工具/自动化/工程化 这些领域都在发展。
语言方面 TypeScript 必然是主流，无论你愿意与否，你都将不得不使用它来写前端。框架方面 React 已经是事实上的主流了，没必要再做选择题。打包工具 Webpack 也是一家独大，虽然被很多人诟病，但是社区生态起来了，想改变就很难。跨端应用 Electron 也不用想了，VSCode 能做好你做不好那就不是选型的问题了。2D 游戏/绘图方面 PixiJS 6 已经在设计中了，3D 我个人认为就先别玩了。
这些看似成熟的体系实际上还是有很多可以挖掘的东西。如果你不深入研究，或许会认为过两年这些技术就稳定了前端就可以做到大一统的状态。这个想法可能就过于天真了，我举例解释下它们各自的瓶颈：
React（并不特指 React）虽然现在看起来是主流，但是它本身有很多问题是没解决的，甚至可以说是无解的。React 的本质只是一个 UI Library，并不是框架 Framework。框架要解决的问题是系统层面的不是某个抽象层面的。用 React 写过几个项目以后你就会认识到用 React 去写大型项目是非常麻烦的事情，React 本身并不解决 SPA 应用中数据流的问题，甚至没解决状态管理的问题（或者说状态管理本来就是个伪命题？）。一个很简单的父子组件之间状态共享的问题一直没有成熟的解决方案，hooks 这种方案更像是拆了东墙补西墙。
而且现在 React 社区弥漫着一种崇尚函数式编程的邪气，hooks 更像是一块遮羞布。多数人用 hooks 的原因仅仅是不想使用 Class，因为 Class 很臃肿，function 更简单。当然这个逻辑是没问题的。函数确实简单，但是如果你把一个函数里面写上几百行的代码，各种 hooks 用到飞起的时候，你才会回过头来反思如何组织代码。如果 Class 能以一种更好/更易于理解的方式去抽象那为什么不用呢？
前端框架如此，基于 Node.JS 的后端框架也好不到哪儿去，难道你真的想用 Express/Koa.js 去写大型的后端应用？这种量级的框架连 web 开发最简单的三层模型（ 模型、视图、控制器）支持都不完整。当然你可能会说小型框架本来就只关注某一方面嘛，视图和模型层的东西可以用其它三方库解决。是的，确实可以这样，不过你不觉得 Node.JS 的第三方库有点太多了吗。正如 NestJS 在文档中提到的一个问题一样「很多 JavaScript 类库都没有高效地解决一个问题 架构。」React/Vue/Express/Koa 这些都是相对独立的点，没有一个东西能把他们连接起来形成一个面，形成一种框架级别的体系。这就是架构的问题。
这里多说一点，结合上面 Java 构建出来的生态，对比 Node.JS 的话。我借用自己打过的比喻：如果你低头看到的是 Node.JS，那么你抬头未必能看见 Java。假如你从事前端开发 2，3 年遇到瓶颈，想转学 Node.JS，你会学习 Exporess/Koa 这类框架，但是很快你就会发现一个严重的问题：没办法深入下去了。因为当你用 Express 写完一个页面后就面临着各种技术上的盲点，会让你无所适从。
我也尝试绘制一张我对 JavaScript/Node.JS 或者说大前端体系理解的一张图:
JavaScript 体系看似前后端通吃，客户端、 服务端甚至桌面端皆有。但是最大的问题在于：没有一个东西能给他们建立起关系并发展成为一种体系。
插播一条娱乐看点，前两天写 Ruby on rails 框架的作者 DHH 发推并配图：
大意如下：
现在的年轻人在 web 开发的时候是这样的嘛？底层逻辑、纯手写连接池 + 纯手工 SQL、配置文件都放在了一起。天哪！（截图中使用的式TJ大神写的 Express 框架）
然后 TJ 大神也回复了：
大意如下：
只有菜鸟玩家才能写出干净、简洁、高性能（黑 Ruby 性能）、见名知意的 SQL，而不是去写一个有15层的抽象。
两者的推特对话挺有意思，大家娱乐一下。
TypeScript 也主流，但是持续关注 TS 到现在，我发现 TS 也遇到了瓶颈，这个瓶颈不仅来自于 TS 的设计目标与理念，更多的还是社区及 TC39。TS 的设计初衷是 JavaScript 的超集，由于本身要编译成 JS，这一点本质上限制了 TypeScript 的方向，设计者对于添加一个新特性会非常谨慎，一者怕与 TC39 ES proposal 冲突，二者要考编译到不同版本 JavaScript 的兼容性问题。以至于现在 TS 新的语言特性只会跟进 TC 39 发布的最新 ES proposal。但是我个人对于 TC 39 的效率及未来持怀疑态度，decorator 的提案一直还处于 Stage 2 的阶段，像这种其它语言都成为标配好几年的事情，现在 JavaScript 社区还在草案（stage-2）阶段。
普及下 ECMA 的标准的流程：
- stage-1：前期设想
- stage-2：正式提案（装饰器所在的阶段）
- stage-3：实现候选
- Stage-4：完成测试
- 各个浏览器 JS 引擎实现；TypeScript 实现
在这个问题上我认为其实也很好解决，开个脑洞：如果微软想借助编程语言一统浏览器和客户端是没有什么不可能的。并入 TC39 组织，开发真正属于 TypeScript 的原生引擎，奉天子以令不臣的方式也未尝不可。
近几年 Microsoft 对于开源的投入是肉眼可见的，微软要发力我相信很多东西都会有翻天覆地的变化。
Webpack/Babel 就更不用说了，主流中的主流。但是也是问题最严重的一个。Webpack/Babel 的流行恰恰从反面证明了前端的基础设施有多么的烂。现在国外网友老天天叫喊着 Webpack/Babel is eval 也是挺值得深思的。我们引入了一个新工具来解决问题，却又在不经意之间产生了新问题。
前端构建工具问题的本质还是在于 Node.JS 的包管理工具的设计。这一点在 Node.JS 的作者 Ryan Dahl 关于 Deno 演讲《10 Things I Regret About Node.js》中也有过「官方」的承认。我相信任何一个实现过构建工具的人都被 Node gyp 打败过。node-sass, fsevent 的痛不必细说。更不用说万年被黑的 node_modules 了，你根本不知道一个简单的 npm install 命令会导致安装成千上万个 npm 包被安装到你的机器上。
当然每种编程语言对应的包管理工具都要解决依赖问题，而且这是一个普遍的问题，脚本/解释型编程语言尤为突出，Python/Ruby/PHP 都有这些类似的问题。或许 Go/Rust 这种把源代码编译打包成单个可执行文件的方式才是好的解决方式。
从前人们总是抱怨 JavaScript 这门语言，黑它、讽刺它。但是我看到的是它在一点点变好。不仅是语言层面逐步完善，工具链生态日趋成熟，使用它的也人越来越多。大家对它的关注程度也在提高，整个 JavaScript 开发者的水平也在向更高更强的方向发展。生存环境只会淘汰那些老旧不再进化的事物，能适应变化的才会永存。
JavaScript 这门语言有两个其它 任何 编程语言都不具备的优点：
当下的前端开发状况不由得让我我想起苏东坡《晁错论》中的一段话：
天下之患，最不可为者，名为治平无事，而其实有不测之忧...
最大的问题在于，有些事物，从表面上看着平淡无奇，但实际上底层暗流涌动，似乎每一时刻都有着巨变的可能性。这也是前端开发最有趣也最有潜力的地方。
作为一名新时代的前端开发者，就是要在这看似风平浪静的表面之下，找到一些真正的突破点，兴许只是一个简单的想法，顺应时势然后造就出不斐的成就也说不定呢。
无论是前端还是后端、国内还是国外，技术才是真正的核心竞争力，只有技术革新才能提高生产力，而对于我们程序员来讲，编程则是唯一能提升硬实力的方法。只要你心中充满了热情，坚持下去总会走出一条自己的路子。
分享一段小经历
我在 2018 年有幸参加了 TypeScirpt 的推广大会，TypeScript 的作者 Anders Hejlsberg 亲自主讲。一位将近 60 岁的程序员在讲台上滔滔不绝的讲技术方案，TS 的设计理念。你真的很难想像这样一位处于「知天命」阶段的老头子（实际上很年轻）讲的东西。
QA 环节有个年轻小伙问到 Anders「在中国做程序员很累、很难应该怎么坚持下去（类似这样的描述，细节记不清楚了）」的问题。
Anders 几乎毫不犹豫的说出了「Passion」这个单词。我瞬间就被打动了。因为在此之前我对于「激情」这个词的认识还停留在成功人士的演讲说辞层面，当 Anders 亲口说出 Passion 一词的时候，让人感觉真的是一字千金。
直到现在 Anders 还做为 TypeScript 的核心贡献者为它提交代码，到处奔走为 TypeScript 宣传。
我们再回到前端，那么未来的前端到底会发展成什么样？长期而言充满了未知数，谁也没法预测，但是短期来讲我比较关注几个东西：
如果你仔细研究一番，上面的这些新鲜东西，都是起源于前端，但又不把视野局限在前端。或许这就是前端未来的发展方向吧。
这几项技术我们会在后期的更新中会有专门的干货文章，敬请期待~
