Является ли Node.js фреймворком? [закрыто]

35

Я продолжаю видеть, что рекрутеры, разработчики и т. Д. Называют Node.js фреймворком. На мой взгляд, это из-за незнания того, чем на самом деле является Node.js.

Часто в должностных инструкциях Node.js группируется как библиотека среди AngularJS , React и т. Д. Обычно я вижу, что ее вводит кто-то, кто не знает различий (HR, рекрутер и т. Д.).

На мой взгляд, Node.js - это платформа или среда выполнения; он отключает DOM API (JavaScript в браузере) для различных других API, таких как файловая система (поскольку он работает как сервер, а не в браузере).

Почему люди думают, что Node.js - это фреймворк? я ошибся? Это на самом деле рамки?

ndugger
источник
5
Не особенно, но я мог видеть замешательство.
ndugger
1
Давным-давно, когда впервые появился узел, я опубликовал ответ на SO, в котором говорилось, что этот узел не является фреймворком. Этот ответ был крайне опущен тогда. Сегодня очень-очень мало людей, которые используют ноды, считают, что это фреймворк. Это фреймворк в том же смысле, что Swift - это фреймворк, или Go - это фреймворк, или Rust - это фреймворк. Современные языки программирования просто имеют высокоуровневые API, которые раньше были реализованы в виде фреймворков. «Платформа» - хорошее слово. Я бы сказал, что это переводчик сам (используя традиционное значение этого слова для Unix)
slebetman
Обратите внимание, что узел не отключает API DOM, и все, что вы можете запустить с помощью javascript, все еще доступно вам, с узлом или без него.
Роб
@slebetman Что означает «другой» переводчик? Я не осознавал, что там тоже были дебаты! : S
Дж. Абрахамсон

Ответы:

44

Сложно сказать, потому что эти слова не очень четкие. Говоря простым языком, я думаю, что нетипично называть Node.js фреймворком, конечно, но мне было бы трудно спорить, почему именно это не так.

Все это становится рискованным, и я часто вижу очень плохое использование языка, поэтому я буду откровенен и начну с самого низа


JavaScript - это компьютерный язык, то есть, в узком смысле, набор соглашений, которые позволяют нам читать и интерпретировать кучу текста как имеющую семантику выполнения - причудливое слово для «способа интерпретации языка как набора инструкций». Классы программ , называемых переводчиков , составителей , transpilers , пуха , текстмаркеры и т.д. Все принимают текст в и попытаться сделать что - то с этим традиционным пониманием того , как выполнить код.

  • Интерпретаторы фактически выполняют семантику выполнения, управляя некоторой машиной - обычно вашим компьютером. Вы можете думать о них, как о маленьком человечке внутри вашего компьютера, переключающем переключатели типа «напечатать этот символ» на основе инструкций, написанных в вашей программе JavaScript.
  • Компиляторы пытаются преобразовать текст JavaScript в новый набор текста, который имеет семантику выполнения для другого языка - возможно, со специальным свойством, которое компьютеры могут непосредственно выполнять.
  • Транспортеры - это обобщенная форма компилятора, заключающаяся в том, что они принимают текст JavaScript и выводят текст какого-либо другого языка. Разница, таким образом, немного субъективна, но обычно считают, что компилятор выводит код очень низкого уровня, а транспортер - вывод кода высокого уровня .
  • Линтер , текстмаркеры , типа шашек , и т.д. все берут в тексте и выход какой - то аналитический продукт JavaScript, выделенный текст например, на который влияет семантикой выполнения, но на самом деле не является представителем этого.

Теперь давайте немного углубимся в семантику исполнения. Как правило, семантика исполнения включает в себя процесс чтения текста на языке и получения либо описания абстрактной машины, либо описания наблюдаемых побочных эффектов . Что я хотел бы предложить, так это то, что оба они предполагают необходимость наличия какого-то «низкоуровневого API» для управления машиной или для выполнения наблюдаемых эффектов. Они обычно считаются частью среды выполнения

  • Среда выполнения или среда выполнения - это набор предполагаемых примитивов, которые обязательны для существования языкового соглашения. Что касается языка, могут быть некоторые предположения об их поведении, но они ненаблюдаемы. На изображении интерпретатора выше, «человек внутри» просто щелкает переключателями среды выполнения - он не может лично проверить, что они делают.

Слово « среда выполнения» обычно используется для обозначения как набора самих предполагаемых примитивов, так и их фактической реализации.


Итак, теперь мы добрались до чего-то волосатого. Язык - это набор соглашений, которые предполагают существование среды выполнения, чтобы придать смысл своей семантике выполнения. Он никогда не "исследует их", поскольку они находятся вне области видимости.

Чтобы фактически использовать язык, вам нужно что-то вроде компилятора или интерпретатора наряду с реализацией во время выполнения. Компилятор / интерпретатор и это время выполнения идут рука об руку, фактически выполняя ваш код.

  • Chrome V8 , часто называемый движком , представляет собой пакетную сделку, содержащую интерпретатор, компилятор, реализацию среды выполнения, совместимую с интерфейсом среды выполнения, требуемым стандартными соглашениями JavaScript ECMA.

Так где же Node.js вписывается в это?

Мы должны разбить его на части:

  1. Node.js расширяет язык JavaScript , предоставляя больший набор примитивов среды выполнения - тех, которые выходят за рамки стандартов ECMA. К ним относятся такие вещи, как файловый ввод-вывод . Это означает, что Node.js меняет язык и в некотором смысле является новым языком: «Node.js JavaScript»
  2. Node.js, как пакет, содержит интерпретатор и компилятор. Он просто крадет их у V8.
  3. Node.js обеспечивает реализацию среды выполнения Node.js, которая позволяет выполнять «Node.js JavaScript».
  4. 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 живет в сложной, плохо определенной области «бизнес-веб-приложений», что означает, что содержащиеся в нем соглашения, безусловно, нечетки и нарушены.


Но все это долгий способ сказать, да, рекрутеры, вероятно, понятия не имеют, что они имеют в виду, когда говорят это. Я предполагаю, что «фреймворк» звучит как лучшее, более унылое слово, чем «время выполнения» или «движок».

Дж. Абрахамсон
источник
эй, замечательно сбалансировано! Итак, probably have no idea«framework» - это слово, которое вы можете понять, не будучи программистом, полезная функция, если ее не учитывать, когда она действительно будет иметь значение.
n611x007
«Node.js добавляет функциональность в сырой JavaScript путем расширения языка». Это не так, это расширяет функциональность, а не язык, это не меняет способ написания кода, как того требуют многие фреймворки. Существуют и другие функции или объекты, добавленные, как добавленная библиотека. Вы можете вызвать его или использовать как любую новую функцию или объект. Стиль программирования не меняется, языковые основы такие же, «только» добавляют некоторую функциональность. Так что это не фреймворк и не расширение языка, а JavaScript с добавленными библиотеками платформы по умолчанию и, следовательно, функциональностью.
Codebeat
Конечно, я могу полностью следовать вашей стороне. Я думаю, что линия здесь нечеткая. Любой способ мышления имеет смысл. Строго говоря, узел расширяет JS, предоставляя FFI, который затем является основной частью, которая позволяет узлу впоследствии предоставлять больше системных библиотек. С другой стороны, в то время как «базовый» узел - это просто среда выполнения (и этот FFI), большую часть времени, когда люди обсуждают узел, они на самом деле имеют в виду «основное время выполнения, расширения FFI и базовые функциональные возможности библиотеки, построенные поверх него», как это как узел упакован.
Дж. Абрахамсон
20

Node.js® - это среда выполнения JavaScript, построенная на движке Chrome V8 JavaScript.

источник

Узел - это среда выполнения или среда. Это не рамки. Люди (я чувствую) часто ошибаются, потому что такие фреймворки, как express, вездесущи с node.

больше читать о средах исполнения и фреймворках, если вам интересно.

rlemon
источник
inb4 "но на странице about написано" Как асинхронный управляемый событиями фреймворк "" Я в курсе.
Rlemon
3
Разве встроенный v8 не время выполнения? ;-)
Йоханнес
@johannes Я склонен с тобой согласиться. V8 - это среда выполнения, а узел просто расширяет инструменты, доступные разработчику (http-сервер, util и т. Д.), Поэтому я думаю, что метка фреймворка все еще работает. Тем не менее, это модифицированная среда v8; узел - это не то, что вы просто «включаете» в свой проект. Это все вопрос перспективы, я думаю.
Ник
@rlemon, часть рамки была удалена.
Эбрам Халил