Natalia Baženova

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

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

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

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

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

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

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

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

Когда работаете в одиночку:
1. Для миграции/синхронизации базы:
1.1. Раз
1.2. Два
1.3. Три

2. Для файлов:
2.1. Раз
2.2. Два (с визуальным сравнением контента перед синхронизацией!)
-----------------------------------
Когда работаете в команде (или без) - подключаемся через систему контроля версий (VCS) из того IDE, с которым привыкли работать:
PhpStorm VCS Help

А как насчет перехвата исключения и в блоке catch определять тип "Division by zero" и возвращать 0.

Когда-нибудь ты сможешь выполнить эту задачу только средствами css, например, когда вот это получит поддержку caniuse.com/#feat=css-has
На сегодняшний день ,думаю, что только JS тебе поможет.

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

Если мне память не изменяет, когда-то давно это поведение можно было задать при помощи

window.status = '';

// к примеру
<a href="x.html" onmouseover="window.status='YYYYY'">Xxxxxxxxxxxxxxxxxx</a>

Но, как пишут тут: https://www.w3schools.com/jsref/prop_win_status.asp это давным давно не работает в современных браузерах (уже в IE7 отменено).

Поэтому остается вариант от Андрей Федоров

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 раза, чтобы они продолжали это поддерживать, но насколько я понял они сами устали от говнокода и хотят вовремя слиться, поэтому вряд ли их удастся удержать.
раз уж вы любите писать правильный код то и правильные слова тоже не помешает. с начальством нужно дружить и помогать им развивать их бизнес, но принять решение как действовать дальше вы сами не можете.

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