Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Коротко:
И да, у вас серьёзные проблемы с тся/ться.
– почему же все-таки Meteor?
– кто-то из ранних последователей технологии вовсю кричит о нём
И да, у вас серьёзные проблемы с тся/ться.
А где же сравнение и факты? В статье можно заменить /Ruby On Rails/ на /PlayFramework/ (или что-то другое) и ровным счетом смысл бы не изменился.
Вовсе не желаю устраивать холивары или спорить с вами, но в нашей команде у фронтэндщика это заняло 2 часа.
— С уважением и любовью к JS
ЗЫ не увидел, что это перевод, прошу не принимать на свой счет.
Мы запустили наиболее важный функционал (MVP) приложения за 3-4 недели, тогда как на rails это бы заняло 4-6 недель.
нам пришлось12-16 часов заниматься конфигурированием
Вовсе не желаю устраивать холивары или спорить с вами, но в нашей команде у фронтэндщика это заняло 2 часа.
— С уважением и любовью к JS
ЗЫ не увидел, что это перевод, прошу не принимать на свой счет.
Давайте расставим все точки над «и».
Rails хороший фреймворк для создания бэкенда большинства приложений — он позволяет быстро и качественно вносить изменения в бизнес логику. Что поверх него натягивать — зависит от задачи.
Meteor нужен там, где есть богатый фротнэнд и его надо как-то увязывать с несложной бизнес-логикой. Да, этой действительно удобно писать сразу клиентсерверный код, но вы забываете что Meteor пока поддерживает только одно хранилище данных и поддерживать затем NoSQL архитектуру будет весьма накладно. Для создания MVP он однозначно подходит, но не более. Делать на нем серьезные проекты я бы пока не стал в виду того что он еще находится в бете.
Думаю из Meteor получится через 2-3 года хороший приемник рельсе на фронтэнде.
Rails хороший фреймворк для создания бэкенда большинства приложений — он позволяет быстро и качественно вносить изменения в бизнес логику. Что поверх него натягивать — зависит от задачи.
Meteor нужен там, где есть богатый фротнэнд и его надо как-то увязывать с несложной бизнес-логикой. Да, этой действительно удобно писать сразу клиентсерверный код, но вы забываете что Meteor пока поддерживает только одно хранилище данных и поддерживать затем NoSQL архитектуру будет весьма накладно. Для создания MVP он однозначно подходит, но не более. Делать на нем серьезные проекты я бы пока не стал в виду того что он еще находится в бете.
Думаю из Meteor получится через 2-3 года хороший приемник рельсе на фронтэнде.
Сорри, из твиттера в тему:
Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно. @lisovskyvlad
актуальная версия — 0.6.6.3… то есть в продакшене его использовать пока нельзя? Всегда напрягала эта дурная черта js библиотек и фреймворков с версиями. Так же хочу отметить жесть в репозитории с тегами…
Так же способ подачи информации о этом фреймворке меня лично сильно напрягает, особенно меня умиляет количество убийц RoR в последнее время.
Так же способ подачи информации о этом фреймворке меня лично сильно напрягает, особенно меня умиляет количество убийц RoR в последнее время.
But, does it scale? :)
Вообще я рад что лучшие практики из рельсы по-тихоньку переносятся в JS — гемы пакеты, понятный стек и хорошее комьюнити.
В meteor смущет только его собственный пакетный менеджер, душа больше лежит к DerbyJS, который использует уже привычный, и более популярный, npm
Мне тоже в Метеоре это не нравится и тоже симпатичен Derby. Еще бы скорости разработки добавить. Уж больно долго еще до 1.0
Ну если учитывать что у Метеор 0.6.2.1, а у Derby 0.5.9 то не такая уж и большая разница.
Я бы тоже хотел уметь по сравнению номеров версий определять даты последующих релизов
Заметьте я дату не называю
«100-200$ в час» — хотеть, за такие деньги можно писать на чем угодно!
И прочитав статью я понял, что не хочу, чтобы продукты разрабатывали фроненд-JS программисты или любящие Meteor дизайнеры.
И прочитав статью я понял, что не хочу, чтобы продукты разрабатывали фроненд-JS программисты или любящие Meteor дизайнеры.
Ruby on Rails хуже чем %технология для разработки навороченного фронтенда% для разработки навороченного фронтенда. Ну да.
В то время, когда RoR был на пике популярности, большая часть работы отдавалась серверу, теперь стали всё больше использовать возможности клиента.
Вместо Рельсов можно было бы упомянуть любую серверную технологию — смысл бы не поменялся.
В то время, когда RoR был на пике популярности, большая часть работы отдавалась серверу, теперь стали всё больше использовать возможности клиента.
Вместо Рельсов можно было бы упомянуть любую серверную технологию — смысл бы не поменялся.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Meteor погубит Ruby on Rails