> В общем, если есть возможность написать все приложение целиком на одном языке — это большое счастье для проекта!
Это не поможет. Знание языка — это очень маленькая часть, от знаний, которые нужны специалисту в той или иной части проекта.
Даже если и там и там JS, фронтендщики не полезут в бекенд, а бекендщики не должны лезть в фронтенд. Они по разному пишут, по разному работают с колбеками (deffered vs async), разные ньюансы (DOM и браузеры vs node и concurrency), разные инструменты отладки, да вообще почти всё разное. Даже разные точки зрения на задачу: фичи и динамика vs стабильность и нагрузка. Бекендщику в фронтенде от знания js примерно столько же пользы, сколько гастроэнтерологу в стоматологии от знаний русского языка и латыни.
Так что время на изучение другого языка (после 10 языков на 11-ый уйдёт час-два + stackoverflow) незначительно на фоне времени, которое нужно, чтобы вникнуть в матчасть, и покрывается с лихвой, если другой язык — это язык заточенный под конкретную задачу, а то и DSL.
> это уже не клиент, ему доверять можно, поэтому достаточно продублировать валидацию на сервер-UI, чтобы не нагружать этим бизнес-логику вообще
На практике, если бекендщик не будет отбрасывать ошибочные запросы с объяснением что не так, то фронтендщики завалят багтрекер тикетами на «глючащий» бекенд, хотя ошибки на их стороне. Поэтому валидация на бекенде нужна, и не из-за паранои, а просто чтобы упростить всем жизнь, как автоматический судья, который решает, у кого бага.
> Авторизация — это щепотка бизнес-задачи (узнать, кто обратился)
Это аутентификация. Я имел в виду авторизацию, т.е. проверку имеет ли этот юзер права на чтение/изменение этих данных. Эта проверка нужна и фронтенду, чтобы попрятать кнопочки и ссылочки, и само-собой бекенду. Вот и дублирование кода.
Про модель, это отсылка к Meteor, где и клиент и сервер расшаривают одно и тоже описание модели. Нет больше этого плюса, если бекенд не на ноде.
Автор очень странный. Первый раз вижу сторонника ноды, который сам говорит, что нода не должна быть бекендом, а всего лишь прослойкой между бекендом и браузером.
Более того, нодовцы должны даже сильнее критиковать эту идею, чем бекендщики. Возьмём валидацию, где её надо делать? Ни один бекендщик не оставит валидацию клиентам, а с его точки зрения ui-backend на ноде — это уже клиент. Значит будет дублирование кода валидации на js и на языке бекенда. Тоже самое с моделью и с авторизацией. Опять дублируем кучу кода. Ассинхронность ноды тоже теперь не достоинство, она никак не поможет бекенду.
И вот единственный плюс от такой прослойки — это то, что бекендщики теперь не думают про REST и веб. Это важно, если у бекенда несколько клиентов, но в остальных случаях эту прослойку скорее всего просто вырежут бритвой Оккама.
Они ставили перед собой цель обеспечить «язык для склеивания» составляющих частей веб-ресурса: изображений, плагинов, Java-апплетов, который был бы удобен для веб-дизайнеров и программистов, не обладающих высокой квалификацией
> а уж переносить ее на backend — это чистой воды мазохизм
Вся горькая суть этого тезиса становится понятна, когда бекенд разработчик обнаруживает, что его либы, которые ещё фронтендщики используют, должны работать в FF, Chrome, IE7-9, а то и в IE6. В этот момент у него обычно появляется когнитивный диссонанс и вопросы к Всевышнему «Как это произошло? Почему я всю жизнь не лез в эти браузеры, и всё равно в конце-концов должен проверять код в осле???»
Из моего субъективного опыта (уже два кода проект на ноде), никто из чистых бекендщиков не рад ноде и js на сервере. Ему рады фронтендщики, которые теперь могут писать серверный код не изучая других языков.
> Наверное не совсем корректно сравнивать какие-то куски кода, вырванные из контекста.
Это не пожет :) Предлагаю просто закрыть вопрос про синтаксис. Перспективы не радужные: само существование CofeeScript и его популярность говорит о том, что людей, которые недовольны js, как языком, очень даже много, и мнения авторитетов вроде Дугласа Крокфорда им не помогают.
> Любое решение кроме Node.js имеет серьезные минусы.
Какие? Пока только одно было: разные языки на клиенте и сервере. А также какие серъёзные минусы есть у решения на ноде по сравнению с другими решениями?
> Но это всё равно не лишает Node.js уникальности — один код на клиенте и сервере.
Тут не буду спорить, не смотря на пример clojure + clojurescript ниже. Надо было так с самого начала, а не пытаться представить ассинхронность как что-то уникальное и инновационное, когда лет 20 назад мы все вешали колбеки на int 21h, а про потоки и локи даже не слышали.
P.S.: Ваш пример не тоже самое, что async.waterfall насколько я помню. В async, если step1() вернёт ошибку, то step2() уже не будет вызван. У вас даже err первым аргументом написан, но обработки нет.
Не у меня. Это вы так сформулировали первый миф: «Node.js — это то, что он не стабилен и запросы иногда теряются».
> На каком языке предлагаете писать? Во сколько раз он быстрее Си?
Что же вы так реагируете :) Я не наезжаю на ноду, просто критикую ваш стиль разрушителя мифов. Вам не кажется забавным, что во всём абзаце, который должен доказать, что нода быстра, сказано только то, что нода медленнее Си в 3-5 раз, и что там можно поднять миллион соединений (а это вообще не про скорость, а про память).
> Примеры ассинхронных конкурентов node.js в студию!
Вашим «уникальным» преимуществом, а именно: «обработка одного запроса не ждёт, пока обработается другой», обладает любой concurrent код, в том числе и многопоточные решения. Было бы странно, если бы не обладали, ведь это и есть смысл concurrent programming :)
> В данном случае «умелые руки» — это руки среднего программиста, имеющего некоторый опыт с node.js (месяц — два).
О да, конечно. Если использовать async.* и другие хитрости, для борьбы с колбеками, возможно такой код станет более или менее прост и красив, по сравнению с другом node-кодом, который эти фокусы не использует. Но стоит только выйти за рамки ноды, посмотреть, как это можно было бы сделать у конкурентов, и всё встанет на свои места. Например два ассинхронных куска кода.
C#
> Главный миф по поводу Node.js — это то, что он не стабилен и запросы иногда теряются. С появлением cluster и domain это больше не актуально.
Претензии к движку решаются с помощью двух модулей?
> Другой миф — Node.js медленный. Тут можно было бы сказать что v8 всего в 3-5 раз медленее Си
Оспариваете медленность утверждая, что он в 3-5 раз медленнее? :)
> Третий миф — это неминуемый Callback Hell. Ассинхронность Node.js — это его идеология и даёт ему уникальное преимущество: новому запросу не нужно ждать пока обработаются все запросы до него. Писать код в ассинхронной среде не совсем тоже самое, что в синхронной, это требует привычки. В умелых руках Node.js код — красив и прозрачен.
Кроме ассинхронных колбеков есть ещё пачка способов, как написать concurrent систему, когда одному коду не нужно ждать другой чтобы выполниться. Очень интересный выбор «уникального преимущества» :)
Ну а про умелые руки вообще хорошо. «Умелые руки» — это такие фантастические руки в которых и dll-ки не конфликтуют, и убунту на 6 версий обновляется сама и с первого раза, и КДЕ собирается под винду без ошибок. Только где бы их найти и сколько они стоят?
> Четвертый миф — это то, что JavaScript является не очень хорошим языком. Дуглас Крокфорд позволил себе не согласиться с этим утверждением.
Так себе опровержение. Если поискать, думаю можно устроить полноценный футбольный матч между именитыми сторонниками и противниками JS.
Вариант 1. Просто посчитали. Например, узнали сколько платит тот же Facebook и уменьшили награду в той же пропорции, в какой популярность Яху меньше популярности Фейсбука ;)
Варант 2. Это стратегическое решение. Специально выбрали смешную цену, чтобы не привлекать ещё больше хакеров к своему сервису. Чинить, наверное, всё равно не собираются, значит чем меньше людей ищут, тем лучше.
Всегда интересно было, почему минусуют за то, что кто-то чего-то не знает. Минус троллю или хаму понятен. Но за ошибку, сказанную нормально, без оскорблений и наездов? Вы сами никогда не ошибаетесь? Вы знаете всё?
В любой тюрьме кого ни спроси, все сидят из-за ошибки (с их слов): ни в ту квартиру забрался, помутнение разума, подговорили, ввели в заблуждение. Часть там сидит действительно из-за ошибки. Например, практически все ДТП произошли из-за ошибок водителей. Всех освободить?
Кроме того речь идёт не о СМИ, а о вирусной клевете в инете. Обязать всех, кто участвовал в распространении клеветы опубликовать опровержение?
Сидишь работаешь, никого не трогаешь, а тут раз какой-то мудак из ЖЖ нашел апартаменты в Майями на твоего тёску, ничего не проверил, ни в чём не убедился и побежал сразу публиковать с твоей фоткой.
И вот через день твоя фотка рядом с незнакомым домом на всех полосах, тебя уволили (просто чтобы сохранить репутацию, а не за дело), на твоего ребёнка плюют в школе, соседи мажут говном твою дверь.
Давайте разделять вред от неадекватной власти в нашей стране и вред от журналистики мнений. И то и то надо давить.
Журналиста всегда можно было нагнуть за клевету. Сейчас блоггеры подтягиваются по влиятельности к журналистам, а чем больше власти, тем больше ответственности. Вполне логичным будет, если и на них расширят ответственность за клевету.
Если не заморачиваться на адекватности срока, адекватности тех кто решает, клевета это или нет, и вообще на российских реалиях, журналистику мнений надо давить. И не только наказывать тех, кто умышленно звездит, но и учить критическому мышлению всех остальных, кто им верит.
Увижу ли я когда-нибудь на первом курсы критического мышления и манипуляции мнений с наглядными примерами из новостей на первом? :)
Это не поможет. Знание языка — это очень маленькая часть, от знаний, которые нужны специалисту в той или иной части проекта.
Даже если и там и там JS, фронтендщики не полезут в бекенд, а бекендщики не должны лезть в фронтенд. Они по разному пишут, по разному работают с колбеками (deffered vs async), разные ньюансы (DOM и браузеры vs node и concurrency), разные инструменты отладки, да вообще почти всё разное. Даже разные точки зрения на задачу: фичи и динамика vs стабильность и нагрузка. Бекендщику в фронтенде от знания js примерно столько же пользы, сколько гастроэнтерологу в стоматологии от знаний русского языка и латыни.
Так что время на изучение другого языка (после 10 языков на 11-ый уйдёт час-два + stackoverflow) незначительно на фоне времени, которое нужно, чтобы вникнуть в матчасть, и покрывается с лихвой, если другой язык — это язык заточенный под конкретную задачу, а то и DSL.
На практике, если бекендщик не будет отбрасывать ошибочные запросы с объяснением что не так, то фронтендщики завалят багтрекер тикетами на «глючащий» бекенд, хотя ошибки на их стороне. Поэтому валидация на бекенде нужна, и не из-за паранои, а просто чтобы упростить всем жизнь, как автоматический судья, который решает, у кого бага.
> Авторизация — это щепотка бизнес-задачи (узнать, кто обратился)
Это аутентификация. Я имел в виду авторизацию, т.е. проверку имеет ли этот юзер права на чтение/изменение этих данных. Эта проверка нужна и фронтенду, чтобы попрятать кнопочки и ссылочки, и само-собой бекенду. Вот и дублирование кода.
Про модель, это отсылка к Meteor, где и клиент и сервер расшаривают одно и тоже описание модели. Нет больше этого плюса, если бекенд не на ноде.
Более того, нодовцы должны даже сильнее критиковать эту идею, чем бекендщики. Возьмём валидацию, где её надо делать? Ни один бекендщик не оставит валидацию клиентам, а с его точки зрения ui-backend на ноде — это уже клиент. Значит будет дублирование кода валидации на js и на языке бекенда. Тоже самое с моделью и с авторизацией. Опять дублируем кучу кода. Ассинхронность ноды тоже теперь не достоинство, она никак не поможет бекенду.
И вот единственный плюс от такой прослойки — это то, что бекендщики теперь не думают про REST и веб. Это важно, если у бекенда несколько клиентов, но в остальных случаях эту прослойку скорее всего просто вырежут бритвой Оккама.
Ну надо же! Вот, оказывается, почему Интернет стал таким популярным.
Вся горькая суть этого тезиса становится понятна, когда бекенд разработчик обнаруживает, что его либы, которые ещё фронтендщики используют, должны работать в FF, Chrome, IE7-9, а то и в IE6. В этот момент у него обычно появляется когнитивный диссонанс и вопросы к Всевышнему «Как это произошло? Почему я всю жизнь не лез в эти браузеры, и всё равно в конце-концов должен проверять код в осле???»
Из моего субъективного опыта (уже два кода проект на ноде), никто из чистых бекендщиков не рад ноде и js на сервере. Ему рады фронтендщики, которые теперь могут писать серверный код не изучая других языков.
Это получается, у нас тут серебрянная пуля, технология без недостатков? А как же у каждой медали есть две стороны?
Это не пожет :) Предлагаю просто закрыть вопрос про синтаксис. Перспективы не радужные: само существование CofeeScript и его популярность говорит о том, что людей, которые недовольны js, как языком, очень даже много, и мнения авторитетов вроде Дугласа Крокфорда им не помогают.
Какие? Пока только одно было: разные языки на клиенте и сервере. А также какие серъёзные минусы есть у решения на ноде по сравнению с другими решениями?
Тут не буду спорить, не смотря на пример clojure + clojurescript ниже. Надо было так с самого начала, а не пытаться представить ассинхронность как что-то уникальное и инновационное, когда лет 20 назад мы все вешали колбеки на int 21h, а про потоки и локи даже не слышали.
P.S.: Ваш пример не тоже самое, что async.waterfall насколько я помню. В async, если step1() вернёт ошибку, то step2() уже не будет вызван. У вас даже err первым аргументом написан, но обработки нет.
Не у меня. Это вы так сформулировали первый миф: «Node.js — это то, что он не стабилен и запросы иногда теряются».
> На каком языке предлагаете писать? Во сколько раз он быстрее Си?
Что же вы так реагируете :) Я не наезжаю на ноду, просто критикую ваш стиль разрушителя мифов. Вам не кажется забавным, что во всём абзаце, который должен доказать, что нода быстра, сказано только то, что нода медленнее Си в 3-5 раз, и что там можно поднять миллион соединений (а это вообще не про скорость, а про память).
> Примеры ассинхронных конкурентов node.js в студию!
Вашим «уникальным» преимуществом, а именно: «обработка одного запроса не ждёт, пока обработается другой», обладает любой concurrent код, в том числе и многопоточные решения. Было бы странно, если бы не обладали, ведь это и есть смысл concurrent programming :)
> В данном случае «умелые руки» — это руки среднего программиста, имеющего некоторый опыт с node.js (месяц — два).
О да, конечно. Если использовать async.* и другие хитрости, для борьбы с колбеками, возможно такой код станет более или менее прост и красив, по сравнению с другом node-кодом, который эти фокусы не использует. Но стоит только выйти за рамки ноды, посмотреть, как это можно было бы сделать у конкурентов, и всё встанет на свои места. Например два ассинхронных куска кода.
C#
и node:
async.waterfall([ function step1(done) { func1(some_const, done); }, function step2(var1, done) { func2(some_const + var1, done); } ], final_callback);> Главный миф по поводу Node.js — это то, что он не стабилен и запросы иногда теряются. С появлением cluster и domain это больше не актуально.
Претензии к движку решаются с помощью двух модулей?
> Другой миф — Node.js медленный. Тут можно было бы сказать что v8 всего в 3-5 раз медленее Си
Оспариваете медленность утверждая, что он в 3-5 раз медленнее? :)
> Третий миф — это неминуемый Callback Hell. Ассинхронность Node.js — это его идеология и даёт ему уникальное преимущество: новому запросу не нужно ждать пока обработаются все запросы до него. Писать код в ассинхронной среде не совсем тоже самое, что в синхронной, это требует привычки. В умелых руках Node.js код — красив и прозрачен.
Кроме ассинхронных колбеков есть ещё пачка способов, как написать concurrent систему, когда одному коду не нужно ждать другой чтобы выполниться. Очень интересный выбор «уникального преимущества» :)
Ну а про умелые руки вообще хорошо. «Умелые руки» — это такие фантастические руки в которых и dll-ки не конфликтуют, и убунту на 6 версий обновляется сама и с первого раза, и КДЕ собирается под винду без ошибок. Только где бы их найти и сколько они стоят?
> Четвертый миф — это то, что JavaScript является не очень хорошим языком. Дуглас Крокфорд позволил себе не согласиться с этим утверждением.
Так себе опровержение. Если поискать, думаю можно устроить полноценный футбольный матч между именитыми сторонниками и противниками JS.
Варант 2. Это стратегическое решение. Специально выбрали смешную цену, чтобы не привлекать ещё больше хакеров к своему сервису. Чинить, наверное, всё равно не собираются, значит чем меньше людей ищут, тем лучше.
Кроме того речь идёт не о СМИ, а о вирусной клевете в инете. Обязать всех, кто участвовал в распространении клеветы опубликовать опровержение?
И вот через день твоя фотка рядом с незнакомым домом на всех полосах, тебя уволили (просто чтобы сохранить репутацию, а не за дело), на твоего ребёнка плюют в школе, соседи мажут говном твою дверь.
Давайте разделять вред от неадекватной власти в нашей стране и вред от журналистики мнений. И то и то надо давить.
Вот ещё о журналистике мнений и журналистике фактов: www.youtube.com/watch?v=P0X42gwEYM4
Если не заморачиваться на адекватности срока, адекватности тех кто решает, клевета это или нет, и вообще на российских реалиях, журналистику мнений надо давить. И не только наказывать тех, кто умышленно звездит, но и учить критическому мышлению всех остальных, кто им верит.
Увижу ли я когда-нибудь на первом курсы критического мышления и манипуляции мнений с наглядными примерами из новостей на первом? :)