Здравствуйте! Не первый раз я сталкиваюсь с этим вопросом. Мне непонятно, как в зависимости от типа сайта, мы подбираем технологию для организации кода. Как понять, какая технология и для какого сайта уместна. И вообще, какие технологии существуют?
Как правильно реализовывать сайты, как правильно разбивать код и какой подход и где используется? Не просто, “а дальше фрейморк” - нет! Для того, чтобы спокойно разобраться в том же фрейморке необходимо глубокое понимание того, как это всё работает. Как ранее разбивался код, использовался подход. Всё зависело от типа сайта(лэндинг, новостной сайт, интернет магазин), или в основе было что-то другое? Какие подходы использовались, какие при этом создавались проблемы, которые способствовали появлению новых подходов. Вы можете ответить, что всё это можно найти в интернете, но для новичка это сложно. В сети нет нормальной статьи/видео по этой теме. Чуть ниже, я напишу просто список непонятных слов, фраз, которые многих вгоняют в ступор.
“подходы разделение кода, шаблонизация, модули, МVC, state, организация кода, биндинг, реактивное программирование, SPA, MPA, Virtual DOM, Нода, Веб-компоненты, Templates, Custom Elements API.” … Что и откуда выходит? Есть ли какие-то блок схемы, на которых это можно увидеть… книги? Можно ли это всё описать одни словом - Паттерны?”
В идеале, если у вас это конечно есть, отлично подошла бы блок-схема, как наглядная демонстрация, что и откуда берётся. Имея такую блок схему, можно было бы с большей лёгкостью двигаться по ней, выучивая каждый блок по отдельности, но уже понимая, куда нужно двигаться и зачем
Попробую ответить, может кто дополнит.
Вопрос как бы в том - с чего и что начать учить?
“Как правильно реализовывать сайты” - если это одностраничник (он же SPA или лендинг или посадочная страница)- тогда можно обойтись html\css (дальше на выбор - bootstrap, препроцессоры less или sass). И JavaScript (стандарт именно для заказчика не имеет значения).
Если интернет-магазин - тогда - то же что и для лендинга но на CMS (любая).
Этого достаточно чтобы можно выходить на фриланс либо искать работу в мелкой студии (по фронтенду + немного в PHP разбираться)
Дальше - “просто список непонятных слов…” - из него Virtual DOM, Веб-компоненты, модули - относиться к фреймворкам. Это для того чтобы вебстраницы были динамичными (быстрее загружались, особенно при просмотре на моб. устройствах). В первом варианте - html\css + JS - у таких сайтов загрузка\отображение идет медленнее. 90% вакансий по фронтенду - с использованием фреймворков.
“Templates” - здесь в зависимости от того где именно вы это прочитали, если в туториалах по CMS - то это уже готовое решение с дизайном (фронтенд часть) для сайта.
“Нода” - NodeJS
“Custom Elements API” - это про API вообще.
Чтобы начать это все использовать - начать с верстки + js. Дальше выбрать для себя - сайты на CMS (на рынке СНГ можно обойтись без фреймворков, это в большинстве будет поддержка старых сайтов), или фреймворки (проекты на западные страны). Чтобы перейти на фреймворки - лучше начать из html\css + js, сделать пару несложных сайтов для себя. Начинать сразу с фреймворков с нуля будет сложно. Если уже на чистом JS опыт есть - тогда выбрать один фреймворк (скорее всего React), так как у вас терминология по его туториалам уже используется - Virtual DOM, state, значит его смотрели. Конкретной схемы как учить - наверное нет. Многие начинали из видеоуроков из очень простых вещей (ToDoList), в таких видео API часто используют, - на конкретных примерах будет легче понять как изменяется состояние какого то элемента (input, button, и т.д.) - этот state, как рендерится содержимое страницы и зачем это (Virtual DOM).
Строго говоря, половина из описанных тобой терминов - это способы организации приложения. MVC - это способ организации приложения и разделения на слои. Model - отвечает за хранение данных и их формат, view - за отображение данных и controller - за бизнес-логику и связь между model и view
state - нужно смотреть на контекст. В общем случае - какие-то данные, которые отвечают за состояние (state) твоего приложения (что уже загружено, что еще грузится, с чем пользователь провзаимодействовал, где какие ошибки и т.д.).
биндинг - способ связывания слоев (например, в том же MVC)
SPA & MPA - Single page application и multipage application - способы построения сайтов без полной перезагрузки страницы или с ней. Как это работало раньше: пользователь заходит на статичную страницу, заполняет форму, нажимает submit, страница полностью перезагружается и сервер рендерит новую страницу. Сейчас, как правило, так не делают, а обновляют только часть страницы (например, дорисовывают ошибки валидации)
Virtual DOM например, в реакте - это объектное представление твоего реального DOM. Это связано с тем, что изменение DOM - довольно медленная операция, и, если что-то поменялось в твоем state, ты не хочешь заново ре-рендерить всю страницу в своем SPA. Ты хочешь проверить, какие именно части поменялись, и с помощью своего binding обновить только те части, которые изменились.
Веб-компоненты - сейчас у нас есть ограниченное количество HTML элементов (div, span, h1 etc) с ограниченным функционалом у каждого. Веб-компоненты позволяют создавать свои собственные нативные компоненты со своим собственным поведением, которое ты сам определяшь.
Простите, но мне сложно сформулировать сразу свой вопрос. Бывает, что получив ответ, я понимаю, что меня не правильно поняли, и задаю уточняющий вопрос) Я разделю свой вопрос на два пункта. Но прежде, оговорюсь, что дело не в заказчиках и не CMS. Мои вопросы не сводятся к ним. Я заказчик и web-разработчик. И я вообще не рассматриваю использование. Считаю, что они убивают развитие начинающего разработчика… У меня есть знания по html/css и уверенная база по js(кроме понимания типов данных, знание о замыкании, лексическом окружении,функции, колбэков, объектов и прототипов, DOM, геттеры и сеттеры, синтаксис ES2015, базовое понимание http запросов, понимание зачем нужен асинхронный код)
Представим, что нужно сделать сайт с несколькими страницами. И тут, я как начинающий, сталкиваюсь с вопросами:
как разделить код, писать всё в одном js файле, или разделить его? Если разделить, то какие механизмы существуют? Я знаю, что в этом случае, нередко используются модули(import export). Но даже здесь нет уверенности в том, что должно быть в главном модуле, куда будут импортироваться другие части js кода
далее, я слышал про MVC, как про один из паттернов. И опять вопрос, в каком случае его использовать? Для каких типов сайта. И зачем нужны остальные паттерны? шаблоны и шаблонизаторы(мне это вообще ни о чём не говорит)
И я так понимаю, что SPA и МPA это всего лишь выбор какой-то методики организации кода, я прав?
Я готовлюсь к началу изучение фрейморка VUE. У меня нет чётко понимания, какие знаниями я должен обладать, чтобы с уверенностью сказать, да, я могу приступать к изучению фрейморка. Нужны ли ниже перечисленные знания, прежде чем начать учить VUE
Не совсем понятно, где прочитать про отрисовку элементов браузером? Как это называется?
обязательны ли знания по HTML Templates, Custom Elements, Shadow DOM?
“Представим, что нужно сделать сайт с несколькими страницами” - если говорим только про фронтенд-часть, и вы выбрали Vue, тогда разбить весь код на компоненты (не все в одном js-файле как было раньше до фреймворков и Virtual DOM). Не знакома с Vue, в Angular например (подход ближе к Vue)это будет отдельная папка с файлами - header.ts(или js), header.html, header.css куда помещаете всю разметку, стили и js которая относиться к шапке. Также и для footer. Раньше надо было в каждой html-странице прописывать в коде html шапки и подвала. Теперь - они будут подтягиваться к каждой странице импортами (суть этого - меньше кода, меньше весит приложение потом). Каждая отдельная страница сайта - это отдельная папка с компонентами.Как дробить на компоненты - решение разработчика (будет их три или 10). Но чем больше дробить - тем лучше, потому что какие то из этих компонентов могут переиспользоваться потом где-то еще.
Навигация (переход по страницам осуществляеться через роутинг, это для того чтобы при переходе по страницам не отправлять каждый раз запрос на сервер чтобы достать оттуда новую страницу, - в итоге быстрее переход по страницам).
Сложную логику, которая отвечает например за логин - для нее создать сервис. Мелкая логика (например поменять картинку при клике или шрифт) - можно оставить в компоненте.
“что должно быть в главном модуле” - это app.module имеется ввиду? - туда прописываються все импорты и все зависимости которые будут использоваться в приложении.
“У меня нет чётко понимания, какие знаниями я должен обладать” - так как вы описали что “есть знания по html/css и уверенная база по js” - этого достаточно чтобы за неделю самостоятельно по видеоурокам сделать несложный фронтенд на 1 фреймворке (сайт на несколько страниц, однотипных). Но здесь не совсем понятно: “кроме понимания типов данных, знание о замыкании, лексическом окружении,функции, колбэков, объектов и прототипов, DOM, геттеры и сеттеры, синтаксис ES2015, базовое понимание http запросов, понимание зачем нужен асинхронный код” - так есть понимание этого или нет? И также “есть понимание (в чужом коде)” и “написать самостоятельно” - это немножко разные вещи.
“шаблоны и шаблонизаторы(мне это вообще ни о чём не говорит)” - шаблонизатор это специальная разметка страницы для упрощения отрисовки html-элементов на ней, к которым применяеться какое-то действие. Например шаблонизатор handlebars. Но это не обязательно использовать его в разработке. Это как bootstrap например для стилей.
Наверное вам лучше будет пройти серию видеоуроков по Vue, на русском хорошо обьясняет вообще по фреймворкам Владилен Минин, на примере создания несложного приложения авторизации или использования стороннего API с нуля.
Написав, “кроме понимания…”, я имел что всё это я знаю! Помимо теории, по этим темам, я проходил различные практические задание, задачи которые, хоть и не были напрямую связаны с разработкой сайтов, всё же помогли в набивании руки, касаемо синтаксиса и того, как это использовать.
Спасибо вам за помощь! Добавлю только, что мне ещё понравился, как преподаватель, Дмитрий Лаврик!
P.S. Добавлю только, что сегодня наткнулся на интересную карту разработчика: https://roadmap.sh/frontend и встретился с понятием Server side Rendering. Есть ещё одна технология… Я так понимаю, что от этого тоже зависит организация кода?
Большое спасибо! Обязательно посмотрю эти уроки и буду ждать вашего ответа! Добавлю лишь к вопросу выше такой момент.
Многие сайты, в силу своей простоты, можно(и нужно) делать без фрейморов(СМS пока не рассматриваю. Не предлагайте) ) Вот как в этом случае состоит организация кода? Как раньше создавали? В моём понимании, сначала был import/export ->потом MVC… дальше, не знаю)
И ещё один вопрос. я правильно понимаю, что на VUE можно сделать как SPA так и MPA?
это уже про бекенд-разработку. Возможно не понимаю сути вопроса: цель вопроса была в том чтобы поверхностно разбираться в разработке вообще? (знать все методы и способы какие существуют, с целью саппорта). Или же - научиться разрабатывать самостоятельно чтобы найти первую работу (я так понимаю по фронтенд, что будет быстрее). Для того чтобы стать фронтенд разработчиком уровня джуниор - эти все знания сразу (уметь что-то делать сразу на всем перечисленном в этой карте) - не надо. Все приобрететься по очереди по мере надобности. Но если суть вопроса в том чтобы предугадать что будет востребовано дальше в ближайшем будущем (чтобы начать это учить прямо сейчас), то из этой таблицы например набирает популярности GraphQL(это для сложных задач связанных с API), также базовое понимание по Security(CORS, отличие http от https) уже в вакансиях на это спрос есть. Но возможно у кого-то будет другое мнение.
Цель вопроса в том, чтобы глубоко изучить фронтенд-разработку. Именно глубокое понимание основ, умение сложить это отдельные знания в мозайку, практика, и опыт, способны помочь в достижение моей цели! А про Server side Rendering я спросил, поскольку я нашёл её в таблице и посчитал, что это тоже важно… Проблема в том, нет чётких разграничении того, что необходимо знать на начальном этапе, а что пока можно пропустить. Нет чёткой программы, которая была бы устроенна в ввиде лестницы знании. Вот я и спрашиваю, всё в подряд.
Потому что нет четких требований на рынке фронтенда, которые были бы актуальны 10 лет, поэтому нет четкой роадмап. Где-то каждые 2 года что-то меняется, одно появляется а второе (где-есть уже опыт) стает неактуальным. Это та профессия где учиться надо будет все время (в бекенде такого нет, если что-то меняется то не так быстро). Самое базовое чтобы начать - html, css, js (на уровне работы с API, манипуляции с DOM, простая авторизация), посмотреть один препроцессор для верстки(сделать на нем 1 проект, не углубляться), также посмотреть бутстрап. И один фреймворк (говорят VueJS легче всех остальных воспринимается).
Может у кого-то есть другое мнение.
Раньше стандартом был один файл стилей, один файл js (который либо писался отдельно под каждую страницу, либо собирался каким-нибудь сборщиком: grunt, gulp etc) + файлы библиотек, которые как правило не сливались с файлом проекта, а лежали где-нибудь на CDN. Иногда, особенно если страницы склеивались из кусочков на сервере, по странице были раскиданы отдельные блоки <script></script>, с джаваскриптом для этого кусочка.
MVC - это не про import/export, а про связь между слоями.
О том, что, например, в слое M у тебя есть массив users[{ name, id }] и массив contacts [{ firstUserId, secondUserId }] и больше ничего нет, только данные. В слое V у тебя есть кнопка “залогиниться” и “Написать пользователю X” и все, только UI.
А в слое C у тебя есть логика, которая проверят, залогинился ты или нет, какой у тебя userId и какой у пользователя, которому ты собираешься написать, и не дает написать кому-то, кого нет в твоей адресной книге (нет элемента в массиве contacts, которые маппит тебя и второго пользователя в одну группу).
Пример очень утрированный, но в первом приближении как-то так.
import/export - это только то, как ты разбрасываешь по файлам, потому что файлов у тебя будет, скорее всего, не три (по одному на каждую букву), а больше.
Роадмап хороший и я тоже на него смотрел, когда был джуном, но это, по сути, не роадмап, это вообще всё, что существует в современном фронтенде и тебе не нужно всё это. И, как мне кажется, к таким схемам нужно относиться критично, потому что даже отвечая на самый первый вопрос “How does the internet work”, можно написать несколько томов, и вряд ли тебе это как-то поможет, особенно на ранних этапах. Ты можешь потратить кучи времени на изучение теории, но иметь 0 практики. Вот тебе Листочкин довольно здраво рассказывает о подходе к изучению новых технологий (с 23:23)
Ну и опять же о роадмапе: тебе не нужно открыть книгу про low-level HTTP потратить неделю на изучение хендшейков и congestion window, тебе нужно знать, что браузер не отправит больше 6 запросов на один домен за раз. Тебе не нужно знать на память все существующие HTMTL тэги, тебе просто нужно знать, что они бывают разные и когда тебе в следующий раз придется верстать, просто держать список тегов перед глазами ну и так далее.
Когда посчитаешь что полностью понял как это работает, закрой пример и напиши то же самое с нуля (это самый важный шаг, потому что “если вы думаете, что можете это написать, это еще не значит, что вы действительно можете”, и с этим я на 100% согласен).
Если застрянешь, гугли или пиши сюда.
Если застрянешь прям намертво, можешь подсмотреть в пример.
После написания такого примера с нуля ты поймешь про организацию кода гораздо больше, чем после рассказов и теоретических обсуждений. Опять же, возникнут вопросы почему именно так, пиши, попробуем разобраться.
Я не понимаю что именно ты подразумеваешь под “разбивать код”. Есть разбитие кода по принципу модулей/файлов (например кнопка логина, аватар). Есть разбитие по принципу архитектуры: как каким компонентам взаимодействовать друг с другом (контроллеры и вьюхи). Тебе нужно сфокусироваться на понимании второго - того как модули взаимодействуют друг с другом. Файловая структура будет отражением модели взаимодействия модулей.
Второй момент - нет такого понятия как “правильное разбитие кода”. Потому что никто не знает как правильно. Есть понятие “целессобразное разбитие кода”. И эта целесообразность разная в разных проекта, компаниях ситуациях. Тебе придется смотреть на то как другие разбивают свой код, пытаться вычленить важные аспекты, и понять как выразить эти аспекты в своем коде. Например в этом проете я вывел отдельный файл для каждой сущности из доменной области (пользователь, коллекция, медиа) куда сложил функции работы с этой сущностью. Суть подхода - держать все что относится к одной сущности рядом чтобы проще находить/менять. Этот подход будет работать не всегда, но в моем случае сработал гут.
В идеале да. Я сам такой что не могу начать писать на библиотеке/фреймверке пока не буду чувствовать что понимаю его хорошо. Но это невозможно в принципе. Мне приходится заставлять себя писать хоть что-то, писать раз, два, три (разные проекты, ибо очень важно заканчивать), допускать ошибки, делать выводы и подходить к следующей итерации более подготовленным.
Ключевое слово - целессобразность. Ищи существующие подходы, находи объяснения почему они целесообразны в том или ином случае, выбирай любой подход, делай вывод, и повторяй цикл. Ничего лучшего не придумали. Спрашивай про конкретный случай.
Одно слово скорее “Архитектура веб приложений”.
Терминов много, они все хорошие и нужные. Некоторые из них неизбежны (шаблонизация, state), с некоторыми ты возможно никогда не столкнешься. Учить все подряд не стоит.
Блок-схемы нет, ибо она будет очень разной для твиттера, магазина и домашней страницы. Она будет разной для самописного магазина, или магазина на .NET или магазина на nodejs.
Пиши как получится. Сначала в одном файле. Потом возникнет необъодимость “развести” файлы. Заверши проект, сделай выводы что пошло не так, посмотри на другие проекты, сравни их решения со своим.
Существующих знаний достаточно
Это сейчас не нужно.
Это сейчас не нужно
И то и то. Четких границ нет. При этом принципиальной разницы как использовать vue для SPA и MPA нет. Так что сразу учить vue.
Все верно понимаешь. Тебе нужен SSR (server side rendering) только если ты делаешь SPA которые должны индексироваться поисковиком. Не заморачивайся с SSR пока не знаешь vue.
Глубоко - только через практику и общение. Ты в правильно месте. Дальше тебе нужно спрашивать конктерные вопросы про приложение и технологии, или даже спрашивать то какие вопросы нужно задать.