один чел сказал что код на ноде не читаем в последствии

При должном умении код <хоть на чём> не читаем.

Нода на десктопе уже есть, зовется electron.
Сильные стороны? - любая опердень для работы с нагруженным io, а вот перемалывать циферки уже не очень будет. Всякие крудики к базе писать будет идеально. Как обычно есть дикая куча библиотек, но большая часть омерзительного качества.
Можно даже кложе-скрипт втащить.

сильные стороны очевидны. 1) И сама нода, и вся инфраструктура заточена на асинхронность. 2) Один и тот же код на клиенте и сервере

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

Нода на десктопе уже есть, зовется electron

Пользуюсь одной софтиной на электроне (Rocket Chat), могу сказать что она шустра, и что самое прикольное - может быть интегрирована в десктоп (чуть ли не в трей и так далее), а может просто открыться как страница в браузере с 99% возможностей что и на десктопе.

Мне кажется это довольно коцептуально круто и шикарно.

Да не чуть ли, а вполне себе встраивается в трей, пример — новый скайп. Проблема только в потреблении памяти. Вот у меня свежезапущенный скайп, 4 процесса: 173+105+101+29=408M Нормально ли для IM жрать 400+ мегабайт? По-моему нет, если так будет жрать каждая программа, никакой памяти не напасешься. А ведь старый скайп жрал меньше 200M и имел возможностей побольше (навскидку, новый пока не поддерживает видеозвонки и шаринг экрана).

Расскажи это слаку, который после свежих обнов внезапно жрет одно ядро подчистую.

У меня доп. вопрос

...к тем, кто в курсе этого node.js & electron: а там для себя реально с мин, знаниями html/css/js собрать что-то, или все-таки надо вдручиваться в теорию по 3 языкам, чтобы этот электрон осилить?

Планирую запедалить что-то вроде «html/css морды для MariaDB/PG» на десктопчик.

Нода на десктопе уже есть, зовется electron

Electron uses Chromium

А есть что-нибудь не такое калорийное? Чтобы просто из js (v8 желательно) дёргать функции нативных библиотек + какие-нибудь автобиндинги.

все-таки надо вдручиваться в теорию по 3 языкам, чтобы этот электрон осилить?

Как я понял, там не сложнее, чем в браузере накидать.

сильные стороны очевидны. 1) И сама нода, и вся инфраструктура заточена на асинхронность. 2) Один и тот же код на клиенте и сервере

1) Ну, мне, например не нужна асинхронность и что делать?
2) Может, один и тот же язык?

Чтобы просто из js (v8 желательно) дёргать функции нативных библиотек + какие-нибудь автобиндинги.

Какой тогда смысл в js? Без браузерной инфраструктуры это просто один из дюжины говняных недоязычков.

Какой тогда смысл в js?

Клеевой язык для мест некритичных по скорости.

Без браузерной инфраструктуры

Но она может быть просто не нужна или избыточна.

Ну, мне, например не нужна асинхронность и что делать?

снимать штаны и бегать

Может, один и тот же язык?

и он тоже

Клеевой язык для мест некритичных по скорости.

на самом деле, в настоящий момент JS один из самых быстрых скриптовых языков, если не самый быстрый. Для веба и десктопа его скорости более чем достаточно, если не пишешь явную ахинею(например в цикле перебора миллиона строк не перерисовываешь на каждой итерации элемент страницы), о производительности думать вообще не придется.

на самом деле, в настоящий момент JS один из самых быстрых скриптовых языков,

Быстрые интерпретаторы у него

и он тоже

Понятно

Один и тот же код на клиенте и сервере

Давай пример одного и того же кода.

Инфраструктура ужасная, куча мелких либ(isarray и т.д), бардак в нпм, ехал колбек через колбек(знаю про асинк), я бы сказал что не скучно все это, учитывая что это и жабаскрипт, так вообще пушка! А так да все норм.

видеозвонки давно поддерживает, шаринг не пробовал

видеозвонки давно поддерживает

х..ево, надо сказать, он их поддерживает. Но соединяется иногда и картинку показывает от собеседника, да.

а вообще нода ненужна. для прототипов годится, ну или перед посонами попантоваться, типа погромист ... для серьезного чего-то нет.

х…ево, надо сказать, он их поддерживает

а чем? у меня без проблем показывает картинку и передаёт мою

Даже если язык позволяет «выстрелить» себе в произвольную часть тела, не стоит добавлять к его недостаткам «неудобно ходить с стрелой в жопе».
Просто в следующий раз попробуй не стрелять себе в зад.

для серьезного чего-то нет.

а посоны из гугла/амазона/тыщи-их/... и не знают

Давай пример одного и того же кода.

Нет желания доказывать очевидное. Открой для себя полиморфизм и абстрагирование. Есть множество библиотек, для которых разница между клиентом и сервером только в способе подключения

посоны из амазонов и гуглов фронтенды на них пишут для браузеров. Ну и для хипстоты и ноды заодно. Не вижу противоречий

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

Из-за легкости скатывания в говнокод 2) бессмысленно - поддерживать относительно не-говнокод на яве или питоне на сервере и говнокод на клиенте легче, чем говнокод везде.

Как ни странно, шаблонизатор на любом коде на сервере может кормить SPA на клиенте. И кода будет не более, чем в реакте.

Тогда я не понял что тебе от десктопа нужно. Будешь через WinAPI сам окна рисовать руками?
В node.js и так стоковый движок v8. Биндинги? Ну сядь напиши на крестах сам.

Электрон это не нода. Это нода и cef. Это вообще разные вещи. В электроне большинство юзаемых апи вообще не нодовские, а хромиумовские или запиленые спецом для электрона.

Нода на десктопе - это как питон, например. Ничто не мешает писать демоны\сервисы на ноде, точно так же как на питоне. Или консольные утилиты, например. На здоровье.

У ноды есть FFI модуль. Можешь дергать внешние либы. Только историй успеха таких я не видел.

В суть на голой ноде логично писать, что-то без фейса. А если нужен фейс, то отдавать его в браузер, который и так есть у всех.

JS это встраиваемый язык. Браузерная инфраструктура ему не нужна и плюсы его не в ней.

Ты описываешь типичную проблему Lib Driven Development. Это не беда языка, а беда голов.

Я пишу на js 15 лет (и не только на нем). Почему я не нуждаюсь в isarray и прочих подобных вещах? Почему у меня все работает как надо, разработка проектов не вызывает боли, а наоборот доставляет удовольствие.

слабые стороны: нет многопоточности; множество кривых/косых/неподдерживаемых/ненужных библиотек в npm; многие (даже с виду адекватные, но излишне подверженные влиянию) программисты ненавидят javascript за его темное прошлое; javascript — это одновременно и сильная, и слабая сторона ноды.

сильные стороны (будет немножко субъективщины): позволяет значительную часть кода делить между фронт и бэк-эндом (один и тот же язык); libuv -> асинхронщина, много IO не напрягаясь; npm - самый лучший менеджер зависимостей, с которым мне приходилось сталкиваться; множество готовых библиотек/фреймворков на все случаи жизни.

не советую использовать ноду для создания мелких кроссплатформенных утилит командной строки. неудобно это массово деплоить на разнородный парк машин. придется через npm зависимости подтаскивать. лучше для этого использовать тот же perl.

для веба — ну наверное если нода не подойдет под конкретную задачу, то это сразу будет понятно... я последние три года всю новую вебню делаю на ноде (как правило, всякие девелоперские тулзы и тырпрайзные сайты в интранете), и пока не столкнулся со случаем где она не годится.

npm - самый лучший менеджер зависимостей

говорят yarn лучшее, если говорить конкретно о npm, а не о его базе

позволяет значительную часть кода делить между фронт и бэк-эндом

Какие одинаковые задачи тебе необходимо выполнять и на фронте и на бэкэнде? Или какой код ты между ними делишь?

в последнем проекте, вся работа с данными на клиенте и сервере работает через одну и ту же кодобазу. проект — инструмент для аудита лицензионных соглашений очень крупного проекта.

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

Валидацию я понимаю, а всё остальное зачем с обоих сторон? Разве оно не будет только с одной стороны работать?

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

(типично, подобные вещи реализуются только на сервере, и результат выполнения кидается на клиент уже в виде данных, или даже в виде HTML, просто нода открывает новые возможности)

Зависит от твоего отношения в яваскрипту. Вместо ноды можешь поставить <любой_другой_язык>. Единственное большое отличие - если ты одновременно пишешь для браузера, то не надо мозг между разными языками переключать.

Под десктоп есть electron и что-то еще.

В конечном счете все сводится не к языку, а к состоянию экосистемы. Для мелких и средних поделок нода вполне сойдет.

По-моему ты пересказываешь чужие старые байки. На колбеках логику уже полтора года как никто не пишет, после появления генераторов.

Один и тот же код - валидаторы, роутер, темплейты. Хотя его действительно не очень много. Но смысл не в одинаковом коде, а в том что не надо между языками переключаться.

Почему при упоминание изоморфного кода, постоянно забывают про структуры данных. Они на клиенте и сервере вполне способны и зачастую и бывают одинаковыми. Те же классы объектов. Чем клиентский класс URI отличается от серверного. Или там, например, какой-нибудь ProductItem. Драйверы по работе с внешними ресурсами, да, различны. Но структуры то, при нормальной архитектуре, одинаковы.

для чего её стоит использовать

для сборки проекта на Angular или https://github.com/angular/angular-electron/tree/development + https://github.com/angular/material2 + https://github.com/angular/flex-layout
;)
вполне интересное десктопное приложение может выйти, ведь как известно в *никсах трабли с гуями и дизайнерами , а тут те гуй с четкими спеками и минимумом усилий

дополнительные грабли в виде «бета/альфа» - это только полюс для пытливого ума
какраз под релиз сможешь и свое приложение выкатить

На колбеках логику уже полтора года как никто не пишет, после появления генераторов.

Тут могу и ошибаться и с тобой спорить не буду, как раз года 2 назад последний раз и писал на ноде.

А по поводу одного языка, на работе стараемся разделять разработку на фронт и бэк.

А по поводу одного языка, на работе стараемся разделять разработку на фронт и бэк.

Ну это себе могут позволить только «большие солидные фирмы, решающие серьезные задачи» :). Чаще прогаммист отвечает за обе стороны.

В твоем случае большого смысла в ноде нет.

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

Сильные стороны? - любая опердень для работы с нагруженным io

Нет. На ноде написана распределённая система хранения данных Sia, и она именно на IO тормозит просто ужасно. Со 100 мб файлом возится пару часов. Приходится на tmpfs её файлы переносить.

https://github.com/NebulousLabs/Sia

Если ты про это, она на Go, и на ноде там только биндинги.

В замесах г. не разумею.

А зачем рассуждаешь о том, в чем не разбираешься, в таком случае?

Я не рассуждаю, я докладываю.

Ты не докладываешь, а обманываешь.