Javascript — это веб-язык. Это интерпретируемый язык. предыдущий блог здесь). Он работает в Интернете. На самом деле он работает в веб-браузерах, клиентах. Javascript работает на движке V8, встроенном в браузеры. NodeJs — это движок времени выполнения, основанный на V8, но позволяющий запускать код javascript в обычных системах на стороне сервера, а не только на стороне клиента в браузерах.

Поздний вход

В общем, python, ruby, java, c/c++, php, какой-то скомпилированный язык, какой-то интерпретируемый, но все они работают на стороне сервера и не могут работать на стороне клиента, то есть в браузере. Браузеры имеют движок V8 и, следовательно, интерпретируют код javascript (поскольку это интерпретируемый язык) и, таким образом, могут запускать javascript в Интернете, но не другие языки, специально созданные для работы в системах напрямую и, следовательно, хорошие для серверной части.

Но javascript — единственный язык, который вошел в обычную систему после того, как был просто языком на стороне клиента. Node Js — это не язык, а движок времени выполнения (можно сказать, что он похож на V8, но создан для работы непосредственно в системе, а не только в браузерах), а не язык. Javascript — это фактический язык, nodejs — это движок, который выполняет код javascript. Например, java — это язык, а JVM — это машина, которая выполняет код java. Cpython VM выполняет код cpython (обычно называемый python). Вы понимаете мою точку зрения? Нет? Хорошо, давайте вкратце расскажем о моем упомянутом сообщении в блоге, связанном с языком.

Интерпретируемый язык

Давайте поговорим о Java или языках на основе Java. Java — это язык, вы кодируете на Java, а затем компилируете свой код. Компиляция преобразует ваш необработанный код в некоторый байт-код Java, который вы затем пытаетесь запустить в системе. Но на самом деле вы запускаете байт-код java в JVM. Это специальная виртуальная машина, созданная специально для запуска Java-приложений.

Давайте посмотрим на другой язык, каждое приложение, которое вы запускаете, работает в системе. Но когда вы пытаетесь запустить программу, которая в основном представляет собой код, который вы пишете, который представляет собой не что иное, как простой текст, он не имеет никакого значения для системы, для системы это просто текстовый файл с строками строк, которые не имеют смысла, никаких инструкций. Итак, чтобы система работала, ей нужны инструкции, ей нужен язык, который она понимает, машинный код или ассемблерный код. Так что возникает потребность в компиляторе. Компилятор преобразует ваш необработанный текстовый код в машиночитаемый файл или код, который затем может работать в системе. Честно говоря, во время абстрактного процесса компиляции происходит множество других процессов, о которых мы говорим, например, генерация ast, компоновка, загрузка разделяемой библиотеки, преобразование кода сборки и т. д. Но мы абстрагируемся от всего этого и говорим всю process — это процесс компиляции, а конечным результатом является файл или код, который вы можете запустить в системе.

C/C++ делают то, о чем мы говорили в предыдущем абзаце. В то время как Java требует немного другого подхода. Он не компилирует код в машинный код, который привязывает вывод к конкретной системе и ее архитектуре. С другой стороны, Java компилируется в некоторый предмашинный класс или код, который является универсальным, и каждая система может генерировать его независимо от архитектуры системы. И этот универсальный код можно запускать универсально на всех машинах. Но как? Каждая машина уникальна, и для запуска любого кода ей нужен собственный набор инструкций. Наступает магия JVM. JVM — это виртуальная машина, которая поставляется в разных вариантах для разных систем и архитектур, но это все. После этого каждый универсальный скомпилированный java-код, о котором я упоминал, некоторый предмашинный код, который при запуске на JVM дополнительно компилирует код в машинный код, который затем фактически запускается на JVM. В конце концов, это виртуальная машина, она может запускать код, как если бы это была единственная система. JVM — это своевременный компилятор, который выполняет некоторые оптимизации и помогает быстрее запускать Java-код.

Теперь давайте поговорим о python, python — это интерпретируемый язык, на самом деле реализация cpython является интерпретатором. Таким образом, код Python, который мы пишем и запускаем с помощью команды python code.py, интерпретирует код построчно и запускается на виртуальной машине Cpython, которая похожа на JVM для python, но не так хороша, как JVM. JVM - это JIT-компилятор, поэтому он очень быстрый. Cpython интерпретируется, следовательно, медленнее. А также одна из основных причин, почему код на Python работает медленнее, чем на Java в несколько раз.

Точно так же интерпретируется Javascript, и он работает только в Интернете (ну, я знаю, что вы, вероятно, в этот момент хмуритесь, но вы уже знаете, что я вру) в своей заказной виртуальной машине под названием V8.

И NodeJs — это движок, подобный JVM, основанный на V8, который позволяет javascript, который работает только в Интернете, дает возможность запускать javascript в системах непосредственно на стороне сервера.

Усталость, дилемма

Слишком много вариантов. Когда вы начинаете использовать javascript, вы чувствуете себя хорошо, но затем вам нужно пройти через кроличью нору библиотек и пакетов, и вы начнете чувствовать усталость от выбора, печально известную как усталость от javascript (один из других печально известных жаргонов, таких как обратный вызов ад). Чрезмерное переживание чего-либо или перенапряжение чего-либо вызывает усталость.

Когда вы начнете писать код javascript, либо для веба, либо для серверной части с использованием узла, вам постепенно понадобится множество других инструментов для выполнения вашей работы. Это связано с тем, что узел довольно гладкий, тонкий и, следовательно, легкий. Он не поставляется со всеми библиотеками, которые вы получаете по умолчанию при использовании такого языка, как python. Но хорошо, это все еще хорошо, учитывая, что вам не всегда нужны эти библиотеки, и, таким образом, вы можете упростить свой процесс.

Но проблемы начинаются, когда вы пытаетесь использовать библиотеку для конкретной задачи. Усталость от выбора возникает, когда вы видите так много вариантов для одной задачи. Поскольку ни один из них не является официальным, и некоторые хорошие парни пытаются помочь сообществу узлов, внося свой вклад в проект, который мы можем использовать, но сейчас так много хороших парней, и поэтому вы чувствуете боль и трудности, чтобы решить, какой из них выбрать. хорошие парни. Никогда не обижай хорошего парня. Редко встречается на планете Земля. Какую библиотеку вы хотите использовать для той конкретной задачи, которую хотите выполнить?

Ноль дней с момента последнего нового JavaScript-фреймворка — Джеймс Уорд

И не только это, есть так много новых концепций, которые начинают появляться тут и там, и они никогда не останавливаются.

Работая над простым веб-приложением, вы сначала начинаете думать о хорошей сетевой и сетевой библиотеке или фреймворке. Это наша привычка, когда мы пришли из мира питона или рубина. У нас тоже есть несколько вариантов, но это все, как только мы выберем фреймворк, такой как Django, или Flask на питоне, или Sinatra, или Rails на рубине, мы уверены, что получим все от этого фреймворка, больше не будет рыбалки. экспедиция для других потребностей. Ну будет, но для особых случаев. Большинство наших потребностей уже будет покрыто этими фреймворками.

Но в мире javascript/node вы сначала узнаете о таких веб-фреймворках, как Express, хорошо. Это круто. Но потом вы начинаете слышать о других фреймворках, таких как hapi, koa, loopback в strongloop. Ну, это происходит во всех языках. Варианты хорошие. Правильно? Хорошо, я учту это. Но затем люди начинают говорить о конфигурации, а не о коде, о коде, а не о конфигурации, а затем о таких вещах, как самоуверенный фреймворк, фреймворк без мнения. Я никогда не слышал этих терминов, когда хотел использовать библиотеку на питоне. Я только слышал и читал о различиях в их функциональности, а не о терминах типа мнений, конфигураций и т.д. при выборе библиотеки.

Что ж, поскольку node js великолепен, мы попытаемся понять, что это новая игра в мяч, и эти термины на самом деле имеют смысл, и мы рассмотрим их снова. Что ж, затем идут такие вещи, как бегуны по задачам, ворчание, и я снова думаю, что просто хотел запустить сервер. Я просто хотел сделать node server.js, но люди говорят об использовании средства запуска задач? Хорошо, я воспользуюсь одним. Но в тот момент, когда вы начинаете использовать его и пытаетесь найти информацию о нем в Google, чтобы узнать, как использовать его более умело, вы завалены блогами и статьями о том, насколько устарел и устарел grunt и почему вы должны вместо этого начать использовать gulp. Они снова приводят некоторые аргументы в пользу конфигурации, а не кода, и наоборот. Я чувствую раздражение, но я все равно начну учиться глотать. Вы спрашиваете, почему? Потому что я не хочу стареть, я хочу чувствовать себя молодым и оставаться им, и без конца поглощать Нетфликс, вот почему, что еще это может быть, да! И, к удивлению, это здорово. Мне это очень нравится. Это работает. Я снова чувствую себя молодым.

Теперь, когда вы начинаете больше кодировать и у вас почти все получается, вы начинаете чувствовать себя уверенно и хотите следовать принципам хорошего дизайна, быть хорошим разработчиком и делать то, что делают хорошие разработчики, разбивая свой код на модули, чтобы он оставался чистым и пригодным для повторного использования. Но опять же, вам становится известно, что к этому тоже есть множество способов. Ты серьезно, где семейные ценности, узел? Почему вы не можете договориться о чем-то на один раз? Нод, ты меня реально бесишь. И проблемы с семейным соглашением Node снова сбивают вас с толку и заставляют узнавать о commonjs, require js, модулях amd. Но поскольку вы хороши, вы соблюдаете вредоносное поведение узла.

Что теперь? Итак, затем вы снова продолжаете писать код, надеясь, что вы, наконец, поняли узел и его проблемы, и начинаете прощать узел в обмен на его потрясающий сервис. Итак, вы возвращаетесь к использованию Google (глупый, как еще разработчики будут кодировать сейчас?), а затем они говорят вам начать минимизацию вещей, иглифацию вещей, линтинг вещей, автопрефиксы, делать живую перезагрузку, детектировать вещи, браузерировать вещи , смотреть материалы, затем какое-то время горячая перезагрузка sutffs и т. д. Опять же, я просто хотел написать простое веб-приложение. И я до сих пор не пришел, чтобы закончить его. :/

Что ж, все эти задачи важны, но дело в том, что когда вы находитесь в мире python, фокус всего вашего рабочего процесса меняется, а в мире node + javascript вы продолжаете слышать обо всем этом и о том, как исполнители задач являются необъяснимой частью вашего проекта. . Теперь мое внимание переключилось с написания кода моего веб-приложения на то, чтобы мой gulp выполнял сотню небольших задач. И иногда вы продолжаете искать лучшие пакеты, которые помогут вам выполнить эти задачи. Видите, это смещение фокуса и времени, о которых я говорю.

На самом деле вы просто не можете писать код, у вас возникает соблазн использовать стандарты ES6 и ES7, а для этого вам нужно бабелифицировать, вахтифицировать, браузерировать и делать еще много чего. Вы даже не можете просто написать код в том синтаксисе, который вам нужен, и просто сойти с рук. Для этого вы настроили полноценный скрипт сборки, используя gulp или webpack. Это так несправедливо! К этому времени Python позволил бы мне создать следующий Instagram.

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

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

Так что я начал склоняться к React. Но что случилось с Angular, который вы так тщательно изучили и приложили столько усилий, чтобы понять его, наконец, и хотя ваши проблемы с интерфейсом ушли, и вдруг вы говорите мне, что я должен использовать React и отказаться от Angular. Это грубо и несправедливо, на самом деле. Я же говорил вам, что если вы вернетесь к node или js через 6 месяцев, я думаю, Рим будет построен за один день. Что ж, Реакт великолепен. Теперь я полон энергии, если вы попросите меня выполнить работу с интерфейсом, в отличие от того, что раньше, когда это доставляло мне неприятные ощущения при написании этих клиентских javascripts.

Поэтому, прежде чем вы действительно запачкаете свои руки реакцией, вас отбрасывает обратно в мир запуска задач, и они рекомендуют (замаскированная сила) использовать веб-пакет и рассказывают вам, как это следующий сдвиг, который вы должны сделать, и каким будет глоток. снова устарел, и привести вам примеры того, как gulp заменил grunt и как подобное произойдет с gulp, просто чтобы убедить вас использовать webpack. И пользователь глотка начинает чувствовать себя загнанным в угол. Рано или поздно вы поймали себя на соблазне и начали писать плагины для веб-пакетов.

Итак, к настоящему времени я, должно быть, использовал, раздражался, менял и снова менял несколько библиотек, чтобы делать одно и то же снова и снова, но с новым внешним видом, новым ощущением. Ощущение, будто меняешь мобильные телефоны уже через несколько дней, даже если они остаются на 6 месяцев. В мире js, если вы вернетесь к работе через 6 месяцев, вы полностью устарели, все библиотеки и пакеты, которые вы, возможно, использовали для работы вашего приложения шесть месяцев назад, должны были уже измениться или, возможно, получили новый дизайн, орнамент, они только что были обновлены, и вы бы их больше не знали.

Сол: "Как дела?"
Я: "Устал".
Сол: "Семья?"
Я: "Нет, Javascript".

- Усталость от Javascript

Ирония в том, что я хочу воспользоваться преимуществами асинхронного ввода-вывода и node. Поэтому я продолжаю принимать разочарование. Теперь вы хотите использовать приложение, вы хотите вести журнал. И знаете что, вы окружены таким количеством опций и их названий, о боже, вы никогда не сможете узнать, для чего они нужны. Баньян, Уинстон и еще 5 человек, какой использовать? Сначала вам нужно прочитать 10 статей о том, как вести журнал в узле или как лучше всего вести журнал в узле js, и только тогда вы убедитесь, что нужно использовать bunyan или winston или те другие 5 библиотек, с которыми вы столкнулись во время Ваше стремление выяснить вышеизложенное.

Это не останавливается на достигнутом. Вы хороший программист, и, как и любой хороший программист, вы хотите протестировать свой код (я знаю, что мы плохие программисты). Итак, вы ищете хорошие библиотеки или инструменты для тестирования в node js. И вы снова завалены огромным количеством библиотек. Я имею в виду, если бы я захотел назвать их, я бы действительно запутался, кто из них что делает. В питоне у нас есть юниттест, нос, pytest и пара фиктивных библиотек, и они просто делают свою работу и компетентно. Но здесь у нас есть библиотеки, называемые мокко, чай, синон, лента, стамбул и другие, и если вы можете сказать мне, какая из них что делает, вы профи. Но на самом деле для новичка это действительно отстой. Вы получаете усталость от выбора, и есть так много вариантов для всего, вы не знаете, какой из них использовать, где и для какой цели, пока вы не прочитаете 10 статей или даже больше, чтобы действительно получить представление о вещах.

И каждый день вы будете слышать о появлении какой-нибудь новой библиотеки. Их так много, так много на самом деле. И все как какие-то js, koajs, hapijs, videojs и так далее.

Вывод

Я пытался быть немного сатирическим в этом, часть 1 была хороша для узла, а эта была плоха для узла. Есть еще один блог, который пытается объяснить аналогичную проблему усталости javascript в более сатирической манере. Прочтите тот пост. Ссылка здесь.

Если вы все это пережили, то поздравляю, вы готовы к следующему дню награждения, я обязательно номинирую ваше имя, скажите, пожалуйста, ваше имя. Но это также означает, что вы знаете потенциал узла и то, как его однопоточная природа и асинхронный ввод-вывод помогают вам делать множество вещей и дают вам преимущество перед многими другими языками. Так что, пока вас не убьет усталость, Go Node!