Сергей Протько

Например есть задумка, о том чтобы включить на сайт лупу

1) это решается на уровне настройки операционной системы, обычно люди которые хотят что-то разглядеть тупо увеличивают масштаб всего. Лучше проверьте верстку на то что оно нормально реагирует на такое.
2) это решается на уровне системных приложений (вспомните лупу в винде).

или перевод всего в текст.

Как это поможет слабовидящим?

Так же интересует возможность полного управлением функционалом сайта лишь с помощью клавиатуры.

хоткеи? Причем тут люди с ограниченными возможностями?

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

если вы не используете БЭМ а только нейминг - то точно нет. Если вы используете БЭМ - то возможно, зависит от того нужно оно вам или нет.

называется это "виртуальный скролл"

Вот готовый велосипед (и есть еще штуки 4 но у них меньше звездочек)

developerdizzle.github.io/react-virtual-list - тут сразу пример с 100К записей. Большинство тех которые я видел расчитаны только на случаи когда у нас всегда известна высота элемента списка заранее. Во вконтактиках или там линкединах чуть хитрее, там они заранее пытаются пререндрить список ну и им еще помогает то что данные подгружаются не сразу (не сразу 100К айтемов а кусками по 100 штук например). Это дает дополнительный простор для действий.

Достаточно солидны список, неправда ли?

Вы не правильно сделали декомпозицию. Дробите список и перемещайте местами пока не будет абстрактных "базовое знание mysql". Да и зачем фронтэндщику вообще базовое знание mysql или php? Вам нужно знать как с бэкэндом взаимодействовать (HTTP, принципы REST хотя бы приблизительно понимать), примерно понимать что такое базы данных (localStorage, IndexedDB). Словом никаких mysql/php. Это потом когда-нибудь освоите.

Или например список ваших фреймворков. Выкидываем backbone - о нем можно почитать просто что он есть и что из себя представляет, но на вашем этапе толку не будет. Есть тройка лидеров - React/Angular/Ember. Затем идут небольшие фреймворки и библиотеки - Aurelia/Vue/Backbone/etc.

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

p.s. я бы требовал еще es2015/2016, webpack/systemjs/вообще модули, препроцессоры стилей (хотя бы основы и понимание зачем нужны) и т.д.

Ну или еще - jquery можно не изучать. Ознакомиться - да, но на уровне джуниора нужно знать как решить стандартную задачку подключения плагина и организации очереди анимаций. А так в 90% случаев jquery даже и не нужен вовсе. Ну и AJAX - разберетесь с HTTP и вы познаете AJAX.

Ну и последнее. Джуниор это разработчик с годом опыта работы. Это человек который запросто может решать типичные задачи (можно пробежаться по фриланс биржам и составить представление о типичных задачах). Перед джуниором идет стажер.

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

Есть очень простой способ - aws s3 + aws lambda для загрузки файлов и обработке оных по загрузке на сервер.

Реально ли запустить что-то стоящее и приносящее прибыль со знаниями, только лишь, фронтенда?

Нет. Вам нужно еще обладать хоть какими-то навыками предпринимателя и маркетолога. Как минимум вы должны в состоянии составить бизнес план и учесть риски. Ну и у вас должны быть деньги.

Хотя может просто повести и тогда... нужно будет меньше денег)

Вы же понимаете что это никакого отношения к ООП не имеет? Это просто объекты содержащие функции, не настоящие объекты. Ну то есть у вас нет конструкторов, у вас есть "модули".

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

Так же используйте модули, они помогут вам убрать лишние уровни вложенности и добиться изоляции, код станет опрятнее.

Меньше императивной логики, больше декларативного поведения. Если событий реально много можно попробовать посмотреть в сторону observable и ивент стримов.

да и не вся информация запомнится

Важно не запоминать документацию а просто знать что там есть. Можете по документации майндмэпы строить что бы потом проще было возвращаться.

А вьюверы на three.js просто захлопываются от нагрузки.

ну так что же вы хотите, у вас судя по всему весьма жирная моделька. Лучше tree.js для браузеров ничего на данный момент особо нет. Можно попробовать поискать плагины для браузера, разве что.

Вам нужен канбан.

в IE10-11 нормальный дебаггер, а меньше десятки я не суппорчу.

А теперь давайте перечитаем что вы написали и подумаем. Если у вас есть AppComponent, который вроде как все ваше приложение, но есть какой-то компонент (LoginForm) который имеет отличный от AppComponent лэйаут и т.д. то логично предположить что AppComponent это не совсем "компонент верхнего уровня" и т.д.

Авторизация (а точнее авторизован ли чувак) проверяется в ресолверах маршрутов а не в компонентах.

только если вы дизайнер и верстка это не то чем вы будете заниматься.

есть блок элемента

Нет там ничего такого. Есть только блоки, элементы и модификаторы.

<div class="sidebar">
    <div class="sidebar__page-header-logo logo">
        <div class="logo__img"></div>
        <div class="logo__element2"></div>
        <div class="logo__element3"></div>
    </div>
</div>

или если кому (например мне) нравится jade:

.sidebar
    .sidebar__page-header-logo.logo
        .logo__img
        .logo__element2
        .logo__element3

все очень просто. Каждый блок - по возможности независим (отказываться полностью от касказа иногда банально не выгодно). Он определяет базовые стили. А за позиционирование блоков отвечают элементы.