打工人最爱技能：JavaScript的未来会走向何方？

Posted 2021-04-06 读芯术

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了打工人最爱技能：JavaScript的未来会走向何方？相关的知识，希望对你有一定的参考价值。

全文共5429字，预计学习时长14分钟

图源：unsplash

作为一个见证了过去17年编程语言发展的软件开发者，笔者试图在本文中对javascript进行一些预测。

如今，JavaScript无处不在，不仅仅应用在前端(浏览器)和后端(Node和Deno)，也包括手机、电脑桌面软件，甚至两者的混合应用。它已经成为2020年求职人最想拥有的工作技能之一（根据 StackOverflow的开发者调查）。

但为何会如此呢？这对JavaScript的未来又意味着什么？JavaScript的发展是否会顺风顺水？未来会不会有一个更新更好的语言诞生，从而推翻JavaScript无所不能的地位？现在探讨一下这种可能性。

是什么让JavaScript如此受欢迎？

不管你是喜欢还是讨厌，JavaScript的流行都是毋庸置疑的。根据 TIOBE的流行指数，在排名前十的语言中，JavaScript目前排在第七位。

根据 StackOverflow的2020年开发者调查，最受欢迎的编程语言正是Java：

这些不是随机数字或有偏见的民意调查，这些数据可以分析出我们的市场，对全球数以百万计的开发者进行调查，一切都在表明JavaScript是2020年的热门语言之一，对此你怎么看？

当然，这个问题可能有很多不同的答案，主要取决于你在挑选编程语言时看重什么，这是我的看法：

· 背后有一个庞大的社区。

围绕着这样一个事实，发生了许多有趣的故事：JavaScript外部框架可能比实际开发者使用的更多。虽然这可能是一个夸张的说法（注意笔者这里说的是 "可能"），但这源于一个事实，那就是我们有这么多的人，试图让这门语言成为我们自己的语言，此举贡献巨大。这并不是一件坏事，证明了这是一个充满生命力并不断尝试发展的社区。

当笔者不得不使用其他语言时，非常怀念的一件事是，人们可以从原社区中获得大量的支持和帮助。这绝对是一个进步的标志，此举还有待完善，并有望在未来取得更多的成就。

· 适当的发展方式。

撇开框架和库不谈，语言本身也在不断发展。不过值得庆幸的是，这种改变并不是由一个实体控制的。

要澄清一下：虽然JavaScript本身（这个术语）是由Oracle所拥有的，但这门语言是要遵循ECMAScript的规范。而这些规范其实是由社区本身间接控制的，并由 TC39委员会来监管和组织。

通过考虑所有不同的建议以发展语言，并不断运行直到语言足够成熟。之后，如果想保持兼容的话，就由例行程序来实现这些更新，而且此后浏览器之间还存在纷争。

作为一个开发者，必须努力保持在兼容性和标准的范围内，因为你更希望你的代码能跨浏览器兼容。现在情况已经不是这样了，所有的例行程序都在努力跟上ECMAScript的最新版本。

· 一个生机勃勃的生态系统。

这与第一点很像。有更多的前端框架可以尝试，没必要去学习所有的框架。每天仅NPM中分享的模块就数以百万计。

这给刚开始尝试该编程语言的人制造了很多麻烦，但同时也吸引了更多的人加入，不同的框架和模块最终都会达成同一件事，只是方式不同而已。而这些不同的方式有助于引起更多个人开发者的共鸣。毕竟，React、Vue和Angular都能帮助开发者创建同样的APP，只需要选择自己喜欢的那一款即可。

那么，综合几年前的情况以及它的发展历程，你如何看待JavaScript的未来？

这绝对是一个很难回答的问题，先看看笔者的想法。

近期变化

在过去的几年里，这门语言正在不断发展。如果你是JavaScript的新手，也许还没有注意到，从ECMAScript 第5版到第6版有一个质的飞跃，在未来的版本中应该也会发生许多改动。如果它继续保持现在的路径和发展速度的话，笔者认为不久之后它可能会这样……

图源：unsplash

作为目标语言的JavaScript

即使JavaScript拥有令人惊叹的社区，为开发者提供工具和框架做了大量工作，却仍然有很大一部分人没有理由地讨厌JavaScript。

是的，没看错，确实有人讨厌它，或者至少不喜欢它的大块头，认为自己可以把它做得更好。于是，就有了CoffeeScript和后来的Dart以及现在的TypeScript这样的项目。

这并不是坏事，事实上，这是一个非常好的机会，让JavaScript不仅可以直接被全世界的开发者广泛使用，还可以成为很多transpiler创造者的目标语言，试图给开发者提供其他选择。

本质上，这场运动将为JavaScript打开大门，通向一个不同的浩瀚宇宙。自从Node.js进入市场并流行以来，JavaScript不再是 “前端语言”，允许公司简化他们的技术堆栈去形成一个跨领域的单一语言。

想一想，如果你也能用Python或Ruby做到这一点，会发生什么？这并不是多么疯狂的想法，过去已经有项目试图实现它，我们可能只是需要更多的时间。

前端开发的问题（笔者认为这是唯一的问题）是，你需要学习JavaScript才能进行工作。这与后端世界完全相反。目前，浏览器只允许一种语言为王，那就是JavaScript，如果想要更多的语言，就必须把你的代码编译（或者说是移植）成JavaScript。

当然，还有WebAssembly，如果他们有更多的能力去访问其他领域，如DOM，它很可能会取代JavaScript。但现在它只能在一个非常狭窄的领域发挥作用：前端的大量计算。这是一个性能工具，而不是一个完全独立的前端开发环境。

演变的例子

JavaScript发展到现在的另一个方式是通过社区开发的框架看到社区的需求。如果你已经使用JavaScript有一段时间了，特别是从ECMAScript 5开始，你可能会记得 lodash 和 underscore 等库。

对项目来讲，这些库都是必要的，因为它们为语言增加了额外的功能，如map、some、find、reduce、get、set、merge等方法。虽然在最近的更新中，有些功能已经渗透进语言本身，但这些库依旧有存在的必要性。

比如ECMAScript 6，增加了很多数组方法，给编程算法带来了相当大的提升。可选链使得 get 方法被淘汰，或者说几乎被淘汰。传播操作符也几乎淘汰了merge 方法，而这个列表还在继续更新。一个功能越是流行，TC39委员会就越会尝试将其纳入到语言中。

另一个明显的例子是如何引入类。JavaScript试图在一个面向使用者的世界中保持初心，但它失败了。要么是因为没有足够的拥护者，要么是因为没有正确的文档化。但是有那么多的开发者试图强行在上层建立一个OOP模型，最终在上层添加了一个薄薄的OOP层。

起初这很浮于表面，但随着不久之后私有字段的加入，它正在慢慢演变成一个更成熟的模型。道阻且长，这只是语言演变的一个例子，说明这门语言是如何发展的，尽管违背了它的初衷，但开发者社区的力量在支持它。

最后一个新增的框架是 Svelte框架，它试图将反应性的概念带入语言本身，不像其他框架，比如React，它反而试图为开发者提供工作方法，将JavaScript还没有准备好的概念强加给他们。

使用Svelte框架，可以编写这样的代码：

  
    
    
  
   
     
     
   <script>
   
     
     
    let count =0;
   
     
     
    functionhandleClick() {
   
     
     
    count +=1;
   
     
     
    }
   
     
     
   </script>
   
     
     
    <buttonon:click={handleClick}>
   
     
     
    Clicked {count} {count ===1? time : times }
   
     
     
    </button>

有一个按钮，点它标签值就会更新。当然，目前这需要编译成实际的JavaScript，你估计需要多长时间才能将类似的例子吸收到合适的ECMAScript规范中？

Modules++

图源：unsplash

从IE6的JavaScript时代开始，语言的另一个方面就一直在发展（是的，在那时，我们必须调整自己的代码，以便在web浏览器上工作），这就是语言的模块系统。

起初，它还不能被称为模块，但随着时间的推移，它朝着一种更可用友好的方式包装我们的代码。这很关键，因为可重用性是软件发展的一个重要概念。你不希望每次启动一个新的项目时，甚至在同一个项目中的两个不同地方调用同一个函数时，都要重来一遍。

我们已经可以看到AMD的模块语法的兴起，我们被允许使用import和export语句来选择哪些函数被共享，可以看到哪些函数最终被私有。这种语法还有其他的替代方案，但AMD的语法似乎是目前赢得标准化竞赛的那个。

这是一个很好的垫脚石，但我们可能还需要更多。也许我们需要考虑的不仅仅是共享或重用某个功能，而是整个模块。而“模块”的概念可以代表着很多东西，这取决于不同的环境。

如果你正在为前端开发一段可重复使用的代码，你可能已经成功地将自己的按钮模块化了，但由于它们不仅仅是抽象的，而且也是一个视觉结构，你要确保代码总是与所需的CSS和html一起导出。

同样的情况也可以适用于后端开发，你可以设计一个日志组件，以便在所有项目中重复使用，但你要确保一组配置和常量能和业务代码一起导出。

JavaScript本身还不能为我们直接解决这个问题，但可以有许多不同的解决方案来帮助解决这个问题。

对于后端用户来说，有 NPM 甚至 Yarn 提供了一个集中的全局仓库，甚至还有新的 Deno 允许导入外部分布式模块，自动映射和下载依赖关系。然而对于前端来说，事情并不完全一样，有些用户决定同样选择NPM和Yarn（如果你注意的话，会发现里面有很多React、Angular和Vue的组件）。

不管你现在选择如何解决这个问题，关键在于，就像过去对单个函数所做的那样，JavaScript（或者更准确的说是TC39委员会）可能会在未来决定采用这种做法，让我们可以从“模块”的概念转向“组件”，把它们打包成一个文件，以便可以在其他项目中重复使用。

笔者不希望将会有一个来自JS本身的“官方”资源库，而是对如何定义和共享这些组件有更详细的规范，为现有的解决方案（同样是Deno、Bit、Node和其他）留下适应和提供自己价值的空间。

Java的长远发展

这是一片未知的领域。根据目前的趋势和过去的经验，预测近期会发生什么比较容易。但要跳到遥远的未来，以几十年为单位进行思考或许就没那么容易了。

各种其他因素的影响也很大，比如正在开发的未知媒介，JavaScript可以在其中扮演重要的角色。比如全息影像技术，前不久还有声称可以充当助手或老师的人造人。也许我们会看到JavaScript作为一种语言供机器使用并扩展语言本身的功能。

Java的长远发展，取决于我们现在对这种语言的处理。这真的会塑造它的未来版本，虽然很难正确预测它的全貌，但我们不妨试试。这其实也是一个有趣的思维练习。

图源：unsplash

2040年及以后的JavaScript有可能会：

· 拥有对ML指令的本地支持的能力，考虑到ML的更新换代以及它如何开始渗透到我们行业的方方面面，笔者认为这样一种流行的语言将不得不在被更新的模式（即一种新的语言）推翻之前适应。

· 反应式和函数式编程将在语言的设计中发挥更大的作用。笔者预测，我们将会经历自己的OOP阶段，最终，我们会看到函数式编程方法的好处，以及它是如何与反应式方法紧密地联系在一起的。

· 甚至可以看到逻辑编程开始初现端倪。人们总是试图把旧的概念和范式当作新的概念和范式来使用，所以最终会看到大家试图按照正常的路线（首先通过框架，然后通过原生支持）将其改编成JavaScript。

· 原生脑机接口可用。这最终将像访问DOMAPI一样，只是它将允许你从你的大脑中读取输入，并且，可能与当时通过DOM的任何东西进行交互。本质上我们将成为一种新的输入设备，比如键盘和鼠标。

而这也不是那么遥不可及， OpenBCI 等公司已经提供了 Node.js SDKs 与他们的开源硬件进行交互，让你可以读取大脑的电活动。当然，这距离成为主流技术还很远，但至少已经在路上了。（而且是用JavaScript！）

笔者假设JavaScript不会消失或被另一种语言取代，特别是当涉及到表征环境时（即未来作为前端的任何东西）。这主要是因为从逻辑上来讲，为了一切都要重来，在旧技术的基础上建立新技术更有意义。

因此，即使你正在创建一个全新的显示技术，一个比目前的能提供更多功能的技术，你仍然希望目前的软件能够在其中发挥作用（即你希望浏览器能够在全息3D显示器上工作，即使一开始，它们只是无聊的2D窗口）。这意味着你必须在你的基础上添加新功能，而不是直接替换它。

你也可以摒弃一切，从头开始，在没有JavaScript的情况下带来下一次技术革命，但你被想要进入的行业接纳的速度可能会比通过利用现有技术的发展速度要慢一些、难一些。

也许几十年后，这篇文章会变成神预言，当然，也可能会被打脸。未来究竟会如何发展，谁又能说得准呢？

推荐阅读专题

留言点赞发个朋友圈

我们一起分享AI学习与发展的干货

编译组：刘森林、蔡漫祺