Сложно сказать, потому что эти слова не очень четкие. Говоря простым языком, я думаю, что нетипично называть Node.js фреймворком, конечно, но мне было бы трудно спорить, почему именно это не так.
Все это становится рискованным, и я часто вижу очень плохое использование языка, поэтому я буду откровенен и начну с самого низа
JavaScript - это компьютерный язык, то есть, в узком смысле, набор соглашений, которые позволяют нам читать и интерпретировать кучу текста как имеющую семантику выполнения - причудливое слово для «способа интерпретации языка как набора инструкций». Классы программ , называемых переводчиков , составителей , transpilers , пуха , текстмаркеры и т.д. Все принимают текст в и попытаться сделать что - то с этим традиционным пониманием того , как выполнить код.
- Интерпретаторы фактически выполняют семантику выполнения, управляя некоторой машиной - обычно вашим компьютером. Вы можете думать о них, как о маленьком человечке внутри вашего компьютера, переключающем переключатели типа «напечатать этот символ» на основе инструкций, написанных в вашей программе JavaScript.
- Компиляторы пытаются преобразовать текст JavaScript в новый набор текста, который имеет семантику выполнения для другого языка - возможно, со специальным свойством, которое компьютеры могут непосредственно выполнять.
- Транспортеры - это обобщенная форма компилятора, заключающаяся в том, что они принимают текст JavaScript и выводят текст какого-либо другого языка. Разница, таким образом, немного субъективна, но обычно считают, что компилятор выводит код очень низкого уровня, а транспортер - вывод кода высокого уровня .
- Линтер , текстмаркеры , типа шашек , и т.д. все берут в тексте и выход какой - то аналитический продукт JavaScript, выделенный текст например, на который влияет семантикой выполнения, но на самом деле не является представителем этого.
Теперь давайте немного углубимся в семантику исполнения. Как правило, семантика исполнения включает в себя процесс чтения текста на языке и получения либо описания абстрактной машины, либо описания наблюдаемых побочных эффектов . Что я хотел бы предложить, так это то, что оба они предполагают необходимость наличия какого-то «низкоуровневого API» для управления машиной или для выполнения наблюдаемых эффектов. Они обычно считаются частью среды выполнения
- Среда выполнения или среда выполнения - это набор предполагаемых примитивов, которые обязательны для существования языкового соглашения. Что касается языка, могут быть некоторые предположения об их поведении, но они ненаблюдаемы. На изображении интерпретатора выше, «человек внутри» просто щелкает переключателями среды выполнения - он не может лично проверить, что они делают.
Слово « среда выполнения» обычно используется для обозначения как набора самих предполагаемых примитивов, так и их фактической реализации.
Итак, теперь мы добрались до чего-то волосатого. Язык - это набор соглашений, которые предполагают существование среды выполнения, чтобы придать смысл своей семантике выполнения. Он никогда не "исследует их", поскольку они находятся вне области видимости.
Чтобы фактически использовать язык, вам нужно что-то вроде компилятора или интерпретатора наряду с реализацией во время выполнения. Компилятор / интерпретатор и это время выполнения идут рука об руку, фактически выполняя ваш код.
- Chrome V8 , часто называемый движком , представляет собой пакетную сделку, содержащую интерпретатор, компилятор, реализацию среды выполнения, совместимую с интерфейсом среды выполнения, требуемым стандартными соглашениями JavaScript ECMA.
Так где же Node.js вписывается в это?
Мы должны разбить его на части:
- Node.js расширяет язык JavaScript , предоставляя больший набор примитивов среды выполнения - тех, которые выходят за рамки стандартов ECMA. К ним относятся такие вещи, как файловый ввод-вывод . Это означает, что Node.js меняет язык и в некотором смысле является новым языком: «Node.js JavaScript»
- Node.js, как пакет, содержит интерпретатор и компилятор. Он просто крадет их у V8.
- Node.js обеспечивает реализацию среды выполнения Node.js, которая позволяет выполнять «Node.js JavaScript».
- Node.js предоставляет набор стандартных библиотек, созданных поверх новых примитивов, которые делают их более доступными для конечных пользователей «Node.js JavaScript».
Так что Node.js много чего!
Но разве это основа?
Вот где терминология полностью разваливается - никто не имеет хорошего, последовательного, значимого определения того, что такое структура на самом деле.
Бушуют споры: «что такое фреймворк против библиотеки», и они заканчиваются неудовлетворительными вещами, такими как «библиотека - это то, что вы называете, а фреймворк - это то, что вызывает вас». Я даже не хочу давать такое грустное объяснение в свете дня, но JavaScript, и JavaScript Node.js в частности, является огромным ударом по этому определению, поскольку вся техника прохождения обратных вызовов означает, что вы постоянно переключаетесь между вызовами и быть призванным.
По моему личному мнению, здесь есть что-то существенное. Я не хочу рисовать яркие линии, но я просто скажу
- Набор кода подобен библиотеке, если он работает как набор legos : делится и создается для сборки. Хотя может быть несколько примеров того, как использовать библиотеку, обычно пользователь сам собирает ее в соответствии со своими потребностями.
- Набор кода подобен фреймворку, если он не делится и подразумевает условные обозначения *: его разделение на части может привести к сбою многих предположений, поэтому для правильного использования фреймворка необходимо понимать обычное использование .
Конечно, это очень сложная линия, но я хочу выделить действительно интересный момент о фреймворках:
Фреймворки подразумевают ряд соглашений о том, как интерпретировать код; поэтому они сами по себе являются языком.
Это может быть тем, о чем люди тоже хотят спорить, но если вы купили мое более раннее определение, что язык - это просто набор соглашений, которые дают жизнь блоку текста, то всякий раз, когда вы устанавливаете новый уровень соглашений, вы ' Мы создали новый язык. Возможно, с помощью фреймворков исходные материалы представляют собой семантические интерпретации их основного языка вместо текстовых файлов, но идея та же!
Итак, учитывая все вышесказанное, я совершенно счастлив назвать Node.js фреймворком, даже если он идет вразрез с нормой! Node.js добавляет функциональность в сырой JavaScript путем расширения языка . С ним появляются новые предположения и инструменты для работы на этом расширенном языке. Функционально эти идеи совпадают с идеями других общепринятых сред, таких как Ruby on Rails .
Я бы сказал, что если в этот момент вы чувствуете тошноту и хотите утверждать, что между Ruby on Rails и Node.js существует огромный разрыв, то я , конечно, с вами . Тип концептуальных миров, в которых живут эти два, кардинально различен - я просто хочу сказать, что это одно и то же: наборы соглашений для расширения возможностей базового языка в определенной области.
Я также рад предположить, что домен Node.js крошечный и узкий, и, следовательно, добавленные в него соглашения просты для осмысления и относительно легко сделать корректными. OTOH, Ruby on Rails живет в сложной, плохо определенной области «бизнес-веб-приложений», что означает, что содержащиеся в нем соглашения, безусловно, нечетки и нарушены.
Но все это долгий способ сказать, да, рекрутеры, вероятно, понятия не имеют, что они имеют в виду, когда говорят это. Я предполагаю, что «фреймворк» звучит как лучшее, более унылое слово, чем «время выполнения» или «движок».