Ну все, тогда шли резюмехи и говори какие крутые у тебя петы

Только не забудь задеплоить их куда-нибудь

Они их производят, новые версии выпускаются, закрывать не планируют (сама планирую взять скоро). Что значит не выстрелил по твоему?

Дык сейчас я бы уже лучше их написал.а переписывать в падлу.

Особенно верстку

Во что?

Котлин мультиплатформ

За советы спасибо, как диплом допишу,так буду активно искать джуниорские позиции.а пока только стажки:)

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

Перепиши. Это часть обучения

Вообще да,согласен.

Нашел тут подсказку по тайлвинду, удобная: https://umeshmk.github.io/Tailwindcss-cheatsheet/

Тебе надо попробовать сделать одно и то же миллионом путей. Это справедливо для любого навыка

Я на реакте делаю то что делал на ангуляре сейчас. Но пока забил,так как надо изучить другое

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

а чего так на tailwind все писяют кипятком сейчас? года три назад - работал на проекте vue+tailwind; по мне - это был кошмар какой-то; tailwind мне тогда показался - прокрустовым ложем каким-то, по сравнению с обычным scss

Да никто не писает, просто удобно 🙂

надо попробовать )

Не рекомендую.
Там 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 ? Никогда.