Комментарии 78
Вы точно знаете что такое MVC? =)
Что именно вас смутило в моих словах?
Другие отказываются от MVC на клиенте в пользу MVC на сервере, жертвуя интерактивностью ради SEO.
Как связан паттерн MVC с SEO? Как связана с ним интерактивность?
Full-Stack фреймворки совмещают в себе всё лучшее MVC на сервере и MVC на клиенте, умножая это на преимущества использования одного языка
А здесь наверное стоит заменить MVC на фреймворк?
В последнее время практически все фрейсворки используют MVC. Можно было назвать их серверные фреймворки и клиентские фреймворки. Но я выбрал название «MVC на сервере» и «MVC на клиенте». Я думаю что в контексте структурирования кода это имеет право на жизнь.
Не будьте буквоедом. У вас по существу замечания есть?
Не будьте буквоедом. У вас по существу замечания есть?
Да вот же по существу:
Чем использование фреймворка с mvc на сервере противоречит использованию его на клиенте? И как интерактивность и SEO связаны с mvc?)
Другие отказываются от MVC на клиенте в пользу MVC на сервере, жертвуя интерактивностью ради SEO.
Чем использование фреймворка с mvc на сервере противоречит использованию его на клиенте? И как интерактивность и SEO связаны с mvc?)
Если вы генерируете html на сервере, то у вас всё хорошо с SEO, если на клиенте, то всё хорошо с интерактивностью. Не Full-Stack фреймворки обычно умеют либо одно, либо другое. Либо бо же вы используете два фреймворка: один на сервере, один на клиенте и пишите код два раза, в отличие от Full-Stack, где всё пишется только один раз.
Так а MVC-то тут причем? Я могу использовать MVC на клиенте, получая куски html с сервера и «проиграю в интерактивности». А могу, не используя паттерн MVC, создавать html на клиенте, «проигрывая в SEO».
А еще я могу (только тссс! никому не говорите!) использовать MVC безе всяких фреймворков — как на сервере, так и на клиенте.
Я соглашусь с nvbn, складывается впечатление, что Вы не видите разницы между фреймворками и паттерном MVC. Тем более, что упомянутый Вами Knockout.js использует MVVM паттерн, а не MVC.
И между делом
Четвертый миф — это то, что Full-Stack фреймворки еще сыроваты, не стабильны, испытвают проблемы произодительности при синхронизации данных. На данный момент есть несколько проектов в продакшене, находящихся под нагрузкой.
Тут бы ссылочки добавить или хотя бы перечислить, а то не очень убедительно.
А еще я могу (только тссс! никому не говорите!) использовать MVC безе всяких фреймворков — как на сервере, так и на клиенте.
Я соглашусь с nvbn, складывается впечатление, что Вы не видите разницы между фреймворками и паттерном MVC. Тем более, что упомянутый Вами Knockout.js использует MVVM паттерн, а не MVC.
И между делом
Четвертый миф — это то, что Full-Stack фреймворки еще сыроваты, не стабильны, испытвают проблемы произодительности при синхронизации данных. На данный момент есть несколько проектов в продакшене, находящихся под нагрузкой.
Тут бы ссылочки добавить или хотя бы перечислить, а то не очень убедительно.
Да. Я ждал вопрос про MVVM в этой ветке комментариев :-) Уже писал почему использую такую терминологию. Если поменять названия, суть статьи не изменится.
Тут вы найдете примеры продакшена. Неужели вы думаете что я вас обманываю?
Тут вы найдете примеры продакшена. Неужели вы думаете что я вас обманываю?
За примеры спасибо :)
же писал почему использую такую терминологию.
Если не сложно, повторите пожалуйста или отправьте меня туда, где это можно узнать. Очень интересно! Спасибо!
же писал почему использую такую терминологию.
Если не сложно, повторите пожалуйста или отправьте меня туда, где это можно узнать. Очень интересно! Спасибо!
Тут. Предлагаю закрыть эту ветку.
Если учесть, что твиттеру не впервой менять архитектуру, и то, что подобную архитектуру гораздо легче поддерживать, почему при всем при этом им не стоит тоже перейти на node/derby?
И да, позволю себе не согласиться с Дугласом Крокфордом.
И да, позволю себе не согласиться с Дугласом Крокфордом.
Спросите у них.
Когда они принимали решение перейти на Scala, Derby еще не было. Не уверен что они захотят еще раз всё переписывать.
Сама концепция Full-Stack появилась не так давно и еще не сильно популярна.
Дуглас Крокфорд смотрит на вас, как на человека не согласного с ним.
Когда они принимали решение перейти на Scala, Derby еще не было. Не уверен что они захотят еще раз всё переписывать.
Сама концепция Full-Stack появилась не так давно и еще не сильно популярна.
Дуглас Крокфорд смотрит на вас, как на человека не согласного с ним.
Я вот не очень знаком с преимуществами node перед другими языками в данной архитектуре. Не могли бы вы вкратце пояснить, почему всё тоже с серверной стороны нельзя сделать на той же скале? Я только один пример оптимизации видел, когда шаблонизатор на клиенте и сервере — одна и та же js-библиотека, но не вижу пока серьезных причин, почему нельзя сделать так, чтобы на клиенте и на сервере за работу шаблонизатора отвечали библиотеки на разных языках.
А на счет javascript, не понимаю, как можно всерьез его сравнивать опять же со скалой по качеству кода, когда статических проверок этого самого кода меньше чем в php, который, как известно, не является эталоном для подражания и ни одна компания в здравом уме не сменит java/scala на php.
А на счет javascript, не понимаю, как можно всерьез его сравнивать опять же со скалой по качеству кода, когда статических проверок этого самого кода меньше чем в php, который, как известно, не является эталоном для подражания и ни одна компания в здравом уме не сменит java/scala на php.
Шаблонизатор, роутер, модель для работы с данными — значительная часть фреймворка. Написать и поддерживать это на двух языках значительно сложнее. Преимущества сомнительны (утверждение что Scala лучше для этого подходит, чем JavaScript — субъективно). В то же время в статье написаны преимущества использования одного языка на сервере и клиенте.
Но разве они не через api взаимодействуют? И разве есть какая-то разница, на чем это api написано? Я вот сейчас интересуюсь этим, т.к. не до конца представляю архитектуру full-stack и почему (благодяря каким особенностям реализации) это дает выигрышь по трудозатратам.
Обсуждать языки думаю смысла нет, т.к. есть объективные показатели, по которым хорошо реализованная статическая типизация превосходит динамическую.
Обсуждать языки думаю смысла нет, т.к. есть объективные показатели, по которым хорошо реализованная статическая типизация превосходит динамическую.
Я имею ввиду что значительная часть кода Full-Stack фреймворка выполняется и на клиенте и на сервере. Это возможно только если использовать Node.js. Так же значительная часть вашего кода, когда вы используете Full-Stack, выполняется и на клиенте и на сервере. Преимущество этого — повторное использование кода. Вам не надо два раза писать одно и тоже.
Я пытаюсь представить, какой код пересекается на клиенте и сервере, и на ум приходит только валидация передаваемых данных. На клиенте при этом вся интерактивщина и визуальные эффекты, на сервере сохранения данных в БД и извлечение оттуда. Но ведь во многих фреймворках по идее можно писать валидацию только на серверном языке, а на клиенте она будет сгенерирована автоматически. И при таком раскладе я не вижу преимущества в одном языке на обеих сторонах.
Есть правда ещё вариант, когда происходит вызов удаленных процедур (RPC), но мне это всегда казалось сомнительной практикой. Хотя опять же в некоторых фреймворках для этих целей происходит трансляция с серверного языка в клиентский. Но здесь node выигрывает, т.к. ничего транслировать не нужно.
А для чего ещё может потребоваться один язык на обеих сторонах?
Есть правда ещё вариант, когда происходит вызов удаленных процедур (RPC), но мне это всегда казалось сомнительной практикой. Хотя опять же в некоторых фреймворках для этих целей происходит трансляция с серверного языка в клиентский. Но здесь node выигрывает, т.к. ничего транслировать не нужно.
А для чего ещё может потребоваться один язык на обеих сторонах?
Все части фреймворка, которые используются на клиенте и на сервере я перечислил. К ним вы можете добавить ваш код, который их использует. Это значительная часть как фреймворка, так и вашего кода. Ваши представления об архитектуре Full-Stack фреймворков полны заблуждений. Я не могу вам быстро и в двух словах объяснить как на самом деле, ибо это другая парадигма. Рекомендую почитать материалы о Derby.
Ну собственно я и сам сказал, что мои представления о full-stack далеки от идеальных. Просто надеялся в комментариях выяснить, почему же фреймворки на разных языках не позволяют добиться той же производительности. Derby меня конечно заинтересовал и как-нибудь о нем я почитаю, однако пока на практике его применить негде как раз из-за необходимости в node.js, поэтому познание будет скорее теоретическое.
Ну тогда уже лучше, пожалуй, на Erlang. ))
Нет, ребята, тут без вариантов. Только Node.js.
В заголовке Angular и Derby, в статье MVC на клиенте и Full-Stack. Непонятно раз.
Сравниваем два совершенно разных подхода, каждый со своими плюсами и минусами и делаем однозначные выводы. Непонятно два.
З.Ы. Мне лично очень интересны Full-Stack фреймворки, но я пока не вижу реального им применения в моих задачах.
Сравниваем два совершенно разных подхода, каждый со своими плюсами и минусами и делаем однозначные выводы. Непонятно два.
З.Ы. Мне лично очень интересны Full-Stack фреймворки, но я пока не вижу реального им применения в моих задачах.
Angular — самый модный MVC на клиенте фреймворк. Derby — яркий представитель Full-Stack. Заголовок привлекает внимание, но не оторван от статьи.
В чем вы видите плюсы MVC на клиенте и минусы Full-Stack?
В чем вы видите плюсы MVC на клиенте и минусы Full-Stack?
Плюсы MVC на клиенте в сравнение с чем? С plain javascript? Они и так очевидны: модульность, простота реализации, управляемость.
Да Full-Stack это прекрасно, да он позволяет (теоретически) уменьшить дублирование кода, да он удобен. Но все это только для новых проектов.
Если у меня есть живой проект с любым серверным фреймворком и plain javascrpipt на клиенте, я могу упростить себе жизнь интегрировав любой клиентский MVC фреймворк и минимально затронув серверную часть. Для Full-Stack мне придется написать все с нуля.
Да Full-Stack это прекрасно, да он позволяет (теоретически) уменьшить дублирование кода, да он удобен. Но все это только для новых проектов.
Если у меня есть живой проект с любым серверным фреймворком и plain javascrpipt на клиенте, я могу упростить себе жизнь интегрировав любой клиентский MVC фреймворк и минимально затронув серверную часть. Для Full-Stack мне придется написать все с нуля.
Я вот вообще не вижу плюсов MVC на клиенте. Я сейчас специально зашел в GMAIL, открыл FIREBUG, и поклацал на разные кнопочки. Это ужас просто, что показывает консоль. Десятки бессмысленных для меня запросов на сервер. При чем первые нажатия пунктов меню все равно сначала шлют что-то на сервер, а потом меняется состояние приложения.
Я каждый день по нескольку раз в день захожу проверить почту и каждый раз я скачиваю тонны кода. Иногда я получив новые письма читаю их, иногда новых писем и нет вовсе. Мне нужно то отобразить список писем, при необходимости просмотреть их, иногда ответить. Действий — на пальцах посчитать. Загруженных килобайт — не больше сотни, за сеанс работы. Но тонны кода я скачиваю себе в браузер из раза в раз. Это по вашему правильное приложение?
Большинство пользователей хотят поменьше кликов для доступа к информации, чтобы ничего не глючило, не тормозило и было предсказуемым. И это всё.
Вы же, как я понял, можете предложить лишь более быстрый отклик приложения, чем обычные 200 — 300 милисекунд. Больше вам предложить пользователю нечего. Все остальное делает работу с приложениями только хуже. Десятки непонятных запросов на сервер, тонны такого же непонятного кода, вы нагружаете наши компьютеры, а мы просто хотели зайти посмотреть не пришло ли письмо от Макса.
Я каждый день по нескольку раз в день захожу проверить почту и каждый раз я скачиваю тонны кода. Иногда я получив новые письма читаю их, иногда новых писем и нет вовсе. Мне нужно то отобразить список писем, при необходимости просмотреть их, иногда ответить. Действий — на пальцах посчитать. Загруженных килобайт — не больше сотни, за сеанс работы. Но тонны кода я скачиваю себе в браузер из раза в раз. Это по вашему правильное приложение?
Большинство пользователей хотят поменьше кликов для доступа к информации, чтобы ничего не глючило, не тормозило и было предсказуемым. И это всё.
Вы же, как я понял, можете предложить лишь более быстрый отклик приложения, чем обычные 200 — 300 милисекунд. Больше вам предложить пользователю нечего. Все остальное делает работу с приложениями только хуже. Десятки непонятных запросов на сервер, тонны такого же непонятного кода, вы нагружаете наши компьютеры, а мы просто хотели зайти посмотреть не пришло ли письмо от Макса.
Я думаю для таких консерваторов как вы еще остались статичные почтовые клиенты. Зачем же каждый день себя мучить?
А зачем вам вообще веб-интерфейс? Ведь можно использовать тот же Mozilla Thunderbird.
Прости меня за любопытство, но где Вы увидели прямую связь между «тоннами кода» и MVC паттерном? Вы думаете, что будь клиент написан без применения MVC, размер исходных файлов бы сократился?
НЛО прилетело и опубликовало эту надпись здесь
Кто же вас так учил мифы оспаривать ;)
> Главный миф по поводу Node.js — это то, что он не стабилен и запросы иногда теряются. С появлением cluster и domain это больше не актуально.
Претензии к движку решаются с помощью двух модулей?
> Другой миф — Node.js медленный. Тут можно было бы сказать что v8 всего в 3-5 раз медленее Си
Оспариваете медленность утверждая, что он в 3-5 раз медленнее? :)
> Третий миф — это неминуемый Callback Hell. Ассинхронность Node.js — это его идеология и даёт ему уникальное преимущество: новому запросу не нужно ждать пока обработаются все запросы до него. Писать код в ассинхронной среде не совсем тоже самое, что в синхронной, это требует привычки. В умелых руках Node.js код — красив и прозрачен.
Кроме ассинхронных колбеков есть ещё пачка способов, как написать concurrent систему, когда одному коду не нужно ждать другой чтобы выполниться. Очень интересный выбор «уникального преимущества» :)
Ну а про умелые руки вообще хорошо. «Умелые руки» — это такие фантастические руки в которых и dll-ки не конфликтуют, и убунту на 6 версий обновляется сама и с первого раза, и КДЕ собирается под винду без ошибок. Только где бы их найти и сколько они стоят?
> Четвертый миф — это то, что JavaScript является не очень хорошим языком. Дуглас Крокфорд позволил себе не согласиться с этим утверждением.
Так себе опровержение. Если поискать, думаю можно устроить полноценный футбольный матч между именитыми сторонниками и противниками JS.
> Главный миф по поводу Node.js — это то, что он не стабилен и запросы иногда теряются. С появлением cluster и domain это больше не актуально.
Претензии к движку решаются с помощью двух модулей?
> Другой миф — Node.js медленный. Тут можно было бы сказать что v8 всего в 3-5 раз медленее Си
Оспариваете медленность утверждая, что он в 3-5 раз медленнее? :)
> Третий миф — это неминуемый Callback Hell. Ассинхронность Node.js — это его идеология и даёт ему уникальное преимущество: новому запросу не нужно ждать пока обработаются все запросы до него. Писать код в ассинхронной среде не совсем тоже самое, что в синхронной, это требует привычки. В умелых руках Node.js код — красив и прозрачен.
Кроме ассинхронных колбеков есть ещё пачка способов, как написать concurrent систему, когда одному коду не нужно ждать другой чтобы выполниться. Очень интересный выбор «уникального преимущества» :)
Ну а про умелые руки вообще хорошо. «Умелые руки» — это такие фантастические руки в которых и dll-ки не конфликтуют, и убунту на 6 версий обновляется сама и с первого раза, и КДЕ собирается под винду без ошибок. Только где бы их найти и сколько они стоят?
> Четвертый миф — это то, что JavaScript является не очень хорошим языком. Дуглас Крокфорд позволил себе не согласиться с этим утверждением.
Так себе опровержение. Если поискать, думаю можно устроить полноценный футбольный матч между именитыми сторонниками и противниками JS.
Претензии к движку решаются с помощью двух модулей?
Какие у вас претензии к движку?
Оспариваете медленность утверждая, что он в 3-5 раз медленнее? :)
На каком языке предлагаете писать? Во сколько раз он быстрее Си?
Кроме ассинхронных колбеков есть ещё пачка способов, как написать concurrent систему, когда одному коду не нужно ждать другой чтобы выполниться. Очень интересный выбор «уникального преимущества» :)
Примеры ассинхронных конкурентов node.js в студию!
Ну а про умелые руки вообще хорошо. «Умелые руки» — это такие фантастические руки в которых и dll-ки не конфликтуют, и убунту на 6 версий обновляется сама и с первого раза, и КДЕ собирается под винду без ошибок. Только где бы их найти и сколько они стоят?
В данном случае «умелые руки» — это руки среднего программиста, имеющего некоторый опыт с node.js (месяц — два).
Так себе опровержение. Если поискать, думаю можно устроить полноценный футбольный матч между именитыми сторонниками и противниками JS.
Я конечно люблю футбол, и на такую игру с удовольствием бы посмотрел, но давайте не будем устраивать холиваров :-)
> Какие у вас претензии к движку?
Не у меня. Это вы так сформулировали первый миф: «Node.js — это то, что он не стабилен и запросы иногда теряются».
> На каком языке предлагаете писать? Во сколько раз он быстрее Си?
Что же вы так реагируете :) Я не наезжаю на ноду, просто критикую ваш стиль разрушителя мифов. Вам не кажется забавным, что во всём абзаце, который должен доказать, что нода быстра, сказано только то, что нода медленнее Си в 3-5 раз, и что там можно поднять миллион соединений (а это вообще не про скорость, а про память).
> Примеры ассинхронных конкурентов node.js в студию!
Вашим «уникальным» преимуществом, а именно: «обработка одного запроса не ждёт, пока обработается другой», обладает любой concurrent код, в том числе и многопоточные решения. Было бы странно, если бы не обладали, ведь это и есть смысл concurrent programming :)
> В данном случае «умелые руки» — это руки среднего программиста, имеющего некоторый опыт с node.js (месяц — два).
О да, конечно. Если использовать async.* и другие хитрости, для борьбы с колбеками, возможно такой код станет более или менее прост и красив, по сравнению с другом node-кодом, который эти фокусы не использует. Но стоит только выйти за рамки ноды, посмотреть, как это можно было бы сделать у конкурентов, и всё встанет на свои места. Например два ассинхронных куска кода.
C#
и node:
Не у меня. Это вы так сформулировали первый миф: «Node.js — это то, что он не стабилен и запросы иногда теряются».
> На каком языке предлагаете писать? Во сколько раз он быстрее Си?
Что же вы так реагируете :) Я не наезжаю на ноду, просто критикую ваш стиль разрушителя мифов. Вам не кажется забавным, что во всём абзаце, который должен доказать, что нода быстра, сказано только то, что нода медленнее Си в 3-5 раз, и что там можно поднять миллион соединений (а это вообще не про скорость, а про память).
> Примеры ассинхронных конкурентов node.js в студию!
Вашим «уникальным» преимуществом, а именно: «обработка одного запроса не ждёт, пока обработается другой», обладает любой concurrent код, в том числе и многопоточные решения. Было бы странно, если бы не обладали, ведь это и есть смысл concurrent programming :)
> В данном случае «умелые руки» — это руки среднего программиста, имеющего некоторый опыт с node.js (месяц — два).
О да, конечно. Если использовать async.* и другие хитрости, для борьбы с колбеками, возможно такой код станет более или менее прост и красив, по сравнению с другом node-кодом, который эти фокусы не использует. Но стоит только выйти за рамки ноды, посмотреть, как это можно было бы сделать у конкурентов, и всё встанет на свои места. Например два ассинхронных куска кода.
C#
var1 = await func1(some_const) var2 = await func2(some_const + var1)
и node:
async.waterfall([
function step1(done) {
func1(some_const, done);
},
function step2(var1, done) {
func2(some_const + var1, done);
}
], final_callback);
Надеюсь, что наш диалог, как раз поможет тем, у кого остались вопросы.
За примеры ассинхронных платформ всем спасибо. Но это всё равно не лишает Node.js уникальности — один код на клиенте и сервере.
Кстати, кто-нибудь может объяснить как у них решается проблема с уже существующей базой синхронного кода? Для Node.js все модули были написаны с нуля и с учетом ассинхронности.
Я как раз раньше писал на C#. Не для холивара, а просто субъективно, на JavaScript в целом писать удобнее и кода получается меньше. Хотя как вы правильно сказали, в данном случае C#, наверное, красивее. А это CoffeeScript, например:
За примеры ассинхронных платформ всем спасибо. Но это всё равно не лишает Node.js уникальности — один код на клиенте и сервере.
Кстати, кто-нибудь может объяснить как у них решается проблема с уже существующей базой синхронного кода? Для Node.js все модули были написаны с нуля и с учетом ассинхронности.
func1(some_const, function(err) {
func2(some_const + var1, final_callback);
});
Я как раз раньше писал на C#. Не для холивара, а просто субъективно, на JavaScript в целом писать удобнее и кода получается меньше. Хотя как вы правильно сказали, в данном случае C#, наверное, красивее. А это CoffeeScript, например:
func1 some_const, (err) ->
func2 some_const + var1, final_callback
> Но это всё равно не лишает Node.js уникальности — один код на клиенте и сервере.
Тут не буду спорить, не смотря на пример clojure + clojurescript ниже. Надо было так с самого начала, а не пытаться представить ассинхронность как что-то уникальное и инновационное, когда лет 20 назад мы все вешали колбеки на int 21h, а про потоки и локи даже не слышали.
P.S.: Ваш пример не тоже самое, что async.waterfall насколько я помню. В async, если step1() вернёт ошибку, то step2() уже не будет вызван. У вас даже err первым аргументом написан, но обработки нет.
Тут не буду спорить, не смотря на пример clojure + clojurescript ниже. Надо было так с самого начала, а не пытаться представить ассинхронность как что-то уникальное и инновационное, когда лет 20 назад мы все вешали колбеки на int 21h, а про потоки и локи даже не слышали.
P.S.: Ваш пример не тоже самое, что async.waterfall насколько я помню. В async, если step1() вернёт ошибку, то step2() уже не будет вызван. У вас даже err первым аргументом написан, но обработки нет.
Можно использовать другие ассинхронные фреймворки, но тогда не будет одного кода на клиенте и сервере. Можно использовать clojure + clojurescript, но тогда будет абстрагированность от веб технологий. Любое решение кроме Node.js имеет серьезные минусы.
Я согласен с вашим замечанием по коду. Наверное не совсем корректно сравнивать какие-то куски кода, вырванные из контекста.
Я согласен с вашим замечанием по коду. Наверное не совсем корректно сравнивать какие-то куски кода, вырванные из контекста.
> Любое решение кроме Node.js имеет серьезные минусы.
Какие? Пока только одно было: разные языки на клиенте и сервере. А также какие серъёзные минусы есть у решения на ноде по сравнению с другими решениями?
Какие? Пока только одно было: разные языки на клиенте и сервере. А также какие серъёзные минусы есть у решения на ноде по сравнению с другими решениями?
Какие? Пока только одно было: разные языки на клиенте и сервере.
Я же сказал. Если не это, то в случае clojure + clojurescript, GWT, Cappuccino — абстрагированность от веб-технологий.
А также какие серъёзные минусы есть у решения на ноде по сравнению с другими решениями?
Лично я не вижу серьезных минусов. Но если вы знаете такие, поделитесь с нами.
> Наверное не совсем корректно сравнивать какие-то куски кода, вырванные из контекста.
Это не пожет :) Предлагаю просто закрыть вопрос про синтаксис. Перспективы не радужные: само существование CofeeScript и его популярность говорит о том, что людей, которые недовольны js, как языком, очень даже много, и мнения авторитетов вроде Дугласа Крокфорда им не помогают.
Это не пожет :) Предлагаю просто закрыть вопрос про синтаксис. Перспективы не радужные: само существование CofeeScript и его популярность говорит о том, что людей, которые недовольны js, как языком, очень даже много, и мнения авторитетов вроде Дугласа Крокфорда им не помогают.
Примеры ассинхронных конкурентов node.js в студию!
ReactPHP — Event-driven, non-blocking I/O with PHP.
Тут ответил.
Примеры ассинхронных конкурентов node.js в студию!
Tornado
Правда я уже переписал код с торнадо на ноду :)
Тут ответил.
Боюсь показаться грубым, но автор выложил статью что бы её и оценили тоже. Так вот по мне так — статья вообще ни о чём.
Заголовок сам по себе, содержание само по себе. Кусками напиханы разные утверждения, а по сути — переливание из пустого в порожное. Привлечь внимание это, конечно же, важно, но заголовок надо развивать, а не просто написать что бы было. С тем же успехом можно было, для привлечения внимания, оставить картинку с котиками.
Заголовок сам по себе, содержание само по себе. Кусками напиханы разные утверждения, а по сути — переливание из пустого в порожное. Привлечь внимание это, конечно же, важно, но заголовок надо развивать, а не просто написать что бы было. С тем же успехом можно было, для привлечения внимания, оставить картинку с котиками.
Здесь уже был вопрос к заголовку.
Сравнивать Angular и Derby не корректно. Нужно сравнивать концепции.
Если у вас есть какие-то замечания к сути статьи, поделитесь с нами. Давайте подискуссируем.
Сравнивать Angular и Derby не корректно. Нужно сравнивать концепции.
Если у вас есть какие-то замечания к сути статьи, поделитесь с нами. Давайте подискуссируем.
Здесь так же есть дискуссия и ни одна по сути статьи.
Моя претензия, возможно, покажется вам неконструктивной, но моё мнение что заголовок, помимо привлечения внимания, обязан иметь развитие в тексте. То что я увидел — яркий заголовок, и первым же предложением «отмазка» что сравниваться будет не то что в заголовке, а используемые подходы в этих двух библиотеках. Тогда уж можно было бы всю статью заменить вашей же фразой «Сравнивать Angular и Derby не корректно».
Моя претензия, возможно, покажется вам неконструктивной, но моё мнение что заголовок, помимо привлечения внимания, обязан иметь развитие в тексте. То что я увидел — яркий заголовок, и первым же предложением «отмазка» что сравниваться будет не то что в заголовке, а используемые подходы в этих двух библиотеках. Тогда уж можно было бы всю статью заменить вашей же фразой «Сравнивать Angular и Derby не корректно».
Здесь я уже некоректно сравнивал Angular и Derby.
Корректное же сравнение этих фреймворков лежит через сравнение концепций MVC на клиенте и Full-Stack. Возможно это немножко сложнее, чем хочется. Но тут ничего не поделать. Такова жизнь.
Считаю что заголовок вполне удачный. Он же смог, например, привлечь ваше внимание.
Корректное же сравнение этих фреймворков лежит через сравнение концепций MVC на клиенте и Full-Stack. Возможно это немножко сложнее, чем хочется. Но тут ничего не поделать. Такова жизнь.
Считаю что заголовок вполне удачный. Он же смог, например, привлечь ваше внимание.
Как раз это сравнение посмотрел с удовольствием. Что снаружи (в заголовке), то и внутри. И можно очень быстро составить первое представление чем одна библиотека (фреймоворк) отличатся от другой. А дальше каждый сам решит нужны ли ему более академические знания, чем фреймворк на клиенте отличается от full-stack фреймворка.
ИМХО, Clojure+ClojureScript — гораздо более правильный FullStack чем node.js + что угодно на js.
Здесь я называю такие фреймворки кросс-компилируемыми. В целом это плохая практика, так как абстрагирует от веб-технологий.
Непонятно, что вы имеете ввиду под «абстрагированием» от веб-технологий. В кложуре идет работа с request, response, session, cookies — полный http стек (В том же джава и пайтон все тоже самое). В кложур скрипт работает с тем же самым DOM только используется lisp-образный синтаксис. Никакой абстракции нет. JavaScript на клиенте — это не самая приятная вещь, а уж переносить ее на backend — это чистой воды мазохизм.
Я имею ввиду что всё api в браузере — это js. И чтобы использовать его на другом языке, нужно этот язык перекомпилировать в js. Это и есть абстрагирование.
Приятно / не приятно — это субъективно.
Приятно / не приятно — это субъективно.
> а уж переносить ее на backend — это чистой воды мазохизм
Вся горькая суть этого тезиса становится понятна, когда бекенд разработчик обнаруживает, что его либы, которые ещё фронтендщики используют, должны работать в FF, Chrome, IE7-9, а то и в IE6. В этот момент у него обычно появляется когнитивный диссонанс и вопросы к Всевышнему «Как это произошло? Почему я всю жизнь не лез в эти браузеры, и всё равно в конце-концов должен проверять код в осле???»
Из моего субъективного опыта (уже два кода проект на ноде), никто из чистых бекендщиков не рад ноде и js на сервере. Ему рады фронтендщики, которые теперь могут писать серверный код не изучая других языков.
Вся горькая суть этого тезиса становится понятна, когда бекенд разработчик обнаруживает, что его либы, которые ещё фронтендщики используют, должны работать в FF, Chrome, IE7-9, а то и в IE6. В этот момент у него обычно появляется когнитивный диссонанс и вопросы к Всевышнему «Как это произошло? Почему я всю жизнь не лез в эти браузеры, и всё равно в конце-концов должен проверять код в осле???»
Из моего субъективного опыта (уже два кода проект на ноде), никто из чистых бекендщиков не рад ноде и js на сервере. Ему рады фронтендщики, которые теперь могут писать серверный код не изучая других языков.
В общем, да. Плюс синтаксис у js и конструкции, мягко говоря, не очень. Он как бы изначально не задумывался как взрослый язык, а когда потребовалось его таким сделать — он оброс костылями. А теперь это еще и на сервер сайд пытаются перенести. Грустно.
Пруфы в студию — где создатели языка говорят, что задумывали js детским языком?
Чего взрослого вам там не хватало раньше?
Какие именно костыли вы в нем видите сейчас?
Чего взрослого вам там не хватало раньше?
Какие именно костыли вы в нем видите сейчас?
Они ставили перед собой цель обеспечить «язык для склеивания» составляющих частей веб-ресурса: изображений, плагинов, Java-апплетов, который был бы удобен для веб-дизайнеров и программистов, не обладающих высокой квалификациейru.wikipedia.org/wiki/JavaScript#JavaScript
Может быть автор меня сейчас закидает камнями, но я не верю в идею универсальности платформы/языка. Поэтому сам по себе подход Full-Stack обречен на провал. НЕ существует платформы/языка, который покроет все мои «хотелки». Не существует языка/платформы/технологии которая умеет все. Я за то, что бы мое приложение было написано с использованием тех технологий/платформ/языков, которые сейчас подходят лучше всего для решения моей задачи, будь то клиент или сервер.
И да, JavaScript отстой, это мое мнение.
И да, JavaScript отстой, это мое мнение.
Cluster: Stability: 1 — Experimental
Domain: Stability: 2 — Unstable
Мифы то не беспочвенны :)
Domain: Stability: 2 — Unstable
Мифы то не беспочвенны :)
А есть сборки Дерби с Ангуляром в качестве фронтэнда? Все-таки фронтендская часть в Ангуляре намного более развита
Дерби с ангуляром в качестве фронтенда, это rails + angular. Посмотрите github.com/hiravgandhi/angularjs-rails — это пример сопряжения. Пару месяцев назад, я смотрел, тогда были проблемы — я им issue запостил. И вроде бы они все поправили. Ага. Вот глянул — довольно много обновлений в последнее время. Может быть все ОК.
Если будете смотреть и тестить, не сочтите за труд — отпишитесь здесь.
Если будете смотреть и тестить, не сочтите за труд — отпишитесь здесь.
Вы, наверно, имеете ввиду Racer + Angular. Тут что-то обсуждали такое.
А чего вам не хватает в Derby, то что есть в Angular?
А чего вам не хватает в Derby, то что есть в Angular?
> А чего вам не хватает в Derby, то что есть в Angular?
Наверное, ему придется сначала Derby изучить, чтобы ответить на этот вопрос :)
Наверное, ему придется сначала Derby изучить, чтобы ответить на этот вопрос :)
Так и есть) Да и после просмотра документации что по Дерби, что по Метеору создалось впечатление, что разработчики просто забили на фронтенд. Ангулярцы же проделали огромную работу, создали крутую модульную архитектуру, написали десятки директив, сделали всё, чтобы ты просто сел и начал писать, не заморачиваясь с биндингами, вилидацией, кроссбраузерностью и т.п. Стоит ли менять все это на упрощение клиент-серверного взаимодействия, которое и так не очень сложное?
На сколько я понял директивы в Англуляр используются, чтобы создать независимые объекты (компоненты) и добавить им поведение. Так? Вот пример синтаксиса компонентов в Дерби 0.6.
Не хватает продуманного фронтенда, директив и проч., чего, думаю, никогда в Дерби не будет, т.к. у них нет 40 человек из Гугла, разрабатывающих фронтендскую часть) Они не планируют объединиться? С их ресурсами был бы хороший вариант расширить Ангуляр методами взаимодействия с сервером и заняться вплотную бекэндом. У Метеора, кстати, подобные сборки есть
> У Метеора, кстати, подобные сборки есть
Чё серьезно? Я что-то порылся в ветках и тагах и не нашел. Можно ткнуть носом?
Чё серьезно? Я что-то порылся в ветках и тагах и не нашел. Можно ткнуть носом?
Например: atmosphere.meteor.com/package/angularjs (https://github.com/lvbreda/Meteor_angularjs)
Еще-какие-то примеры интеграции видел
github.com/bevanhunt/meteor-angular-leaderboard и т.п.
Еще-какие-то примеры интеграции видел
github.com/bevanhunt/meteor-angular-leaderboard и т.п.
-
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Angular vs Derby. Должен остаться только один