很难说,因为这些词的定义不明确。通常来说,我认为将Node.js称为框架确实有点不典型,但是我很难辩解为什么它不是真正的框架。
所有这些都变得扑朔迷离,而且我经常看到语言的使用非常差,所以我会明确地从下而上开始
JavaScript是一种计算机语言,狭义地讲,是一组约定,这些约定使我们能够阅读和解释一堆具有执行语义的文本,这是一个奇特的词,意为“将语言解释为一组指令的方式”。叫程序类翻译,编译器,transpilers,棉短绒,荧光笔等,都以文本,并尝试做一些与如何执行代码这种传统的理解。
- 口译实际执行通过操作一些设备,通常是你的电脑执行语义。您可以将它们视为计算机内的一个小人物,它会根据JavaScript程序中编写的指令,像“打印此字符”一样翻转开关。
- 编译器尝试将JavaScript文本转换为具有不同语言的执行语义的一组新文本-也许具有计算机可以直接执行的特殊属性。
- Transpilers是编译器的推广形式,他们采取在JavaScript中的文本和其他语言的文本输出。因此,差异有点主观,但通常人们会认为编译器输出的是非常低级的代码而是高级代码。
- 棉短绒,荧光笔,类型检查器,等都以在JavaScript文本输出某种产品分析的,突出显示的文本例如,它是由执行语义的影响,但实际上并不代表它。
现在,让我们深入研究执行语义。通常,执行语义涉及读取语言文本并得出抽象机器的描述或可观察到的副作用的描述的过程。我想建议的是,这两个都假设需要某种“低级API”来操作机器或执行可观察的效果。这些通常被认为是运行时环境的
- 在运行时环境或运行时是一组假设原语的语言公约要求,以经营存在。就语言而言,可能会对它们的行为有一些假设,但它们是不可观察的。在上面解释器的图像中,“内部人员”只是轻拂运行时的开关-他无法亲自检查它们在做什么。
通常会滥用运行时一词来指代假定的原语本身及其实际实例化。
因此,现在我们有了一些毛病。语言是一组约定,它们假定存在运行时,以便为其执行语义提供含义。它永远不会“探究它们”,因为它们超出了范围。
为了实际使用一种语言,您需要诸如编译器或解释器之类的东西以及运行时实现。编译器/解释器和此运行时在实际执行代码时紧密结合。
- Chrome的V8(通常称为引擎)是一种打包交易,其中包含与ECMA标准JavaScript约定所需的运行时接口兼容的解释器,编译器和运行时实现。
那么Node.js在哪里适合呢?
我们必须将其分为几部分:
- Node.js 通过提供更多的运行时环境原语集(这些超出ECMA标准范围的原语)来扩展JavaScript语言。这些包括文件I / O之类的东西。这意味着Node.js 更改了语言,并且在某种意义上是一种新语言:“ Node.js JavaScript”
- Node.js作为一个包,包含一个解释器和一个编译器。它只是从V8中窃取了这些。
- Node.js提供了Node.js运行时环境的实现,该环境允许执行“ Node.js JavaScript”。
- Node.js提供了一组在新原语之上构建的标准库,这些标准库使“ Node.js JavaScript”的最终用户可以更轻松地访问它们。
因此,Node.js有很多东西!
但这是一个框架吗?
这就是术语完全崩溃的地方-没有人对框架实际是什么有一个良好,一致,有意义的定义。
争论激昂:“什么是框架而不是库”,它们最终以不令人满意的事情结束,例如“库是您所调用的东西,而框架是您所需要的东西”。我什至不是真的想像今天这样悲伤地解释一下,但是JavaScript(尤其是Node.js JavaScript)对该定义有很大的打击,因为整个回调传递技术意味着您不断在调用之间进行切换被召唤。
我个人认为,这里有些实质性内容。我不想划清界限,所以我只想说
- 如果一组代码就像乐高玩具一样工作,则它们类似于库。:可分割并用于汇编。尽管可能有一些有关如何使用该库的示例,但通常由用户自己将其组装成符合他们需要的库。
- 一组代码是不可分割的,并且暗含约定*:如果将它们分开可能会导致许多假设失败,因此您必须了解常规用法才能正确使用框架。
可以肯定地说,这是一条容易动摇的话,但是我想对框架提出一个非常有趣的观点:
框架暗示了一组有关如何解释代码的约定;因此,它们本身就是一种语言。
人们可能也想对此进行争论,但是如果您购买了我先前的定义,即语言只是一组约定,可以赋予一段文本以生命,那么只要您放下新的约定层,您就可以建立了一种新的语言。也许对于框架而言,原材料是其宿主语言的语义解释,而不是原始文本文件,但是想法是一样的!
因此,尽管如此,我很高兴将Node.js称为框架,即使它有点违反规范!Node.js以扩展语言的方式向原始JavaScript添加功能。随之带来了使用这种扩展语言的新假设和工具。从功能上讲,这些想法与其他公认的框架(如Ruby on Rails)的想法相同。
我会争辩说,如果此时您感到有点不安,并且想争辩说Ruby on Rails和Node.js在这种事情上存在巨大分歧,那么我当然会陪在您身边。两者所生活的概念世界截然不同 -我只想说它们是同一种东西:用于在特定领域内扩展基本语言功能的一组约定。
我也很高兴地建议Node.js的域很小且很紧,因此它添加的约定很容易推论,并且相对容易正确。在OTOH中,Ruby on Rails生活在一个复杂的,定义不明确的“业务Web应用程序”域中,这意味着它所遵循的约定肯定是模糊不清的。
但是所有这一切都说得很长,是的,招聘人员可能不知道说这些的意思。我猜想“框架”听起来比“运行时”或“引擎”更好,更古怪。