Безумная идея овладела Райаном Далом (Ryan Dahl) годы спустя: подружить движок V8 с библиотекой libev, дабы могли программисты выполнять свой JavaScript-код за пределами браузера. И возник Node.js. И npm. И люди возрадовались.
И стали люди писать веб-сервера на JavaScript, и запускать вертолёты с JavaScript на борту, и водружать его на планшеты и смартфоны, и встраивать его в термостаты и холодильники, да и во всё, во что их душа желала. И распространился JavaScript весьма и весьма широко. И презирали Нормальные Программисты™ (Serious Developers) простых людей, пишущих на JavaScript, но простые люди продолжали писать на JavaScript всё больше и больше.
И ждали люди Слово, способное вместить в себя всю широту проникновения JavaScript, ибо слово «JavaScript», как оно есть, более не вмещало той широты. И изрёк Чарли Роббинс (Charlie Robbins) мысль, что термином «Isomorphic JavaScript» можно назвать JavaScript-код, выполняющийся и в браузере, и на сервере. И никто нафиг не понимал значения сего, но, вместо просто программирования на JavaScript, люди стали программировать на изоморфном JavaScript.
Секундочку, что?
Вводя термин «Isomorphic JavaScript», Роббинс поясняет, что он имеет в виду (почти) любую строку кода, способную выполниться и в браузере, и на сервере. Но, если мы внимательно посмотрим на значение слова «изоморфный», мы увидим, что это есть «сходный по форме и структуре». Другими словами, две разные сущности, выглядящие одинаково. Хорошие примеры изоморфных сущностей есть у нас:
jQuery и jZepto, или Underscore и lodash. Библиотеки эти сходны по форме (одинаковый API), но различны в плане лежащих в их основе идей и философии.Короче, нам нужно Слово для одного и того же кода, способного выполняться в различных окружениях. Ибо в настоящее время мы выполняем JavaScript-код не только на серверах и в браузерах, но и на мобильных/встраиваемых устройствах. На Raspberry Pi, Wii U и айФонах. Однако, это сугубо инженероориентированные аргументы. Ясное понимание Слова — вот что более значимо.
Всё весьма субъективно в этом мире, конечно же. Недавно Райан Флоренс (Ryan Florence) и я (Michael Jackson, автор) начали вести курсы по React.js. Мы уже обучили несколько сотен программистов, и многие из них не понимали значение Слова и спрашивали, что значит «изоморфный». Как показала практика, когда мы говорили «универсальный» вместо «изоморфный», подобных вопросов не возникало. Это типа как Apple говорил «universal» про приложения, которые выполнялись на двух архитектурах во времена перехода с PowerPC на Intel.
Ибо сказано, в Computer Science есть две большие проблемы. Мы говорим про вторую, ибо хорошие Слова аццки важны, и говорят они про цели (purpose) и обязанности (responsibility). И да поразмышляет об этом на досуге каждый.
Что ж, давайте назовём наш JavaScript-код понятным всем Словом. Реальным Словом, вместо вброса в наш программистский, и без того замусоренный, словарь слова, которому не место в нём. И да будет то Слово не только про сервера и браузеры, но про всё.
И да будет Словом Universal JavaScript.
Моё спасибо следующим товарищам: Ryan Florence, Pete Hunt, Peter Cooper, Dan Abramov и Mark Dalgleish за рецензирование. Также, спасибо Райану за вычитку этого поста.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (98)
witbier
13.08.2015 01:01-4монопольный стандарт на клиентский код в web
Нет монополии. Живые и энтерпрайзные: typescript и clojurescript.
что особенно хорошего в нем?
Изоморфизм же.
some_x
13.08.2015 15:25-1typescript это язык надстройка (superset), то есть это попытка сделать js не таким ужасным. Не было бы монополии js, не было бы typescript.
С clojurescript я близко не работал, но опять таки если бы в web`е можно было применять любой язык то наверное не было бы clojurescript, был бы просто clojure
crackedmind
13.08.2015 17:06-2чем вам как enteprise не угодили elm и coffeescript? тем более в es6 по ощущениям куча всего из coffee взяли
bolk
13.08.2015 07:43+5Безумная идея овладела Райаном Далом (Ryan Dahl) годы спустя: подружить движок V8 с библиотекой libev, дабы могли программисты выполнять свой JavaScript-код за пределами браузера.
Эта «безумная идея» была реализована ещё во времена того же Нетскейпа. Был их сервер, который это мог. Кроме того, был ASP (который не .Net ещё) и JScript, на котором достаточно активно (в России менее активно) клепались сайты.
DenimTornado
13.08.2015 15:01+5«Но потом они передумали и решили, что Java хотят они. И вот, рождён был JavaScript. И было это (достаточно) хорошо.»
Как понять эту фразу? Java и JavaScript кроме четырёх букв ничего общего не имею же.
f0rk
13.08.2015 16:21-1Java и JavaScript кроме четырёх букв ничего общего не имею же.
Неправда, порядок этих букв в названии тоже общий.
kaatula
14.08.2015 08:12В следующем абзаце тоже ошибка — серверный JS как идея был почти сразу.
Просто реализация в тот момент не потянула
evocatus
13.08.2015 16:19-1Лично я давно бы перешёл на JS для всего, если бы
1) Если бы был простой интерпретатор JS типа интерпретатора Lua или Python. Я не хочу, чтобы моё приложение было ни на что не способно без монструозного браузера или NodeJS. Почему бы тот же V8 не выпустить отдельно?
2) Если бы JS умел просто открывать файлы с диска без NodeJS. Отсутствие у него до сих пор этой функции в стандартной библиотеке — наследие браузерного окружения.
3) Если бы можно было создавать GUI-приложения без HTML+CSS. Т.е. привязки к Tk, GTK, wxWidgets… а может быть написать новую библиотеку, которая победит монструозный Qt? Надо кончать с браузерным прошлым и поскорее.
А пока JS вызывает у меня только раздражение как узкоспециализированный инструмент, который суют везде к месту и не к месту.
P.S. Заголовок статьи — ложь. JS _не_ универсальный.
Sirion
13.08.2015 16:40evocatus
13.08.2015 17:21+1Спасибо за наводку, конечно, но у меня ссылка фиолетовая.
В том то и дело, что лично я хочу пользоваться JS полноценно вне web-технологий. Без HTML+CSS, без браузеров. Мухи отдельно, котлеты отдельно. Ведь сам по себе язык очень симпатичный. Глядя на JS я мечтаю — вот бы Lua имел такой крутой JIT-компилятор, такую огромную базу библиотек и такое активное сообщество.Sirion
14.08.2015 01:40+1У меня симметричные мечты: хочется, чтобы JS, а не Lua, был языком игровых скриптов. Моддить лично мне стало бы гораздо удобнее)
leemuar
14.08.2015 13:20Чем JS был бы удобнее LUA?
И почему именно JS, а не, например, ActionScript 3 (именно третья версия)?Sirion
14.08.2015 15:39+1Не хочу разводить холивар, просто для меня JS наиболее комфортен. Поигравшись с парой десятков языков и поработав на трёх из них, я нашёл в JS свой идеал.
bogus92
13.08.2015 17:411) Как раз из-за пункта №2. Ведь именно NodeJS добавляет те вещи, которые в других языках есть изначально.
2) Стоит понимать, что JS просто не может развиваться так же быстро, как и остальные языки, т.к. чтобы добавить новую фичу в язык производители самых популярных браузеров должны договориться, нужна ли эта фича и как она будет выглядеть. В других языках, например, выкатили новую версию и можно пользоваться. NodeJS можно считать немного отдельным языком. Сейчас наоборот, фичи из NodeJS добавляют в клиент-сайд (require, например) и библиотеки делают такими, что использовать их можно и на сервере и на клиенте.
3) Так можно же. Если я правильно понимаю, то Вы имеете ввиду это, это, это и это? Все это есть, но для десктоп приложений сейчас именно активнее всего развивается nw.js, о котором уже упоминали выше. Все дело в том, что как раз намного проще писать веб приложения для десктопа, т.к. опять же можно переиспользовать код с сервера или с сайта. Кроме того, дизайн приложения в таком случае можно делать очень гибким и делать его могут верстальщики, а не только программисты.
Я не считаю JS узкоспециализированым. Он и правда универсальный. Например, мне всегда не нравилось, что для валидации данных нужно по сути описывать одну и ту же логику на клиенте и на сервере (чтобы проверять все что можно не обращаясь к серверу и чтобы сам сервер не пропускал не правельные данные, если что). И в случае с JS на клиенте и на сервере это реально возможно и реально удобно. Одну и ту же систему валидации можно использовать и там и там.
hell0w0rd
13.08.2015 19:241) node.js как раз для этого и создан. v8 и выпущен отдельно. Это просто JIT машина для js. Как JVM для java/scala/closure.
2) JS — это просто язык. В любом просто языке нет никаких функций, есть переменные, типы данных, арифметика, возможность объявлять функции, классы и тп. Node.js — это в том числе стандартная библиотека для JS вне браузера. На пример в node.js нет DOM Api, или localStorage. Потому что это расширения для языка внутри браузера.
Ну и возьмите C++, там нет библиотеки для работы с файловой системой, ну так, к слову.
3) Как минимум десяток таких есть. Более того есть библиотеки, которые также как node.js, или браузер прокидывают нативное api в JS. React Native/Nativescript.
Прежде чем делать громкие заявления — разберитесь в теме.
Grox
14.08.2015 14:04www.espruino.com это пример JS интерпретатора без привязки к браузеру. Причём там нет VM, только интерпретатор. Это конечно очень узкий пример ) Показывает, что такие вещи существуют.
PerlPower
16.08.2015 07:48+2Пройдет время и JS уйдет в забвение или останется в своей нише. Он существует довольно давно, но популярность получил только в последние годы — потому что взрывными темпами стала расти отрасль в которой он применяется, а не потому что он хороший. Все его фичи так или иначе присутствуют в других современных языках. Асинхронность — это не фича языка, а следствие того, что язык используется в среде, где доминирует событийная модель. Фреймворки для асинхронности есть во всех языках, просто из-за их более широкой ориентированности они там не так заметны. А что касается скорости — это просто следствие того, что из-за роста числа тяжелых приложений на JS у google и mozilla просто не оставалось выхода кроме как оптимизировать реализации языка в своих браузерах, вкладывая в это деньги.
bigfatbrowncat
Господа гуру и просто глубоко понимающие JS. Поясните человеку, владеющему в разной степени понимания более, чем 4-мя языками программирования — в чем преимущества JS? В смысле, как языка… Я понимал его всегда как неизбежное зло — монопольный стандарт на клиентский код в web. Когда появился node.js, я смотрел на него как на странную фанатскую поделку — ну кому, — думал я, — взбредет в голову писать на таком
нелестный эпитетязыке что-то, помимо кнопочек и картинок в браузере?А потом оказалось, что я неправ. Просто статистически. Объявилась толпа людей, которые реально пишут на нем целые серверы. И теперь я в недоумении. То ли эти люди просто не решились выучить Java или, хотя бы, Ruby, то ли у меня лыжи не едут…
Прошу, не холивара ради, а токма прояснения истины для — объясните мне, что особенно хорошего в нем?
witbier
Упс, промазала. Ответ: habrahabr.ru/post/264607/#comment_8533903
Zibx
В языке ~4 концепции. Его красота именно в минимализме. Он позволяет писать в функциональном стиле. Объектное наследование отличается от классического, но это не хуже или лучше, просто другое. А когда V8 довёл его скорость до ~1/3 сишного компилированного — стало разумно утягивать это на сервак. Компиляция на лету. Собственно вот сравнение с руби.
witbier
Прототипное, не?
Zibx
Да, и прототип — тоже объект (или, иногда — примитив).
andyudol
Сообщество писателей на ЯС — это популяция живых организмов. И как и любая другая она стремится захватить как можно большее пространство. Это закон природы. Они не могут по-другому. Если кто-то придумает компилятор ЯС, они и операционки будут на нём писать.
Zibx
Так они уже придумали. V8 именно компилирует код, только за счёт этого можно добиться такой скорости, причём умудряется делать это очень быстро. Есть компиляторы си в am.js код, когда asm.js только появился — чуваки скомпилили таким образом квейк и он не тормозил в браузере.
andyudol
V8 возможно на js переписать?
jonic
если отойти от канонов, и генерировать исполняемый файл компилятора который так же пакует в исполняемый файл… то почему нет?
Zibx
Я почти уверен что кто-то уже забавы ради через llvm компилировал код v8 в js. Погуглил. Не v8, но llvm.js.
Grox
Каков минимальный размер программы на Java?
Каково обычное потребление памяти виртуальной машиной Java?
Люди привыкли к тому, что Java это медленно и много памяти. Жалобы на тормозной OpenOffice(Libre etc) их валом.
Он даже стартует медленно.
Парсер кода в PhpStorm(как по мне, он лучший) на большом количестве текста вешается и остановить это можно только выключив процесс.
То же и в других Java-based редакторах. А вот NuSphere PhpEdit, который написан на С++ переваривает любое количество текста, кода, чего угодно, что было открыто в нём. И делает это относительно легко.
Я не слышал про интерпретаторы Ruby для STM32, а Javascript есть. Я писал на С для контроллеров, но как же удобно делать мелкие проекты на Javascript. Причём, интерпретатор же событийный и сам управляет питанием чипа, в отличии от большинства программ новичков, где просто
Я слышал про Ruby, который всегда на рельсах. Про Ruby без рельс вообще кто-то слышал? ;) А на рельсах оно всё тяжёлое.
Javascript даёт
- быстрый старт. При изучении. При минимальном размере кода для программы. При запуске программы.
- Малое потребление памяти.
- Множество библиотек.
- Скорость виртуальной машины почти равна, а в некоторых случаях превосходит результаты компилируемых языков, таких, как С и С++.
- Можно писать на коленке, т.е. нужен браузер и блокнот, и уже можно начать.
- Можно делать GUI в лёгкую, без каких либо библиотек.
Что есть у приведённых вами языков, что сравниться с jQuery (и т.д.) + Bootstrap? Минимум размера файлов и кода — максимум результата.Продолжать можно долго.
egor_masalitin
Да ладно вам, а как же руби скрипты? Например тот же homebrew ;)
egor_masalitin
Не понимаю минусов. Лично для меня писать руби скрипты удобнее чем баш скрипты. И я считаю что это не плохо, они выполняют свою задачу, на них удобно писать тесты, их можно объединять в гемы, etc.
egor_masalitin
Тут не соглашусь, медленно разрабатывать — да, но скорость выполнения у Java приложения будет выше чем у JS/Ruby приложения.
Вы не подумайте, я обеими руками за JS, но стоит признать, что Java работает быстрее.
Grox
Стоит показать сравнительные тесты. Только в качестве примера — клиент-сайд приложения, которые запустил, поработал, выключил. А не те, что через 1000 часов непрерывной работы на сервере виртуальная машина идеально оптимизирует.
egor_masalitin
Я вам говорю про сервер сайд конечно же, не думаю что сейчас можно вообще рассматривать клиент сайд на джаве.
Grox
Мне всё равно было бы интересно увидеть тесты, даже в случае сервер-сайд. Интересно же, на чём основываются ваши слова.
egor_masalitin
Ну вот например:)
habrahabr.ru/post/66562
benchmarksgame.alioth.debian.org/u64/javascript.html
egor_masalitin
Похоже в случае с JS V8 я ошибался
egor_masalitin
Я думал что по всем тестам будет опережение времени у Java
some_x
Ну в большинстве то у ява, причём в разы. А ещё javascript однопоточен и многопоточность в нём реализуется только через костыли и модули написаннные на других (нормальных) языках.
Zibx
Вебворкеры и webgl творят чудеса. В продакшене у меня крутится несколько серверов, на каждом через node-cluster в 4 потока работает приложение, cинхронизация через redis. Внешний round robin балансер на сервера и внутренний между ядрами. Загрузка ядер при тысячах rps меньше процента.
konsoletyper
Вебворкеры — это не потоки! Потоки разделяют адресное пространство, а вебворкеры — нет. Но это не самое страшное, а страшно то, что из вебворкера я не могу сказать «вот тут подожди секунду и продолжай» или «отправить запрос к БД и подожди, пока он не выполнится». Всё это даже в вебворкерах делается через привычные колбэки, и даже promises решают проблему лишь частично. Когда мы говорим о сервере, то в node.js есть webworkers? А синхронную работу с БД там можно организовать?
hell0w0rd
А тут делается через асинхронность. Так работает nginx, на пример. От shared memory столько же минусов, сколько и плюсов. Например в JS сложно получить deadlock, чего не скажешь о многопоточных приложениях.
konsoletyper
А как делается в JS, я прекрасно знаю. Весь посыл в том, что типичный бэкэнд писать в колбэчном стиле крайне неудобно по сравнению с тем
Зато очень просто получить live lock :-) И даже гонка за общими ресурсами может быть, я по всем этим граблям даааавным давно прошёлся.
hell0w0rd
Гм, ну посмотрите на современный js. Есть промисы, есть, пока не стандартизованные, но таки доступный к использованию async/await.
Вот пример из реального проекта, авторизация:
Если не нравится не стандартизованные фичи, вот во что это компилируется:
Можно писать так. Это уже доступно и прекрасно работает в io.js.
hell0w0rd
А можно пример, как в многопоточных приложениях решается гонка за ресурсами? Я думаю и там и там нужно держать пул соединений к базе, или вы о чем то другом?
konsoletyper
Я не про базу, а про общие области памяти (например, поля объектов, которые видны нескольким потокам). И там для разруливания гонки используются блокировки. Есть несколько примитивов синхронизации, которые позволяют более-менее удобно управлять ресурсами (семафоры, мониторы, fork-join), есть CAS, который работает аппаратно, а не через средства ОС (а значит быстрее), но при этом он сложнее. Так же бывают многопоточные коллекции, которые гарантируют сохранение внутренней согласованности при условии параллельного доступа из нескольких потоков. На потоках прекрасно реализуются альтернативные средства для работы с параллельными задачами: акторы, транзакционная память.
hell0w0rd
Я не понимаю к чему вы мне это рассказываете. У нас однопоточное приложение, IO которого работает асинхронно. Это ровно все, что предоставляет нам node. Какие общие области памяти могут быть у одного треда?
konsoletyper
Я рассказываю это к тому, что «работает асинхронно» — это через колбэки. А колбэки разрастаются в кромешный ужас, и promises не всегда справляются. С синхронным IO и возможностью создавать потоки я просто пишу код без колбэков, не опасаясь того, что поток может «подвиснуть» на IO. Пусть себе подвисает — другие-то потоки в это время выполняются.
hell0w0rd
Можно пример, когда промисы не спасают? Ну и если так наплевательски относиться к IO, у вас все встанет в какой-то момент, что с колобками, что с потоками. Помимо прочего потоки — это лишняя память и лишнее процессорное время.
konsoletyper
Что значит «наплевательски относиться»?
Потоки — это не лишнее процессорное время. Ну да, на шедулинг потоков тратится процессорное время. Но на шедулинг корутин разве не тратится? А как по памяти? Я понимаю, на каждый поток создаётся по своему стеку. А на замыкания разве память не тратится? Я понимаю, бывают задачи вроде раздачи большущих файлов, когда логика простейшая, а IO много, но в типичном enterprise экономия памяти на корутинах — это экономия на спичках.
Sirion
Мне кажется, что вы заблуждаетесь. Чтобы исключить неясности, приведите, пожалуйста, этот цикл в синхронном виде, а я попытаюсь переписать его асинхронно с помощью промисов.
hell0w0rd
Ок. Если вы реально упретесь в что-то из выше перечисленного, можно написать расширение на любом языке с поддержкой ffi, или просто взять плюсы и написать эту конкретную задачу нативно.
Я думаю каждый инструмент имеет ограниченную область применения. Но я всего лишь не согласен с тем, что у JS — это только браузер.
А по поводу потоков — я не достаточно компетентен, чтобы продолжать тут спорить. На вскидку — да, свой стек, конкурентный доступ к общей памяти.
arvitaly
-
DexterHD
А можно пример такого же парсера на JS, который это все переварит лучше Шторма в том же окружении?
hell0w0rd
tern.js, на пример, проект. Пользуется популярностью у любителей простых редакторов, а не IDE. То есть vim/atom/sublime etc.
crackedmind
ну атом не катит как пример, он разве научился переваривать файлы > 2 мб?
RubyMine хоть в состояние логи открыть, это может затянутся конечно… Приходится Sublime для здоровенных файлов использовать
hell0w0rd
Научился. Только он зависает на некоторое время, прежде чем можно скроллить. Sublime тоже зависает, но показывает прогресс-бар.
IDEA тоже не открывает большие файлы нормально)
DexterHD
А можно пример IDE? Иначе какое то получается сравнение странное. Это все равно что Notepad с MS Word сравнивать по потреблению ресурсов.
hell0w0rd
Ну, code, наверное. На JS нет IDE, во всяком случае в вашем понимании. А WebStorm — это не IDE для JS. Это маркетинговый булшит.
Хотя, посмотрите на Nuclide. Это одна из попыток, сделать из Atom IDE. Судя по презентации, facebook использует Atom, как IDE вместо xcode, phpstom и webstorm. Там есть много возможностей, которые дает полноценная IDE.
stalkerg
Написан на C++!!!
Grox
Из википедии: Written in C++[3] and Java
Насколько я понимаю, на С++ оболочка, а нутро на Java. Возможно я ошибаюсь, найдёте подробности?
stalkerg
Откройте код, там только C++ (я немного патчил Либру). А так даже на вики написано:
ru.wikipedia.org/wiki/LibreOffice
Java там только для нескольких плагинов.
Grox
Я говорил в первую очередь про OpenOffice. Вики: Написана на C++, Java
Не думал, что Либре за несколько лет сумели отказаться от Java. Спасибо, было интересно узнать.
stalkerg
В OpenOffice аналогичная ситуация. Там только C++ старый… в Libre смогли перенести всё на стандартный STL с самопала (что сильно сократило размер кода, ускорило сборку и кое где скорость работы).
PerlPower
Размер JAR обычно ничтожен — там байткод. Если вы хотите считать размер вместе с JRE, то не забудьте приплюсовать к размеру программы на JS и размер браузера и движка JS. И у JRE круг решаемых задач будет поболее чем у браузера.
Посмотрите сколько отъедает одна открытая вкладка с JS приложением типа твиттера.
OpenOffice написан на C++. И скорость его старта это следствие сложности самого приложения. К слову на JS пока что-либо такой сложности я не встречал.
Вы доказываете превосходство JavaScript сравнивая Java и C++? Вы точно сравнивали PHPStorm и PhpEdit по возможностям? PHPEdit тоже поддерживает все рефакторинги, дает API для траснформации AST, поддерживает встроенные в PHP шаблонизаторы?
Равно как и питон есть для микроконтроллеров. Потому что и питон и JS минималистичны в плане грамматик. Когда JS будет поддерживать столько же возможностей как Ruby вроде постфиксных условий, операторов, возможностей для создания DSL, его тоже врядли запихнут в микроконтроллер.
Наверное если новичок не знает про режимы работы STM32, то не сильно огорчится если его программа будет работать на максимальном режиме энергопотребления. А если перед нами профессионал и он умеет работать с прерываниями и таймером, то бог ему судья. Более натужный пример нужно было бы еще постараться придумать.
Про JS без веба кто-то слышал? Ну может конечно уже и слышал — когда такая толпа программистов на одном языке появляется, то индустрия начинает адаптироваться и совать язык куда только можно.
Ответ не верный. Python дает:
cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the-most-popular-introductory-teaching-language-at-top-us-universities/fulltext
www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-simple-performance-comparison
pypi.python.org/pypi
morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html
А для питона — питон и блокнот.
IUP, Tkinter, PyQt, PyQt, WxWidgets.
Просто JS всотребован из-за вынужденного отсутствия альтерантив в данной области. Если в браузеры запилят байткодную виртуальную машину независимую от языка и JS там продержится как топовый язык еще 3 года, то тогда можно будет о чем-то говорить.
Что есть у JS, что сравится с Microsoft Excel и его VBA? Минимум размеров файлов и кода — максимум результата.
Несомненно, ведь количество аругментов, которые человек готов привести в защиту чего-то, прямо пропорционально симпатии к защищаемому объекту.
heilage
Событийность из коробки? Возможность писать в разных стилях (императивный, функциональный, объектный, процедурный, да даже декларативный прости господи) без принуждения к какому-то конкретному? Отсутствие необходимости осваивать мегабайтные фреймворки, чтобы написать hello world?
Ну и да, хотя изоморфность довольно спорна сама по себе, перспектива писать на одном и том же языке в бэкенде и фронтенде достаточно интересна и привлекательна. Плюс сокращение объема кодобазы.
some_x
А где в js событийность из коробки?
heilage
Там же, где event loop.
some_x
Я так понимаю вы говори о nodejs, но bigfatbrowncat говорил именно о языке
heilage
Неправильно понимаете.
К тому же, если рассматривать любой язык в отрыве от реализации, в любом языке из коробки нет ничего, кроме формальной грамматики.
some_x
К большинству языков прилагается стандартная библиотека. Так где в js event loop?
heilage
Вам погуглить?
rock
И мне, пожалуйста, погуглите.
heilage
Раз вы настаиваете. lmgtfy.com/?q=js+event+loop
rock
Не вижу ни одного упоминания event loop в стандартной библиотеке языка. Плохо гуглите или его там нет?
heilage
Я правильно понял, что вы утверждаете об отсутствии event loop как такового в js? Вы это серьезно?
rock
Абсолютно. Кстати, сами бы посмотрели чего нагуглили — «как в спецификации» :) В стандарте ECMAScript 5 абсолютно ничего про основной цикл, разве что в ECMAScript 6 появляется Promise.
heilage
А вы дальше первого абзаца, очевидно, не читали? «У браузеров (и в node.js) основная петля вшита.» Спецификация это безусловно круто, только в спецификациях говорится о том, как это должно работать, но ничего не говорится о том, как это должно быть реализовано.
И да, покажите хотя бы одну реализацию, где нет event loop.
rock
А должен был? Что я когда-то там в комментариях отметился вас явно не смущает :)
Отличайте язык (в котором, по вашему, событийность есть искаропки) и окружения.
Вы забыли или не знаете про различные встраиваемые реализации JavaScript, например, V7?
Zibx
Паттерн observable пишется на js в 15 строк. Десятки их писал под разные задачи, в том числе компилирующий новую функцию при каждом невешивании события (профит скорости ~30%).
В node.js есть eventemitter из коробки, под браузер уверен что есть полный полифилл (если это не прям тот же код).
В браузере события приходят из window, элементов, xhr и других ассинхронных штук. Чертовски удобно.
rock
Паттерн observable может появиться в стандарте языка в будущем, но пока его там нет искаропки — не принимается.
Zibx
В браузерах из коробки можно забавляться с подписыванием на кастомные события дом элементов.
Suvitruf
Он идеально подходит для прототипирования. У нас на серваках есть и Java, и Node.js сервисы. Я много лет пишу на Java, но вынужден признать, что многие вещи проще и быстрее сделать на Node.js.
Другое дело, если бы было время и деньги, то мы бы не использовали Node.js (:
Grox
А зачем? Если есть инструмент, который даёт тот же результат быстрее и дешевле, значит он оптимальнее? Это как Шаттл и Союз. Можно летать на Шаттле, но на Союзах оптимальнее.
Suvitruf
Зависит от нагрузки. Для софт-ланча оно подойдёт. Но вот релизиться с нодой я побаиваюсь.
isden
> Но вот релизиться с нодой я побаиваюсь.
Почему? Оно вполне стабильное, и куча народу его в продакшене уже используют.
blog.risingstack.com/node-js-is-enterprise-ready
Suvitruf
Мы и планируем её потестить на софт-ланче (да и остальные сервисы). Если нагрузку выдержит, то оставим )
konsoletyper
Потому что прототип потом не придётся поддерживать. А рефакторинг большой системы на JS — это по моему опыту гораздо и гораздо больнее, чем сопоставимой системы на Java. В общем, как всегда — хорошо можно только одну вещь: или быстро делать или легко поддерживать.
leemuar
JS — противоречивый язык. Он содержит как замечательные элегантные возможности, так и отвратительные, просто ужасные вещи.
Понять его мне помогли лекции и книга Дугласа Крокфорда, в которых он очень подробно и честно рассказывает о том, как появился этот язык, почему он стал популярным, что в нем есть хорошего и плохого (очень немногие рассказывают подробно о недостатках), почему так получилось и как жить дальше.
Лекции на youtube: Crockford On Javascript
Книга: Javascript: The Good Parts
Попробуйте посмотреть цикл лекций, затем прочитать книгу. Возможно, как и я, в них вы сможете найти ответы на ваши вопросы о JS.