Максим Иванов

Я бы написала в профиле подробнее о том, что хочет менять сферу деятельности. И прямым текстом, что очень заинтересована в стажировке.

И прокомментировать нерелевантный опыт работы. Что, мол, да - не дизайнером, но такие-то личные качества, как минимум, были развиты. Как минимум ясно, что она не разгильдяйка (раз кем-то работала) - можно эту мысль аккуратно сформулировать и проговорить, а не оставлять эйчарам соображать самим.
Можно пригласить в портфолио - мол, вот там ссылка, обязательно сходите.

Еще насчет опыта работы - можно ли как-нибудь передвинуть "Дарси Студио" в начало списка, наверх? А преподавательский - ниже? Или HH принудительно так расставляет? (я не помню, как и что на НН) Просто сейчас человек начинает читать - и с порога видит "преподаватель", так что может и не дойти до "контент-менеджера", бросить... Можно кстати попутно переименовать "контент-менеджера" в "контент-менеджера с функциями дизайнера"; название должности чуть изменить.

Сертификат слабый :( Всего 6 часов обучения. Надо еще каких-нибудь сертификатов где-то добывать.

Поставьте фронтэндом nginx и повесьте на один IP адрес хоть сотню сервисов на 80 порту с доступом по доменному имени.

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

Рассмотрим упомянутые варианты...

AngularJS. JS. Он пляшет от шаблонов. В этом его сила (заверстали страницу, добавили директив и готово) и слабость (динамическое формирование страниц, как вы заметили, даётся с большим трудом). Криво реализованное двустороннее связывание и обнаружение изменений приводит к странным костылям и тормозам.

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

Vue. JS. По уму сделанный AngularJS. Довольно практичный (если не пытаться прикручивать TS) с приятной "затягивающей" реактивностью. Из трендовых фреймворков я бы обратил внимание именно на него.

React based. JS. Сам реакт - не более чем библиотека для рендеринга. Так что под его лейблом подразумевается на самом деле "мы написали свой фреймворк, в котором рендерим через реакт". Достаточно легко в нём реализуется динамика. Но с переиспользуемостью кода и его лаконичностью - просто беда. Куча копипасты во имя великой идеи с глобальным состоянием - типичная ситуация. Каждый такой фреймворк по своему уникален, так что "знание реакта" мало чем помогает при вхождении в проект.

Polymer. JS. Попытка воспользоваться самыми последними стандартами. Всё крутится вокруг DOM, что весьма не эффективно. Реактивности как таковой нет. Спека ShadowDOM имеет уже вторую версию и та весьма ограниченна и требует костыльных костылей и вытягивания гланд через анус при использовании. Динамика с одной стороны отличная - рендерите что угодно куда угодно и динамически всё подгружается. Но без "вулканизации" вся эта динамика дико тупит, поэтому всё-равно всё объединяют в один бандл.

$mol. TS. Полностью динамичен и ленив. Что угодно может быть динамически загружено, но в этом нет необходимости, так как компоненты получаются крайне компактными, а в бандл тянется лишь то, что реально используется. Рендерит тоже по возможности лениво, что позволяет быстро показать даже очень большую страницу. Имеет стандартную библиотеку компонент. В качестве примера, могу привести визуальный редактор компонент, который динамически строится по его коду и тут же в рантайме этот компонент изменяет (он ещё в разработке, но уже много чего позволяет): mol.js.org/#demo=mol_app_hello/edit/path

К тем вариантам, что "JS", разумеется можно прикрутить сбоку и TS, но очень ограниченно:

1. Будет много кода с декларациями типов и мало выведения типов.
   
2. Практичная с точки зрения JS магия вырождается в весьма непрактичную борьбу с типизацией.
   
3. Многие библиотеки/плагины/компоненты написаны на JS. В лучшем случае вы сможете своими силами написать для них типы.
   

Итого:

1. Под вашу задау идеально подходит $mol, но он далеко не в тренде (80 звёзд на гитхабе, ага). На нём можно быстро разрабатывать приложения, но сложно найти работу. Если есть желание, то мы ищем разработчиков от стажёров до сеньёров.
   
2. Из востребованного сейчас на рынке: AngularJS, React*. Мой прогноз - скоро реакт выйдет из моды. Многие уже обожглись на нём, нафигачив горы говнокода, и переползают на более практичный Vue.
   
3. Для устройства в Я имеет смысл изучать BEMJS (тогда точно возьмут :-D) или что-то трендовое типа React или Vue ну и VanillaJS нужно знать обязательно. Я сам в нём 2 раза работал, но как видите самореализоваться там не смог.
   
4. Так как сроки у вас поджимают, то переписывать проект уже поздно. Так что лучше подумать о типичных костылях: CDN, нескучная анимация загрузки, агрессивное кеширование. Тем не менее по скорости разработки я бы отсортировал решения в следующем порядке (от быстрой к медленной): $mol, Vue, Angular, Polymer, React*
   
5. Производительность и размер приложений на упомянутых фреймворках можете сравнить тут: mol.js.org/app/bench/#bench=https%3A%2F%2Feigenmet...
   
6. Так как у вас энтерпрайз, то выбирать стоило бы из фреймворков, предоставляющих свою библиотеку высокоуровневых компонент (ExtJS,OpenUI5,KendoUI,VCL.JS,$mol). Энтерпрайзу обычно скорость разработки, богатство и единообразие функциональности важнее кастомных дизайнерских изысков на каждом экране.
   
7. Для разработки более-менее крупных поектов имеет смысл брать фреймворки написанные с использованием статической типизации, тогда вы получите от типизации больше преимуществ и меньше боли. Их пока ещё не очень много: Angular (TS/Dart), $mol (TS), CycleJS (TS), VCL.JS (TS)...
   
8. Джуниору лучше не заниматься созданием нового фреймвора (даже на Реакте), ничем хорошим это не закончится. Тут нужен опыт, чутьё и рациональность. Не у каждого сеньёра это всё есть.
   
9. IE10 - это боль и страдания. Вы профилировали, на что именно уходит больше всего времени (загрузка, инициализация приложения, загрузка данных рендеринг)? Возможно стоит уменьшить объём единовременно отображаемых данных или подумать о серверном рендеринге ангуляровских шаблонов.
   

Хочу узнать, мне теперь переписывать весь проект на другую технологию

а вам выделят бюджет переписать все с нуля ?
да в react есть возможность разбить бандл на части но вы уверены что вам это нужно ?
я не писал на angular но мне очень интересно и если это не займет много времени поделитесь пожалуйста сравнением сколько весит бандл с 10 компонентами, 50 и 200

Если Vue такой крутой, почему на нем мало вакансий

Ты сам ответил на этот вопрос. Потому что почти все корпоративные монстры вливают бабло в разработку на Реакте!

Кроме того, вакансии на Вью растут по экспоненте. Недавно выкладывали статистику. Рост очень стабильный.

Ну я React даже не трогал, на первом Angular писал когда-то и вот несколько месяцев уже на Vue работаю.
Я бы брал Vue. Порог вхождения у него низкий, документация русскоязычная просто пушка, ну и для вашей задачи мне кажется самое то.

Да, можно.

специальные заголовки для css и js файлов

"Специальные заголовки" не имеют никакого отношения ни к js, ни к css, ни к содержимому ресурса вообще. Content-Encoding: gzip означает, что тело ответа закодировано в gzip, что там внутри - вообще неважно. Тип содержимого определяется другим заголовком - Content-Type.

В 2006 году появился AJAX, это сильно изменило мир фронтенда. Тогда и начался перелом.

По пунктам:

Почему в университете стало популярней разрабатывать сайты, ежели учить C++ и писать "толстые" клиенты.

Потому что скриптовые языки дают существенно бОльшую скорость разработки чем C++ что собственно является главным аргументом. Разработчики стоят дороже железа условно.
С++ остается в каких-то узко-специфических задачах со сложной математикой где производительности скриптовых языков не хватает. Писать на C++ интерфейс не актуально года с 2000 пожалуй что.

Когда произошла точка перелома, что "тонкие" клиенты теперь популярней и почему? Хотя ведь мобильные приложения, это ведь тоже "толстый" клиент

И мобильное приложение, и фронт сайта - могут быть и тонким и толстым клиентом, зависит от конкретного проекта.
Это всегда баланс между бизнес-хотелками и затратами.
Толстый клиент - лучше отзывчивость интерфейса, можно вынести часть нагрузки на железо клиента, дороже поддерживать (дорогие ios/android/angular/... разработчики, специфические проблемы синхронизации данных).
Тонкий клиент - все наоборот :)

UPD Если трактовать вопрос в стиле "почему веб более популярен чем десктоп":
1. Как показывает практика любой софт который физически крутится у пользователя можно взломать и получить бесплатно. Если софт не лежит на торентах - скорее всего он никому не нужен.
2. Многие сервисы сейчас продаются по модели ежемесячной-ежегодной подписки - это даёт существенно лучшие экономические показатели чем продажа платных обновлений.
3. Интернет становится все более доступным и по географии и по $, все более быстрым.

Все это делает модель SAAS и её наследников весьма привлекательным.
Я бы сказал так - сейчас нужны какие-то ОЧЕНЬ веские причины не использовать SAAS.

Потому что все каждый день в интернете взаимодействуют с фронтендом. А где работает с++ я даже не знаю.
Еще во фронте нет сложной математики.

Вы можете добавить синонимы (alias):

module.exports = {
  resolve: {
    alias: {
       // имя синонима: путь
       'style': path.join(__dirname, 'style.override.css'),
       'любоеУдобноеИмяСинонима': path.join(__dirname, 'путь к модулю'),
       'любоеУдобноеИмяСинонима2': 'илиТакЕслиВкорне',
    }
  }
}

И использовать синонимы в коде:

import 'style';
import 'любоеУдобноеИмяСинонима';
require('любоеУдобноеИмяСинонима2');

В webpack.config.js можно добавить любой функционал для получения путей к синонимам, да и в целом можно все что угодно сделать:

var suffix = '.override';

module.exports = {
  resolve: {
    alias: {
       'style': path.join(__dirname, 'style' + suffix + '.css'),
    }
  }
}

Что касается передачи пользовательских переменных через командную строку, то можно попробовать их указывать через SET (если под Windows). Будет что-то типа этого:

SET ANY_NAME="VALUE" && webpack -d --color

Найти переменные можно в process.env. Чтобы сделать вывод переменных в консоль, добавьте в файл webpack.config.js следующую строчку кода:

console.log('process.env', process.env);
console.log('ANY_NAME', process.env.ANY_NAME);

Признаки плохого дизайна:

- Использование глобальных переменных (у вас же есть контейнер зависимостей)
- Вы почти везде инжектите инджектор. Это означает что вы часто полагаетесь на serviceLocator и это является плохой практикой. Это делает зависимости в коде менее явными.
- кастомные компоненты должны иметь какой-то префикс (по спецификации w3c) как минимум что бы отличать какой компонент откуда. То есть вместо loginContent лучше назвать это дело myLoginForm или что-нибудь описывающее что это за контрол. Это все же компонент а не "контент".
- Использование jquery. Он вам не нужен. выставите нужный стэйт и ангуляр сам обновит DOM.
- кривой хэндлинг аутентификации. Используйте интерцепторы и ждите 401-ой ошибки. Остальные ошибки не должны бросать на логин. Ну может у вас бэкэнд кривой тогда ладно.
- mixinsRegistry - какая-то сатана. Не делайте так. Делайте все явно.

цикл пробегается раньше чем отрабатывает timeout
/* написаное ниже - ошибочно */
JS однопоточен, поэтому setTimeout фактически выбрасывает код в конец текущего обработчика, когда i == 10
/* написаное выше - ошибочно */

можно прибегнуть к ES6 и использовать оператор let

for (let i = 0; i < 10; i++) {
  setTimeout(function () {
    console.log(i); // ?
  }, 0);
}

таким образом мы сократили область видимости переменной i до блока внутри цикла
а в случае с var переменная была общая и setTimeout выводил только ее конечное значение

UPD: дока для ознакомления тут https://learn.javascript.ru/let-const

UPD2: По поводу однопоточности я ошибся (в том что это причина).
Исправляюсь )) как оказалось. setTimeout(func,0) и setTimeout(func,4) выполнятся одновременно.
По крайней мере в хроме. минимальный порог значения таймаута в разных браузерах может отличаться, но он больше 0мс. В хром это 4мс. обусловлено это тем, что многие используют setTimeout для асинхронности и страница где несколько setTimeout(func,0) сильно нагрузит процессор. По крайней мере базовой причиной появляения минимальной задержки называют это.

while true; do
    inotifywait -qq -e create,close_write,modify,move,delete $CHECK_FOLDER && $BUILD_COMMAND
done

Стоит ли все function собирать в одном файле?

Нет. Группируйте функции по их зоне ответственности. В целом вам просто должно быть удобно. Попробуйте через неделю найти какую-нибудь функцию и засеките сколько на это у вас ушло времени.

И стоит ли плодить около 5-10 функций для разборчивости кода?

Стоит. Это называется декомпозицией. Когда вы одну большую задачу (отобразить страницу) дробите на маленькие подзадачи. Велик шанс что на других страницах что-то из этого пригодится. Да и просто так удобнее. Маленькое проще править чем большое.

Дело в том, что между точками следования (это точка с запятой, вызов функции и экономные операции &&, || и ?:) компилятор имеет право переставлять операции как хочет. Вот он и решил вычислять c++ с конца.

В C++11 нет точек следования, есть «вычисляется прежде», но языка это кардинально не меняет.

В C++17 это обещают поправить.
19) In a shift operator expression E1<<E2 and E1>>E2, every value computation and side-effect of E1 is sequenced before every value computation and side effect of E2

en.cppreference.com/w/cpp/language/eval_order

ЗЫ. MinGW даже предупреждение выводит, что результат такой строчки явно не определён. И на классе Co тоже (см. флейм с Толстым Лорри).