Комментарии 30
Ember хорош, но в тоже время «магия» иногда приводит к значительным остановкам, а некоторые вещи нельзя сделать до определенной версии Ember.
ember-cli прикольная штука, благодаря тому, что:
* унифицирует структуру приложения еще жестче и облегчает работу новичкам
* будет частью 2.0+ и поддерживается core разработчиками
* предоставляет инфраструктуру и для тестов сразу
но:
* скорость (по итогу вынес tmp на RAM disk)
* разные дополнения разного уровня «деталей реализации», что может вылиться в необходимость или делать свой похожий или патчить чужой
* необходимость прописывать, что именно мы складываем из bower_components после brunch выглядит излишним
В целом, это отличный фреймворк, но надо быть готовым столкнуться с различными подводными камнями, источник которых не сразу будет явно виден.
ember-cli прикольная штука, благодаря тому, что:
* унифицирует структуру приложения еще жестче и облегчает работу новичкам
* будет частью 2.0+ и поддерживается core разработчиками
* предоставляет инфраструктуру и для тестов сразу
но:
* скорость (по итогу вынес tmp на RAM disk)
* разные дополнения разного уровня «деталей реализации», что может вылиться в необходимость или делать свой похожий или патчить чужой
* необходимость прописывать, что именно мы складываем из bower_components после brunch выглядит излишним
В целом, это отличный фреймворк, но надо быть готовым столкнуться с различными подводными камнями, источник которых не сразу будет явно виден.
Абцац про подводные камни я бы выделил жирным шрифтом.
Реши недавно освоить этот «замечательный» фреймворк. Прочитал документацию, начал делать проект. Сначала был в восторге т.к. все действительно делалось просто и быстро. Но тут появилась необходимость чуть отойти в сторону и началось. Оказалось, что документация покрывает только самые простые случаи использования, в свою очередь магия сокрывает внутреннию логику фреймворка, не давая возможности быстро разобратся по исходным кодам. Сообщество у фремворека есть и в интернете много ответов, но фреймворк так много и часто меняется, что эти ответы уже не актуальны и по большей части мешают процессу поиска информаци. В результате разработка привращается в ад.
Реши недавно освоить этот «замечательный» фреймворк. Прочитал документацию, начал делать проект. Сначала был в восторге т.к. все действительно делалось просто и быстро. Но тут появилась необходимость чуть отойти в сторону и началось. Оказалось, что документация покрывает только самые простые случаи использования, в свою очередь магия сокрывает внутреннию логику фреймворка, не давая возможности быстро разобратся по исходным кодам. Сообщество у фремворека есть и в интернете много ответов, но фреймворк так много и часто меняется, что эти ответы уже не актуальны и по большей части мешают процессу поиска информаци. В результате разработка привращается в ад.
Можете рассказать с каким проблемами вы столкнулись?
— Не очевидность кастомезации мепперов для API. И не очевидность того, что именно кастомезировать, описания требований я не нашел, поэтому все пришлось выяснять в процессе работы. Причем не всегда очевидно, что проблема в несоотвествие, обычно сначала сталкиваешься с проблемой, а потом уже выясняешь, что тут просто Ember ожидал другой формат ответа от API.
— Не очевидно как передавать данные между разными элиментами приложения. Я так и не понял, как я могу иницировать запрос новых данных для одного контроллера из другого.
— Как я уже написал, большая проблема с быстрым устаревание информации от сообщества. Чувствует большой дискомфорт, когда тебе не подходят ответы из топа гугла т.к. у тебя уже слишком новая версия эмбера.
— Не очевидно как передавать данные между разными элиментами приложения. Я так и не понял, как я могу иницировать запрос новых данных для одного контроллера из другого.
— Как я уже написал, большая проблема с быстрым устаревание информации от сообщества. Чувствует большой дискомфорт, когда тебе не подходят ответы из топа гугла т.к. у тебя уже слишком новая версия эмбера.
1. Местами ember-data кривоват и с форматом json бывают проблемы, но я сталкивался всего 1 раз
2. Я не совсем понял что вам нужно, Вы имеете ввиду вложенные контроллеры для айтемов?
3. К сожалению, да
2. Я не совсем понял что вам нужно, Вы имеете ввиду вложенные контроллеры для айтемов?
3. К сожалению, да
— Не очевидно как передавать данные между разными элиментами приложения. Я так и не понял, как я могу иницировать запрос новых данных для одного контроллера из другого.
Сейчас переходят на компоненты, a-la React. Но в целом, конструкций вида this.controllerFor хватало. Опишите детальней пример, подумаю, как можно решить, потому что сам много раз бодался.
На второй вопрос: если вложенность, то делаете this.send('actionName') и ждете в более высокой роуте. Оттуда берете this.get('controller') и передаете в него информацию… В случае равнозначных контроллеров вам поможет cotrollerFor
В последнее время в вебе идет тенденция к «утончению» сервера и «утолщению» клиента. С каждым днем вакансий Full-stack разработчиков становится все больше, а чистого бэкенда все меньше
- «утолщению» клиента идет довольно давно по известной причине, тонкий_клиент_браузер (браузеры) становится всё толще и код писать можно в формате RIA, только, конечно, не в терминологии вики, а в смысле, что можно внедрять фичи совершенно иного порядка, нежели обычное клацанье по контролам и прочий функционал порядка «это моя первая домашная страница».
- а у чистого бэкенда, если вы не совсем курсе, последние 5-7 лет творятся такие вещи, что просто жуть — 3-4 крупных игрока (игры в компонентные фреймворки, или кто кого лучше заинтегрирует). То есть для фронта он конечно всё тоньше становится, но сам по себе утощается
- Если мы говорим о каком-то конкретном языке\наборе инструментов, то (ИМХО) будущее специалиста зависит от его персональной должной активности в жизни сообщества этого языка\фреймворка и, конечно же, в больше степени, коллективной активности сообщества
- Если мы говорим о специалисте в принципе, то не надо зацикливаться на языке\фреймворке. Простите за капитанство. Надо использовать инструменты, вернее, даже связку, которая лучше всего решает поставленную задачу
+ (ИМХО) и фронт и бэк в меру возможностей языков программирования развиваются в сторону SOA-инструментов. Грубо говоря, это когда любую маломальски полезную фичу можно оформить в виде готового подключаемого решения (S — сервис) и встроить в архитектуру (A — Architecture)
А теперь внимание, какое это отношение имеет к Ember.js?
Да очень простое. Вроде как для того, чтобы расширить\кастомизировать поведение приложения, приходится тщательно постучать в бубен (иногда стенкой в свой бубен). то есть он плохо соответствует этой тенденции развития в сторону SOA-инструментов. Поэтому, если я прав и если это не исправится, то очень скоро автор будет искать на кого-бы еще переучиться
Если не секрет, почему такой выбор из трех? Насколько я вижу, сейчас ReactJS набирает популярность, конкурирует с Angular'ом.
Метеор, как я говорил, отпал по причине того что хочу продолжать писать бэкенд на рельсах, а вот между ангуларом и эмбером выбор был сложный. Оба фреймворка хорошие, сообщества тоже. К тому же, я немного работал с Discourse и мне понравилось. В свое время, был в примерно такой же ситуации с Ruby и Python — больше понравился руби, начал с ним работать и теперь не хочу уходить.
В React особо не вникал, но обязательно посмотрю.
В React особо не вникал, но обязательно посмотрю.
Я тоже не хочу уходить с Рельс. Но хороший фронт тоже очень хочется. Я недавно написал первый апп с React & Rails. В итоге в приложении вместо slim/erb теперь jsx. React просто стал V в MVC рельс. Правда сам React ещё довольно молод и некоторые вещи приходится заново изобретать. Но, судя по темпам, оно скоро исправится. И надеюсь серверный рендеринг в геме допилят до вменяемого состояния.
Я всё хочу спросить, как люди которые с React работают уживаются с этим кошмарным синтаксисом (JSX который)? Тем более после Slim.
Я как на него посмотрю, так сразу пропадает желание учить React. Хотя задумка вроде хорошая.
Я как на него посмотрю, так сразу пропадает желание учить React. Хотя задумка вроде хорошая.
Я сначала тоже плевался и пока изучал — всё писал на чистом JS. Но как только переключился с коротких примеров на реальный апп, то очень быстро вернулся к JSX и сейчас у меня с ним в принципе harmony)
Нет, так понятно что на JavaScript эти вьюхи писать невозможно при сколько-нибудь серьёзном объёме. Почему собственно вот это их «никаких шаблонов, только JavaScript» — полнейшая ерунда, JSX те же шаблоны, только уродливые (со смешиванием JS и HTML ещё и без явных разграничений).
Или я может один такой эстет и остальным это не принципиально?
Или я может один такой эстет и остальным это не принципиально?
Вы не один) Нас даже не двое ;-) Вот ребята сделали тот же принцип, что у реакта (сравнение virtual-dom), но с обычными шаблонами http://www.ractivejs.org/
>вместо slim/erb теперь jsx
>Правда сам React ещё довольно молод и некоторые вещи приходится заново изобретать
Если не менять erb на jsx, то можно использовать готовые решения на jQuery там где это нужно, а сложную фронтенд логику которую удобнее реализовывать с помощью MVC писать на react и подключать ее к erb. Большинству веб-приложений этого вполне достаточно, если, конечно, вы не пишете полноценное SPA. Чтобы все было быстро и современно – достаточно turbolinks с отдельными react компонентами. Все это крайне удобно дебажить и поддерживать, при этом никакие rails гемы переписывать под react не нужно.
>Правда сам React ещё довольно молод и некоторые вещи приходится заново изобретать
Если не менять erb на jsx, то можно использовать готовые решения на jQuery там где это нужно, а сложную фронтенд логику которую удобнее реализовывать с помощью MVC писать на react и подключать ее к erb. Большинству веб-приложений этого вполне достаточно, если, конечно, вы не пишете полноценное SPA. Чтобы все было быстро и современно – достаточно turbolinks с отдельными react компонентами. Все это крайне удобно дебажить и поддерживать, при этом никакие rails гемы переписывать под react не нужно.
Derby не смотрели? Просто если речь о Метеоре зашла (который сколько я его помню, а этом минимум года два, «многообещающий но сырой»), то вроде Дерби намного приличнее смотрится (менее костыльный и не такой сырой), но сам пока его не пробовал.
Отлично написано, отдельный плюс за четкие схемы и подробное описание. Жду следующей част.
Уже давненько работаю в EmberJS… В самом начале плевался и ругался на него, а после, когда вник и разобрался, то понял, что штука замечательная: все довольно быстро и удобно.
Клиент жирнеет только в некоторых областях. Если вы пишете публичный сайт, который должен хорошо индексироваться, и хотите максимальной скорости отображения то шаблонизация на сервере и тонкий клиент никуда не уйдут.
Клиент пожирнел, в интранетах или в интернет сервисах которые и раньше с трудом можно было назвать сайтами.
Клиент пожирнел, в интранетах или в интернет сервисах которые и раньше с трудом можно было назвать сайтами.
выбор фреймворка человека, который пришел с серверной разработки:
Java -> Angular
Ruby -> Ember
.NET -> Knockout
я не говорю что это 100%, но сами понаблюдайте на своем примере и примере коллег с других проектов (которые конечно могут влиять на выбор фреймворка)
Java -> Angular
Ruby -> Ember
.NET -> Knockout
я не говорю что это 100%, но сами понаблюдайте на своем примере и примере коллег с других проектов (которые конечно могут влиять на выбор фреймворка)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Философия Ember.js