Почему ненавидят PHP? Какое будущее у PHP
Многие программисты имеют холодное отношение к PHP, а другие – вовсе ненавидят язык. Действительно ли он настолько плохой? Мы постараемся разобраться.
Есть масса причин для « ненависти », у каждого разработчика они свои. Часть из них являются реальными проблемами языка, но некоторые всего лишь результат предвзятого отношения.
Даже наличие плохих отзывов об языке не является причиной полностью сбрасывать PHP со счетов. Даже сегодня он входит в 5 самых распространённых и популярных языков (по состоянию на 2018 год). Он занимает место среди других гигантов: Java , JS , C# и Python . Многочисленные аналитические компании не замечают падения рейтингов PHP, даже порой отмечается постепенный прирост. Одной из причин притока программистов является лёгкость обучения, после знакомства с PHP многие переходят к обучению Java или других языков.
HTML файл с логикой
Неприязнь к PHP часто обуславливается помещением кода в HTML-файл и дальнейшей обработкой внутри. Да, эти файлы имеют соответствующее расширение .php , но здесь доля чистого PHP часто меньше, чем остальных языков. Внутри файла размещаются HTML , CSS , JS коды или загружаются скрипты. Подход не позволяет обеспечить полную чистоту кода, хотя при должных навыках можно структурировать файл так, чтобы все элементы были легкодоступны, аккуратно сложенные и понятны.
Явное преимущество PHP – простая работа с шаблонизаторами, их можно разрабатывать самостоятельно, или просто разбить код на отдельные файлы, отвечающие за конкретные функции. С разбивкой кода по файлам удаётся исключить из него HTML, останется всего несколько строк.
Нельзя назвать проблему важной или критичной, так как на стабильность работы системы или логичность расположения данных это не влияет. Оформление напрямую зависит от разработчика, при желании можно сделать вполне красивый и правильный код.
Качественные пакеты
Bundler, PIP, NPM, CPAN и другие – это пакеты, помогающие писать код качественно. Посредством подключения стороннего кода удаётся повысить производительность труда и расширить возможности языка. Есть одна проблема – перечисленные пакеты написаны на других языках: Ruby, Python, Node JS , Perl.
Собственного, структурированного пакета в PHP практически нет, за исключением PEAR . Имеющийся пакет используется нечасто, так как он имеет низкое качество и не соответствует требованиям современного кода.
Разработан специальный стандарт PSR-0 , который помогает в работе всех пакетов при одновременном подключении. С помощью Composer удаётся получить полноценный менеджер, обеспечивающий определение зависимостей у библиотек PHP. Уже совсем скоро планируется значительное улучшение качества кода и весомое сокращение затрат времени. Проходят времена, когда приходилось разрабатывать решение и затачивать его под конкретный фреймворк.
Проблема действительно существует, но разработчики знают об её существовании и ищут способ убрать лишние сложности.
Устаревшие понятия
Только в моём кругу есть масса матёрых разработчиков на Ruby, которые по привычке используют пятую версию языка, думая и уверяя других в отсутствии каких-либо значимых изменений в PHP 7. В действительности отличия существуют, и они весомые.
Со стороны Ruby-разработчиков часто летит заявление в адрес PHP, что у него нет « method_missing », но это не совсем так, ведь в реальности альтернативой является __call () . Люди привыкли жаловаться, они часто это делают в отношении проблем, которые уже были устранены в новых версиях. Получается так, что большинство людей, высмеивающих PHP, даже не знают о разработке новых версий языка или просто не обладают достаточным уровнем навыков. Ещё часто к PHP относились пренебрежительно по причине отсутствия встроенного сервера (у Ruby он есть), но сейчас и PHP обзавёлся этим дополнением.
Незнание реальности языка, работа с устаревшим кодом, заблуждения – это частый повод бросать не лестные заявления в адрес PHP.
Предвзятое мнение
Не прибегать к PHP – это круто. Причина отказа от языка лежит в воспоминаниях, разработчик помнит, как он писал кривой код и скрипты в детстве. Никто не хочет становиться на уровне с новичками, которые усердно пишут ужасные скрипты на PHP.
Для хорошего разработчика здесь есть место, перечисленные моменты не являются проблемами. Ещё одно заблуждение – человек использующий PHP не в силах освоить какой-то другой язык. Здесь уже я ненавижу подобное предвзятое отношение.
Встречалось мнение, слышал его краем уха возле бизнес-центра: «У меня нет никакого доверия к магазинам на PHP. Почему разработчики не способны освоить хороший язык?». Это мнение многих программистам, но подобные заявления свидетельствуют о недальновидности разработчика.
Заключение
В упрёк PHP поставить больше нечего, все моменты, с которыми ранее приходилось мириться, остались в прошлом. Согласно недавней статистике, проведённой W3Techs , сегодня около 83% всех ресурсов разработаны на основании PHP. Обладая реальными данными в отношении языка, становится легче оценить его перспективы.
Я имею опыт создания приложений как на PHP, так и Python, NodeJS, Ruby (в меньшей мере), но я на постоянной основе использую PHP. Почему я так делаю? Рынок языка является самым большим, и он занимает наибольшую долю. Его популярность обусловлена широкими возможностями, в нём возможно реализовать любой функционал.
Сегодня многие программисты постоянно меняют направления работы в поисках идеального языка, IDE или превосходной хостинг-платформы. Это глупо, так как нет одного идеального и полноценного инструмента, способного покрыть все потребности программистов. Не существует совершенного варианта, но есть просто варианты, которые ненавидеть странно.
Целая ниша людей недолюбливает PHP, но неизбежно сталкиваются с ним или постоянно работают с языком. Это в большей мере напоминает привычку, пользователи критикуют язык, причины для этого есть, но нельзя говорить о PHP слишком пренебрежительно, у него есть будущее.
Больше интересных новостей
7 ошибок начинающих программистов
ИИ на Python для распознавания голоса и выполнения команд
Телеграмм и коронавирус / Пишем бота на Python с отслеживанием данных
Программа на Python для управления компьютером / PyAutoGui
Комментарии (1)
Андрей 23 октября 2023 в 20:39
Не нужно стыдиться PHP
Недавно я решил зайти на сайт cybersport.ru (проект VK GROUP), где хотел посмотреть результаты матчей наших мальчиков по Dote. Мой взгляд упал на статью «Когда будет новый сайт». Там помимо общей информации было пару фраз про PHP и Symfony, которые меня расстроили.
Что же меня меня расстроило
Хотя мотивации писать новую версию проекта все на том же PHP вполне понятна, адекватна и разумна, общий тон ответа содержит извинения за то, что проект пишется на PHP. Словно, вот где-то есть настоящие проекты, на настоящих языках программирования, которые пишут настоящие программисты, а тут пишется поделка на PHP, ибо ничего лучше команда не умеет и не может. Словно люди должны стыдиться, что они пишут на PHP, поэтому вот как-то все обходится фразами «все довольно неплохо». Об этом хочется и поговорить.
Почему PHP стал «плохим» и «постыдным»
В силу того, что в свое время у PHP был достаточно низкий порог входа, и работа по натягиванию шаблонов на различные CMS системы не требовала каких-то глубоких знаний в Computer Science, в PHP пришло много людей, которые не знали, как писать хороший код.
Качество кода таких ребят бросило тень на сам PHP, поэтому в IT-сообществе появились байки, что все PHP-программисты — плохие программисты, а PHP — плохой язык программирования. Вот точно такие же байки, как у всех Subaru проблема с 4 цилиндром, а весь Дальний Восток ездит на Toyota Mark II. Ничего общего с реальностью, но забавно.
На самом деле на PHP создавалось много успешных хайлоад-проектов, где работали талантливые программисты с высоким уровнем профессионализма.
Давление рекламы и лидеров мнений
Помимо того, что PHP имел не самое положительное мнение в IT-сообществе о себе, в инфо-пространство ворвались онлайн-школы, которые по какой-то рандомной причине выбрали python «тем самым языком, на котором с тобой говорит интернет». Это привело к заказам рекламы своих курсов у множества лидеров мнений. Многие из лидеров мнений, чтобы подчеркнуть превосходство курсов по Python, стали топить PHP — его главного конкурента.
Как итог у людей, которые имели мало опыта в программировании, стало формироваться мнение, что PHP — это плохо, не модно, не клево. Да и вообще «Насмехайтесь над ним, гоните его».
К сожалению, статья от редакции cybersport.ru говорит о том, что уже сами команды, которые работают на PHP, стали поддаваться пропаганде, и стали считать PHP плохим языком программирования и оправдываться за это. Это все печально.
Хватит стыдиться PHP
В своих статьях «Стоит ли учить PHP в 2022 году» и «Потрясающее будущее PHP-стека для карьеры» я привел аргументы, почему PHP является клевым, перспективным и эффективным языком программирования, который имеет современную экосистему и готов для решения большого круга, как текущих, так и перспективных задач, стоящих перед современными командами.
Более того, именно PHP дает наилучшие шансы начать карьеру в IT, участвовать в интересных проектах и расти до существенных зарплат, общаюсь с опытными коллегами и перенимать их ценнейший опыт.
PHP — отличный инструмент, поэтому нужно иметь профессиональную гордость, что вы смогли его освоить, и нашли применение своим знаниям на реальных проектах. Я не понимаю, причем тут стыд!
Вернемся к cybersport.ru
Окай, у нас есть контентный проект, где планируется некоторая интерактивность. Для чего ребята вполне разумно выбрали PHP (Symfony) и некоторые event-сервисы, которые (я полагаю) будут написаны либо на node.js, либо на go. Можно ли было выбрать более подходящий стек?
Весь бек на node.js/go/rust — очевидно, что писать бизнес логику на этих языках с админкой, ролями, паблишером, выводом контента и прочими штуками — не самый лучший выбор. Будет долго и неудобно.
Java/C# — удачи найти адекватных ребят в команду, когда за ними уже стоит очередь из финтеха, операторов связи, крупного ритейла, российского FAANG’а, галер и крипто-стартапов. Явно контентный проект не сможет на равных конкурировать за ребят на этом стеке.
Ruby (ROR) — в российских реалиях это новый Perl. Новых проектов пишется не так много, поддержка старых продолжается, интерес молодых ребят минимальный. Как итог, старички на поддержку выбивают очень хорошие условия. Переманивать их сложно и дорого.
Python (Django) — на самом деле хороший вариант, который достаточно неплохо подходит для контентных проектов. Проблемой можно лишь назвать сложность найма адекватных ребят в команду, ибо на рынке много джунов без боевого опыта (ибо проектов на Django не так много на самом деле в РФ (статья на эту тему), а опытные разработчики уже работают в российском FAANG. Ну и самое главное — есть ли какое-то объективное преимущество Python (Django) над PHP (Symfony) — нет!
Поэтому я до конца не понимаю, почему ребята из Cybersport.ru оправдывались в выборе PHP (Symfony), когда они сделали максимально правильное и грамотное решение.
$PHP не нужен*
Хорошо известно, что PHP — это мёртвый язык программирования и его 22-летняя экосистема фактически стала бесполезна, когда появился Node и новые асинхронные фреймворки на его основе. Превосходство Node очевидно, потому что все знают, что однопоточные асинхронные программы более лучше по умолчанию. И быстрее.
«Но Саймон! Почему?!», вы, вероятно, прокричите увидев этот текст на экране. И вот почему:
Перспективы трудоустройства
PHP-разработчики не пользуются спросом. По прошествии 22 лет, все компании, использующие PHP, сразу же отказались от него, как только был выпущен Node v0.0.1, потому что этот стек разработки мгновенно стал лучшим. Кроме того, всем известно, что для успешного запуска (забудем про Slack) вам нужно создавать веб-интерфейсы на Node, а данные сохранять в MongoDB.
Иначе просто невозможно добиться успеха.
Приведем немного научных™ фактов, чтобы доказать эти утверждения:
$заголовок = ‘PHP-разработчики не могут найти работу чтобы содержать свои семьи’;
Экосистема языка
Экосистема, вероятно, является самым важным фактором в принятии решения не использовать язык программирования. К счастью для нас, PHP существует достаточно давно, и его экосистема полна крупных, хорошо поддерживаемых и полнофункциональных фреймворков, которые все ненавидят — это и Laravel, своего рода эквивалент Rails, или энтерпрайз решения на подобии Symfony и Zend.
В отличие от PHP, разработчикам Node не нужно беспокоиться о том, чтобы найти фреймворк, который придётся ненавидеть, потому что каждый просто пишет свой собственный. Создавая свои собственные фреймворки, разработчик может действительно выделиться на фоне конкурентов, изобретая колесо таким образом, который имеет смысл только для него самого (разработчика). Эта практика также удваивает гарантию сохранения работы, что очень важно, как показано в результатах научных™ исследований, приведенных выше. Также, это утраивает Фактор Крутости Разработчика™ (Developer Cool Factor™).
Ошеломляющее свидетельство превосходной экосистемы Node можно увидеть на графике ниже:
$заголовок = ‘Чем больше фреймворков — тем лучше’;
Временные затраты
Реальный уровень производительности разработчика можно измерить только оценив как он тратит собственное время. Видно, что разработчики PHP больше времени тратят на написание кода и построение функциональных приложений, чем на культивацию Фактора Крутости Разработчика™ и получение звёзд на GitHub. Это, очевидно, отразится на них негативно при работе в стартапе, ведь они используют свое время непродуктивно. Все мы знаем что звёзды GitHub — это количественный способ оценки навыков разработчика.
Неспособность PHP-разработчиков внести свой вклад в сообщество показана ниже:
$заголовок = ‘Выслушивать жалобы — менее продуктивно, чем жаловаться. Факт.’;
Вещи, которые вы не сможете сделать являясь PHP-разработчиком
- Программировать асинхронно (по-настоящему!);
- Получить простую и понятную последовательность параметров функций стандартной библиотеки;
- Создать свой собственный шаблон приложения React TODO MVC;
- Реализовать полноценный бэкенд на стороне сервера с фронтендом на стороне клиента;
- Создавать собственные утечки памяти;
- Сделать пробел значимым ;
- Добиться потери данных между запросами;
- Решить проблему голода во всём мире;
- Программировать на JavaScript;
- Признаться людям, что вы — PHP-разработчик.
PHP как инструмент для бизнеса
Мы все знаем, что PHP, безусловно, уступает и не может использоваться при разработке бизнес-приложений, поэтому вот список предприятий-неудачников, использующих PHP, в сравнении со списком успешных компаний, реализующих свои продукты на основе Node:
$заголовок = ‘Node замечательный и эффективный инструмент зла’;
Заключение
Каждый разработчик знает, что самый быстрый и эффективный путь к получению чего-либо — это много жаловаться и каждый раз начинать всё с нуля. Рынок всегда будет ждать запуска вашего стартапа, ведь в первую очередь нужно закончить создание собственного фреймворка.
Кроме того, почему мы должны беспокоиться о перекладывании работы и полагаться на сообщество с открытым исходным кодом, когда мы можем просто всё сделать сами?
- Оригинальный заголовок статьи — , однако парсер не позволил ни в каком виде использовать emoji в тексте.
- разработка
- фреймворки
- php
- node.js
- вентилятор
- нужно больше фрейворков
- никто не читает теги
Почему JavaScript и PHP победили в Интернете
Ни PHP, ни JavaScript не являются великой технологией. Если вы смотрите на оба языка с точки зрения дизайна, вы не найдете много интересного. На самом деле, вы найдете много разочарования.
Это не теоретический анализ с точки зрения исследовательского языка; множество широко используемых языков избегают формальных методов, не раскрывают основного формализма, или даже избегают базовой безопасности типов и вывода из 1970-х годов. Действительно, одним из самых популярных языков, которые до сих пор широко используются, является язык программирования C, который берет свое начало с конца 1960-х годов. (Несмотря на обновления в последние десятилетия, он все еще по существу тот же язык, что и в своей первоначальной форме.)
Почему PHP добился успеха?
Первоначальная цель дизайна PHP была сделать создание веб-страниц простым. В его основе — это язык шаблонов. Возьмите веб-страницу. Добавьте пару циклов и условий. Добавьте некоторые переменные. У вас есть PHP. Уберите все это, и у вас все равно будет PHP.
Это означает, что любая когда-либо написанная веб-страница является действительным документом PHP. Это действительный шаблон PHP. Тот, кто управляет вашим веб-сервером, может настроить этот сервер на обслуживание этой страницы с помощью PHP, и она будет работать идеально. Кроме того, веб-сервер Apache httpd вскоре получил расширение под названием mod_php, которое добавило поддержку PHP. Когда Apache httpd был самым популярным веб-сервером на планете, любой сервер мог включить PHP без проблем.
PHP не всегда был очевидным лидером в серверном веб-программировании. Администраторы систем должны были сами включить PHP. Однако это было логично. Модель выполнения PHP — способ, которым PHP превращает веб-страницу с командами PHP в веб-страницу — очень проста. У каждого запроса есть своя память. Она инициализируется, страница обслуживается, а затем эта память освобождается. Отсутствие каких-либо ошибок в самом PHP позволяет иметь тысячу различных сайтов на одном сервере, каждый из которых работает на PHP, и ни один из них не будет знать ничего о других.
Да, PHP, работающий через mod_php, был более эффективным, чем серверные программы, работающие в модели выполнения CGI. Если вы запускали сто различных сайтов на одном хосте и любой из них имел какую-то популярность, накладные расходы CGI могли перегрузить веб-сервер.
Установка mod_php была дешевой и простой, а обучение пользователей тому, как изменить существующую HTML-страницу для использования нескольких директив PHP, было намного проще, чем объяснение того, как настроить скрипт CGI на Perl или shell или C, включая установку прав доступа и перемещение вещей в правильный файл и добавление необходимых библиотек, поэтому
веб-серверам было проще использовать mod_php.
Если вы платили 4 доллара в месяц за хостинг вашего сайта, скорее всего, у вас был доступный PHP. Если вы установили свою собственную дистрибутив Linux, скорее всего, установка Apache httpd, которую он имел в конфигурации по умолчанию, включала mod_php.
PHP стал успешным, потому что сначала было очень легко его получить. Он действительно преуспел, потому что он уже был там. Не недооценивайте ценность того, чтобы быть там. Да, было относительно легко начать — проще, чем Perl или shell или C, потому что любая существующая HTML-страница является действительным документом PHP — но более важно, что он уже был там. Люди изучали его, потому что он уже был там, и люди устанавливали его, потому что люди изучили его и хотели его.
Наем программистов PHP
Работодатели хотят нанимать программистов PHP, потому что эта технология повсеместна (поэтому риск выбора стандартной технологии минимален) и потому что есть много программистов PHP, которых можно нанять (что делает их дешевыми и легкими для замены). Программисты хотят изучать PHP, потому что его легко учить и доступно много вакансий. Конечно, эта ситуация была предрасположена к тому, чтобы стать лимонным рынком принятия языка программирования — и так оно и случилось.
Почему JavaScript добился успеха?
Когда интернет только начинал свое развитие, в нем даже не было изображений. Были только ссылки между страницами, и это было практически все. Это было огромным преимуществом перед тем, что существовало ранее.
Затем появились формы и серверное программирование. Вы могли взаимодействовать с этими документами. Могли вводить свой адрес электронной почты и получать письма с сайтов. Могли добавлять текущую дату на страницу или общее количество всех, кто ее когда-либо прочитал. Возможности были безграничными.
Потом появились апплеты Java, которые были небольшими кусочками кода, который ваш веб-браузер загружал с сервера и запускал на вашем компьютере. Это должно было быть быстрым и простым способом делать вещи без ожидания медленного интернета. К сожалению, апплеты Java склонны были к сбоям, использовали много памяти и работали медленно.
Потом появился JavaScript, который не был расширением браузера. Это была часть самого браузера. Вы могли иметь браузер без Java, но с Netscape Navigator у вас был браузер, включающий JavaScript. Если вы хотели отображать текущее время или перемещать текст или показывать здесь или там крутой эффект (когда вы нажимаете одну кнопку, появляется окно, если вам не нравится ответ!), вы могли положиться на то, что у людей есть JavaScript.
JavaScript не был везде — многие отключали его, потому что он склонен к раздражающим вещам — но он мог быть везде. Когда веб увидел свой огромный рост популярности, веб-браузеры были везде, и они все привносили в себя JavaScript.
(В те времена веб был диким местом. Один браузер добавлял функцию, а другие спешили ее скопировать. Попечители JavaScript мудро представили язык стандартному агентству ECMA, которое помогало контролировать фрагментацию, даже когда Microsoft пыталась захватить веб с помощью Internet Explorer.)
JavaScript не является идеальным языком. Он был разработан за деся
ть дней, и это заметно. Кроме того, он сталкивается со многими теми же проблемами, что и HTML: современный веб-браузер должен быть способен отображать веб-страницы, написанные в 1993 году, наряду с веб-страницами, написанными в 2013 году. За 20 лет многое изменилось, но старые страницы все еще должны работать. С JavaScript та же история; старый код, написанный для Internet Explorer 4, все еще должен работать. Это усложняет реализацию языка, потому что он должен поддерживать странные старые крайние случаи, и это усложняет программирование на языке, потому что программисты JavaScript должны учитывать эти странные крайние случаи.
Это не должно было сделать JavaScript успешным. На самом деле, его успех был неизбежен. Как и ни один веб-браузер действительно не подходит для не технических конечных пользователей, если он не поддерживает изображения, так и ни один веб-браузер действительно не подходит для не технических конечных пользователей, если он не поддерживает JavaScript. Когда Google Maps продемонстрировала удивительные вещи, которые вы могли сделать с JavaScript, игра была окончена. JavaScript победил. Вот почему планшет у вас под рукой или телефон в вашем кармане (не говоря уже о ноутбуке на вашей кухонной столешнице и настольном компьютере на вашем рабочем столе) все имеют по крайней мере один веб-браузер, который поддерживает JavaScript.
Это означает две вещи.
Во-первых, несмотря на свои недостатки (одним из первых среди которых является полное отсутствие системы библиотек, насчет которой можно утверждать, что существует несколько конкурирующих систем библиотек, которые взаимодействуют почти совсем не взаимодействуют, если они все не очень дисциплинированны и которые или увеличивают объем загрузки одной страницы, или полагаются на очень точные версии и системы кеширования браузера и прокси-сервера, которые слишком византийские, чтобы объ
яснить даже в этой технической скобочной заметке), вы можете рассчитывать на то, что JavaScript будет присутствовать на каждом устройстве, способном к интернету, которое позволяет неограниченный доступ к веб-браузеру. Каждый из них.
В отличие от случая с PHP, где возможно, что установка веб-сервера не включает mod_php или где администратор запрещает использование PHP, вы можете с уверенностью предположить, что на любом устройстве, способном к интернету, будет какая-то форма JavaScript. Телефон, планшет, компьютер, телевизор, консоль, что угодно.
Таким образом, если вы хотите написать программное обеспечение, которое работает везде, где есть конечный пользователь, JavaScript — это опция. Его легко развернуть и он поддерживается везде.
Во-вторых, каждая из этих сред с доступом к клавиатуре (даже если это одна из этих ужасных экранных клавиатур, которые у вас есть на телефонах, планшетах или консолях) потенциально является средой программирования на JavaScript. Вам не нужно учиться об IDE и компиляторах или о том, как их устанавливать, и вам почти не нужно учиться о путях к файлам на вашем устройстве. Вы можете начать программировать на JavaScript прямо там. Как и PHP, документы JavaScript могут начинаться как простые HTML-документы. Вы можете добавлять к ним столько или насколько мало, сколько вам нравится, и они все равно будут работать.
Размывание границ при использовании серверного JavaScript и клиентских фреймворков JavaScript
Программисты так любят последовательность, что готовы потратить невероятное количество времени, усилий и ресурсов, чтобы сделать несколько казалось бы несовместимых вещей более последовательными. Это как если бы вы весь день распутывали запутанные шнурки на обуви. Конечно, это удовлетворяет ваши эстетические чувства, но что вы в итоге добились?
При создании сложных приложений, таких как Google Maps, которые написаны в основном на JavaScript, неизбежно возникает вопрос. «В чем польза сервера, если все, что он делает, — это отправляет некоторые данные, которые приложение на стороне клиента должно как-то перестраивать?»
Вместо того, чтобы JavaScript служил улучшением для идеально работающей веб-страницы — небольшой специей, добавляющей вкус к питательному блюду — веб-страница стала просто средством доставки целой программы, написанной на JavaScript, выполняемой на клиенте, которая производит реальный вывод, который веб-браузер будет отображать клиенту. Это уже не улучшение. Это главный ингредиент.
Формат взаимодействия этих данных, конечно, был JSON, который сам по себе является способом представления структур данных JavaScript. Учитывая сложное клиентское приложение на JavaScript, запрашивающее структуры данных JavaScript от сервера, имеет ли смысл, чтобы Perl, Python, Java или даже PHP брали данные из базы данных, обрабатывали их как структуры данных Perl, Python, Java или PHP, а затем преобразовывали их в структуры данных JavaScript и отправляли их в приложение на JavaScript, работающее на клиенте?
(Все становится еще забавнее, когда это не настоящая база данных, что бы это ни значило в данном контексте, и это приложение на JavaScript, которое содержит документы JavaScript, но это только подтверждает мой пункт.)
Почему бы вместо этого не запускать JavaScript на сервере, отправлять сериализованные данные JavaScript клиенту и выполнять JavaScript на клиенте? Позвольте программистам использовать один и тот же язык на сервере и на клиенте. В конце концов, на сервере вы должны использовать что-то, а на клиенте у вас есть только один выбор.
Наем программистов JavaScript
Работодатели хотят нанимать программистов JavaScript, потому что у этой технологии нет конкурентов. (Java апплеты не получили широкого распространения, Flash ушел, и если вы не хотите писать один и тот же код три раза для пользователей настольных компьютеров, Android и iOS, то для планшетов, телефонов и других мобильных устройств есть только JavaScript.) Программисты учатся JavaScript частично потому, что у него нет конкурентов, и частично потому, что это всепроникающая программная среда на всех их устройствах.
В отличие от PHP, у JavaScript нет достойных конкурентов. Как и в случае с PHP, нет недостатка желающих разработчиков. В отличие от PHP, отсутствие конкуренции не ухудшило качество доступных разработчиков. Сложность поддержки нескольких браузеров с JavaScript-реализациями сомнительного качества привела к появлению вспомогательных библиотек, таких как jQuery, которые помогают обеспечить соблюдение стандартов кодирования (хотя бы в том, что они часто предоставляют приемлемые системы расширения и стабильное поведение на протяжении всего многообразия реализаций). Поскольку разработчики реализаций JavaScript обычно хотят сохранить обратную совместимость веба, программа на JavaScript, написанная в 1996 году, с большой вероятностью будет работать без изменений в веб-браузере, выпущенном в 2014 году.
JavaScript не столкнулся с таким же явлением «рынка лимонов» при найме, как PHP, вероятно, из-за отсутствия конкуренции. Хороший разработчик JavaScript должен оставаться разработчиком JavaScript или полностью отказаться от разработки на стороне клиента. (Это в некоторой степени может объяснить желание использовать JavaScript на серверной стороне разработки: это альтернативный способ продолжить программировать на JavaScript, избегая работодателей низкого качества, заинтересованных исключительно в разработке на стороне клиента.)
Качество, принятие и победа
PHP и JavaScript стали доминирующими в своих областях похожим образом, но важные детали, обусловившие это, различны. Оба языка позволяют пользователям начать с существующего HTML-документа и постепенно расширять его с помощью программирования. PHP требует установки (хотя можно предположить, что он доступен повсюду, потому что его установка и настройка дешевы и все хотят его), в то время как JavaScript доступен повсюду так же, как веб-браузер доступен повсюду.
Ни одно из этого не касается качества реализации, пользовательского опыта, дизайна или опыта. Техническое качество является второстепенным аспектом в сравнении с соответствием продукта рынку. С технической точки зрения сложно утверждать, что JavaScript или PHP лучше своих конкурентов. Во-первых, оба языка и экосистемы имеют недостатки, которых нет в других языках и экосистемах. Во-вторых, и самое главное, у них почти нет конкуренции.
Оба языка стали успешными, потому что они повсюду, и оба языка продолжают оставаться повсюду потому, что они повсюду.
Если это звучит круговым рассуждением, то это так. Если это звучит обескураживающе для потенциальных конкурентов, то, вероятно, так оно и есть. Единственный вероятный способ вытеснить PHP или JavaScript с позиции доминирования — это предоставить нечто неотъемлемое на новой платформе, которая будет еще более доминирующей, чем существующая платформа. Однако, пока существующая платформа продолжает развиваться — сравните HTML 5 с HTML 2.0 — шансы заменить что-либо из них на что-то лучшее невелики.
Возможно, появится конкурент, который предложит качественное улучшение в производительности, всепроникновенности или простоте поддержки (заметьте, что ни одно из этих качеств не является специфическим техническим аспектом качества дизайна). Однако, пока это не произойдет, веб будет оставаться прикованным к PHP
и JavaScript — и если эта тезис верна, то скорее к последнему, чем к первому.
Вывод, который можно сделать из этого, может быть очень простым, поскольку его выполнение чрезвычайно сложно. Найдите доминирующую платформу, которая все еще развивается. Сделайте себя неотъемлемой частью этой платформы. Продолжайте быть неотъемлемыми.
- https://liamka.me/the-lemon-market-of-programming-language-adoption.html
- http://www.dreamsongs.com/WorseIsBetter.html