Я с вами полностью согласен. В моем случае у меня не было выбора. Решение использовать ангуляр было принято "сверху", и все что мне оставалось, по максимуму заставить его работать быстро.
А о том, к чему мы пришли в команде, я написал выше. :)
Как и автор, я не понимаю навязывания везде где только можно RxJS. Нет, с исторической точки зрения, оно понятно. Когда только начиналась разработка Angular 2, то async/await был в черновиках спецификации. И брать в работу что-то, что только в черновике спеки и еще не понятко как будет выглядеть в релизе, было бы очень стремным решением. Да и RxJs был (да и сейчас, благодяря Ангуляру) популярен.
Но сегодня не вчера, можно ведь и по другому.
У себя в проекте, мы сделали так. Разделили логику и компоненты. Все сервисы работают только с async/await. Вся обработка данных, проебразования итд только в service layer. Так же все вызовы к API проходят через инстанс класса API, который всего лишь обертка с методами GET/POST/PUT/DELETE над fetch функцией.
А компоненты ангуляра стали просто крайне простыми компонентами, которые просто берут данные из сервиса и рендерят. Не более.
Из профита.
Service layer может быть написан не ангуляр девелоперами. Если нехватает рук, то ребята с бекенда могут без проблем имплементировать задачу.
Упростилось тестирование, так как тестируем сервис отдельно, а компонент отдельно. И тестирование компонента стало очень простым, так как там просто отображение данных.
Повысился перформанс приложения, так как мы убрали с ангуляра часть работы по проверке, сравнению итд.
Я к тому, что и на ангуляре можно нормально делать приложения. Главное включить думалку, а не слепо следовать разным модным трендам и делать только так, как книжка пишет.
Да нет там особого профита. Просто у людей пригорает от вида JS/TS. Ну вот не заходит им, а взять в команду выделенного фронтенда, возможно, бюджет не позволяет. Вот и страдают.
Но в таких кейсах, почему-то всегда забывают о том что за любой комфорт надо платить, и в конце концов это низкий перфоманс и большое время загрузки. Выше кстати уже написали, что лучше в DevTools не заглядывать. С чего бы это, да? :)
Как по мне. Не вижу никакой проблемы делать фронт отдельно на JS/TS + ваш любимый фреймвок (React/Anguar/Vue etc), а бек на С#.
DI это не просто фабрика по возвращению синглтона класса по ID. Основная идея DI это как раз управление зависимостями. Это избавляет разработчика от внедрения в класс других инстансов.
Вот как это раз это у вас отсутствует. Приведу TS код, как должно быть
Что только не изобретают, лишь бы не писать на Javascript. :)
Кстати, сам JS довольно неплохой язык, особенно в последних спецификациях (ES). Увы, все убивает не сколько JS, столько DOM. Кривое API, которое тянется не одно десятилетие.
Если предстивить на минуту, что кто решил завести другой движок (язык) в браузере, то думаю, его бы ждал такой же перформанс как и с JS, а может даже и хуже. Так как DOM API все тоже.
И вопрос автору, чем синтаксис JS так уж плох? Как я уже упомянул выше, на сегодня в JS много чего вкусного завезли — модули, классы, async/await. Для статики кода можно Typescript использовать, а там и декораторы, и приватные переменные, и типы, и интерфейсы.
Приведу пример, мой хороший друг работает в одном крупном стартапе в Лондоне Product Owner. Так вот когда они начинали, они искали команды (Go девелоперов) на GitHub. И именно github был основным критерием для офера девелоперам.
Если вы еще раз внимательно прочитаете мой пост, то увидите, что я написал — «Мне не сложно было написать эти функции и ответить на простые вопросы...» (с)
Если их еще нет, то возможно настала пора их завести :)
Кстати, мои проекты не супер популярны и половина была написана «just for fun», но сам код и подходы я старался проработать по максимуму, что бы не стыдно было.
Если у сеньера все таки нет ничего из open source, тогда возможно есть один два домашних проекта, которые не стыдно показать.
Приведу примеры задач и вопросов из интервью, которые были у меня. Итак собеседование на позицию Architec, Tech Lead, Senior TS/JS developer. Все что связано с фронтом короче.
— напишите функцию замены строки ДНК на другой участок ДНК
— напишите функцию фибоначчи
— напишите сортировку массива
— что такое замыкание
— что такое промис
-итд
А теперь главный вопрос — это серьезно задачи для архитектора и тех лида? Таких интервью у меня были десятки только за последние 10 лет моей 20-летней карьеры.
Понимаете, никак, вот совсем никак, такие задачи не раскрывают моих умений и знаний. Мне не сложно было написать эти функции и ответить на простые вопросы. Но где вопросы об архитектуре, о походах проектирования проекта, о организации документации, подходах к тестированию?
Когда таких интервью один или два — ты просто не обращаешь внимания. Когда десятки — это начинает раздражать.
Перед любым интервью оговаривают этот момент, что кодить не буду, так как это вообще не показатель для сеньора. В место этого, даю ссылку на свой github профиль, где у меня мои open source проекты. Открывайте, смотрите код, коммиты. Будут вопросы — с радостью пообщаемся, расскажу почему и как выбрал то или иное решение.
И знаете, это экономит как общее время так и мои нервы.
Ну мы пока еще живем по классической схеме у нас компании. Микрофронтенд пока на этапе архитектуры. Пока изучили плюсы и минусы. И я все еще в сомнениях. Стоит оно того или нет.
Позвольте мне немного внести понимания зачем это нужно.
Давайте посмотрим на классическую схему, шаг за шагом:
Команда/Проект
Разработка
Тестирование
Публикация в NPM (NPM приватный)
Оповещение других команд или обновление других проектов на новую версию
Как видно из списка, есть проблема в последнем пункте. Т/е как только мы опубликуем изменения, это не значит, что они будут доступны для использования. Т/е вам еще надо будет разослать уведомления командам, о том, вы опубликовали измения/багфиксы. И дождаться, когда другие команды обновят зависимости. Из реальной жизни пример — обновление на новые версии иногда занимает день-два. Это очень долго, поверьте мне.
Следующая проблема. Надо срочно откатиться на предыдущую версию. Бывают случаи, когда баг таки просочился на прод. Как быстро откатиться? Проблема.
Нет, такая схема с публикацией модуля/либы в NPM, прекрасно работает, когда у вас два-три тима. Но когда их уже за 10-к. Постоянно возникают задержки.
Вот один из путей решения — микрофронтенд. Где команда выкладывает JS билд (что-то типа myspa.com/app/component1.js), а приложение уже по необходимости, загружает отдельно файл в браузер.
Такой подход решает проблему публикации и отката версий, так как код сразу становися доступен после публикации.
По поводу IFrame. Да они тоже могут использоваться, но как решить проблему глобального стейта? Как красиво позволить компонентам обмениваться данными, реагировать на изменения? Не, не спорю — можно. Но будет ли это изящно — не факт :)
Только что замерил. Практически одно и тоже время, как проверка по ключу, так и поиск в массиве.
Я когда-то тоже так делал, как автор статьи. Заводил индексный объект, как я его тогда называл. Думал, что перфоманс будет улучшен. И вот в один день я проводил лекцию для джунов, где делился всякими фишками по JS. Ну и типа что бы показать, что можно улучшить, сделал такой тестовый пример. И когда замерил — ой! Реально был удивлен. Так что профита такой подход особо не приносит, и я от него отказался в последствии.
Хотя, надо на досуге покопать. Может можно как-то заставить это работать быстрее.
Я с вами полностью согласен. В моем случае у меня не было выбора. Решение использовать ангуляр было принято "сверху", и все что мне оставалось, по максимуму заставить его работать быстро.
А о том, к чему мы пришли в команде, я написал выше. :)
Как и автор, я не понимаю навязывания везде где только можно RxJS. Нет, с исторической точки зрения, оно понятно. Когда только начиналась разработка Angular 2, то async/await был в черновиках спецификации. И брать в работу что-то, что только в черновике спеки и еще не понятко как будет выглядеть в релизе, было бы очень стремным решением. Да и RxJs был (да и сейчас, благодяря Ангуляру) популярен.
Но сегодня не вчера, можно ведь и по другому.
У себя в проекте, мы сделали так. Разделили логику и компоненты. Все сервисы работают только с async/await. Вся обработка данных, проебразования итд только в service layer. Так же все вызовы к API проходят через инстанс класса API, который всего лишь обертка с методами GET/POST/PUT/DELETE над fetch функцией.
А компоненты ангуляра стали просто крайне простыми компонентами, которые просто берут данные из сервиса и рендерят. Не более.
Из профита.
Service layer может быть написан не ангуляр девелоперами. Если нехватает рук, то ребята с бекенда могут без проблем имплементировать задачу.
Упростилось тестирование, так как тестируем сервис отдельно, а компонент отдельно. И тестирование компонента стало очень простым, так как там просто отображение данных.
Повысился перформанс приложения, так как мы убрали с ангуляра часть работы по проверке, сравнению итд.
Я к тому, что и на ангуляре можно нормально делать приложения. Главное включить думалку, а не слепо следовать разным модным трендам и делать только так, как книжка пишет.
Всем добра! :)
Да нет там особого профита. Просто у людей пригорает от вида JS/TS. Ну вот не заходит им, а взять в команду выделенного фронтенда, возможно, бюджет не позволяет. Вот и страдают.
Но в таких кейсах, почему-то всегда забывают о том что за любой комфорт надо платить, и в конце концов это низкий перфоманс и большое время загрузки. Выше кстати уже написали, что лучше в DevTools не заглядывать. С чего бы это, да? :)
Как по мне. Не вижу никакой проблемы делать фронт отдельно на JS/TS + ваш любимый фреймвок (React/Anguar/Vue etc), а бек на С#.
Wiki DI
Так же рекомендую глянуть под капот очень популярной либы inversify
Вот как это раз это у вас отсутствует. Приведу TS код, как должно быть
где UserService и GroupService это сервис классы, которые так же имеют свои зависимости. И DI должен уметь строить дерево зависимостей.
Удачи в доработке :)
Кстати, сам JS довольно неплохой язык, особенно в последних спецификациях (ES). Увы, все убивает не сколько JS, столько DOM. Кривое API, которое тянется не одно десятилетие.
Если предстивить на минуту, что кто решил завести другой движок (язык) в браузере, то думаю, его бы ждал такой же перформанс как и с JS, а может даже и хуже. Так как DOM API все тоже.
И вопрос автору, чем синтаксис JS так уж плох? Как я уже упомянул выше, на сегодня в JS много чего вкусного завезли — модули, классы, async/await. Для статики кода можно Typescript использовать, а там и декораторы, и приватные переменные, и типы, и интерфейсы.
Т/е за каждую строчку своего кода я готов ответить. Это самый дейтвенный способ проверить, мой это код или нет :)
Так что ваш сарказм неуместен.
Если в компанию требуется специалист высокого уровня и в компании нет людей, способных провести интервью, то следуют двум путям:
— Затратный. Нанимают людей или компанию, с подходящим уровнем, со стороны для аудита кандидатов.
— Дешевый или сарафанное радио. Ищем среди друзей, людей с уровнем знаний и договариваемся за пиво/кофе/пиченьки.
Но признаюсь, я такое в своей жизни не встречал.
Но все же повторю — мне не сложно было ответить и написать, что я и делал. И увы, придется делать в будущем.
И это не нытье, это разговор о полезности/бесполезности некоторых видов интервью.
Так что, к чему ваши замечания?
Кстати, мои проекты не супер популярны и половина была написана «just for fun», но сам код и подходы я старался проработать по максимуму, что бы не стыдно было.
Если у сеньера все таки нет ничего из open source, тогда возможно есть один два домашних проекта, которые не стыдно показать.
— напишите функцию замены строки ДНК на другой участок ДНК
— напишите функцию фибоначчи
— напишите сортировку массива
— что такое замыкание
— что такое промис
-итд
А теперь главный вопрос — это серьезно задачи для архитектора и тех лида? Таких интервью у меня были десятки только за последние 10 лет моей 20-летней карьеры.
Понимаете, никак, вот совсем никак, такие задачи не раскрывают моих умений и знаний. Мне не сложно было написать эти функции и ответить на простые вопросы. Но где вопросы об архитектуре, о походах проектирования проекта, о организации документации, подходах к тестированию?
Когда таких интервью один или два — ты просто не обращаешь внимания. Когда десятки — это начинает раздражать.
И знаете, это экономит как общее время так и мои нервы.
Давайте посмотрим на классическую схему, шаг за шагом:
Как видно из списка, есть проблема в последнем пункте. Т/е как только мы опубликуем изменения, это не значит, что они будут доступны для использования. Т/е вам еще надо будет разослать уведомления командам, о том, вы опубликовали измения/багфиксы. И дождаться, когда другие команды обновят зависимости. Из реальной жизни пример — обновление на новые версии иногда занимает день-два. Это очень долго, поверьте мне.
Следующая проблема. Надо срочно откатиться на предыдущую версию. Бывают случаи, когда баг таки просочился на прод. Как быстро откатиться? Проблема.
Нет, такая схема с публикацией модуля/либы в NPM, прекрасно работает, когда у вас два-три тима. Но когда их уже за 10-к. Постоянно возникают задержки.
Вот один из путей решения — микрофронтенд. Где команда выкладывает JS билд (что-то типа myspa.com/app/component1.js), а приложение уже по необходимости, загружает отдельно файл в браузер.
Такой подход решает проблему публикации и отката версий, так как код сразу становися доступен после публикации.
По поводу IFrame. Да они тоже могут использоваться, но как решить проблему глобального стейта? Как красиво позволить компонентам обмениваться данными, реагировать на изменения? Не, не спорю — можно. Но будет ли это изящно — не факт :)
Я когда-то тоже так делал, как автор статьи. Заводил индексный объект, как я его тогда называл. Думал, что перфоманс будет улучшен. И вот в один день я проводил лекцию для джунов, где делился всякими фишками по JS. Ну и типа что бы показать, что можно улучшить, сделал такой тестовый пример. И когда замерил — ой! Реально был удивлен. Так что профита такой подход особо не приносит, и я от него отказался в последствии.
Хотя, надо на досуге покопать. Может можно как-то заставить это работать быстрее.
Создайте объект с 50 атрибутами
const obj = {a: true, b: true, c: true, ...};
Далее создайте массив с ключами
const arr = ['a', 'b', 'c', ...];
Теперь запустите в консоли
console.time('obj'); console.log(obj['c'] === true); console.timeEnd('obj');
а потом и для массива
console.time('arr'); console.log(arr.includes('c')); console.timeEnd('arr');
И вуаля! Скорость почти одинакова!
На вопрос почему так. Полагаю что дело в HashMap таблицах под капотом в движке. Но это не точно :)
PS заранее извиняюсь, что нет решения для старых браузеров. Просто хотел обратить внимание, что объект как ключ возможно не улучшит перформанс.