Natalia Baženova

jQuery "видит" весь DOM целиком. И манипулирует DOM-ом, доступ к которому предоставляет браузер. Но можно и по-другому.

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

Затем отделим состояние от поведения и представления. Состояние можно описать статической структурой данных, JSON-ом, например. А поведение - это чистая функция, из предыдущего состояния и некоего события (действия) делающая следующее состояние. Представление же "знает", как визуализировать состояние. Можно этот принцип воспроизвести от самых мелких компонент (не имеющих потомков) в нашем дереве и до корня. Тогда весь жизненный цикл приложения можно изобразить как цепочку состояний от некоего начального и до текущего, ведомую событиями (действиями).

Для того, чтобы это всё отобразить, не обязательно в ходе вычисления следующего состояния (или представления) сразу манипулировать DOM-ом. Можно построить из состояния и его представления фрагмент DOM-а, каким он должен получиться. А потом вычислить diff между этим построенным фрагментом (виртуальным DOM-ом) и реальным браузерным. И этот diff применить к реальному DOMу. Один раз. Получится быстро.

Насколько мне известно (поправьте, если это не так), Redux заимствован из Elm-а. Elm - это экосистема и функциональный язык, компилируемый в JS, сделанный для того, чтобы фронтэнд можно было разрабатывать удобно, быстро и без runtime-ошибок. По синтаксису - это адаптация Haskell-a. Ключевым элементом Elm-а является как раз вот эта самая архитектура. Советую подробнее почитать в первоисточнике. https://guide.elm-lang.org/architecture/

Кроме упомянутых особенностей эта архитектура также позволяет выполнять так называемую time-travelling отладку. Поскольку каждое состояние и каждое событие по пути от исходного до текущего можно залогировать и воспроизвести (ведь функция, вычисляющая следующее состояние у нас чистая).

С точки зрения функционального программирования, при таком подходе текущее состояние является результатом функции leftFold, применённой к исходному состоянию, последовательности событий (действий), приводящих к текущему и функции, умеющей вычислять следующее состояние.

Сайт, который грузится 1.5 минуты и лагает при прокрутке на core i5, ммм, ну даже не знаю. Может быть лучше уж видео ?)

Ну тогда

#block2 {
   display: flex;  
   align-items: flex-end;
   background-color:#CC9933;
}

Проще всего использовать готовые библиотеки для отправки писем, например PHPMailer:
https://github.com/PHPMailer/PHPMailer

По ссылке есть пример, как отправлять письма с вложениями.

Уже нет в нём особо смысла. Все использовали его в основном из-за сетки в своё время. Сейчас есть замечательный Flexbox. Остальное можно подключать отдельно, что надо.

а всплывающее окно обязательно должно быть в другой форме? почему его не сделать частью первой?

Никак, давай элементам осмысленные имена. Не как они должны выглядеть, а что они из себя представляют. И не надо делать классы, явно указывающие на размер/цвет и т.д. Потому что это почти ничем не лучше, чем вёрстка прямо в html-коде через атрибут style.
Можешь посмотреть как рекомендуют чуваки из яндекса.

27 лет. 27, Карл!
И уже задаваться вопросом, а не поздно ли?
Цензурных комментариев как-то в голову не приходит.

evnuh на 100% прав.

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

Если же хотите переубедить владельца бизнеса, то научитесь считать выгоду не как разработчик, а как бизнесмен. На какую аудиторию заточена CMS, какие текущие расходы на продажи и на разработку(в деньгах, а не абстрактных человеко-часах), во сколько обойдется переход, как изменятся расходы\прибыль при приходе на стандартные CMS? Это всего лишь малая часть вопросов. Предоставьте владельцу веер решений, из которого можно будет выбрать лучшее для бизнеса.

насколько я понял ключевой момент в том что поддерживать старый код вы не хотите.

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

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

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

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

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

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

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

при отправке формы ты выполняешь POST запрос на сервер. Тоесть ты говоришь железяке: сделай мне страницу при том что я передам вот этиданные. Железяка в ответ тебе генерит страницу. То куда ты делаешь этот пост запрос за это отвечает атрибут ACTION в форме. Если у тебя белы экран после посыла то значт железяка не генерит страницу после пост запроса