А, ну и последнее. Тупой жирный маскот хомяк.
Наверное, жирные американцы => жирный маскот.

"... но это по моему эффект утёнка и сейчас ангуляровская версия мне больше нравится ..." - а что такое - эффект утенка? ) @vetrovadariya

"... но это по моему эффект утёнка и сейчас ангуляровская версия мне больше нравится ..." - а что такое - эффект утенка? ) @vetrovadariya

Это когда ты учишься что-то делать первый раз и потом начинаешь думать, что такой способ единственно верный, а все, кто делает иначе - идиоты.
Типа, научился писать код на промисах, и после думаешь, что rxjs не нужен

Что первое увидел — то и больше нравится

А, ну и последнее. Тупой жирный маскот хомяк.
Наверное, жирные американцы => жирный маскот.

а яндекс по-моему, даже тестировщиков через алгоритмы гоняет)

а ты работала на ember.js, говоришь? и как он - по сравнению с angular, например?

Не рекомендую.
Там MVC модель, после MVVM не очень заходит.
Там компонент состоит из трёх частей: view (template), controller (разные методы, которые дёргаются из тимплейта, типа клика на баттон и тп, но при этом данные дёргаются не здесь, а в сущности, которая называется route  (по сути в эмбере используется модель Model-View-Controller-Route, в рауте дёргаются данные и всякие приготовления с ними происходят, чем-то похож (из далека) на ангуляровский интерсевптор. То есть, в ангуляре мы дёргаем данные в ngOnInit, а в эмбере есть отдельный файлик route, данные с которого передаются в контроллер через отдельный хук, по моему называется onModel или как-то так. На самом деле для джуна довольно сложного работать с этим зоопарком сразу, даже ангуляр комфортнее)) и Model . Причём, Эмбер по дефолту навязывает определённую структуру проекта, где сущности группируются не по компонентам, а по типам MVC концепции (одна папка - контроллеры, другая - вью, третья модельки). Если работаешь с одним компонентом, то отдельные его части придётся собирать по разным папкам. И да, это можно поправить, но, во-первых, по дефолту стоит именно так (и так в большинстве проектов), а во-вторых, если ты вкатываешься в существующий проект, то договориться с тимлидом поменять структуру проекта на нормальную далеко не факт что получится).
С личной точки зрения, дефолтная структура проекта эмбера прям бесит, ангуляровский подходит намного ближе.

Ещё из личного опыта. Там похожая система директив, но есть некоторые отличающиеся детали, например, аналог ngFor выглядит так

{{each items as item}}
  <li>{{item}}</li>
{{/each}} 

( {{each}} - это штука не существует на уровне итогового html, что-то типа ангуляровского ng-template )
 (пишу примерно по памяти, уже два года не трогала его и слава богу)
То есть примерно похоже, но, вспоминая свои ощущения, было неприятно переходить с эмберовской версии на ангуляровскую (почему-то казалось, что эмберовская версия удобнее, но это по моему эффект утёнка и сейчас ангуляровская версия мне больше нравится).  И в целом у них там целый зоопарк структурных директив (больше чем у ангуляра) с разнообразным синтаксисом, которые придётся учить.

Ещё, по моему, там механизм детекции изменений работает по другому. Почитать можно здесь, если кратко, то

Ember, just like Backbone, sends out events from the data model when changes occur. The difference is that with Ember, there's also something the framework provides for the receiving end of the event. You can bind the UI to the data model, which means that there is a listener for update events attached to the UI. That listener knows what updates to make when it receives an event.

Ещё, из проблем - npm пакеты для эмбера либо плохо написаны, либо отсутствуют (для реакта выбора намного больше, причём, не только больше, но и лучше: лучше документация, меньше ошибок и тп.). Просто потому что коммьюнити фреймворка маленькое.
Насколько я поняла, протаскивать эмбер любят рубисты с бека (его и рекламируют примерно также, как рельсы, тип" фреймворк для амбициозных стартапов"). Если ты не рубист, то лучше не трогать это.
Эмбер использует устаревшие концепции (MVC, data binding, унаследованный от backbone) и, если сравнивать с большой тройкой (Angular, React, Vue), то у него нет никаких (подчёркиваю - никаких   ) преимуществ по сравнению с каждым из них в своей нише. У вас магазинчик с продажей всякого говна, нужно "хуяк хуяк и в продакшн"? Vue . Корпоративное бизнес приложение с графиками и множеством потоков данных и сложной логикой взаимодействия их? Angular . Соц сеть? React .
Ember ? Никогда.

Кстати, по поводу шаблонизации, то в ember handlebars использовался, и angular, когда делали свой, то очень им вдохновлялись. И даже cli был основан на базе ember cli по началу.

☝️ но это все лучше перепроверить, так как было давно и могу путать)

Слушайте , вопрос немного не по фронту - вот есть бд SQL, есть noSql. А есть ещё графовые бд. В чем их особенность перед скл и носкл?

Слушайте , вопрос немного не по фронту - вот есть бд SQL, есть noSql. А есть ещё графовые бд. В чем их особенность перед скл и носкл?

Может кто-то ее использовал?