Node.js: где лучше, а где лучше не

Язык, по сравнению со всякими похапями, неплохой.

Но уже Эрланг гораздо более вменяем, а уж какой-нибудь окамль – вообще супер.

их ерланг для stateful сервисов

Мдя. Попробуй что-нибудь узнать об эрланге, для начала.

> Ерлангисты идут лесом, так как их ерланг для stateful сервисов вроде онлайн игр и видео серверов. В обычном вебе оно как козе баян, так как проблем с параллелизмом в вебе не существует благодаря чудной stateless архитектуре.

Ну да, конечно, erlang для statful сервисов: он как раз для stateless больше подходит, и уж всяко лучше говна, вроде node.js, на котором можно писать только вебдванольные чатики.

Если язык обрабатывает конкатенацию по другому

В нормальных языках есть удобные операторы форматирования строк, хе-хе.

java

Брать джаву, как пример удобного языка… ну ты понел.

о. у меня есть готовое кунг-фу RESTful web service + webUI на Java. Многие советовали уползти с жавы, и переползти на nodejs.

Как думаешь, корректно было бы сам сервис оставить на Java, морду сделать на ноде, или перетаскивать на ноду вообще все?

Сомнения вызывает вот что: в жаве, с точки зрения быдлокодинга, хороший язык, использование оперативки и ормы. Но ведь через какое-то время оперативки будет не хватать, и всё закончится memcached/redis, а на орме неизменно получается структура, симулирующая документную БД (куб, файловая система). Все это есть в ноде почти искаропки. Но зато там нет - библиотек, поддержки IDE, и удобного для быстрого быдлокодинга языка, и никаких гарантий ;)

> о. у меня есть готовое кунг-фу RESTful web service + webUI на Java. Многие советовали уползти с жавы, и переползти на nodejs.

nodejs серверная часть. Или ты в серверной части обращаешься к restful web service?

Сомнения вызывает вот что: в жаве, с точки зрения быдлокодинга, хороший язык, использование оперативки и ормы. Но ведь через какое-то время оперативки будет не хватать, и всё закончится memcached/redis, а на орме неизменно получается структура, симулирующая документную БД (куб, файловая система). Все это есть в ноде почти искаропки. Но зато там нет - библиотек, поддержки IDE, и удобного для быстрого быдлокодинга языка, и никаких гарантий ;)

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

Разделять морду и бекенд стоит.

Я думаю с жавы слезать не стоит, так как она хорошо дружит с middleware. В любом случае у тебя есть возможность писать несколько сервисов на разных языках.

морду сделать на ноде

можно вот тут поподробнее? как?

можно вот тут поподробнее? как?

Элементарно, Ватсон!

У тебя есть горсть REST-сервисов. И есть фронтенд на ноде. На юзерский реквест нодой ходишь с помощью http.Client по бекендам, собираешь данные, потом с помощью одного из этих шаблонизаторов формируешь html и отдаешь клиенту.

Надо бы Pet Store на разных архитектурах накатать и побенчить

> У тебя есть горсть REST-сервисов. И есть фронтенд на ноде. На юзерский реквест нодой ходишь с помощью http.Client по бекендам, собираешь данные, потом с помощью одного из этих шаблонизаторов формируешь html и отдаешь клиенту.

Бред какой-то. Зачем веб-сервер, там где должена быть БД (не одна), которая лучше для этого предназначена?

а в БД данные появляются магически? Или ты предлагаешь всю бизнес-логику накодить на PL/SQL ?;)

Кто-то подобное на ЛОРе уже предлагал.

Выходи из анабиоза, узнай про N-звенку.

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

Если на жабе все работает, зачем сваливать?

С библиотеками у ноды и правда траблы имеются.Хотя, надо по задачам смотреть.

Если на жабе все работает, зачем сваливать?

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

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

Ну и надо быть готовым писать свои библиотеки.

Вообще, ноде еще годик-два повариться надо. Сам пишу потому что меня прикалывает. Сваливал с пыха - там точно было хуже :)

Тануда, node.js девелоперов (или пряморуких JS девелоперов) найти проще чем java девелоперов?

Жабаскриптовых девелоперов по веб-гуй палюбасу искать придется. Дык проще иметь всех одинаковых, чем сборную солянку :)

> Для остальных есть вебворкеры.

Угу, потоки, да. От чего ушли, к тому пришли, замечательно.

Жабаскриптовых девелоперов по веб-гуй палюбасу искать придется.

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

Более того, будет ли у них время на этот самый бэкенд?

Смешно, но на одном проекте у нас был Java серверсайд, а клиент - на .NET. Когда появилось предложение назначить девелопера, который хорошо знает обе платформы в обе команды, чтобы он был на планировании и т.д., то решили такого не делать. Причина - возможное появление хаков из-за tight coupling, которое может появиться из-за того, что есть люди, которые видят две стороны.

> Вы хотите сказать, что фронтэндщики прямо таки сели и сразу

могут бэкендом заниматься?

Вообще, это и есть оптимальный способ разработки.

а какой сейчас самый модный темплейтер для ноды?

Вообще, это и есть оптимальный способ разработки.

Слова лида с командой из минимум 10 человек, угу. А еще, они же и функциональные тесты должны писать, я угадал?

> Слова лида с командой из минимум 10 человек, угу

Примерно, что не так? Впрочем, я и так знаю что не так. Помню когда Google опубликовала Closure Templates я сразу подумал «какая клёвая вещь», но к моему большому удивлению сюда по отзывам никто не понял зачем это надо. Ведь у нас разработчики клиентской морды и серверной логики часто жёстко разделены. Что связано, естественно, с низким уровнем квалификации (разделение труда всегда есть следствие недостаточного уровня квалификации). В Google же уровень квалификации разработчиков выше и там хорошо понимают зачем нужна Closure Templates. Как-то так.

А еще, они же и функциональные тесты должны писать, я угадал?

Было бы отлично.

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

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

А фронтедщик пишет код агрегации информации от сервисов, это совершенно другое. Чисто формально да, это серверная часть, но фронтэнд.

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

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

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

почему бы им и на стороне сервера не пописать на их любимом js?

Много они не понапишут, сам же про это и сказал, собственно.

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

Слова лида с командой из минимум 10 человек, угу

> Хороший разработчик морды — на вес золота

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

Слова лида с командой из минимум 10 человек, угу

Давай ссылки, чо. На большие проекты, где js и верстку делали те же личности, что и в бд ползают.

Разделение труда: http://baza.farpost.ru

Но когда человек не понимает всей системы, то это зачастую ведёт к совершенно уродливым решениям.

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

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

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

> Для больших систем разделение обязанностей, наложенное на

архитектурное разделение системы - необходимость.

Что такое большая система?

Что такое большая система?

Где само-собой получается разделение труда. То есть у человека есть время только на какую-то узкую область.

> Где само-собой получается разделение труда. То есть у человека

есть время только на какую-то узкую область.

Ну тогда даже «Hello world» можно сделать большой системой.

Ну тогда даже «Hello world» можно сделать большой системой.

Довести до абсурда можно что-угодно. Я говорил об естественном процессе.

> Я говорил об естественном процессе.

С такой методологией разработки не знаком, можно побольше деталей?

С такой методологией разработки не знаком

Это управление.

> Это управление.

PMBOK тоже читал, но про естественное разделение всё равно не понял.

естественное разделение

Интуитивное. Само собой разумеющееся. Постепенно увеличивающее специализацию сотрудников и связанное с ростом сложности проекта.

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

Все правильно, просто приходит момент и становится понятно, что кандидат на должность должен обладать характеристиками полу-бога. Но я согласен, что ничего в разделении по сути хорошего нету. Чем более команда кроссфункциональна, тем она более эффективна. Как там в Getting Real: оставайтесь «маленькими» и будет вам счастье.

> Что такое большая система?

Это система, которую 90% команды понимают не более, чем на 20%

:)

Jade + Stylus.

Это что-то вроде навернутых haml и sass/less.

Видимо, запереть 100 человек в комнате, и не давать еды пока не напишут код.

кстати, как тебе stylus vs less? Через плечо утверждают, что «stylus круче»

Просто следующий виток развития. Ясен пень, круче. Так же как Jade круче Haml.

Хотя если надо ынтырпрайзненько, под миллион языков, можно и на хамле с лессом остановиться.