Alex

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

• WordPress написан на PHP, так что очевидно, что PHP вам нужно знать.
  
• Вам нужно знать какие-то основы в CSS, JavaScript и HTML, если вы планируете только интегрировать готовую верстку на Wordpress.
  
• Вам нужно знать не только основы CSS, JavaScript и HTML, но и уметь хорошо работать с этими технологиями, если вы планируете делать сайт полностью с нуля
  

Это всё нужно и для простых и для сложных сайтов. Правда к сложным сайтам может добавиться ещё много чего другого, но основа разработки под WordPress - это PHP, JavaScript, CSS, HTML.

Насколько вообще подробно надо вникать в языки программирования?

Подробно нужно. Чем подробнее - тем лучше :)

Я прошла совсем базовый курс по html5.

HTML - это не язык программирования.

Можно ли учиться по курсам от 2014-15-16 годов?

Можно, чтобы иметь представление о том, что это такое и как работает. Потом вы всё равно будете неоднократно посещать документацию. Можете пользоваться вот этим ресурсом https://wp-kama.ru/. Достаточно много чего полезного можно найти.

> Я могу себе представить требования к backend, потому что backend сложнее.
Нет

> Там нужно учитывать количество пользователей, контролировать нагрузку, управлять памятью.
Во фронте тоже нужно это учитывать

> Там разного рода масштабирования, linux и sql.
Во фронте много js, json, xml, CS, много зрелых технологий на изучение которых требуется много времении сил, много новых технологий.

> А вот требования к frontend разработчику высокого уровня мне представить сложно. Тут один достаточно простой (по сравнению) ЯП, приходящие модные технологии вроде babel, webpack и TypeScript, которые еще сильнее упрощают работу и какой-нибудь фреймворк.
А как же webassembly, html5, RMTP, и другое медиа? Флэш сейчас уступил место JS и HTML5, но это только расширяет возможности использования.

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

> Фронтенд не масштабируется, не реплицируется.
Так можно говорить, если переложить всю работу на бэкенд. А правильно - грамотно распределять что делает фронтенд, что делает бэкенд и оптимизировать передачу данных. Это оба специалиста должны сотрудничать.

> В целом, если его очень хорошо протестировать, то разработчик уверен на 99.9%, что все работает на всех браузерах и на всех утройствах. Здесь не может быть ситуации, когда пришло слишком много пользователей или память на сервере закончилась.
Ну как это не может? Вы знаете все устройства, где запустится ваше вебприложение? А если на смарттв? А если на нонейм планшете? А если это голосовой чат в веб-приложении на 50 человек?

> Тут нет мониторинг систем.
Зато есть понимание метрик, их сбора, и отправки на бэкенд или куда-то еще?

Вдобавок фронтенд, в отличие от бэкенда, ОЧЕНЬ быстро прогрессировал за последние несколько лет. Настолько быстро, что хороших специалистов крайне сложно найти - они просто не успевают изучить все, что на них падает. Бэкенд постабильнее, там печатные книги успевают выйти в 10-м издании.

linux

Ну, это и фрондендеру нужно часто знать.

ЯП

Я сомневаюсь, что он сейчас сильно проще питона или php, JS очень довольно быстро развивается. А если взять в расчет TypeScript, то тем более.

В целом, если его очень хорошо протестировать, то разработчик уверен на 99.9%

Совсем нет. Не получится протестировать на всех браузерах, на всех операционных системах и на всех устройствах с разным экраном, с разным способом ввода.

то в случае с frontend все гораздо проще

Ну вот просто вообще не правда. Я также могу сказать, что в бэке учить нечего, изучил язык, изучил laravel, а sql даже учить не надо, используй ORM. Справедливое высказывание?

Теперь в общем. Во front-end много чего можно изучить
1) Верстка. Хороший front-end'ер должен хорошо верстать, вопреки частому мнению, что этим должен заниматься верстальщик. А верстка это отдельная широкая тема.
2) SVG, для многих интерактивных приложений, очень полезно использовать svg, а там куча своих особенностей, хаков и.т.д.
3) Webgl - довольно сложная тема, не знаю, есть ли в бэке что-то аналогичное по сложности.
4) Canvas - не просто знать, а уметь рисовать то, что желаешь.
5) Фрейморки, а там тебе для каждого свое разветвление.
6) Асинхронное программирование, которое для многих php-шников кажется непонятным.
7) ООП, т.к. в JS завезли классы, да и TypeScript часто нужно использовать.
8) Шаблоны проектирования - не только для бэкенда.
9) Webpack+gulp - ну это было.

Буду дополнять, если что-то еще в голову придет.

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

На TS есть фреймворк, называется Nest. Он изначально использует модульную структуру, и там она реализована достаточно хорошо. Гляньте.

Далее как я делаю в Laravel проекте:
- /vendor - зависимости компоузера, в виде сторонних библиотек и компонентов symfony/laravel. Там есть весь базовый функционал, как, например, работа с БД. Такие зависимости в любом случае будут тесно связанны с логикой приложения, и думать об их удалении не стоит вообще. Максимум, что вы можете - построить слой абстракции над /vendor, но это ПЛОХАЯ идея.
- /app/Ship - увидел это в другом фреймворке, называется Apiato. Сам по себе он хрень, но сама идея мне понравилась. Этот "корабль" - слой твиков, временных фиксов, загрузчиков и другого, что касается каких-то базовых, недостающий частей фреймворка/библиотек, и используется всемя модулями в проекте. Например:

• загрузка модулей. Так как для laravel нету нормальной системы, пришлось написать свой костыльчик. Лежит он в ship.
  
• обработчик исключений
  
• ядра (хттп и консольное)
  
• твики для миграций
  
• общие трейты, скоупы
  
• миксины
  
• общие миддлвейры
  

В общем все то, что относится ко всему проекту в целому. Структура - хаотична.

Таким образом в третьем, финальном слое, у меня только чистая бизнес логика:
- /app/Containers - контейнеры - пафосное слово на замену модулям. Идея та же. В каждом контейнере, в корне, лежит класс с названием контейнера, в котором находятся такие штуки как: краткое название для авто-префикса ресурсов, список провайдеров и миграций (назовем их "штуками из фреймворка", к структуре не относятся).
Структура каждого контейнера:

• API/ - все, что касается хттп апи приложения
  - Controllers/ - контроллеры хттп
  - Requests/ - классы form request хттп
  - Tests/ - функциональные тесты этого апи
  - routes.php - файл раутов
  
• Broadcasting/ - все, что относится к броадкастингу через сокеты
  - Events/ - сами классы эвентов
  - channels.php - файл регистрации каналов броадкастинга
  
• Configs/ - конфиги этого конкретного контейнера (и НЕ его зависимостей)
  
• Extra/ - иногда бывает что-то, немного выходящее за рамки контейнера, но еще не входит в Ship. Идет сюда.
  
• Middlewares/ - хттп миддлвейры
  
• Database/ - все, что связано с базой данных
  - Factories/ - файлы пхп, регистрирующие фабрики моделей ларавель
  - Migrations/ - классы миграций
  - Seeders/ - сидеры базы
  - Setup/ - классы-фабрики, обложка над Factories
  
• Enums/ - энамы
  
• Exceptions/ - исключения
  
• JsonResources/ - гсон ресурсы
  
• Models/ - eloquent модели
  
• Providers/ - провадйеры
  
• Services/ - маленькие классы-сервисы, содержащие всю бизнес логику, не привязанные к ХТТП. Каждый сервис выполняет либо одну задачу, либо несколько мелких задач одного типа. Singleton
  
• Traits/ - трейты
  

Все, что я выше указал - либо часть самого языка (как трейты), либо часть фреймворка Laravel. Гуглите.

Есстественно, под разные фреймворки внутренняя структура каждого контейнера может и будет менятся.

PS: БД одна для всего проекта. Зачем вам разные БД, когда есть разные таблицы?)
PS2: то, что вы себе представили - называется микросервис. Выполняет какой-то небольшой набор задач, имеет отдельную базу и вообще изолирован от всего остального. Но раз вы задаете такие вопросы, вам они точно не нужны.

Как вариант использовать Symfony. Уже имеет модульную структуру (модули используют одну БД, но каждый может использовать свои таблицы и быть независимым от остальных)

возможно это сделать вообще

Dropbox же есть, значит возможно.

написать свой сайт, где будут хранится мои файлы

Это и без облачных технологий можно сделать.

Как это реализовать?

1. Изучить принципы web-разработки;
   
2. Изучить Python;
   
3. Выбрать подходящий фреймворк;
   
4. Написать код;
   
5. Настроить сервера(а);
   
6. Развернуть на них свой проект.
   

parseFloat("222") // 222
parseFloat("222.2") // 222.2

//есть parseInt, но 
parseInt("222") //222 
parseInt("222.2") //222

Если просто склейка, то и ffmpeg справится

AWS

В общем. Хочется проверить свои навыки, но в тюрьму не хочется : )

Поставьте себе на виртуалку какую-нибудь популярную CMS и ломайте на здоровье.