Как подступиться к fullstack-разработке сегодня, если ты проспал десять лет

В качестве вступления...

Базовые понятия

• В первую очередь, актуализируйте свои знания о современных стандартах, используемых для вёрстки (HTML5, CSS3 и вот это всё). Также полезно будет прочесть про эволюцию ECMA Script (JS, на самом деле, это реализация именно этого стандарта), и освежить свои знания про JSON и JWT.
• Объектно-ориентированный подход в программировании. Да-да! Многие, кто, вроде бы, понимает о чём речь, саму идею не до конца осознают, хотя она и появилась лет 50 назад. Поэтому желательно ещё раз ознакомиться, если хоть чуть-чуть сомневаетесь.
• Системы контроля версий. Это абсолютный вин, знать их сегодня просто необходимо всем, кто работает в сфере разработки любого ПО. Даже если работаешь один системы контроля версий очень полезны, а уж в команде без них просто ад. Раньше для этого использовали, в основном, SVN или CVS, просто потому что серьёзных конкурентов у них почти не было. Сейчас стандарт де-факто это GIT (спасибо Линусу Торвальдсу). Я рекомендую начать с изучения консольной версии (даже для Windows), это займёт от силы пару дней, но когда придёт понимание, все фишки (типа git flow) вы поймёте очень быстро, а там уже и GUI-клиент какой-нибудь можно будет поставить. И уж совсем крутым можно стать, например, если освоить git hooks и настроить отправку данных на боевой сервер при коммите в мастер-ветку репозитория проекта.
• Концепция MVC (не будет преувеличением сказать, что практически во всём современном вебе ПО работает по этому принципу, поэтому читать точно придётся).
• Концепция RestAPI.
• Виды, особенности и различия баз данных и основы SQL (я не говорю что это надо прямо учить, но представление иметь однозначно надо, вплоть до составления хотя бы простейших запросов). Почитать про NoSQL-базы данных, в частности MongoDB и Redis.
• Методологии БЭМ. Я не сторонник такого подхода, но многие работают с его использованием, чтобы понимать о чём речь желательно почитать хотя бы вкратце.
• Методологии разработки Agile и Scrum (там ничего особо сложного, скорее для общего развития).
• Концепция Single Page Application (SPA) — применима не всегда, но почему-то всё чаще используется даже для очень объёмных проектов. Читать определённо.
• Почитайте про Web Sockets — это технология, которая позволяет создавать интерактивное соединение между клиентом (браузером) и сервером для обмена сообщениями в режиме реального времени. Веб-сокеты, в отличие от HTTP, позволяют работать с двунаправленным потоком данных. Предлагаю смотреть на это как на AJAX нового поколения. Основная плюшка — это отсутствие необходимости постоянно запрашивать новые данные с сервера. При необходимости сервер сам отправит данные, а браузер их получит.
• Ещё один стандарт который, вероятно, значительно изменит фронтэнд-разработку уже в ближайшем будущем — Web Components. Очень мощный инструмент и он вам определённо пригодится, хотя в данной статье я не буду уделять ему внимания.
• XPath — язык запросов к DOM-документа. Маловероятно что он вам пригодится, так как в абсолютном большинстве случаев CSS-селекторы удобнее, но знать о его существовании полезно. Сейчас используется в основном в области тестирования или для парсинга больших объёмов данных.
• Одно из ключевых отличий, по сравнению с разработкой десяток лет назад — сейчас практически везде принято использовать т.н. пакетные менеджеры (менеджеры зависимостей), которые пришли из мира UNIX. О некоторых из них я расскажу более подробно далее. Основная идея в том, чтобы снять с плеч программиста заботу о соблюдении зависимостей и обновлении используемых библиотек и фреймворков. Если раньше для начала проекта требовалось руками копировать в нужные места все нужные файлы и библиотеки, прописать все пути, проследить чтобы они были между собой совместимы и т.п., то сейчас всё это делается парой команд в консоли (да, без консоли до сих пор никуда, увы).
• Прекомпиляторы. Возможно звучит странно, так как мы говорим о интерпретируемых языках, но таки да, сплошь и рядом используются отдельные программы, позволяющие, например, собрать все используемые стили в один файл перед заливкой в продакшн, а также позволяющие использовать в своём коде всякие удобные штуки, которых нет в стандарте (например переменные в CSS). Особенно популярны прекомпиляторы во фронтэнде — так как для бэкэнда чаще всего используются полноценные ООП-языки, там прекомпиляторы не так распространены и применяются, в основном, для ускорения и кэширования (например PHP Zend OPcache).
• Для упрощения развёртывания разработки сейчас принято использовать т.н. контейнеры (Docker, Kubernetes). Это относительно новая концепция в современной разработке, рассматривать подробно её я не буду, однако представление иметь надо — технология очень мощная и однозначно полезная.
• Тестирование — отдельная большая тема. Чаще всего под этим подразумевается т.н. юнит-тестирование. Суть идеи легко понять на простом примере. Создавая тест вы пишете некую обёртку, которая выполнит одну из ваших функций и проверит ожидаемый результат. Затем, когда вы поменяете что-либо в другой функции, от которой зависит первая функция, чтобы проверить, что изменение ничего не сломало — вам достаточно запустить созданные ранее тесты. Надеюсь понятно, насколько это может быть полезно в большом проекте.

• Самый первый и самый простой вариант — веб-сервер парсит запрос и просто выдаёт HTML-файл, соответствующий этому запросу. Максимум, может использоваться какой-нибудь SSI. По сути это просто классический статический сайт, а бэкэндом в данном случае выступает сам веб-сервер. Очевидно, для проекта в котором может быть множество страниц такой подход катастрофически неудобен — если нужно что-либо изменить, правки придётся вносить во всех файлах. Также очевидно, что ничего кроме статических сайтов тут реализовать практически невозможно. Сейчас это используется максимум для каких-нибудь совсем простых лендингов, и то, разработка фронтэнда для них всё равно сейчас ведётся, в основном, с помощью современных js-фреймворков, а их применение в абсолютном большинстве случаев практикуется посредством функциональности Node.js.
• Развитие статического варианта — использование интерпретируемых языков на стороне сервера. Тут появилась возможность писать шаблоны на одном из интерпретируемых языков, в которые подставляются данные в зависимости от запроса, а также стало возможно храненить данные не файлах, а в БД. Можно считать, что с этого момента появляется чёткое разделение:
  
  1. Собственно сам веб-сервер. Сейчас это уже вовсе не обязательно монолитное приложение, например, распространённый вариант — когда Nginx выступает в качестве балансировщика нагрузки, а сами запросы обрабатывает уже Apache. Хотя вариантов может быть множество (спасибо за уточнение @prijutme4ty).
  2. Язык и фрейморк на этом языке, которые используются для обработки запроса и маршртизации по URL. Пожалуй, не будет ошибкой сказать, что в контексте fullstack-разработки под понятием «бэкэнд» как раз данный слой чаще всего и подразумевается, хотя строго говоря, всё серверное ПО, обеспечивающее работу веб-сервера это, разумеется, тоже бэкэнд. Важно, что язык и фреймворк для бэкэнда могут быть практически любые. Например, в случае Ruby и Ruby on Rails в качестве шаблонизатора может использоваться встроенный ERB, в случае PHP и Laravel — в качестве шаблонизатора чаще всего используют Blade, ну и так далее.
  3. Код, который выполняется непосредственно на клиенте — то, что принято называть фронтэнд. Тут всё, фактически, сводится к JS.
  
  Долгое время данный подход был основным и единственным в web-разработке, пока не начали развиваться облачные технологии и не появилась концепция SPA.
• Когда стали развиваться облачные вычисления, появились различные модели их использования (SaaS, PaaS, IaaS). Среди них хотелось бы отметить т.н. serverless-подход от AWS. Суть в том, что веб-сервер из предыдущего пункта заменяется на специальный фреймворк, посредством которого бэкэнд приложение взаимодействует с облаком. Облака развиваются семимильными шагами, появляется множество новых технологий и подходов к их использованию, поэтому описать всё кратко возможным не представляется. Если вам интересно данное направление, посмотреть большинство используемых сейчас облачных технологий с сортировкой по категориям можно тут: landscape.cncf.io (спасибо KonstantinSpb).
  
• С развитием концепции SPA и появлением HTML-компонентов, которые рендерятся с помощью JS, встала проблема слишком долгого отображения — пока JavaScript загрузится и отрисуется у клиента, может пройти достаточно много времени. В связи с этим появился ещё один подход к генерации HTML, который исторически принято связывать именно со SPA-приложениями — Server Side Rendering (SSR). Суть в том, что мы можем выполнить первый рендер компонентов в HTML ещё на сервере, затем отдать это клиенту, вместе с тем же кодом, который сформировал этот HTML, и затем не передавать каждый раз целиком код приложения по сети, а просто отрисовывать нужные компоненты сразу в браузере, передавая лишь данные, необходимые для изменения состояния системы (то самое REST). Нужно понимать, что в некоторых случаях так могут не делать, разбив систему на независимые функциональные блоки (например, сгруппировав по формам, каждая из которых работает со своей областью системы), тогда это уже будет не SPA в классическом смысле. В таком случае рендеринг компонентов выполняется один раз перед отправкой с помощью какого-либо JS-шаблонизатора прямо на сервере — тогда, концептуально, это ничем не отличается от использования шаблонизатора на любом другом бэкэнд-языке, и, хотя, по сути, рендеринг из JS в HTML всё ещё будет происходить на стороне сервера, это уже не является SSR, потому что сие понятие исторически употребляется именно в контексте SPA. За прояснение сего момента спасибо товарищам staticlab, napa3um и justboris.

Бэкэнд

• Java
• .NET
• Python
• Node.js (тут неоднозначно, но об этом дальше),
• Ruby on Rails
• И, конечно же, PHP

Про Python...

Тем, кто по какой-либо причине еще его не знает, а возможно даже обходит его стороной, хочется посоветовать, все-таки, присмотреться к этому языку получше. Я сам очень долго не хотел его изучать, и причина была не как у многих («фу, да там все через отступы»), а в том, что приводя плюсы питона (да простят меня люди говорящие «пайтон»), обычно называют лаконичность языка.

Часто приводят фразу в духе: «что на си занимает 100 строчек кода, в притоне это займет 10». Вот эта «простота» отпугивала, особенно после C++ и любимого С#. Казалось, что язык больше для «домохозяек» и людей не умеющих программировать на нормальных языках с нормальной типизацией, да и вообще язык только для скриптов. Я никогда так не ошибался! :) Язык очень мощный, невероятно удобный, который можно применять во многих областях. Я не знаю ни одного человека, перешедшего с PHP на питон, и который после этого опять хотел бы вернуться к PHP. Это я все к чему веду: питон отличный язык для того чтобы создавать на нем бэкэнд.

Ну а теперь непосредственно про фреймворки… Для начала надо определиться: какой сервер нам нужен блокирующий или неблокирующий. У каждого из них есть плюсы и минусы. Неблокирующий сервер чаще всего используют для веб-сокетов, но на нем можно писать и обычные сайты, способные одновременно обрабатывать большое количество подключений. Но при работе с такими серверами надо помнить, что все подключения крутятся в одном «общем цикле» и блокировка этого «цикла» приведет к полной блокировке всех подключений, в связи с этим все используемые библиотеки должны быть не блокирующими. Среди неблокирующих фреймворков на сегодняшний день я бы советовал использовать aiohttp, есть и другие достаточно популярные такие как Tornado, но все они уступают aiohttp. Что же касается блокирующего фреймворка, то тут выделяется Django. Он подходит для людей, которые любят чтобы все было в одном флаконе и желательно сразу. Django уже «из коробки» включает в себя и шаблонизатор, и ORM, и многие другие удобные библиотеки. Но если Вы, как и, я любите выбирать библиотеки под задачу, тогда советую использовать Flask, а все остальные библиотеки уже настраивать под себя. Шаблонизатор чаще всего используют Jinja2, это достаточно удобный и распространённый шаблонизатор, с которым если и возникнут вопросы, то ответ можно будет нагуглить очень быстро. Что касается ORM, то в мире питона правит sqlalchemy. Это, как пишет создатель peewee (конкурента sqlalchemy): «SQLAlchemy is the gold standard for ORM in the Python world» — и я с ним полностью согласен. Это универсальный и мощный инструмент. Но за все надо платить, в данном случае приходится «платить» сложностью данного фреймворка. Хотя, начать с ним работать можно очень быстро, а вникать в сложности уже в процессе.

Есть очень много и других полезных библиотек, полезных при работе с веб, таких как wtforms, beautifulsoup, Pillow и т.д, но тут все уже зависит от конкретного проекта и задач, которые стоят перед разработчиком.

Я бы еще добавил библиотеку requests (прямо очень мне понравилась). Для облачного serverless бэкенда стоит посмотреть на фреймворки Chalice и SAM. Ну и pipenv, black и flake8 наше все, конечно.

PHP

<?php
function test($param){}
test();
?>

Современные PHP-фреймворки

• Laravel — один из самых популярных фреймов. Ключевые фичи, доступные «из коробки»: шаблонизатор «Blade» (люблю его), Eloquent ORM для работы с БД и создания моделей (речь про модели из концепции MVC), механизм автоматической загрузки классов PHP без необходимости подключать файлы из определений в include, миграции (система управления версиями БД), есть свой формат пакетов, которые позволяют создавать и подключать модули Composer к приложению на Laravel. Многие дополнительные возможности уже доступны в виде таких модулей. Очень гибкий и, в целом, понятный инструмент. Будет хорошим стартом для дальнейшего изучения — при понимании используемых технологий, многие концепции других фреймворков будут понятнее. Также немаловажно, что данный фреймворк использует множество компонентов следующего фреймворка — Symfony, что тоже послужит хорошим подспорьем при дальнейшем расширении кругозора.
• Symfony — в качестве ключевых плюсов упоминаются универсальность, стабильность, однако тут достаточно высокий порог вхождения. Из коробки имеет два ORM-инструмента: Propel и Doctrine.
• Zend — самый высокий порог вхождения, взамен высокая стабильность и минимальные зависимости между частями проекта. Создан для разработки больших приложений корпоративного уровня (enterprise). Интересно, что Zend создан и поддерживается разработчиками PHP, а, например, виртуальная машина в интерпретаторе языка PHP именуется не иначе как Zend Engine.
• Yii — считается одним из наиболее производительных и при этом простых фреймворков, хотя однозначных подтверждений этому нет (Впрочем, есть интересное сравнительное тестирование, не сказать что оно всеобъемлющее, но скорость неплохо иллюстрирует. Спасибо tnsaturday ). У Yii огромное сообщество и высокая популярность. Имеется множество расширений, например для работы со Sphinx. Одна из «киллерфич» — генератор кода Gii, разумеется есть миграции БД.
• CodeIgniter — достаточно старый фреймворк, постепенно уходящий на задний план. Ключевые фичи это собственный гибкий шаблонизатор, шаблоны для работы с БД (очень похожи на синтаксис SQL), и мощные возможности кэширования на стороне сервера. Считается что это самый минималистичный и легкий фреймворк с одной из лучших документаций.
• От себя хотел бы также отметить ещё один фреймворк, ныне считающийся устаревшим, однако он хорош скоростью и минимализмом. Также, если начать изучение технологий с него, многие подходы в других фреймворках будут понятнее. Речь о Kohana(RIP) — (Koseven). Проект изначально отпочковался от CodeIgniter, и был написан для PHP5. На данный момент Kohana считается умершей, однако есть более-менее активный форк с поддержкой PHP7 — Koseven. В данном фреймворке имеется своя система ORM, модуль Minion для выполнения Cron-задач, есть своя система миграций БД, при желании несложно подключить расширения (например шаблонизатор Blade или модуль SCSS). По стилю чем-то напоминает Laravel.

Другие бэкэнд технологии

Фронтэнд

<script type="text/javascript" src="/jquery.js"></script>

<script type="text/javascript">
console.log($); // function n() - тут вроде всё понятно

// Если мы сейчас попробуем определить любой свой объект с именем $,
// это, очевидно, переопределит одноимённую функцию из предыдущего файла
var $ = 'Not jquery';
console.log($); // Not jquery
</script>

// Если же мы теперь попробуем подключить ещё один файл
<script type="text/javascript" src="/new.js"></script>
// То внутри него мы уже не сможем использовать функцию $ из jquery,
// потому что все включения в код страницы используют глобальную область видимости

var moment = require('moment');
console.log("Hello from JavaScript!");
console.log(moment().startOf('day').fromNow());

JavaScript-фреймворки

• React — библиотека, разработанная, в первую очередь, для SPA и реализующая концепцию т.н. «реактивного» взаимодействия между элементами и предоставляющая шаблонизатор JSX, позволяющий описывать компоненты интерфейса с помощью синтаксиса JS. Основная идея, пожалуй, в использовании собственной системы событий, которая и обеспечивает эту самую «реактивность» (тут могу ошибаться, буду рад, если меня поправят). Насколько я могу судить, чаще всего используется в связке с Redux (Redux это одно из решений, реализующее «реактивную» архитектуру Flux). React придумали ребята из Facebook.
• Angular — мощнейший фреймворк, предоставляющий огромные возможности для разработки приложений, на нём можно реализовывать как «классические» небольшие SPA, так и действительно огромные проекты. Этот фрейм, в полной мере соответствует концепции MVC, предоставляет возможность использовать компоненты, имеет свою удобную систему событий и вообще, по моему субъективному мнению, всячески хорош. Если вы планируете разрабатывать большой серьёзный проект, я бы рекомендовал изучать именно его. С выходом версии 2.0. проект разделился на два независимых — это AngularJS и просто Angular (нумерация версий начинается с двойки), не следует их путать.
• Vue — популярный ныне фрейморк. Я с ним не работал, поэтому могу лишь констатировать то, что понял из чужих статей. Насколько могу судить, развитие данного фреймворка испытывает значительное влияние React — он также как и React использует виртуальный DOM, а вторая его версия поддерживает шаблонизатор JSX. Судя по всему, это попытка упростить чрезмерно сложные фреймворки типа React или Backbone, выкинув лишнее, поскольку, например, для реализации своей системы событий тут необходимо подключать дополнительный модуль (Vuex), а ядро фреймворка используется в первую очередь как шаблонизатор и селектор элементов. Повторюсь, у меня нет опыта работы с этой библиотекой, я могу ошибаться и буду рад, если кто-нибудь меня поправит.

Современный подход к CSS-вёрстке

• LESS — это вложенный метаязык: валидный CSS будет валидной LESS-программой с аналогичной семантикой. LESS разработан с целью быть как можно ближе к CSS, поэтому у них идентичный синтаксис. В результате существующие CSS можно использовать в качестве LESS кода.
• SASS — это метаязык на основе CSS, предназначенный для увеличения уровня абстракции CSS кода и упрощения файлов каскадных таблиц стилей.

• SASS — более краткий, отличается отсутствием фигурных скобок, в нём вложенные элементы реализованы с помощью отступов;
• SCSS (Sassy CSS) — использует фигурные скобки, как и сам CSS.

Node.js

1. Клиент передаёт запрос серверу (который реализован на ноде) в виде адреса запрашиваемой страницы.
2. Дальше может быть реализовано несколько вариантов — например, для малонагруженных применений может быть использован develop-сервер, который на лету выполняет сборку приложения, анализирует запрашиваемый адрес и формирует нужную страницу из компонентов, описанных с помощью шаблонизатора используемого фреймворка. Плюс здесь в том, что любое изменение кода приложения сразу отражается у клиента, без необходимости деплоя, что может быть удобно для небольших компаний, а также такой вариант очень быстро настроить. Минус же в том, что в качестве сервера используется NodeJS, что не особо быстро.
3. Либо другой вариант (который, собственно, чаще всего и испоьзуют в современных приложениях) — из исходников с помощью сборщика и необходимых подключаемых модулей (компиляция SASS/LESS или тестирование, например) «собирают» всё приложение в production build, который представляет собой уже готовый JS-файл (или несколько файлов, если используется деление на чанки), а серверу остаётся лишь отдать клиенту index.html, в котором этот самый JS-файл будет подключен (тут тоже бывают вариации, типа встраивания части кода прямо в тело html). Плюс сборки в том, что она позволяет добиться максимальной производительности, т.к. в этом случае всё что надо сделать серверу — отдать клиенту пару файлов.

Некоторые популярные пакеты Node.js для разработчиков

• Babel — транспайлер кода разных стандартов в валидный JS для разных «рантаймов» (старые браузеры и т.п.). Не содержит в себе правил преобразования, они идут отдельными пакетами. Без этого инструмента сейчас не обходится практически ни один проект.
• Grunt — менеджер задач для автоматического выполнения рутинных операций (например, минификация, сжатия изображений, тестирование, объединение файлов). Использует командную строку для запуска задач, определённых в файле Gruntfile.
• Примеры бандлеров для Node.JS: Webpack и Browserify. С помощью Webpack и встроенного NPM, например, можно легко заменить связку Bower и Gulp/Grunt.
• Yarn — по сути, аналог NPM, оптимизирующий некоторые аспекты, например загрузку и установку пакетов. Использует тот же формат package.json и те же типы пакетов, что NPM.
• Bower — менеджер пакетов предназначенный в первую очередь для подключения JS и CSS библиотек и фреймворков. По сути, аналог NPM, но только для фронта. Раньше был популярнее, сейчас считается устаревшим и, что важнее, небезопасным — даже сами авторы Bower призывают мигрировать на более современные инструменты, типа связки Yarn и Webpack.
• Jade — по сути это шаблонизатор HTML, написанный специально для ноды, имеющий также некоторую функциональность JS. На мой субъективный взгляд идея в целом неплохая, но мне не нравится его синтаксис. Правда есть и ещё один сомнительный момент — если проект небольшой, спорна необходимость использовать шаблонизатор. А если большой, то один из трёх популярных JS-фреймворков скорее всего будет использован и возможности любого из них, по факту, функциональность Jade полностью перекроют.

Stackshare.io — чтобы быть в курсе, что используется в топовых и не очень компаниях.
Libhunt.com — отличный категорированный список по огромному числу технологий со сравнительной статистикой.