Зачем писать на PHP в 2020?
Главные вкладки
В начале июня один из ведущих подкаста «Цинковый прод» разместил на Хабре резонансную статью «Какая ниша у языка и поможет ли PHP8 решить [его] насущные проблемы (спойлер: имхо, нет)». Незадолго до этого мы решили, что пора бы сделать доклад, зачем выбирать PHP, когда вокруг расцветают сто цветов языков. Эти вещи так совпали по времени, что захотелось устроить совместный эфир и обсудить нишу и перспективы языка — с разных точек зрения.
Что обсудим
Во многом, разговор будет импровизацией на час с небольшим. Но какое-то направление мы набросали: если кажется, что что-то важное упущено, а что-то можно и опустить, не стесняйтесь писать об этом и закидывайте свои предложения. Пока среди мыслей:
- Как и кем формируется рынок PHP-разработки, кто по факту решает, на чем писать и переписывать проекты.
- Тяжелое детство, взросление и текущее состояние 25-летнего языка — что поправили, что научились решать иначе. С чем и кто обычно столкнется в реальности. И что из того, что хочется, реально нужно.
- Почему PHP, который хоронят лет 20, может быть “новым коболом” — и какая кому от этого выгода.
- Посравниваем с другими языками: ну куда же без этого. И, конечно, обсудим саму статью и реакцию на нее.
Подключайтесь к трансляции 18 июня в 20 часов по Москве — комментарии на ютубе обязательно попадут в выпуск. А может и с голосовым общением что придумаем.
Ссылка на видео-трансляцию: https://www.youtube.com/watch?v=QrlWrFILjMk
Расшифровка обсуждения появится в июле-августе отдельным материалом. Мы сделаем апдейт к этому посту со ссылкой на нее.
Комментарии
Меня, кстати, (если уж на то пошло) ближе к старости всё больше и чаще занимает безумный вопрос: почему в 2020 году вообще весь Web всё ещё держится на тексте?
Вся web-механика от транспорта/передачи (HTTP) данных до разметки лэйаута и стилей страниц - всё по сути в текстовом виде и всё на парсинге текста и регулярках. Понятно, что тут гипертекст в основе, природа его такая, наследие и все дела. Но что мешает придумать более компактный (возможно, бинарный) формат передачи разметки и самого веб-контента?
Мы обрабатываем и таскаем по сети порой (ну, чисто эмпирически) до 80-90% информации, относящейся к теговой разметке или стилевому оформлению страниц. И эта информация всё в том же текстовом виде. А какая потребность в этом в наше время? И насколько быстрее была бы обработка и передача "компилированного" контента, в котором вся разметка отдельного блока сводилась к считанным байтам (возможно, даже из каких-то наиболее типичных пресетов-паттернов).
Просто как пример - ну, навскидку:
...
<div class="card card-secondary rounded border-dark">
<div class="card-header">Однажды в студёную <b>зимнюю</b> пору</div>
<div class="card-body">Я из лесу вышел, был сильный мороз...</div>
</div>
...
// Мрачное светлое будущее
...
^¶Ⱪ0ae>Ǹ~Однажды в студёную ^*6зимнюю пору
^Ǽ3≤1a>¿~Я из лесу вышел, был сильный мороз...
...
При этом текстовое содержимое остаётся текстом. Поисковым машинам, по-моему, уже давно всё равно, в каком виде будет представлено и размечено веб-содержимое. Не всё равно разве что гикам-программистам, поскольку код вряд ли можно будет назвать human-readable и руками писать его будет затруднительно чуть менее чем всегда. Ну, собсна на то компиляторы и существуют.
Услышал Вашу мольбу и жалобы, взвесил и отправился назад во времени на пару лет. Придумал для Вас HTTP/2 и вебсокеты.
Не благодарите!
HTTP/2 бинарный транспорт, но не разметка (как сжатый/компилированный аналог формата HTML). Т.е. во многом тот же текст, только в бинарном виде. Вебсокеты - ну, полезная и долгожданная плюшка, но выше речь главным образом о "всё-ещё-текстовом-вебе" в 2020 году.
Так и не за что
А Вы хотите вперемешку? О_о
Вы же понимаете, что это: ¶Ⱪ0ae>Ǹ~ - не бинарные данные?
И что бинарные данные + не бинарные данные = не бинарные данные. В чем же профит?
Да это просто ASCII-представление некоей компилированной/компактной разметки - для сравнения с типичным HTML-маркапом. Которое, кстати, вполне себе может быть и в бинарном виде. Пример же здесь просто с "потолка", у меня разумеется нет какой-либо законченной реализации.
Собственно, речь о том, что все эти тонны теговой текстовой разметки документа (да и сам текстовый контент) можно упаковать в более компактную цифровую форму/структуру, где разметка (в виде каких-то заготовок/паттернов) может даже существовать отдельно от основного текстового/значимого содержимого. Возможно местами применяя ещё и gzip-сжатие цепочек контента.
Скажем, такой простой пример. Большинство современных сайтов интенсивно используют HTML-контейнеры (а-ля универсальный DIV), поведение которых в общем-то обычно приходится "наруливать" другими правилами CSS, чтобы обеспечить требуемое позиционирование и/или размеры контейнера. Что в свою очередь может генерировать много опять же текстовой разметки (порой достаточно просто вывести какие-нибудь ряды данных в Bootstrap 3-4, чтобы убедиться в этом)
Так почему в спецификациях до сих пор нет простых и удобных HTML-контейнеров именно для лэйаута? Какой-нить
<box>
или<overlay>
или<column>
или все вместе. Где все типичные необходимые свойства уже предустановлены, и только нюансы наруливаются правилами (не будем про flex'ы, речь именно о разметке).А если пойти дальше, то лучше вообще отказаться от прожорливой мнемоники в названиях и формировать сущности разметки как некие компактные указатели на встроенные/предустановленные (или расширяемые/загружаемые) ресурсы. Что, разумеется, практически возможно только при использовании каких-то программных средств обработки (а-ля компиляторы). И тогда уже как-то невольно (по крайней мере у меня) возникает мысль о бинарном характере и хранения и транспорта данных в целом как о следующем шаге.
Опять-таки. Все это уже разрабатывается, а с определенной долей экспертизы - уже доступно к применению с помощью современных фронт-енд библиотек, вроде ангуляра, реакта, вью, светла и прочих.
Ну, а про бинарность - задайтесь вопросом, на сколько удобно Вам было бы писать такой код. Уверен, ответ на этот вопрос сразу материализуется. Не зря ведь, с каждым годом, тренды развития индустрии программирования развивается в сторону от маш-команд к все более высоким абстракциям, не наоборот.
Конечно, неудобно - если пытаться писать двоичный код руками. Я и указал на это где-то выше. Но мы же пишем на С, например. Просто так и получается, что до сих пор по сути весь веб - это обмен исходниками-простынями в открытом текстовом виде.
А почему не зря, как думаете? Какой сакральный смысл в этом?
Смысл - делать больше, получая больше выгоды, затрачивая на это меньшее к-во времени.
Думаю, при правильном развитии сценария с компиляцией веб-содержимого - времени на разработку/отладку будет требоваться ещё меньше.
Например, сколько сейчас времени отнимает отслеживание зависимостей и переопределений правил CSS - особенно в случае с фреймворками типа BS. Понятно, что сейчас в каждом утюге есть инспекторы свойств, консоль отладки и т.д., но всё равно это жрёт время и порой существенное.
Да и какой выигрыш от текстового представления разметки и текстового же режима передачи?
Вычислительные мощности все еще стремятся вверх. Их стоимости, с другой стороны, вниз. Потому, это все экономия на спичках уже сейчас (уже давно).
Ну, а выигрыш - очевиден:
Ладно, сдаюсь: не найду я здесь апологетов и адептов. И мрачное светлое компилированно-бинарное сетевое будущее не состоится.
Благодарю за дискуссию!
Даёшь гипертекстовый векторный бинарный Фидонет.
Конечному юзеру (браузеру) пофиг, какими байтами реализована разметка.
Разработчикам пофиг, потому что всё равно будут какие-то компиляторы или постпроцессоры
И вам поклон!
Не, я уже не гожусь для таких дерзаний. Боюсь, времени уже не хватит
Собсна, это всего лишь мои личные тараканы. Признак надвигающейся старости, видимо. А то жизнь, братцы, как-то проходит, а ты как пялился более 20 лет назад на все эти километры тегов и стилей, так и пялишься до сих пор. Пора бы уже их с глаз долой, отработали своё, что-то более компактное/удобное взамен.
Я как бы пытался педалить эту мысль выше. Но современность, видимо, всё ещё озабочена подсветкой синтаксиса. Хотя компиляция разметки - это ж как бы не md5-хеширование, т.е. реверс не то, чтобы возможен, а скорее предполагается по умолчанию. А компилировать можно и на лету веб-сервером.
Кстати даже старик-апач вполне может быть допущен в светлое бинарное будущее при наличии соответствующего модуля (какой-нить cml.so - Compiled Markup Language - о!).