Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 98
Господа гуру и просто глубоко понимающие JS. Поясните человеку, владеющему в разной степени понимания более, чем 4-мя языками программирования — в чем преимущества JS? В смысле, как языка… Я понимал его всегда как неизбежное зло — монопольный стандарт на клиентский код в web. Когда появился node.js, я смотрел на него как на странную фанатскую поделку — ну кому, — думал я, — взбредет в голову писать на таком нелестный эпитет языке что-то, помимо кнопочек и картинок в браузере?
А потом оказалось, что я неправ. Просто статистически. Объявилась толпа людей, которые реально пишут на нем целые серверы. И теперь я в недоумении. То ли эти люди просто не решились выучить Java или, хотя бы, Ruby, то ли у меня лыжи не едут…
Прошу, не холивара ради, а токма прояснения истины для — объясните мне, что особенно хорошего в нем?
А потом оказалось, что я неправ. Просто статистически. Объявилась толпа людей, которые реально пишут на нем целые серверы. И теперь я в недоумении. То ли эти люди просто не решились выучить Java или, хотя бы, Ruby, то ли у меня лыжи не едут…
Прошу, не холивара ради, а токма прояснения истины для — объясните мне, что особенно хорошего в нем?
Упс, промазала. Ответ: habrahabr.ru/post/264607/#comment_8533903
В языке ~4 концепции. Его красота именно в минимализме. Он позволяет писать в функциональном стиле. Объектное наследование отличается от классического, но это не хуже или лучше, просто другое. А когда V8 довёл его скорость до ~1/3 сишного компилированного — стало разумно утягивать это на сервак. Компиляция на лету. Собственно вот сравнение с руби.
Сообщество писателей на ЯС — это популяция живых организмов. И как и любая другая она стремится захватить как можно большее пространство. Это закон природы. Они не могут по-другому. Если кто-то придумает компилятор ЯС, они и операционки будут на нём писать.
Так они уже придумали. V8 именно компилирует код, только за счёт этого можно добиться такой скорости, причём умудряется делать это очень быстро. Есть компиляторы си в am.js код, когда asm.js только появился — чуваки скомпилили таким образом квейк и он не тормозил в браузере.
V8 возможно на js переписать?
если отойти от канонов, и генерировать исполняемый файл компилятора который так же пакует в исполняемый файл… то почему нет?
Я почти уверен что кто-то уже забавы ради через llvm компилировал код v8 в js. Погуглил. Не v8, но llvm.js.
Прошу, не холивара ради, а токма прояснения истины для — объясните мне, что особенно хорошего в нем?
Каков минимальный размер программы на Java?
Каково обычное потребление памяти виртуальной машиной Java?
Люди привыкли к тому, что Java это медленно и много памяти. Жалобы на тормозной OpenOffice(Libre etc) их валом.
Он даже стартует медленно.
Парсер кода в PhpStorm(как по мне, он лучший) на большом количестве текста вешается и остановить это можно только выключив процесс.
То же и в других Java-based редакторах. А вот NuSphere PhpEdit, который написан на С++ переваривает любое количество текста, кода, чего угодно, что было открыто в нём. И делает это относительно легко.
Я не слышал про интерпретаторы Ruby для STM32, а Javascript есть. Я писал на С для контроллеров, но как же удобно делать мелкие проекты на Javascript. Причём, интерпретатор же событийный и сам управляет питанием чипа, в отличии от большинства программ новичков, где просто
while(1){
включили диодик
цикл пауза - считаем до 1 000 000
выключили диодик
цикл пауза - считаем до 1 000 000
}
Я слышал про Ruby, который всегда на рельсах. Про Ruby без рельс вообще кто-то слышал? ;) А на рельсах оно всё тяжёлое.
Javascript даёт
- быстрый старт. При изучении. При минимальном размере кода для программы. При запуске программы.
- Малое потребление памяти.
- Множество библиотек.
- Скорость виртуальной машины почти равна, а в некоторых случаях превосходит результаты компилируемых языков, таких, как С и С++.
- Можно писать на коленке, т.е. нужен браузер и блокнот, и уже можно начать.
- Можно делать GUI в лёгкую, без каких либо библиотек.
Продолжать можно долго.
Про Ruby без рельс вообще кто-то слышал? ;)
Да ладно вам, а как же руби скрипты? Например тот же homebrew ;)
Люди привыкли к тому, что Java это медленно и много памяти.
Тут не соглашусь, медленно разрабатывать — да, но скорость выполнения у Java приложения будет выше чем у JS/Ruby приложения.
Вы не подумайте, я обеими руками за JS, но стоит признать, что Java работает быстрее.
Стоит показать сравнительные тесты. Только в качестве примера — клиент-сайд приложения, которые запустил, поработал, выключил. А не те, что через 1000 часов непрерывной работы на сервере виртуальная машина идеально оптимизирует.
Я вам говорю про сервер сайд конечно же, не думаю что сейчас можно вообще рассматривать клиент сайд на джаве.
Мне всё равно было бы интересно увидеть тесты, даже в случае сервер-сайд. Интересно же, на чём основываются ваши слова.
Похоже в случае с JS V8 я ошибался
Я думал что по всем тестам будет опережение времени у Java
Ну в большинстве то у ява, причём в разы. А ещё javascript однопоточен и многопоточность в нём реализуется только через костыли и модули написаннные на других (нормальных) языках.
Вебворкеры и webgl творят чудеса. В продакшене у меня крутится несколько серверов, на каждом через node-cluster в 4 потока работает приложение, cинхронизация через redis. Внешний round robin балансер на сервера и внутренний между ядрами. Загрузка ядер при тысячах rps меньше процента.
Вебворкеры — это не потоки! Потоки разделяют адресное пространство, а вебворкеры — нет. Но это не самое страшное, а страшно то, что из вебворкера я не могу сказать «вот тут подожди секунду и продолжай» или «отправить запрос к БД и подожди, пока он не выполнится». Всё это даже в вебворкерах делается через привычные колбэки, и даже promises решают проблему лишь частично. Когда мы говорим о сервере, то в node.js есть webworkers? А синхронную работу с БД там можно организовать?
А тут делается через асинхронность. Так работает nginx, на пример. От shared memory столько же минусов, сколько и плюсов. Например в JS сложно получить deadlock, чего не скажешь о многопоточных приложениях.
А тут делается через асинхронность
А как делается в JS, я прекрасно знаю. Весь посыл в том, что типичный бэкэнд писать в колбэчном стиле крайне неудобно по сравнению с тем
Например в JS сложно получить deadlock, чего не скажешь о многопоточных приложениях.
Зато очень просто получить live lock :-) И даже гонка за общими ресурсами может быть, я по всем этим граблям даааавным давно прошёлся.
Гм, ну посмотрите на современный js. Есть промисы, есть, пока не стандартизованные, но таки доступный к использованию async/await.
Вот пример из реального проекта, авторизация:
Если не нравится не стандартизованные фичи, вот во что это компилируется:
Можно писать так. Это уже доступно и прекрасно работает в io.js.
app.get('/users', async (req, res) => {
const users = await User.findAll();
res.json(users);
});
Вот пример из реального проекта, авторизация:
async authorize(username, password) {
const user = await User.findOne({
where: {username}
});
if (user && await user.checkPassword(password)) {
return user;
}
throw new Error(`Unknown user ${username}`);
}
Если не нравится не стандартизованные фичи, вот во что это компилируется:
const authorize = bluebird.coroutine(function *authorize(username, password) {
const user = yield User.findOne({
where: {username}
});
if (user && yield user.checkPassword(password)) {
return user;
}
throw new Error(`Unknown user ${username}`);
});
Можно писать так. Это уже доступно и прекрасно работает в io.js.
А можно пример, как в многопоточных приложениях решается гонка за ресурсами? Я думаю и там и там нужно держать пул соединений к базе, или вы о чем то другом?
Я не про базу, а про общие области памяти (например, поля объектов, которые видны нескольким потокам). И там для разруливания гонки используются блокировки. Есть несколько примитивов синхронизации, которые позволяют более-менее удобно управлять ресурсами (семафоры, мониторы, fork-join), есть CAS, который работает аппаратно, а не через средства ОС (а значит быстрее), но при этом он сложнее. Так же бывают многопоточные коллекции, которые гарантируют сохранение внутренней согласованности при условии параллельного доступа из нескольких потоков. На потоках прекрасно реализуются альтернативные средства для работы с параллельными задачами: акторы, транзакционная память.
Я не понимаю к чему вы мне это рассказываете. У нас однопоточное приложение, IO которого работает асинхронно. Это ровно все, что предоставляет нам node. Какие общие области памяти могут быть у одного треда?
Я рассказываю это к тому, что «работает асинхронно» — это через колбэки. А колбэки разрастаются в кромешный ужас, и promises не всегда справляются. С синхронным IO и возможностью создавать потоки я просто пишу код без колбэков, не опасаясь того, что поток может «подвиснуть» на IO. Пусть себе подвисает — другие-то потоки в это время выполняются.
Можно пример, когда промисы не спасают? Ну и если так наплевательски относиться к IO, у вас все встанет в какой-то момент, что с колобками, что с потоками. Помимо прочего потоки — это лишняя память и лишнее процессорное время.
Можно пример, когда промисы не спасают?
- алгоритм Дейкстры по графу, который хранится на диске (или в БД);
- сортировка слиянием большущего объема данных, не умещающихся в памяти;
- ленивая загрузка ассоциаций через прокси, как в Hibernate;
- синтаксический разбор кода через LR-парсер, если код хранится на диске;
- банальный вложенный цикл с break'ом по условию, зависящему от элемента, выбранного на очередной итерации.
Ну и если так наплевательски относиться к IO, у вас все встанет в какой-то момент, что с колобками, что с потоками.
Что значит «наплевательски относиться»?
Помимо прочего потоки — это лишняя память и лишнее процессорное время.
Потоки — это не лишнее процессорное время. Ну да, на шедулинг потоков тратится процессорное время. Но на шедулинг корутин разве не тратится? А как по памяти? Я понимаю, на каждый поток создаётся по своему стеку. А на замыкания разве память не тратится? Я понимаю, бывают задачи вроде раздачи большущих файлов, когда логика простейшая, а IO много, но в типичном enterprise экономия памяти на корутинах — это экономия на спичках.
банальный вложенный цикл с break'ом по условию, зависящему от элемента, выбранного на очередной итерации.
Мне кажется, что вы заблуждаетесь. Чтобы исключить неясности, приведите, пожалуйста, этот цикл в синхронном виде, а я попытаюсь переписать его асинхронно с помощью промисов.
Ок. Если вы реально упретесь в что-то из выше перечисленного, можно написать расширение на любом языке с поддержкой ffi, или просто взять плюсы и написать эту конкретную задачу нативно.
Я думаю каждый инструмент имеет ограниченную область применения. Но я всего лишь не согласен с тем, что у JS — это только браузер.
А по поводу потоков — я не достаточно компетентен, чтобы продолжать тут спорить. На вскидку — да, свой стек, конкурентный доступ к общей памяти.
Я думаю каждый инструмент имеет ограниченную область применения. Но я всего лишь не согласен с тем, что у JS — это только браузер.
А по поводу потоков — я не достаточно компетентен, чтобы продолжать тут спорить. На вскидку — да, свой стек, конкурентный доступ к общей памяти.
-
Парсер кода в PhpStorm(как по мне, он лучший) на большом количестве текста вешается и остановить это можно только выключив процесс.
А можно пример такого же парсера на JS, который это все переварит лучше Шторма в том же окружении?
tern.js, на пример, проект. Пользуется популярностью у любителей простых редакторов, а не IDE. То есть vim/atom/sublime etc.
ну атом не катит как пример, он разве научился переваривать файлы > 2 мб?
RubyMine хоть в состояние логи открыть, это может затянутся конечно… Приходится Sublime для здоровенных файлов использовать
RubyMine хоть в состояние логи открыть, это может затянутся конечно… Приходится Sublime для здоровенных файлов использовать
А можно пример IDE? Иначе какое то получается сравнение странное. Это все равно что Notepad с MS Word сравнивать по потреблению ресурсов.
Ну, code, наверное. На JS нет IDE, во всяком случае в вашем понимании. А WebStorm — это не IDE для JS. Это маркетинговый булшит.
Хотя, посмотрите на Nuclide. Это одна из попыток, сделать из Atom IDE. Судя по презентации, facebook использует Atom, как IDE вместо xcode, phpstom и webstorm. Там есть много возможностей, которые дает полноценная IDE.
Хотя, посмотрите на Nuclide. Это одна из попыток, сделать из Atom IDE. Судя по презентации, facebook использует Atom, как IDE вместо xcode, phpstom и webstorm. Там есть много возможностей, которые дает полноценная IDE.
OpenOffice(Libre etc)
Написан на C++!!!
Из википедии: Written in C++[3] and Java
Насколько я понимаю, на С++ оболочка, а нутро на Java. Возможно я ошибаюсь, найдёте подробности?
Насколько я понимаю, на С++ оболочка, а нутро на Java. Возможно я ошибаюсь, найдёте подробности?
Откройте код, там только C++ (я немного патчил Либру). А так даже на вики написано:
ru.wikipedia.org/wiki/LibreOffice
Java там только для нескольких плагинов.
ru.wikipedia.org/wiki/LibreOffice
Написана на
C++
Java там только для нескольких плагинов.
Событийность из коробки? Возможность писать в разных стилях (императивный, функциональный, объектный, процедурный, да даже декларативный прости господи) без принуждения к какому-то конкретному? Отсутствие необходимости осваивать мегабайтные фреймворки, чтобы написать hello world?
Ну и да, хотя изоморфность довольно спорна сама по себе, перспектива писать на одном и том же языке в бэкенде и фронтенде достаточно интересна и привлекательна. Плюс сокращение объема кодобазы.
Ну и да, хотя изоморфность довольно спорна сама по себе, перспектива писать на одном и том же языке в бэкенде и фронтенде достаточно интересна и привлекательна. Плюс сокращение объема кодобазы.
А где в js событийность из коробки?
Там же, где event loop.
Я так понимаю вы говори о nodejs, но bigfatbrowncat говорил именно о языке
Неправильно понимаете.
К тому же, если рассматривать любой язык в отрыве от реализации, в любом языке из коробки нет ничего, кроме формальной грамматики.
К тому же, если рассматривать любой язык в отрыве от реализации, в любом языке из коробки нет ничего, кроме формальной грамматики.
К большинству языков прилагается стандартная библиотека. Так где в js event loop?
Вам погуглить?
И мне, пожалуйста, погуглите.
Раз вы настаиваете. lmgtfy.com/?q=js+event+loop
Не вижу ни одного упоминания event loop в стандартной библиотеке языка. Плохо гуглите или его там нет?
Я правильно понял, что вы утверждаете об отсутствии event loop как такового в js? Вы это серьезно?
Абсолютно. Кстати, сами бы посмотрели чего нагуглили — «как в спецификации» :) В стандарте ECMAScript 5 абсолютно ничего про основной цикл, разве что в ECMAScript 6 появляется Promise.
А вы дальше первого абзаца, очевидно, не читали? «У браузеров (и в node.js) основная петля вшита.» Спецификация это безусловно круто, только в спецификациях говорится о том, как это должно работать, но ничего не говорится о том, как это должно быть реализовано.
И да, покажите хотя бы одну реализацию, где нет event loop.
И да, покажите хотя бы одну реализацию, где нет event loop.
А должен был? Что я когда-то там в комментариях отметился вас явно не смущает :)
Отличайте язык (в котором, по вашему, событийность есть искаропки) и окружения.
Вы забыли или не знаете про различные встраиваемые реализации JavaScript, например, V7?
Отличайте язык (в котором, по вашему, событийность есть искаропки) и окружения.
Вы забыли или не знаете про различные встраиваемые реализации JavaScript, например, V7?
Паттерн observable пишется на js в 15 строк. Десятки их писал под разные задачи, в том числе компилирующий новую функцию при каждом невешивании события (профит скорости ~30%).
В node.js есть eventemitter из коробки, под браузер уверен что есть полный полифилл (если это не прям тот же код).
В браузере события приходят из window, элементов, xhr и других ассинхронных штук. Чертовски удобно.
В node.js есть eventemitter из коробки, под браузер уверен что есть полный полифилл (если это не прям тот же код).
В браузере события приходят из window, элементов, xhr и других ассинхронных штук. Чертовски удобно.
Паттерн observable может появиться в стандарте языка в будущем, но пока его там нет искаропки — не принимается.
Он идеально подходит для прототипирования. У нас на серваках есть и Java, и Node.js сервисы. Я много лет пишу на Java, но вынужден признать, что многие вещи проще и быстрее сделать на Node.js.
Другое дело, если бы было время и деньги, то мы бы не использовали Node.js (:
Другое дело, если бы было время и деньги, то мы бы не использовали Node.js (:
Другое дело, если бы было время и деньги, то мы бы не использовали Node.js
А зачем? Если есть инструмент, который даёт тот же результат быстрее и дешевле, значит он оптимальнее? Это как Шаттл и Союз. Можно летать на Шаттле, но на Союзах оптимальнее.
Зависит от нагрузки. Для софт-ланча оно подойдёт. Но вот релизиться с нодой я побаиваюсь.
> Но вот релизиться с нодой я побаиваюсь.
Почему? Оно вполне стабильное, и куча народу его в продакшене уже используют.
blog.risingstack.com/node-js-is-enterprise-ready
Почему? Оно вполне стабильное, и куча народу его в продакшене уже используют.
blog.risingstack.com/node-js-is-enterprise-ready
Потому что прототип потом не придётся поддерживать. А рефакторинг большой системы на JS — это по моему опыту гораздо и гораздо больнее, чем сопоставимой системы на Java. В общем, как всегда — хорошо можно только одну вещь: или быстро делать или легко поддерживать.
JS — противоречивый язык. Он содержит как замечательные элегантные возможности, так и отвратительные, просто ужасные вещи.
Понять его мне помогли лекции и книга Дугласа Крокфорда, в которых он очень подробно и честно рассказывает о том, как появился этот язык, почему он стал популярным, что в нем есть хорошего и плохого (очень немногие рассказывают подробно о недостатках), почему так получилось и как жить дальше.
Лекции на youtube: Crockford On Javascript
Книга: Javascript: The Good Parts
Попробуйте посмотреть цикл лекций, затем прочитать книгу. Возможно, как и я, в них вы сможете найти ответы на ваши вопросы о JS.
Понять его мне помогли лекции и книга Дугласа Крокфорда, в которых он очень подробно и честно рассказывает о том, как появился этот язык, почему он стал популярным, что в нем есть хорошего и плохого (очень немногие рассказывают подробно о недостатках), почему так получилось и как жить дальше.
Лекции на youtube: Crockford On Javascript
Книга: Javascript: The Good Parts
Попробуйте посмотреть цикл лекций, затем прочитать книгу. Возможно, как и я, в них вы сможете найти ответы на ваши вопросы о JS.
монопольный стандарт на клиентский код в web
Нет монополии. Живые и энтерпрайзные: typescript и clojurescript.
что особенно хорошего в нем?
Изоморфизм же.
typescript это язык надстройка (superset), то есть это попытка сделать js не таким ужасным. Не было бы монополии js, не было бы typescript.
С clojurescript я близко не работал, но опять таки если бы в web`е можно было применять любой язык то наверное не было бы clojurescript, был бы просто clojure
С clojurescript я близко не работал, но опять таки если бы в web`е можно было применять любой язык то наверное не было бы clojurescript, был бы просто clojure
чем вам как enteprise не угодили elm и coffeescript? тем более в es6 по ощущениям куча всего из coffee взяли
Безумная идея овладела Райаном Далом (Ryan Dahl) годы спустя: подружить движок V8 с библиотекой libev, дабы могли программисты выполнять свой JavaScript-код за пределами браузера.Эта «безумная идея» была реализована ещё во времена того же Нетскейпа. Был их сервер, который это мог. Кроме того, был ASP (который не .Net ещё) и JScript, на котором достаточно активно (в России менее активно) клепались сайты.
Лично я давно бы перешёл на JS для всего, если бы
1) Если бы был простой интерпретатор JS типа интерпретатора Lua или Python. Я не хочу, чтобы моё приложение было ни на что не способно без монструозного браузера или NodeJS. Почему бы тот же V8 не выпустить отдельно?
2) Если бы JS умел просто открывать файлы с диска без NodeJS. Отсутствие у него до сих пор этой функции в стандартной библиотеке — наследие браузерного окружения.
3) Если бы можно было создавать GUI-приложения без HTML+CSS. Т.е. привязки к Tk, GTK, wxWidgets… а может быть написать новую библиотеку, которая победит монструозный Qt? Надо кончать с браузерным прошлым и поскорее.
А пока JS вызывает у меня только раздражение как узкоспециализированный инструмент, который суют везде к месту и не к месту.
P.S. Заголовок статьи — ложь. JS _не_ универсальный.
1) Если бы был простой интерпретатор JS типа интерпретатора Lua или Python. Я не хочу, чтобы моё приложение было ни на что не способно без монструозного браузера или NodeJS. Почему бы тот же V8 не выпустить отдельно?
2) Если бы JS умел просто открывать файлы с диска без NodeJS. Отсутствие у него до сих пор этой функции в стандартной библиотеке — наследие браузерного окружения.
3) Если бы можно было создавать GUI-приложения без HTML+CSS. Т.е. привязки к Tk, GTK, wxWidgets… а может быть написать новую библиотеку, которая победит монструозный Qt? Надо кончать с браузерным прошлым и поскорее.
А пока JS вызывает у меня только раздражение как узкоспециализированный инструмент, который суют везде к месту и не к месту.
P.S. Заголовок статьи — ложь. JS _не_ универсальный.
Спасибо за наводку, конечно, но у меня ссылка фиолетовая.
В том то и дело, что лично я хочу пользоваться JS полноценно вне web-технологий. Без HTML+CSS, без браузеров. Мухи отдельно, котлеты отдельно. Ведь сам по себе язык очень симпатичный. Глядя на JS я мечтаю — вот бы Lua имел такой крутой JIT-компилятор, такую огромную базу библиотек и такое активное сообщество.
В том то и дело, что лично я хочу пользоваться JS полноценно вне web-технологий. Без HTML+CSS, без браузеров. Мухи отдельно, котлеты отдельно. Ведь сам по себе язык очень симпатичный. Глядя на JS я мечтаю — вот бы Lua имел такой крутой JIT-компилятор, такую огромную базу библиотек и такое активное сообщество.
У меня симметричные мечты: хочется, чтобы JS, а не Lua, был языком игровых скриптов. Моддить лично мне стало бы гораздо удобнее)
Реализация JIT-компилятора для lua есть — luajit.org/luajit.html
1) Как раз из-за пункта №2. Ведь именно NodeJS добавляет те вещи, которые в других языках есть изначально.
2) Стоит понимать, что JS просто не может развиваться так же быстро, как и остальные языки, т.к. чтобы добавить новую фичу в язык производители самых популярных браузеров должны договориться, нужна ли эта фича и как она будет выглядеть. В других языках, например, выкатили новую версию и можно пользоваться. NodeJS можно считать немного отдельным языком. Сейчас наоборот, фичи из NodeJS добавляют в клиент-сайд (require, например) и библиотеки делают такими, что использовать их можно и на сервере и на клиенте.
3) Так можно же. Если я правильно понимаю, то Вы имеете ввиду это, это, это и это? Все это есть, но для десктоп приложений сейчас именно активнее всего развивается nw.js, о котором уже упоминали выше. Все дело в том, что как раз намного проще писать веб приложения для десктопа, т.к. опять же можно переиспользовать код с сервера или с сайта. Кроме того, дизайн приложения в таком случае можно делать очень гибким и делать его могут верстальщики, а не только программисты.
Я не считаю JS узкоспециализированым. Он и правда универсальный. Например, мне всегда не нравилось, что для валидации данных нужно по сути описывать одну и ту же логику на клиенте и на сервере (чтобы проверять все что можно не обращаясь к серверу и чтобы сам сервер не пропускал не правельные данные, если что). И в случае с JS на клиенте и на сервере это реально возможно и реально удобно. Одну и ту же систему валидации можно использовать и там и там.
2) Стоит понимать, что JS просто не может развиваться так же быстро, как и остальные языки, т.к. чтобы добавить новую фичу в язык производители самых популярных браузеров должны договориться, нужна ли эта фича и как она будет выглядеть. В других языках, например, выкатили новую версию и можно пользоваться. NodeJS можно считать немного отдельным языком. Сейчас наоборот, фичи из NodeJS добавляют в клиент-сайд (require, например) и библиотеки делают такими, что использовать их можно и на сервере и на клиенте.
3) Так можно же. Если я правильно понимаю, то Вы имеете ввиду это, это, это и это? Все это есть, но для десктоп приложений сейчас именно активнее всего развивается nw.js, о котором уже упоминали выше. Все дело в том, что как раз намного проще писать веб приложения для десктопа, т.к. опять же можно переиспользовать код с сервера или с сайта. Кроме того, дизайн приложения в таком случае можно делать очень гибким и делать его могут верстальщики, а не только программисты.
Я не считаю JS узкоспециализированым. Он и правда универсальный. Например, мне всегда не нравилось, что для валидации данных нужно по сути описывать одну и ту же логику на клиенте и на сервере (чтобы проверять все что можно не обращаясь к серверу и чтобы сам сервер не пропускал не правельные данные, если что). И в случае с JS на клиенте и на сервере это реально возможно и реально удобно. Одну и ту же систему валидации можно использовать и там и там.
1) 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.
Прежде чем делать громкие заявления — разберитесь в теме.
2) JS — это просто язык. В любом просто языке нет никаких функций, есть переменные, типы данных, арифметика, возможность объявлять функции, классы и тп. Node.js — это в том числе стандартная библиотека для JS вне браузера. На пример в node.js нет DOM Api, или localStorage. Потому что это расширения для языка внутри браузера.
Ну и возьмите C++, там нет библиотеки для работы с файловой системой, ну так, к слову.
3) Как минимум десяток таких есть. Более того есть библиотеки, которые также как node.js, или браузер прокидывают нативное api в JS. React Native/Nativescript.
Прежде чем делать громкие заявления — разберитесь в теме.
www.espruino.com это пример JS интерпретатора без привязки к браузеру. Причём там нет VM, только интерпретатор. Это конечно очень узкий пример ) Показывает, что такие вещи существуют.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Универсальный JavaScript