Natalia Baženova

Hype Driven Development

У нас ситуация такая:

1) Есть старый сервис, написанный еще на костылях с кучей всякого шлака. Он обрабатывает основную часть логики, его допиливают, дополняют и прочее.
2) Есть апи сервис на современном стеке, который постепенно забирает функционал от старого монстра.
3) Все новые задачи в приоритете ставятся на новый стек..

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

Так можно поступать, если это it-компания.

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

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

Изначально Web задумывался как набор страниц с гиперссылками. Прошло время, мир в целом начал постепенно деградировать, вместе с ним и интернет... Когда у большинства разработчиков появились мощные компьютеры и смартфоны, они задумались над тем, как-бы разгрузить сервер и перенести нагрузку на клиент а другим хотелось меньше работать и больше зарабатывать... Как-то так родилось понятие "web-приложение" коим и является львиная доля сайтов, они являются приложениями, которые выглядят как web-страницы...
Можете смело говорить таким разработчикам в любых спорах по этому поводу, что тяжеловесные фреймворки и библиотеки, портят концепцию сети интернет. Какими-бы полезными они не были. Web, в текущем виде, НЕ предназначен для этого.

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

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

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

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

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

почему вы думаете 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. Остальное можно подключать отдельно, что надо.