Comments 107
Еще есть такой вариант как AngularJS + SailsJS. Sails неплохо выглядит последнее время.
Если назвать одним словом: модный, сладкий, превосходный— мнение твое :)?
Как я понял на текущий момент у derby тоже в качестве бд только mongo, для всего остального нужно еще писать адаптеры (хотя и простые), но все же — так ли это?
Конечно моё. Не стоит серьезно к этому относиться.
Да. В данный момент у derby.js есть адаптер только для Mongo DB. Написать другие адаптеры как ты правильно сказал не сложно. Адаптер выглядит буквально вот так
У Метеора тоже пока с адаптерами не густо, но можно написать. Другое дело что api будет всё равно Mongo Queries.
Да. В данный момент у derby.js есть адаптер только для Mongo DB. Написать другие адаптеры как ты правильно сказал не сложно. Адаптер выглядит буквально вот так
У Метеора тоже пока с адаптерами не густо, но можно написать. Другое дело что api будет всё равно Mongo Queries.
Как показывает мировая практика — коммьюнити решает. На остальное можно закрыть_глаза/найти_решение. Thus, Angular rules.
Коммьюнити — это такая штука: сегодня нету, завтра есть. Как раз этим и занимаюсь.
Да, вы правы, не всегда популярными становятся лучшие технологии.
Да, вы правы, не всегда популярными становятся лучшие технологии.
UFO just landed and posted this here
Я не сказал умирает. Я сказал появляется. У всех проектов в начале не было коммьюнити. Через какое-то время появилось. Да люди инертны. Даже программисты. Так устроен наш мозг. Это не хорошо и не плохо. Если человек пишет на AngularJS, то его сложно переманить на derby, например. Даже если ему доказать что derby лучше, он всё равно найдет причину остаться на Angular (например, скажет что там коммьюнити больше). Но для людей, которые только начинают писать на node.js выбор фреймворка довольно актуален. Тут большое не паханное поле.
И чтобы вы меня не поняли неправильно. Я не преследую ни каких прямых личных интересов. Я просто идейный. Просто верю что derby лучше. Хочу чтобы он развивался.
И чтобы вы меня не поняли неправильно. Я не преследую ни каких прямых личных интересов. Я просто идейный. Просто верю что derby лучше. Хочу чтобы он развивался.
Я позволю с вами не согласиться — коммьюнити не всегда инертно. IT — среда, в которой люди способны думать и анализировать. Способны выбирать и прогнозировать. Это вам не фейсбук и вконтакт — тут все серьезно. Неполучится вот так вот взять, и одной статьей привить людям любовь навсегда. И тому есть много примеров фейлов и винов, но, дабы не разводить холиваров, я не стану их упоминать здесь.
Да ну конечно. То есть ни капли популярности анагуляру не прибавил факт того, кто его разработал?
Хотя думаю автору стоит добавить в табличку «легкость смены бекенда», метеор и дерби явно завязаны на ноду, в отличии от анагуляра
Хотя думаю автору стоит добавить в табличку «легкость смены бекенда», метеор и дерби явно завязаны на ноду, в отличии от анагуляра
По поводу инертности IT-среды, я вам советую посмотреть лекции Дугласа Крокфорда. Не всегда люди способны выбирать и прогнозировать. Чаще каждый хвалит свой язык / свою платформу.
Я не надеюсь вправить любовь одной статьей. Мое дело просто посеять семя сомнения.
Я не надеюсь вправить любовь одной статьей. Мое дело просто посеять семя сомнения.
очень интересуюсь направлением разработки веб-клиентов корпоративных приложений с .net на серверной стороне.
Некоторых вещей ещё до конца не вкурил, поэтому хочу поинтересоваться по пункту: «Обновление приложения без перезагрузки». В случае с angular подразумевается, что нужно самому городить механизмы обновления например с помощью singalr ну или по старинке ajax? А в случае с meteor и derby имеется ввиду подгрузка partal'ов на html+css?
Некоторых вещей ещё до конца не вкурил, поэтому хочу поинтересоваться по пункту: «Обновление приложения без перезагрузки». В случае с angular подразумевается, что нужно самому городить механизмы обновления например с помощью singalr ну или по старинке ajax? А в случае с meteor и derby имеется ввиду подгрузка partal'ов на html+css?
и вдовесок: поделитесь, из личного опыта, для интранетовских приложений какой фреймворк (или связку) порекомендовали бы? Предполагается, что будет использоваться на server-side именно .net, ибо много наработок, которые не хочется терять, а использовать повторно
Вопрос, наверное, к топикстартеру, но все равно отвечу.
Ну, на самом деле, клиентский фреймворк — такое себе дело вкуса. Здесь, в отличие от каждой серверной платформы, нет однозначного мега-фаворита (есть просто те, что постарше и проверены временем). Радует, что есть много действительно качественных. По опыту, не вдаваясь в особые детали, посоветовал бы однозначно освоить Angular.js, очень нелишним будет Ember.js и разобраться в том, как работает Backbone.js (+Marionette.js). Тогда можно будет выбрать себе по вкусу. Angular позволяет очень быстро решать задачи, благодаря тому, что он очень целостный (хотя у него немного странная терминология). Backbone очень гибок, но требует большего времени на «въехать» :) В сыром виде использовать для реального проекта — ни в коем случае.
Ну а на сервере, думаю, и так уже используете ASP.NET MVC 4/WebApi? И копаете ASP.NET MVC 5, который вот-вот выйдет? :)
Ну, на самом деле, клиентский фреймворк — такое себе дело вкуса. Здесь, в отличие от каждой серверной платформы, нет однозначного мега-фаворита (есть просто те, что постарше и проверены временем). Радует, что есть много действительно качественных. По опыту, не вдаваясь в особые детали, посоветовал бы однозначно освоить Angular.js, очень нелишним будет Ember.js и разобраться в том, как работает Backbone.js (+Marionette.js). Тогда можно будет выбрать себе по вкусу. Angular позволяет очень быстро решать задачи, благодаря тому, что он очень целостный (хотя у него немного странная терминология). Backbone очень гибок, но требует большего времени на «въехать» :) В сыром виде использовать для реального проекта — ни в коем случае.
Ну а на сервере, думаю, и так уже используете ASP.NET MVC 4/WebApi? И копаете ASP.NET MVC 5, который вот-вот выйдет? :)
с моими-то ресурсами хоть что с js на клиенте в продакшен версию совсем не стоит брать, ибо чревато. Но чтоб уж совсем не быть инертным, надо щупать всякие модные вещи, чтоб уже к более реальной задаче быть хоть малость подготовленным, а там уж решить — получится или нет, созрел или нет, тут уже фактор пройденного времени будет большую роль играть.
Да если б MVC4, пока только MVC3. Но по большому счёту там различий-то принципиальных нет, так, больше в мобильном направлении. MVC5 совсем не трогал, больно уж времени дефицит (надо хотя бы client-js пощупать сперва, там знаний почти нет, а MVC подождет)
Да если б MVC4, пока только MVC3. Но по большому счёту там различий-то принципиальных нет, так, больше в мобильном направлении. MVC5 совсем не трогал, больно уж времени дефицит (надо хотя бы client-js пощупать сперва, там знаний почти нет, а MVC подождет)
Ну да, между MVC3 и MVC4 принципиальных отличий нет, более того, чего-то принципиального, думаю, не будет и в MVC5. Что касается мобильных веб-приложений, то MVC4 — ну очень условно «лучше» для этого, несколько новых соглашений, упрощающих жизнь, все это возможно было и в MVC2/3. Сам не особо пристально слежу за его развитием сейчас, после переключения на альтернативные платформы.
Клиентские фреймворки — это новый тренд и, на мой субъективный взгляд, очень хороший. Если работаете с вебом — найдете массу применений, особенно если пишете не «веб-сайты», а «веб-приложения». Но готовьтесь к тому, что там целая огромная экосистема, и каскадом придется осваивать много всего. Быстренько за вечер освоить не получится.
Клиентские фреймворки — это новый тренд и, на мой субъективный взгляд, очень хороший. Если работаете с вебом — найдете массу применений, особенно если пишете не «веб-сайты», а «веб-приложения». Но готовьтесь к тому, что там целая огромная экосистема, и каскадом придется осваивать много всего. Быстренько за вечер освоить не получится.
Я сам пришел из dot net. Вот здесь уже писал про это.
Рекомендую node.js. Это сэкономит вам время и силы. А там может и дерби распробуете.
Рекомендую node.js. Это сэкономит вам время и силы. А там может и дерби распробуете.
Да, я читал его. Но уже наработано достаточно кодовой базы, которую переписывается под node.js с практически нулевым уровнем знаний совсем не хочется
С моей точки зрения различия между клентскими mvc фреймворками (Angular, Ember, Backbone и т.д тыщи их) минимальны. Как я вам уже сказал я не могу вам советовать использовать mvc- на клиенте фреймворки во времена node.js и full-stack фреймворков.
Вы продвигаете очень спорную и субъективную точку зрения как «действительно верную», что времена отдельных клиентских фреймворков прошли, а кто этого не понимает — слишком инертен. На мой взгляд — это нехорошо и чересчур субъективно.
Я работаю с node.js (Express/Sails/Locomotive), Ruby/Rails/Sinatra, немного PHP (Laravel/Slim/Yii), немного Python/Django и ASP.NET (MVC) и с Angular/Backbone/Ember/Knockout на клиенте, как архитектор, и пытаюсь относиться беспристрастно ко всем технологиям и платформам. Meteor не подошел для многих проектов, возможно стоит попробовать и Derby, и, несмотря на наличие личных фаворитов, я бы ни за что не стал говорить, что времена всего, кроме «технологии N» прошли.
Я работаю с node.js (Express/Sails/Locomotive), Ruby/Rails/Sinatra, немного PHP (Laravel/Slim/Yii), немного Python/Django и ASP.NET (MVC) и с Angular/Backbone/Ember/Knockout на клиенте, как архитектор, и пытаюсь относиться беспристрастно ко всем технологиям и платформам. Meteor не подошел для многих проектов, возможно стоит попробовать и Derby, и, несмотря на наличие личных фаворитов, я бы ни за что не стал говорить, что времена всего, кроме «технологии N» прошли.
это всё js-евангелизм ))
Ну тут дело не в языке как таковом или в платформе, а в продвигаемой концепции. Например, говорить «концепция full-stack-anywhere — это единственный верный и современный подход» — совершенно субъективно.
Я, к примеру (опять же субъективно), в большинстве случаев предпочту подход, когда решение собирается из множества маленьких кусочков-компонентов, сделанных _специально_ для решения той или иной задачи. Поэтому, я не вижу проблемы собрать связку из node.js, express.js, sails.js, backbone.js, socket.io, share.js, passport.js и еще доброй дюжины микро-компонентов, получив при этом больше гибкости и решив ту же задачу, которую пытаются решить с помощью монолитного full-stack-фреймворка. И никогда не забываю про «Right Tool for the Right Job».
Я, к примеру (опять же субъективно), в большинстве случаев предпочту подход, когда решение собирается из множества маленьких кусочков-компонентов, сделанных _специально_ для решения той или иной задачи. Поэтому, я не вижу проблемы собрать связку из node.js, express.js, sails.js, backbone.js, socket.io, share.js, passport.js и еще доброй дюжины микро-компонентов, получив при этом больше гибкости и решив ту же задачу, которую пытаются решить с помощью монолитного full-stack-фреймворка. И никогда не забываю про «Right Tool for the Right Job».
это подход, хорошо описанный ещё Макконнеллом про новаторские вещи, т.е. объясняющий скорость распространения той или иной новой технологии в IT. Другими словами: не стоит гнаться за чем-то сверхмодным, если текущие инструменты (актуальные) в купе с личным опытом позволяют решать свои задачи максимально эффективно. Поэтому я с вами полностью соглаен
Если вы соберете всё то, что перечислили, то получите хорошего конкурента для Meteor и Derby.
Я могу согласится с вами что Метеор довольно монолитный и не гибкий.
Но по поводу Дерби — это не так. Он как раз и состоит из разных частей. live-db, tracks, share.js, browerify, racer и т.п. Все их можно использовать отдельно. Некоторые можно заменить.
Я думаю тут есть определенное противоречие между гибкостью и монолитностью. Если мы хотим красивый апи, то фреймворк будет монолитный. Если хотим гибкости, то это будет стоить чего-то. Думаю что нужна золотая середина.
Я могу согласится с вами что Метеор довольно монолитный и не гибкий.
Но по поводу Дерби — это не так. Он как раз и состоит из разных частей. live-db, tracks, share.js, browerify, racer и т.п. Все их можно использовать отдельно. Некоторые можно заменить.
Я думаю тут есть определенное противоречие между гибкостью и монолитностью. Если мы хотим красивый апи, то фреймворк будет монолитный. Если хотим гибкости, то это будет стоить чего-то. Думаю что нужна золотая середина.
Насчет красоты api немного неоднозначный вопрос — смотря что подразумевать под красотой. Но такой момент есть — API разнятся от компонента к компоненту, и тут важно выбирать действительно хорошие разработки. В мире node.js очень много нового и разного, в том числе с весьма посредственными API, но полно и хороших вещей. Тут, imho, главное не заморачиваться особо на однотипности API, а просто рассматривать каждый API с точки зрения решения конкретной задачи, для которой создан компонент. Так, кстати, многие решения принимаются (и чем качественнее продукты, тем сложнее это сделать) — socket.io vs SockJS, passport.js vs everyAuth, и так далее.
Насчет золотой середины согласен полностью.
Насчет золотой середины согласен полностью.
Кстати, насчет монолитности Meteor. Они работают над тем, чтобы сделать его менее связным. Сейчас, например, можно удалить пакет standard-app-packages и набрать ядро из компонентов, которые тебе нужны. Заменив некоторые на свои.
Или можно отказаться от их сервера и реализовать DDP на чем угодно.
Так что при желании — все можно переделать. Может не так просто, как в конструкторе-derby, зато и целостность-удобство-простота в базовых сценариях у метеора, имхо, выше.
Или можно отказаться от их сервера и реализовать DDP на чем угодно.
Так что при желании — все можно переделать. Может не так просто, как в конструкторе-derby, зато и целостность-удобство-простота в базовых сценариях у метеора, имхо, выше.
Это хорошо. Я думаю что их стратегический просчет был в том, что они отказались от npm-пакетов в пользу своего пакетного менеджера. Позже конечно прикрутили.
Переделывать всегда хуже, чем изначально предусмотреть.
В базовых сценариях Метеор более удобен. Верно. Но чем сложнее ваше приложение, тем больше проблем.
Переделывать всегда хуже, чем изначально предусмотреть.
В базовых сценариях Метеор более удобен. Верно. Но чем сложнее ваше приложение, тем больше проблем.
NPM-то они не сделали не просто так. Большинство из них ведь не в fibers-стиле, нада их под него адаптировать. Ну и другие причины есть. Где-то у них был большой топик про это.
Не fiber стиль и npm — это иделогоия node.js. Meteor пошли своим путем. Преимущества этого пути не совсем очевидны. А вот проблемы есть.
Да, тут можно спорить, но, по-моему, клевее принять, что то, что продукты идут разными путями — хорошо. Для тех, кому хочется гибкости npm из коробки и стандартного для платформы стиля, есть derby. Для тех, кому хочется меньше boilerplate пусть и с меньшей гибкостью и большими отступлениями, есть meteor.
Надеюсь, скоро еще и что-то среднее появится.
Надеюсь, скоро еще и что-то среднее появится.
Спасибо за замечание.
Я и правда иногда в жарких дебатах по поводу технологий возможно не всегда остаюсь объективным. Постараюсь исправиться.
У вас богатый опыт в вебе. Мне было бы очень интересно ваше мнение по поводу full-stack фреймворков (Meteor, Derby)
Чем кстати Meteor не подошел?
Я и правда иногда в жарких дебатах по поводу технологий возможно не всегда остаюсь объективным. Постараюсь исправиться.
У вас богатый опыт в вебе. Мне было бы очень интересно ваше мнение по поводу full-stack фреймворков (Meteor, Derby)
Чем кстати Meteor не подошел?
Метеор не подошел не столько технически, сколько концептуально. Критично было поддерживать то, что называют «polyglot persistence», то есть несколько источников данных, NoSQL, SQL и Redis, а в Meteor уж слишком навязан определенный способ работы с данными. Никто не мешает что-то немного поменять, но тогда «целостность» метеора дает сбой, появляются костыли, и метеор становится не нужен. Далее — недостаточное количество фич для фулл-стэка, все равно пришлось приправлять сторонними библиотеками, чтобы решить задачу, в итоге опять же оказался не нужен сам метеор.
Ну и, в конце концов, просто удавалось все решить миксом других технологий, почти не изобретая при этом велосипедов.
Надо бы актуализировать информацию по нему, кстати, что поменялось на текущий момент. Еще показалось, что в Метеоре слишком большой акцент на фичи для «вау-эффекта», типа горячего внедрения кода, который на практике не пригодился ни разу (при этом очень не хватало других, более простых, вещей).
P.S. Обязательно посмотрю Derby, чтобы сложилось какое-то мнение. Плюс, всегда интересны новые перспективные разработки. Находясь в мире node.js, часто о нем слышу, но руки у самого пока не доходили.
P.P.S. По поводу опыта — здесь я намеренно работаю с мульти-стэком, на альтернативных платформах всегда находятся новые идеи, в итоге велик шанс, что если задача на платформе текущего проекта еще не решалась — знаешь, как решали ее на других. Времени требует немало, к сожалению.
Ну и, в конце концов, просто удавалось все решить миксом других технологий, почти не изобретая при этом велосипедов.
Надо бы актуализировать информацию по нему, кстати, что поменялось на текущий момент. Еще показалось, что в Метеоре слишком большой акцент на фичи для «вау-эффекта», типа горячего внедрения кода, который на практике не пригодился ни разу (при этом очень не хватало других, более простых, вещей).
P.S. Обязательно посмотрю Derby, чтобы сложилось какое-то мнение. Плюс, всегда интересны новые перспективные разработки. Находясь в мире node.js, часто о нем слышу, но руки у самого пока не доходили.
P.P.S. По поводу опыта — здесь я намеренно работаю с мульти-стэком, на альтернативных платформах всегда находятся новые идеи, в итоге велик шанс, что если задача на платформе текущего проекта еще не решалась — знаешь, как решали ее на других. Времени требует немало, к сожалению.
Да, маркетинг у Метеора как говорится — что надо. «вау эффекта» много.
Менять Метеор сложно. Тоже согласен.
Я думаю что если бы вы написали обзорную статью про все платформы, попытавшись как-то классифицировать знания, то все веб-разработчики от счастья просто в штаны бы написали. :-) По крайней мере это были бы очень полезные знания. Только посмотрите Derby перед этим.
Менять Метеор сложно. Тоже согласен.
Я думаю что если бы вы написали обзорную статью про все платформы, попытавшись как-то классифицировать знания, то все веб-разработчики от счастья просто в штаны бы написали. :-) По крайней мере это были бы очень полезные знания. Только посмотрите Derby перед этим.
Под «Обновление приложения без перезагрузки» автор видимо имел ввиду, что если на сервере скажем обновился файл, то банально на клиенте не надо жать F5 чтобы увидеть изменения css или html. Это если утрировать. А вообще это достаточно важная вещь.
Спасибо!
Оказывается более чем просто важная. Тогда получается этот пункт можно подвязать с пунктом «Канал синхронизации данных». Уже после такого очень поверхностного понимания и быстро полученных новых знаний нельзя не согласиться с этим комментом habrahabr.ru/post/195636/#comment_6786448
Оказывается более чем просто важная. Тогда получается этот пункт можно подвязать с пунктом «Канал синхронизации данных». Уже после такого очень поверхностного понимания и быстро полученных новых знаний нельзя не согласиться с этим комментом habrahabr.ru/post/195636/#comment_6786448
Конечно не совсем корректно сравнивать эти фреймворки
Я бы сказал — совсем некорректно. derby.js и meteor.js — вполне возможно, они, по сути, конкуренты, при этом качественные и каждый со своей идеологией.
А вот Angular.js + Express.js ну просто нельзя добавлять в эту таблицу в таком виде. Создается ощущение, что это решение явно хуже других двух, а это далеко не так. Очень много упирается во вкус разработчика и необходимую ему гибкость.
Сравнивать full-stack-фреймворки с клиентским фреймворком ну просто нельзя. Что касается Express.js — тут даже сам автор пишет: «Keep in mind that the goal of Express is to aid you with HTTP, not to become a framework super-power like Rails».
Так что получается сравнение технологий разного уровня абстракции и с разным количеством фич, возможно, решающие разные задачи.
P. S. Похожая история со сравнением Backbone.js, Angular.js и подобных. Рано или поздно всплывает мнение, что первый ведет к утечкам памяти и нужно приложить немало усилий, чтобы решить эту проблему. Но тому, кто имел со всем этим дело, очевидно, что так сравнивать нельзя, ведь Backbone обязательно использовать с Marionette/Thorax/Chaplin. И кто-то хочет решений «все-в-одном», а для кого-то (для меня в том числе) преимущество Backbone в его гибкости. То же самое — сравнивать Express.js с full-stack-фреймворком на сервере.
Я абсолютно понимаю, что это решения разных уровней. И то, что любой mvc-на клиенте фреймворк (Angular, Ember, Backbone) будет выглядеть хуже, чем full-stack, дак это тоже понятно. Но люди спрашивали.
А что вы подразумеваете под «вкусом разработчика и необходимой ему гибкостью» и «решающее разные задачи»? В каких случаях вы советуете применять mvc-на клиенте фреймворки вместо full-stack?
А что вы подразумеваете под «вкусом разработчика и необходимой ему гибкостью» и «решающее разные задачи»? В каких случаях вы советуете применять mvc-на клиенте фреймворки вместо full-stack?
UFO just landed and posted this here
Angular — не имеет отношения к бэкенду, что не является ни достоинством, ни недостатком. С одной стороны — это дает гибкость в выборе бэкенда, с другой — он конечно не может всего того, что могут full-stack фреймворки. Но так как бэкенд для него всё-таки нужен, то я позволил взять на себя смелость и выбрать в качестве оного express.js, чтобы как-то сделать angular немного похожим на full-stack для этого сравнения. Вы можете сказать, что не самый лучший вариант бэкенда для angular. Тогда предложите другой вариант.
Я быть может чего-то еще не понимаю, но использование Express подразумевает использование на бэке именно Node.js, что сразу ставит Angular в неконкуретное положение с оппонентами из топика, ибо нельзя же армию jee, asp.net, django и ror разработчиков взять так и сагитировать на node.js. Поэтому альтернатив на бэке полно, перечислял основные из них
Angular тут изначально не конкурентна, потому что это не full-stack.
express.js/node.js как бэкенд для Angular имеет плюсы:
1) повторное использование кода на клиенте и сервере (валидация, например)
2) browserify (использование одних и тех же модулей на клиенте и сервере)
Любой другой бэкенд для Angular ставит ее в еще более не конкурентное положение.
Я тут уже написал по поводу «преимущества возможноти любого бэкенда»
express.js/node.js как бэкенд для Angular имеет плюсы:
1) повторное использование кода на клиенте и сервере (валидация, например)
2) browserify (использование одних и тех же модулей на клиенте и сервере)
Любой другой бэкенд для Angular ставит ее в еще более не конкурентное положение.
Я тут уже написал по поводу «преимущества возможноти любого бэкенда»
Angular тут изначально не конкурентна, потому что это не full-stack
Вот в этом и проблема — вы выдаете желаемое за действительное. Angular может не быть конкурентен сам по себе. Но у вас «не-full-stack» приводится как недостаток. А кто сказал, что весь stack должен покрываться одной технологией/библиотекой/фреймворком?
Это хороший глубокий философский вопрос. Чувствуется опыт работы архитектором.
Что лучше один фреймворк решающий все задачи сразу или много разных частей соединенных вместе, каждая из которых решает только свои задачи и делает это хорошо?
Наверное в первом случае мы получим больше удобства. Во втором случае — больше гибкости. Наверно истина где-то посередине.
Поделитесь своими мыслями. Очень интересно.
Допускаете ли вы возможность существования такого фреймворка, чтобы он был и гибким и удобным?
Что лучше один фреймворк решающий все задачи сразу или много разных частей соединенных вместе, каждая из которых решает только свои задачи и делает это хорошо?
Наверное в первом случае мы получим больше удобства. Во втором случае — больше гибкости. Наверно истина где-то посередине.
Поделитесь своими мыслями. Очень интересно.
Допускаете ли вы возможность существования такого фреймворка, чтобы он был и гибким и удобным?
Вопрос действительно непростой. Я все-таки больше за компоненты (даже если они в рамках одного фреймворка или библиотеки), чем за комбайн, который умеет все. Я думаю, в сферическом идеале, решение разных задач фреймворком допустимо в определенных пределах — причем (субъективно) достаточно узких.
Не уверен, что удобство идет именно из за целостности фреймворка, скорее из того, насколько хорошо/плохо написаны отдельные компоненты и насколько удобное у них API.
Для full-stack фреймворков вижу одно очень большое преимущество — интеграция из коробки и куда более простое освоение. Для frameworkless-подхода — конечная гибкость. Второй вариант не обязательно сложнее в плане разработки, но владеть надо бОльшим количеством технологий.
Пример хорошего фреймворка для меня — как ни странно Express.js, который решает строго отведенные ему задачи, ни больше, ни меньше. Далее — Backbone.js — супер-стабильное API, предсказуемость работы, итд. Это сами по себе — фреймворки, решают свои задачи и решают очень хорошо. Но каждый требует расширения, ибо в сыром виде использовать нельзя — можно утонуть в boilerplate-коде. Так появляются Sails.js, Marionette.js, итд.
Возьмем обратный пример — Java Spring, PHP Symfony — это такие комбайны, где есть все и вся. Тяжелые, содержат кучу фич, которые редко нужны. На мой взгляд — это перебор. Не то чтобы все совсем плохо — просто зачем усложнять, если можно решить все более простыми методами.
Не уверен, что удобство идет именно из за целостности фреймворка, скорее из того, насколько хорошо/плохо написаны отдельные компоненты и насколько удобное у них API.
Для full-stack фреймворков вижу одно очень большое преимущество — интеграция из коробки и куда более простое освоение. Для frameworkless-подхода — конечная гибкость. Второй вариант не обязательно сложнее в плане разработки, но владеть надо бОльшим количеством технологий.
Пример хорошего фреймворка для меня — как ни странно Express.js, который решает строго отведенные ему задачи, ни больше, ни меньше. Далее — Backbone.js — супер-стабильное API, предсказуемость работы, итд. Это сами по себе — фреймворки, решают свои задачи и решают очень хорошо. Но каждый требует расширения, ибо в сыром виде использовать нельзя — можно утонуть в boilerplate-коде. Так появляются Sails.js, Marionette.js, итд.
Возьмем обратный пример — Java Spring, PHP Symfony — это такие комбайны, где есть все и вся. Тяжелые, содержат кучу фич, которые редко нужны. На мой взгляд — это перебор. Не то чтобы все совсем плохо — просто зачем усложнять, если можно решить все более простыми методами.
Абсолютно согласен с вами по поводу Express и Backbone. Это очень элегантные решения конкретных задач. Но требуют расширений.
Наверно идеальный фреймворк — это full-stack, который является связующим звеном между независимыми, взаимозаменяемыми компонентами, каждая из которых решает свою задачу. При чем этот фреймворк не пытается каким-то образом подменить эти компоненты и остается гибким на сколько это возможно.
Спасибо за ответы. Очень интересно.
Мне будет очень интересно узнать ваше мнение о Derby, как только вы его попробуете.
Наверно идеальный фреймворк — это full-stack, который является связующим звеном между независимыми, взаимозаменяемыми компонентами, каждая из которых решает свою задачу. При чем этот фреймворк не пытается каким-то образом подменить эти компоненты и остается гибким на сколько это возможно.
Спасибо за ответы. Очень интересно.
Мне будет очень интересно узнать ваше мнение о Derby, как только вы его попробуете.
UFO just landed and posted this here
часто приходится или приходилось мигрировать один клиент с одного бэка на другой? ))
вот честно, это какой-то вопиющий случай, даже при разработке приложения для широкой публики, когда неизвестно, какое там окружение будет у конечного потребителя.
вот честно, это какой-то вопиющий случай, даже при разработке приложения для широкой публики, когда неизвестно, какое там окружение будет у конечного потребителя.
Если выбирать между повторяемость кода и «отвязанностью» от бэкенда, то на мой взгляд преимущества первого в том что:
1) один язык и среда
2) меньше пишите кода
3) используете одни и те же модули на сервере и клиенте
Преимущество же «отвязанности» от бэкенда — то что можно менять бэкенд. Но как совершенно справедливо вас спрашивают в соседнем комментарии: Часто ли вы это делаете?
1) один язык и среда
2) меньше пишите кода
3) используете одни и те же модули на сервере и клиенте
Преимущество же «отвязанности» от бэкенда — то что можно менять бэкенд. Но как совершенно справедливо вас спрашивают в соседнем комментарии: Часто ли вы это делаете?
Почти год использую Meteor и немного использовал Angular. Derby смотрел только мельком, ничего конкретного сказать про него не могу. Так что о Meteor vs Angular.
Для меня самые значимые плюсы Angular:
— Мощная система директив, позволяющая делать компоненты и добиваться высокого уровня повторного использования. В Meteor из коробки вы получаете просто handlebars, делать компоненты на котором — то еще извращение.
— Можно встроить куда угодно и на любом этапе. С любым бэкэдом.
— Более доделанный, не меняется все от версии к версии. Можно с минимальными опасениями использовать на продакшене.
— Более развитое комьюнити.
Но тем не менее, для себя я использую и допиливаю Meteor, потому что:
— Meteor это своего рода продолжение MVVM и на сервер. Я не хочу два раза заниматься одной и той же работой (на клиенте и сервере). Если я где-то обновляю значение, оно должно сразу обновляться везде. К тому же, Meteor без каких либо дополнительных усилий моментально раскидывает апдейты по всем клиентам, что логично для современного приложения.
— Meteor из коробки заточен на использование Node Fibers, что позволяет писать асинхронный код в линейном стиле на манер Erlang, а не заниматься извращением с асинхронной лапшой или каким-нибудь async. На клиенте это, понятно, невозможно, но за счет MVVM лапши тоже почти не возникает.
— Человечность и ощущение, что ребята стремятся скинуть всю работу, которую могут делать компьютеры, на компьютеры, а не на программиста. На хабре проскакивало мнение, что Meteor это чуть ли не фреймвок для домохозяек. Отнюдь. Механика его работы очень сложна, много магии. Да, легко сделать hello world, но без понимания внутренней кухни не написать ничего серьезного. Зачем тогда так заморачиваться? Чтобы по максимуму писать и поддерживать только полезный код, а не boilerplate.
Основные недостатоки Meteor зеркалят преимущества Angular: сырой; handlebars а не компоненты/директивы; нет модели (валидация руками, нет виртуальных свойств); не подходит для олдскульных постраничных сайтов; завязан на свой бэкэнд; небольшое комьюнити (но быстро растет).
Для меня самые значимые плюсы Angular:
— Мощная система директив, позволяющая делать компоненты и добиваться высокого уровня повторного использования. В Meteor из коробки вы получаете просто handlebars, делать компоненты на котором — то еще извращение.
— Можно встроить куда угодно и на любом этапе. С любым бэкэдом.
— Более доделанный, не меняется все от версии к версии. Можно с минимальными опасениями использовать на продакшене.
— Более развитое комьюнити.
Но тем не менее, для себя я использую и допиливаю Meteor, потому что:
— Meteor это своего рода продолжение MVVM и на сервер. Я не хочу два раза заниматься одной и той же работой (на клиенте и сервере). Если я где-то обновляю значение, оно должно сразу обновляться везде. К тому же, Meteor без каких либо дополнительных усилий моментально раскидывает апдейты по всем клиентам, что логично для современного приложения.
— Meteor из коробки заточен на использование Node Fibers, что позволяет писать асинхронный код в линейном стиле на манер Erlang, а не заниматься извращением с асинхронной лапшой или каким-нибудь async. На клиенте это, понятно, невозможно, но за счет MVVM лапши тоже почти не возникает.
— Человечность и ощущение, что ребята стремятся скинуть всю работу, которую могут делать компьютеры, на компьютеры, а не на программиста. На хабре проскакивало мнение, что Meteor это чуть ли не фреймвок для домохозяек. Отнюдь. Механика его работы очень сложна, много магии. Да, легко сделать hello world, но без понимания внутренней кухни не написать ничего серьезного. Зачем тогда так заморачиваться? Чтобы по максимуму писать и поддерживать только полезный код, а не boilerplate.
Основные недостатоки Meteor зеркалят преимущества Angular: сырой; handlebars а не компоненты/директивы; нет модели (валидация руками, нет виртуальных свойств); не подходит для олдскульных постраничных сайтов; завязан на свой бэкэнд; небольшое комьюнити (но быстро растет).
Спасибо, что так расиписали. Ваш опыт будет очень полезен многим.
В свою очередь хочу сделать несколько утверждений:
Если вы хотите повторно использовать код между сервером и клиентом, то бэкенд может быть только один — node.js. По этому утверждение, что «возможность любого бэкенда для mvc-на клиенте фреймворков — это их плюс» — ложно. Это такой же их плюс, какой и минус. Ибо они изначально ограничены этим и теряют возможности.
fibers не нужно использовать. node.js — ассинхронен. В этом есть плюсы и ест минусы.
Это примерно как прототипная модель наследования в js, Нельзя сказать что она хуже, чем классы. Просто не всем это привычно.
Если ваш код в node.js превращается в спаггети, то это не проблема node.js. Вам просто нужно поменять манеру писать код. Использование же fibers делает node.js синхронным, блокирует event-loop. Это очень большой костыль. Его использование убивает все сильные стороны node.js на корню. fiber я бы отнес к минусам Meteor, а не к плюсам.
Кстати в Derby есть компоненты. И реализованы они очень классно. И олдскульные сайты можно делать (ибо есть генерация html на сервере).
Синхронизация данных между клиентам в Метеор сделано довольно топорно. Метеор долбит монго каждые 10 секунд, либо по изменению данных (событий у монго нету). Вычисляет изменения и передает их клиентам. Такой подход плох с двух сторон:
1) Нету механизма разрешения конфликтов при одновременном изменении одних и тех же данных разными клиентами. Изменения будут теряться.
2) Масштабироваться такая модель будет плохо. И будет 10 секундный лаг.
В Derby это на другом уровне.
До Derby я пробовал Meteor. Писал тут. В целом могу сказать, что то что вы любите в Meteor и в Angular, вы найдете в Derby. И даже больше.
В свою очередь хочу сделать несколько утверждений:
Если вы хотите повторно использовать код между сервером и клиентом, то бэкенд может быть только один — node.js. По этому утверждение, что «возможность любого бэкенда для mvc-на клиенте фреймворков — это их плюс» — ложно. Это такой же их плюс, какой и минус. Ибо они изначально ограничены этим и теряют возможности.
fibers не нужно использовать. node.js — ассинхронен. В этом есть плюсы и ест минусы.
Это примерно как прототипная модель наследования в js, Нельзя сказать что она хуже, чем классы. Просто не всем это привычно.
Если ваш код в node.js превращается в спаггети, то это не проблема node.js. Вам просто нужно поменять манеру писать код. Использование же fibers делает node.js синхронным, блокирует event-loop. Это очень большой костыль. Его использование убивает все сильные стороны node.js на корню. fiber я бы отнес к минусам Meteor, а не к плюсам.
Кстати в Derby есть компоненты. И реализованы они очень классно. И олдскульные сайты можно делать (ибо есть генерация html на сервере).
Синхронизация данных между клиентам в Метеор сделано довольно топорно. Метеор долбит монго каждые 10 секунд, либо по изменению данных (событий у монго нету). Вычисляет изменения и передает их клиентам. Такой подход плох с двух сторон:
1) Нету механизма разрешения конфликтов при одновременном изменении одних и тех же данных разными клиентами. Изменения будут теряться.
2) Масштабироваться такая модель будет плохо. И будет 10 секундный лаг.
В Derby это на другом уровне.
До Derby я пробовал Meteor. Писал тут. В целом могу сказать, что то что вы любите в Meteor и в Angular, вы найдете в Derby. И даже больше.
Понятно, что если проект новый, то лучше начинать с JS и на клиенте, и на сервере. Но не всегда это возможно.
Fibers ничего не убивает. Он не синхронный, он псевдосинхронный. Зато его использование делает код в два раза короче и два раза понятнее. Очень правильно, что Meteor'овцы его использовали. Впрочем, это мое имхо. Хотите страдать — страдайте)
Изменения данных на одной ноде метеор рассылает сразу, а не после пулинга монго. Пулинг сделан для распространения между нодами. Но это, конечно, временный костыль. В планах у них использовать pub/sub для распространения событий между нодами, как в derby.
В Derby пока нравится Operational transformation. Компоненты и генерацию на сервере не смотрел. Спасибо за наводку, посмотрю.
Fibers ничего не убивает. Он не синхронный, он псевдосинхронный. Зато его использование делает код в два раза короче и два раза понятнее. Очень правильно, что Meteor'овцы его использовали. Впрочем, это мое имхо. Хотите страдать — страдайте)
Изменения данных на одной ноде метеор рассылает сразу, а не после пулинга монго. Пулинг сделан для распространения между нодами. Но это, конечно, временный костыль. В планах у них использовать pub/sub для распространения событий между нодами, как в derby.
В Derby пока нравится Operational transformation. Компоненты и генерацию на сервере не смотрел. Спасибо за наводку, посмотрю.
Да не страдаем мы. :-)
Для того чтобы в Метеоре сделать Pub/sub как в Derby им нужно переписать «пол Метеора» и написать свою share.js. Они изначально пошли не в том направлении. Derby кстати тоже не сразу к share.js пришли и переписали весь racer для этого в версии 0.5.
Я просто к тому что у многих фреймворков в планах и Pub/sub и генерация html на сервере. Но это не так просто добавить, если сразу не было заложено в архитектуру.
Для того чтобы в Метеоре сделать Pub/sub как в Derby им нужно переписать «пол Метеора» и написать свою share.js. Они изначально пошли не в том направлении. Derby кстати тоже не сразу к share.js пришли и переписали весь racer для этого в версии 0.5.
Я просто к тому что у многих фреймворков в планах и Pub/sub и генерация html на сервере. Но это не так просто добавить, если сразу не было заложено в архитектуру.
Насчет генерации на сервере — может и не придется. Это все же костыль, обусловленный кривизной поисковиков и медлительностью браузеров. И то, и другое все время улучшается и уже сейчас проблема не так уж актуальна для многих видов сайтов/сервисов.
Что касается синхронизации апдейтов через pub/sub — имхо, это просто. Да и они обещают допилить еще до первой версии.
Что касается синхронизации апдейтов через pub/sub — имхо, это просто. Да и они обещают допилить еще до первой версии.
Все мы ждем этого светлого будущего :-)
По поводу fibers посмотрел и правда псевдосинхронность. Извиняюсь ошибся, просто очень давно их ковырял.
Но я всё же не рекомендую их использовать, ибо это противоречит идеологии node.js.
Для синхронизации данных в Meteor хорошо бы реализовать модель разрешения конфликтов какую-нибудь или взять уже готовую (OT от share.js). Для OT кстати важен порядок получения сообщений между клиентом и сервером. Этого нельзя добиться в веб-сокетах. А DDP-протокол в Meteor как раз на веб-сокетах завязан. Варианта три:
1) Они меняют DDP-протокол и что там на него завязано еще. Используют share.js
2) Используют другую модель разрешения конфликтов, отличную от OT. Тут я даже не знаю что посоветовать.
3) Просто добавляют pub/sub, но не меняют модель разрешения конфликтов. Масштабироваться будет лучше, но данные будут теряться.
Я склонен к тому, что они выберут последний вариант.
По поводу fibers посмотрел и правда псевдосинхронность. Извиняюсь ошибся, просто очень давно их ковырял.
Но я всё же не рекомендую их использовать, ибо это противоречит идеологии node.js.
Для синхронизации данных в Meteor хорошо бы реализовать модель разрешения конфликтов какую-нибудь или взять уже готовую (OT от share.js). Для OT кстати важен порядок получения сообщений между клиентом и сервером. Этого нельзя добиться в веб-сокетах. А DDP-протокол в Meteor как раз на веб-сокетах завязан. Варианта три:
1) Они меняют DDP-протокол и что там на него завязано еще. Используют share.js
2) Используют другую модель разрешения конфликтов, отличную от OT. Тут я даже не знаю что посоветовать.
3) Просто добавляют pub/sub, но не меняют модель разрешения конфликтов. Масштабироваться будет лучше, но данные будут теряться.
Я склонен к тому, что они выберут последний вариант.
чисто теоретически, для повторного использования кода на сервере и клиенте можно же написать обёртку для работы именно со своим бэком, заточенным под применение того или иного фреймворка на клиенте и правильно разнести ответственность? более того, возможно, такие обёртки уже существуют
Вот здесь я назвал такие фреймворки кросс-компилируемыми. В целом это плохая практика из-за абстракции от веб-технологий.
я имел ввиду не те фреймворки, а случай проработки архитектуры и построения стека применяемых технологий, не абстрагируясь от них, именно таким образом, чтобы использовать их совместно с разделением ответственности (нк и синхронизация данных между клиентами как раз через сервер-сайд). Т.е. простой случай: поменялось значение на клиенте, а через обертку (какой-нибудь observer, использующий штатные механизмы фреймворка) отпрвил запрос на серверную часть, где и пошла следующая обработка. Понимаю, возможно получилось слишком абстрактно.
Прошу прощения, не так понял.
Такое возможно. Например Метеор для синхронизации данных использует DDP-протокол и серверная часть для него может быть любой (есть пример на python).
Но причем тут повторяемость кода? Для повторяемости кода нужен:
1) один язык на сервере и клиенте
2) архитектура фреймворка, способствующая этому
Тут как бы опять же node.js и full-stack
Такое возможно. Например Метеор для синхронизации данных использует DDP-протокол и серверная часть для него может быть любой (есть пример на python).
Но причем тут повторяемость кода? Для повторяемости кода нужен:
1) один язык на сервере и клиенте
2) архитектура фреймворка, способствующая этому
Тут как бы опять же node.js и full-stack
да, на счёт повторяемости кода я косякнул. Хотел дать понять повторяемость логики работы с данными, чтобы одно и тоже (валидность, к примеру) не выполнялась по 2 раза.
Ладно, спасибо за ответы в разных тредах, очень содержательно получилось.
Ладно, спасибо за ответы в разных тредах, очень содержательно получилось.
Ну тут всё возможно, хотя не могу привести каких-то примеров.
Спасибо за вопросы. :-) Рад если помогло.
Спасибо за вопросы. :-) Рад если помогло.
Кстати, полезность одного языка на сервере и клиенте скорее в унификации и отсутствии необходимости переключать сознание, чем в написании повторяемого кода. Повторяемого кода реально получается немного.
Например, та же валидация в случае полноценной модели на 90% сводится к десятку стандартных валидаторов. Большая часть из них однострочные или около того. Какие-то более сложные валидации получаются все равно разными для клиента и сервера, так что это не критично.
Возможно, это было бы критично для игр, где нужно оперативно считать все на клиенте, а потом перепроверять на сервере. Но в типичных CRUD-приложениях это не очень востребовано. Но в то же время эти фреймвоки не рекомендуются для игр, ибо перерисовывают состояние во время простоев, т.е. будут лаговать.
Например, та же валидация в случае полноценной модели на 90% сводится к десятку стандартных валидаторов. Большая часть из них однострочные или около того. Какие-то более сложные валидации получаются все равно разными для клиента и сервера, так что это не критично.
Возможно, это было бы критично для игр, где нужно оперативно считать все на клиенте, а потом перепроверять на сервере. Но в типичных CRUD-приложениях это не очень востребовано. Но в то же время эти фреймвоки не рекомендуются для игр, ибо перерисовывают состояние во время простоев, т.е. будут лаговать.
Да, в случае с node/npm + browserify — одни и теже пакеты на сервере и клиенте — это крайне удобно.
А что вы про игры говорите? Какие эти фреймворки? Что значит перерисовывают состояние? Я не совсем понял.
А что вы про игры говорите? Какие эти фреймворки? Что значит перерисовывают состояние? Я не совсем понял.
Не знаю как дерби, но и метеор, и ангуляр по заявлениям делают flush когда event loop'у больше нечем заняться, поэтому попадались рекомендации не использовать их в приложениях с активным юзерским вводом или расчетами, так как могут быть лаги с перерисовкой. Но на практике я не проверял, может и ок будет.
Сейчас я понял что вы имеете ввиду. Я кстати сталкивался с этим в Meteor. У меня было много данных на клиенте и во время синхронизации интерфейс фризился на несколько секунд. Это связано как я думаю с реализацией синхронизации данных.
В Derby таких проблем нету. Хотя очень активный ввод я не пробовал.
В Derby таких проблем нету. Хотя очень активный ввод я не пробовал.
я думаю фактор переключения сознания не настолько критичен в командах (архитекторы всея проекта не в счёт), т.к. обязанности всё равно распределяются на бэк и фронт (очень часто даже в вакансиях для корпоративных проектов указывается специализация по конкретному направлению: фронт или бэк).
С другой стороны если все в команде общаются «на одном языка», в одних терминах. Это же плюс.
Безусловно.
Но все было бы просто, если бы у ноды были одни плюсы, но ведь есть и минусы.
Я вот подумываю сравнить ее с Erlang. На то есть две причины:
1) Нестабильность ноды. Я не одобряю эту веру Node-программистов в то, что они смогут писать приложения, которые никогда не падают ни на одной ветке. Эрланг же в этом плане весьма хорош. Упало и упало, все остальное продолжает работать.
2) Долгое время был уверен, что нода будет быстрее эрланга, но наткнулся на несколько тестов, которые говорят об обратном. Теперь хочется проверить это самому и увидеть, насколько же большая разница. Стоит ли овчинка выделки.
Но других потенциальных конкурентов ноде я сейчас не вижу.
Но все было бы просто, если бы у ноды были одни плюсы, но ведь есть и минусы.
Я вот подумываю сравнить ее с Erlang. На то есть две причины:
1) Нестабильность ноды. Я не одобряю эту веру Node-программистов в то, что они смогут писать приложения, которые никогда не падают ни на одной ветке. Эрланг же в этом плане весьма хорош. Упало и упало, все остальное продолжает работать.
2) Долгое время был уверен, что нода будет быстрее эрланга, но наткнулся на несколько тестов, которые говорят об обратном. Теперь хочется проверить это самому и увидеть, насколько же большая разница. Стоит ли овчинка выделки.
Но других потенциальных конкурентов ноде я сейчас не вижу.
Конечно всегда всё падает. Тут никуда не деться. Но вы можете с помощью cluster запустить несколько процессов и в каждом с помощью domain ловить ошибки. Как толко поймаете, останавливаете веб-сервер (чтобы не было новых запросов на этот процесс), запускаете новый процесс (чтобы компенсировать простой этого) и ждете пока все запросы в текущем процессе отработают. Ну например минут 5. Или там события какие-нибудь ловите. Тут зависит от приложения. Потом самоубийство. Всё. Ничего страшного не произошло. Если лень, есть готовые решения в npm. К сожаления ничего не могу порекомендовать, ищите.
По поводу производительности. v8 достаточно быстр. node.js тратит порядка 8кб на поддержание одного соединения (это мало). Ryan Dahl недавно говорил, что есть потенциал для улучшения.
С другой стороны у node.js есть уникальные преимущества. Один язык на клиенте и сервере, ассинхронность.
Если фреймворк B будет быстрее на 30%. Перекроет ли это достоинства node.js?
А по поводу тестов: конечно делайте и выкладывайте. Это всегда интересно.
По поводу производительности. v8 достаточно быстр. node.js тратит порядка 8кб на поддержание одного соединения (это мало). Ryan Dahl недавно говорил, что есть потенциал для улучшения.
С другой стороны у node.js есть уникальные преимущества. Один язык на клиенте и сервере, ассинхронность.
Если фреймворк B будет быстрее на 30%. Перекроет ли это достоинства node.js?
А по поводу тестов: конечно делайте и выкладывайте. Это всегда интересно.
Проблема в том, что если приложение зайдет на сбойную ветку во всем кластере, то это не поможет. Вероятность этого, конечно, гораздо меньше, но бывает всякое.
Плюс, одна нода может держать десятки тысяч коннектов. Все-таки неправильно, когда из-за сбоя у одного юзера, отвалятся все.
То что проблему пытаются закрыть — хорошо, но пока она существует и стоит учитывать ее при выборе технологии.
Преимущество в 30% может быть существенным на некоторых задачах. И может перекрыть преимущества node.
В общем, в очередной раз возвращаемся к тому, что все по задаче. Но и цифры знать неплохо. Может и созрею провести и выложить тесты.
Плюс, одна нода может держать десятки тысяч коннектов. Все-таки неправильно, когда из-за сбоя у одного юзера, отвалятся все.
То что проблему пытаются закрыть — хорошо, но пока она существует и стоит учитывать ее при выборе технологии.
Преимущество в 30% может быть существенным на некоторых задачах. И может перекрыть преимущества node.
В общем, в очередной раз возвращаемся к тому, что все по задаче. Но и цифры знать неплохо. Может и созрею провести и выложить тесты.
Вы имеете ввиду если ошибка будет в master процессе кластера? Ну тут:
1) в мастере ошибка мало вероятна в связи с тем, что там только код запускающий/останавливающий процессы.
2) если всё-таки случилось. то я надеюсь вы используете какой-нибудь upstart и он перезапустит мастера. А мастер перед смертью должен отправить всем своим процессам сигнал, что те должны остановить сервер (через минутку), доработать все звпросы и самоликвидироваться. Когда они закончат, то уже будет запущен новый мастер с новыми процессами. Как-то так. Готовые решения должны быть.
Подождите. Кто отвалится? Я же описал порядок действий. Вы закрыли сервер и дождались пока все запросы отработают. Никто не отвалился.
Ну тогда приводите примеры таких задач, где 30% производительности так важно.
1) в мастере ошибка мало вероятна в связи с тем, что там только код запускающий/останавливающий процессы.
2) если всё-таки случилось. то я надеюсь вы используете какой-нибудь upstart и он перезапустит мастера. А мастер перед смертью должен отправить всем своим процессам сигнал, что те должны остановить сервер (через минутку), доработать все звпросы и самоликвидироваться. Когда они закончат, то уже будет запущен новый мастер с новыми процессами. Как-то так. Готовые решения должны быть.
Подождите. Кто отвалится? Я же описал порядок действий. Вы закрыли сервер и дождались пока все запросы отработают. Никто не отвалился.
Ну тогда приводите примеры таких задач, где 30% производительности так важно.
Не, я имею ввиду в обычном процессе. Он же один на процессор и может обслуживать дофига коннектов. Хотя я сейчас вот попробовал его уронить из своего кода и мне это не удалось. Так что проблема, видимо, стала не столь актуальной как на заре становления node, когда любая проблема валила весь сервер. А если они еще и научились передавать незавершенные коннекты другому процессу — вообще хорошо.
В общем да, проблема, похоже, стала не актуальной и можно ее вычеркивать. Спасибо.
В общем да, проблема, похоже, стала не актуальной и можно ее вычеркивать. Спасибо.
Передавать незавершенные коннекты другому процессу нельзя. Можно их завершить в текущем процессе. Для этого есть инструменты.
Проблема и правда не актуальна.
Проблема и правда не актуальна.
Хотя нет, все-таки осталась возможность написать что-нибудь тяжелое синхронное. Или просто сделать ошибку в цикле и устроить вечный луп. Или бросить эксепшен в setTimeout(). И прощай процесс.
Но тут уж и эрланг не спасет в большинстве случаев)
Но тут уж и эрланг не спасет в большинстве случаев)
Вы заблуждаетесь. Передать текущие коннекты другому процессу можно. У нас написан модуль, который позволяет это делать. К сожалению он слишком сыроват, чтобы его отдавать в opensource.
Но передача коннектов другому процессу актуальна только в случае долгоживущих соединений, как пример это websocket`ы или стриминг.
Но передача коннектов другому процессу актуальна только в случае долгоживущих соединений, как пример это websocket`ы или стриминг.
30% на любом большом кластере. На 30% меньше железа — неплохо для бизнеса с небольшой добавленной стоимостью.
Упс. мимо
Упс. мимо
Основной минус ангулара (хотя это кому как) что он фрейморк а не библиотека. После того как нам надоело тратить кучу времени на обход его бесконечных багов и навешивание костылей там где не хватает его гибкости мы написали по быстрому свою легковестную библиотеку которая делалает все что нам нужно alight.py-my.ru/…
Согласен в том, что в Angular много лишнего/дублирующейся функциональности.
А в чем не хватило гибкости?
А в чем не хватило гибкости?
Да много чего, долго вспоминать перечислять, с роутами маялись например когда по простому можно было джикверивские использоватьна, на баги какие то постоянно натыкались или вот для сравнения, попробуй повторить на Angular.JS jsfiddle.net/lega911/Rn8cY/ и почувствовать разницу…
Я боюсь что не осилю. :-) Но где же все те фанаты Angular? Ну ка запилите нам fiddle.
jsfiddle.net/script/SmPB8/1/ на мой взгляд, вполне логичный код и по простому… можно еще подшаманить — вообще конфетка будет
Пример не плох, но тут есть минус — «засоряется» $rootScope, если я буду подключать его как библиотеку, то в моих контроллерах будут «левые» переменные и ф-ии, и их будет все больше с каждой библиотекой и нужно что-бы они не пересеклись.
и нет главного: возможность вызвать вне контроллера onclick=«xalert('hello')» — (для jQuery проектов) и в данном случае пришлось поправить html приложения.
Когда я делал аналог того alert'a на Angular.js (а нужно было подключать его в любой момент как библиотеку js без правки html) он содержал добавление элементов, создание своего scope, компиляцию и т.п. — все это выглядело не так красиво.
и нет главного: возможность вызвать вне контроллера onclick=«xalert('hello')» — (для jQuery проектов) и в данном случае пришлось поправить html приложения.
Когда я делал аналог того alert'a на Angular.js (а нужно было подключать его в любой момент как библиотеку js без правки html) он содержал добавление элементов, создание своего scope, компиляцию и т.п. — все это выглядело не так красиво.
Как-то так: jsfiddle.net/D8VKb/1/
Alerts — повторно используемый сервис, с которым можно будет работать отовсюду, откуда надо — различных контролеров, сервисов-оберток AJAX с общей обработкой, например, HTTP 500 ошибок, сервисов с бизнес-логикой и обработкой специфичных ошибок.
Шаблон вывода сообщений скорее всего вставится один раз в index.html одностраничного приложения.
Вообще Вы сделали чересчур сильные заявления и слабо подкрепили их аргументами. Бесконечных багов там нет и с гибкостью очень хорошо, а также тестируемостью, возможностями для декомпозиции приложения и т.п.
Alerts — повторно используемый сервис, с которым можно будет работать отовсюду, откуда надо — различных контролеров, сервисов-оберток AJAX с общей обработкой, например, HTTP 500 ошибок, сервисов с бизнес-логикой и обработкой специфичных ошибок.
Шаблон вывода сообщений скорее всего вставится один раз в index.html одностраничного приложения.
Вообще Вы сделали чересчур сильные заявления и слабо подкрепили их аргументами. Бесконечных багов там нет и с гибкостью очень хорошо, а также тестируемостью, возможностями для декомпозиции приложения и т.п.
Пример выше не про сами алерты, а про создание ф-ла без вставки html в свой проект, т.е. когда вы будете подключать alert.js в разные проекты, вам не потребуется в каждый из них вставлять ещё и html. Так же, например, когда я подключаю jquery.dialog, я не пихаю шаблон диалога в мой код.
Вот пример от ScRiPt является «аналогом».
Как его вызвать не из контроллера напрямую? Это для случаев если в проекте много jQuery и других js-библиотек.
Вот пример от ScRiPt является «аналогом».
Alerts — повторно используемый сервис, с которым можно будет работать отовсюду
Как его вызвать не из контроллера напрямую? Это для случаев если в проекте много jQuery и других js-библиотек.
Дело в том, что я специально разделил html и js. Это один из основополагающих принципов в AngularJS. Разделение сущностей, ответственностей, декомпозиция. Называть это минусом и пытаться много и густо вызывать что-то напрямую из html и других js-библиотек, а потом говорить ну вот он так не умеет (или умеет неудобно) — это все равно, что про микроскоп говорить, что у него не такая удобная ручка как у молотка, да и боек какой-то странный.
Можно, конечно, и такое написать: jsfiddle.net/XumaZ/. Но точно не с целью вызывания «отовсюду». Я под этим словом подразумевал, конечно, не html и любой javascript, раскиданный где угодно.
P.S. $rootScope значит засоряется, а на window положить нестрашно? :)
Можно, конечно, и такое написать: jsfiddle.net/XumaZ/. Но точно не с целью вызывания «отовсюду». Я под этим словом подразумевал, конечно, не html и любой javascript, раскиданный где угодно.
P.S. $rootScope значит засоряется, а на window положить нестрашно? :)
Называть это минусом и пытаться много и густо вызывать что-то напрямую из html и других js-библиотек...
Согласен, просто инструменты имеют разные возможности (хотя по основной части пересекаются).
P.S. $rootScope значит засоряется, а на window положить нестрашно? :)
Ну на window уже лежат такие переменные как angular, $, jQuery и т.п. — вроде никто не жалуется, можно так же, аккуратно делать.
В последнее время кайфую от marionette.js, все очень разумно сделано
что такое Full-stack?
Sign up to leave a comment.
Angular.js vs Meteor.js vs Derby.js