Совет по разработке веб фронта для неразработчика

пхп надо ещё установить и отконфигурировать и ещё установить и отконфигурировать модуль для вебсервера и ещё вебсервер надо установить и отконфигурировать и потом ещё надо домен направить куда надо и там настроить вебсервер слушать куда надо. А ещё сертификат выпустить надо и в вебсервере его прицепить правильно.

А на джанге это не недо? Ты голой жопой джангу выставляешь в интернеты? Так-то на пыхе вообще достаточно php -S тогда.

если посчитать процент SQL injections по языкам, то PHP будет держать пальму первенства, потому что

Потому же, почему в винде больше всего вирусов. Быть неуловимым Джо такое себе достижение.

самые популярные из нынешних фреймворков для Python основаны на DI.

Нет, они основаны на том, что в питоне называют DI, и что к реальному DI имеет слабое отношение.

Нет, они основаны на том, что в питоне называют DI, и что к реальному DI имеет слабое отношение.

Покажи разницу на реальном примере.

Потому же, почему в винде больше всего вирусов. Быть неуловимым Джо такое себе достижение.

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

Последние громкие инжекции SQL в плагинах для WP - подтверждение моих слов. Причём, во многих плагинах инъекции находят повторно (!), т.к. не доходит до разработчика, что в серьёзном подходе всяких mysql_query не должно быть вообще.

Давай реальный пример DI в Джанге или Фласке, расскажу что там не так.

Во-первых он приводил простоту пыхи как аргумент.
Во-вторых пшла в игнор.

потому что PHP склоняет разработчика

Ору чёт. Ну ты бди, задом не поворачивайся.

Последние громкие инжекции SQL в плагинах для WP

Потому и громкие, что на WP работает половина интернета. Причём та, которая делает деньги. А чё там в джанге словил очередной ненужный стартап никому не интересно.

Смотрите-ка, овца порвалась.

В Django и Flask по умолчанию DI не применяется, если самому не вкрячить.

На DI основан FastAPI.

Потому и громкие, что на WP работает половина интернета. Причём та, которая делает деньги. А чё там в джанге словил очередной ненужный стартап никому не интересно.

Очередной «стартап» типа YouTube, Instagram, Dropbox?.. Ну-ну.

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

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

Даже я лично знаю минимум пару таких проектов. Которые, сюрприз, были переписаны на том же Django, и с тех пор благополучно работают выдерживая любые нагрузки. И позволяют легко добавлять новую функциональность, без разгребания простыней кода с 30 уровнями вложенности if/for/while.

99% писателей на Python не могут не знать о DI, хотя бы потому что самые популярные из нынешних фреймворков для Python основаны на DI.

Я чё-то пропустил, Джанга и Фласк не самые популярные? Даже тут только их и советовали.

Ну посмотрим туториал.

from fastapi import FastAPI, Form

app = FastAPI()


@app.post("/login/")
async def login(username: str = Form(), password: str = Form()):
    return {"username": username}

А чё это Form не инжектится, ась?

Очередной «стартап» типа YouTube, Instagram, Dropbox?.. Ну-ну.

А там джанга что ли? Или фласк? Ну давай я тебе проведу пыхом по морде: как на счёт Facebook или Wikipedia? Там ещё всякие Tubmlr есть и даже Slack.

PHP будет держать пальму первенства, потому что там SQL injection

Минуточку, но это проблема не PHP, а SQL и его текстовой (а не объектной) природы формирования запросов.

Оставить питон или взять какое-нибудь php?

Если знаешь питон, то бери его, а это лучше руками вообще не трогать.

Минуточку, но это проблема не PHP, а SQL и его текстовой (а не объектной) природы формирования запросов.

Тем не менее, в Django/Flask/FastAPI приложении скорее всего инъекции не найдешь.

Дело в том, что:

На Python по умолчанию проще написать код, в котором не будет SQL инъекций, чем код, в котором они будут. На PHP проще написать код, в котором будут инъекции, чем код, в котором их не будет.

На Python по умолчанию проще написать код, в котором не будет нечитаемой мешанины кода и HTML. На PHP проще написать мешанину.

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

Всё это приводит к тому, что львиная доля PHP проектов пишется как придётся, с самого начала представляет никак не структурированную лапшу, мешанину, плохого кода.

Да, и ещё раз: это опыт человека, который в том числе когда-то пытался писать на PHP за деньги. Критики Python здесь никогда не пытались писать на других языках, насколько я понимаю, иначе критика не была бы настолько беззубой, в стиле «сам дурак».

На Python по умолчанию …

Это субъективно, и нам не интересно обсуждать личные предпочтения в данном контексте.

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

Надеюсь, вы согласитесь, что SQL нужно вынести за рамки обсуждения PHP vs Python.

Апеллировать же к стилю кода тоже не стоит, есть хорошие практики как этой «мешанины кода» избежать, и они полностью не зависят от конкретного языка. Например, как минимум принять соглашение о стиле кодирования до начала работы, соблюдать его в процессе, и передать в техархив после завершения. Или сделать ревью кода вторым разработчиком неотъемлемой частью процесса разработки и приёмки кода.

Понимаю, что прозвучу снобом, но промолчать не могу.

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

Ужасный стиль большинства кода на PHP - тоже следствие. Толку от линтеров и ревью, если ты варишься в той же среде, где все пишут простыни?..

Выше привёл ссылку на код одного из самых известных проектов на PHP - WordPress, который здесь же рекомендовали, как «отличную» базу для своих проектов.

Ну это же, ё-моё, адская лапша… Архитектура Big Ball of Mud. Как можно это рекомендовать?..

любой фанат [любой язык] имеет ограниченный кругозор и не желает ничему учиться

Так вот в чём дело… 🤔 Что ж, я согласен с вашими опасениями: всегда стоит расширять свой кругозор и специально выбирать другой язык программирования, отличный от привычного, так сказать, выйти из зоны комфорта. 😉 Конечно это будет крайне непродуктивно и затратно для конкретного проекта, но если цель стоит в обучении, то вероятно это стоит сделать.

Наверное, да, так и есть. Но у меня достаточно богатый опыт, и внутри всё начинает сразу кричать, когда кто-то говорит мне, что для разработки решено использовать PHP.

В последний раз, компания знакомых из экономии этим летом наняла кого-то писать MVP продукта на PHP. У меня глаз начал подёргиваться ещё на этапе смотрения на интерфейс полученного MVP.

Ещё я работал в большой и очень известной компании, где один из продуктов был сделан на PHP. Наняли независимый аудит, результаты которого гуляли по компании с веселыми комментариями. Компанию и продукт называть не могу, но о них все точно хотя бы слышали, если даже не используют. Даже не затрагивая качество кода, аудит нашёл десятки дыр в безопасности (потому что «достаточно же просто помнить про mysql_escape_string!»)

Понятно, что это всё субъективные вещи, но по ощущениям:

• если человек пишет на PHP, то ни на что более он никогда не смотрел, и расширять свой кругозор/арсенал средств не собирается («мне и mysql_query сойдёт, идите нахер со своими java-подобными паттернами», как один из комментаторов выше)
• как ни крути, код получится говно (см. тот же «великолепный» WordPress, по которому сразу видно, что написано человеком, не врубающимся вообще в разработку)

Субъективно, да. Как объективно измерить - не знаю.

Тем не менее, в Django/Flask/FastAPI приложении скорее всего инъекции не найдешь.

Почему вы сравниваете фреймворки с простым mysqli_query? Как Django защитит от говнокода?

execute(f"select * from users where id = {request.GET.get('id')}")

Сравнивайте тогда уж с Laravel и Symfony. Там тоже есть защиты от инъекций.

На Python по умолчанию проще написать код, в котором не будет нечитаемой мешанины кода и HTML. На PHP проще написать мешанину.

Что, в python исчезла конкатенация строк и я не смогу написать нечитаемую мешанину в html?

"<div>" + foo + "bar" + "</div>"

Или, всё таки, предложите использовать шаблонизатор? Так в php они тоже есть.

Ваше «проще» относится не к языку, а лишь к тому, кто его использует.

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

Смысл в том, что ни один из туториалов по Python или любому фреймворку по Python или даже по низкоуровневому db-api, не предложит использовать конкатенацию для SQL. Фреймворки будут использовать ORM, а в секции про Raw SQL напишут про плейсхолдеры и три раза напишут про опасность конкатенации. В доке DB-API то же самое.

В итоге, я по результатам вижу, что даже зелёные джуны сразу начинают писать правильно.

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

Всё, что ты описал, не связано с PHP вообще никак. Как PHP может склонять, например, конкатенировать строку SQL-запроса? Лично я такое видел в проектах на Python, Go и JS. И такое может быть где угодно, где есть функция конкатенации строк. Это говорит лишь о неопытности разработчика, а не проблемах языка программирования. Просто PHP, видимо, более популярен, в том числе и у начинающих разработчиков, поэтому и создаётся такое ощущение, что виноват язык программирования.

Опять же, документация на db-api, документация на фреймфорк…

Для примера, документация на вoctrine и symfony учат использовать подготовленные выражения и плейсхолдеры.

Так что дело всё же не в языке.

Смысл в том, что ни один из туториалов по Python или любому фреймворку по Python или даже по низкоуровневому db-api, не предложит использовать конкатенацию для SQL

А есть туториалы по пыху где советуют использовать конкатенацию для SQL? Примеры будут, или опять сольёшься?

туториалы начала нулевых или полных нубасов :) я последние лет 15 слышу одни и те же претензии к пыху, но никто из них не в курсе, что там на самом деле и как принято сегодня.

туториалы начала нулевых или полных нубасов

Именно. Когда всех этих джанг и фласков в помине не было. Мне кажется что в пыхе из-за всех этих стереотипов наоборот ситуация стала лучше чем в среднем по больнице.

Оставить питон или взять какое-нибудь php?

Акстись, какой PHP, 2023 год на носу.

Ага, Django не было, но были Zope и Plone, которые превосходили всё, что есть в мире PHP даже сейчас.

Тебе надо джангу и bootstrap (это не стрёмные виджеты без пердолинга)

которые превосходили всё

Настолько превосходили, что сдохли от своей крутости.

Настолько превосходили, что сдохли от своей крутости.

Для Zope в целом справедливо, она оказалась слишком продвинутой для среднестатистического разраба. Это не лапша WordPress, сляпанная третьеклассником (по уровню развития скиллов), в которую любой с IQ <= 80 может накидать такой же лапши под гордым названием «плагин».

Plone в целом ещё живёт, даже конференции мировые проводятся. Более того, не уверен, что в мире существует хотя бы десяток CMS, превосходящих по возможностям Plone.

Вот не надо их идеализировать, там были хорошие вещи, да, но в итоге они сдохли вытесненные всякими джангами и т.д. Мы хотели заюзать, но в 2001 миграция с перла на пых оказалась существенно проще что по времени, что по деньгам, несмотря на то, что на питоне я на тот момент что-то писал уже года два. И на пыхе оно до сих пор работает потому, что не делали лапшекод, а вполне себе оопненько. И миграция с 4.0.6 до вчера вышедшего 8.2 проходила идеально ибо никогда не юзали упоротые возможности типа регистер глобалсов :о)

Вот не надо их идеализировать, там были хорошие вещи, да, но в итоге они сдохли вытесненные всякими джангами и т.д.

Думаю, что основная причина смерти была почти такой же, что у Perl: полное ломание совместимости между версиями 2 и 3.

В Zope 3 не осталось практически ничего от Zope 2, и она была очень сложной для понимания. Наложим на это практически полное отсутствие документации и книг, как для неё разрабатывать, и получаем полное отсутствие разработчиков.

У меня знакомый сделал на Zope 3 большой известный портал, который потом пришлось переписать то ли на Django, то ли ещё на чем-то, т.к. хотя он и был доволен Zope 3, но разработчиков на поддержку и развитие найти было невозможно.

Но вообще, что Zope 2, что Zope 3, на десятилетия опередили своё время.

Я там выше приводил код «успешного» продукта на PHP. Да, он успешный, с этим спорить не стану. Но его код - это просто говно из разряда «что вижу, то пишу», что многократно было проверено опытом многих бизнесов, которые пытались масштабировать это говно и менять под себя, и потом приходилось начинать с нуля на основе чего-нибудь другого.

В общем и целом, тусовка PHP по-моему не смогла удивить мир ничем. Там нет каких-то «вау-продуктов», просто потому что этот хаотичный лапшеобразный подход в состоянии решать какие-то мелкие проблемы, но не построить что-то такое, от чего все восхитятся.

P.S. При этом Zope и какие-то её части продолжают существовать до сих пор, и приносят пользу. Например, на прошлой работе успешно заюзали в проекте один из компонентов Zope, который поддерживается до сих пор.

Лапшеобразного подхода в пыхе давно нет, но возможность так делать осталась, да. В то же время я за последние 10 лет такой дичи насмотрелся в питоновском и нодовском мире, что спать страшно :о) Но это не значит, что там всё плохо. Но что точно есть везде и будет всегда – карго-культ, он тем сильнее в каждой технологии, чем больше последователей.