Философия Ember.js

[gagoman]

Ember хорош, но в тоже время «магия» иногда приводит к значительным остановкам, а некоторые вещи нельзя сделать до определенной версии Ember.

ember-cli прикольная штука, благодаря тому, что:
* унифицирует структуру приложения еще жестче и облегчает работу новичкам
* будет частью 2.0+ и поддерживается core разработчиками
* предоставляет инфраструктуру и для тестов сразу

но:
* скорость (по итогу вынес tmp на RAM disk)
* разные дополнения разного уровня «деталей реализации», что может вылиться в необходимость или делать свой похожий или патчить чужой
* необходимость прописывать, что именно мы складываем из bower_components после brunch выглядит излишним

В целом, это отличный фреймворк, но надо быть готовым столкнуться с различными подводными камнями, источник которых не сразу будет явно виден.

[bushart]

Абцац про подводные камни я бы выделил жирным шрифтом.

Реши недавно освоить этот «замечательный» фреймворк. Прочитал документацию, начал делать проект. Сначала был в восторге т.к. все действительно делалось просто и быстро. Но тут появилась необходимость чуть отойти в сторону и началось. Оказалось, что документация покрывает только самые простые случаи использования, в свою очередь магия сокрывает внутреннию логику фреймворка, не давая возможности быстро разобратся по исходным кодам. Сообщество у фремворека есть и в интернете много ответов, но фреймворк так много и часто меняется, что эти ответы уже не актуальны и по большей части мешают процессу поиска информаци. В результате разработка привращается в ад.

[Tonkonozhenko]

Можете рассказать с каким проблемами вы столкнулись?

[bushart]

— Не очевидность кастомезации мепперов для API. И не очевидность того, что именно кастомезировать, описания требований я не нашел, поэтому все пришлось выяснять в процессе работы. Причем не всегда очевидно, что проблема в несоотвествие, обычно сначала сталкиваешься с проблемой, а потом уже выясняешь, что тут просто Ember ожидал другой формат ответа от API.
— Не очевидно как передавать данные между разными элиментами приложения. Я так и не понял, как я могу иницировать запрос новых данных для одного контроллера из другого.
— Как я уже написал, большая проблема с быстрым устаревание информации от сообщества. Чувствует большой дискомфорт, когда тебе не подходят ответы из топа гугла т.к. у тебя уже слишком новая версия эмбера.

[Tonkonozhenko]

1. Местами ember-data кривоват и с форматом json бывают проблемы, но я сталкивался всего 1 раз
2. Я не совсем понял что вам нужно, Вы имеете ввиду вложенные контроллеры для айтемов?
3. К сожалению, да

[gagoman]

— Не очевидно как передавать данные между разными элиментами приложения. Я так и не понял, как я могу иницировать запрос новых данных для одного контроллера из другого.

Сейчас переходят на компоненты, a-la React. Но в целом, конструкций вида this.controllerFor хватало. Опишите детальней пример, подумаю, как можно решить, потому что сам много раз бодался.

[DSL88]

На второй вопрос: если вложенность, то делаете this.send('actionName') и ждете в более высокой роуте. Оттуда берете this.get('controller') и передаете в него информацию… В случае равнозначных контроллеров вам поможет cotrollerFor

[bushart]

cotrollerFor уже deprecated. Но это был не вопрос. Меня попросили привести примеры, я привел.

[hanovruslan]

В последнее время в вебе идет тенденция к «утончению» сервера и «утолщению» клиента. С каждым днем вакансий Full-stack разработчиков становится все больше, а чистого бэкенда все меньше

• «утолщению» клиента идет довольно давно по известной причине, тонкий_клиент_браузер (браузеры) становится всё толще и код писать можно в формате RIA, только, конечно, не в терминологии вики, а в смысле, что можно внедрять фичи совершенно иного порядка, нежели обычное клацанье по контролам и прочий функционал порядка «это моя первая домашная страница».
• а у чистого бэкенда, если вы не совсем курсе, последние 5-7 лет творятся такие вещи, что просто жуть — 3-4 крупных игрока (игры в компонентные фреймворки, или кто кого лучше заинтегрирует). То есть для фронта он конечно всё тоньше становится, но сам по себе утощается
• Если мы говорим о каком-то конкретном языке\наборе инструментов, то (ИМХО) будущее специалиста зависит от его персональной должной активности в жизни сообщества этого языка\фреймворка и, конечно же, в больше степени, коллективной активности сообщества
• Если мы говорим о специалисте в принципе, то не надо зацикливаться на языке\фреймворке. Простите за капитанство. Надо использовать инструменты, вернее, даже связку, которая лучше всего решает поставленную задачу

+ (ИМХО) и фронт и бэк в меру возможностей языков программирования развиваются в сторону SOA-инструментов. Грубо говоря, это когда любую маломальски полезную фичу можно оформить в виде готового подключаемого решения (S — сервис) и встроить в архитектуру (A — Architecture)

А теперь внимание, какое это отношение имеет к Ember.js?

Да очень простое. Вроде как для того, чтобы расширить\кастомизировать поведение приложения, приходится тщательно постучать в бубен (иногда стенкой в свой бубен). то есть он плохо соответствует этой тенденции развития в сторону SOA-инструментов. Поэтому, если я прав и если это не исправится, то очень скоро автор будет искать на кого-бы еще переучиться

[grigoryvp]

Если не секрет, почему такой выбор из трех? Насколько я вижу, сейчас ReactJS набирает популярность, конкурирует с Angular'ом.

[Tonkonozhenko]

Метеор, как я говорил, отпал по причине того что хочу продолжать писать бэкенд на рельсах, а вот между ангуларом и эмбером выбор был сложный. Оба фреймворка хорошие, сообщества тоже. К тому же, я немного работал с Discourse и мне понравилось. В свое время, был в примерно такой же ситуации с Ruby и Python — больше понравился руби, начал с ним работать и теперь не хочу уходить.
В React особо не вникал, но обязательно посмотрю.

[alexfedoseev]

Я тоже не хочу уходить с Рельс. Но хороший фронт тоже очень хочется. Я недавно написал первый апп с React & Rails. В итоге в приложении вместо slim/erb теперь jsx. React просто стал V в MVC рельс. Правда сам React ещё довольно молод и некоторые вещи приходится заново изобретать. Но, судя по темпам, оно скоро исправится. И надеюсь серверный рендеринг в геме допилят до вменяемого состояния.

[malroc]

Я всё хочу спросить, как люди которые с React работают уживаются с этим кошмарным синтаксисом (JSX который)? Тем более после Slim.
Я как на него посмотрю, так сразу пропадает желание учить React. Хотя задумка вроде хорошая.

[alexfedoseev]

Я сначала тоже плевался и пока изучал — всё писал на чистом JS. Но как только переключился с коротких примеров на реальный апп, то очень быстро вернулся к JSX и сейчас у меня с ним в принципе harmony)

[malroc]

Нет, так понятно что на JavaScript эти вьюхи писать невозможно при сколько-нибудь серьёзном объёме. Почему собственно вот это их «никаких шаблонов, только JavaScript» — полнейшая ерунда, JSX те же шаблоны, только уродливые (со смешиванием JS и HTML ещё и без явных разграничений).
Или я может один такой эстет и остальным это не принципиально?

[unel]

Вы не один) Нас даже не двое ;-) Вот ребята сделали тот же принцип, что у реакта (сравнение virtual-dom), но с обычными шаблонами http://www.ractivejs.org/

[malroc]

Ну вот да, это вроде по-человечески выглядит. Но насколько я понимаю, перспективы довольно туманные на фоне всеобщей любви к реакту? Ну то есть реакт-то понятно что теперь будут поддерживать, всё-таки это фейсбук, да и сообщество уже приличное набралось. А тут как-то сильно меньше уверенности.

[v_t]

>вместо slim/erb теперь jsx
>Правда сам React ещё довольно молод и некоторые вещи приходится заново изобретать
Если не менять erb на jsx, то можно использовать готовые решения на jQuery там где это нужно, а сложную фронтенд логику которую удобнее реализовывать с помощью MVC писать на react и подключать ее к erb. Большинству веб-приложений этого вполне достаточно, если, конечно, вы не пишете полноценное SPA. Чтобы все было быстро и современно – достаточно turbolinks с отдельными react компонентами. Все это крайне удобно дебажить и поддерживать, при этом никакие rails гемы переписывать под react не нужно.

[alexfedoseev]

SPA как раз и писал. Изначально поставил себе условие — без jQuery.

[malroc]

Derby не смотрели? Просто если речь о Метеоре зашла (который сколько я его помню, а этом минимум года два, «многообещающий но сырой»), то вроде Дерби намного приличнее смотрится (менее костыльный и не такой сырой), но сам пока его не пробовал.

[Tonkonozhenko]

Meteor вырвался вперед т.к. какое-то время назад получил $11.2M и пишет его команда, а не один человек как Derby.

[malroc]

Ну вот пишет-пишет и всё никак ничего приличного не напишет. Серверный рендеринг так вроде и не сделали по-человечески до сих пор. Хотя казалось бы очевидная вещь, если уж код изоморфный. На Дерби это есть чуть ли не с самого начала.

[nKognito]

Отлично написано, отдельный плюс за четкие схемы и подробное описание. Жду следующей част.

[DSL88]

Уже давненько работаю в EmberJS… В самом начале плевался и ругался на него, а после, когда вник и разобрался, то понял, что штука замечательная: все довольно быстро и удобно.

[malroc]

Вроде слышал что начиная с определённого уровня сложности приложения приходится «бороться» с фреймворком. Ну то есть чтобы вот здесь сделать не так, а немного по-другому, а фреймворк не даёт, он лучше знает. Нет такого?

[DSL88]

Тут есть определенные нюансы, но решить их можно с помощью Ember

[stalkerg]

Клиент жирнеет только в некоторых областях. Если вы пишете публичный сайт, который должен хорошо индексироваться, и хотите максимальной скорости отображения то шаблонизация на сервере и тонкий клиент никуда не уйдут.
Клиент пожирнел, в интранетах или в интернет сервисах которые и раньше с трудом можно было назвать сайтами.

[STEVER]

выбор фреймворка человека, который пришел с серверной разработки:
Java -> Angular
Ruby -> Ember
.NET -> Knockout

я не говорю что это 100%, но сами понаблюдайте на своем примере и примере коллег с других проектов (которые конечно могут влиять на выбор фреймворка)

[roman_truschev]

Вообще похоже, правда у нас два проекта java + ember и ruby + ember.

[bDrwx]

Да, действительно. Тенденция прослеживается в «Разбор полетов» все любят Angular.