Сергей Шлоков

Ну или возьмем пример из топика. Что сделал ТС? Он подцепился к API modx.pro который разработал Василий и завернул ответ в GraphQL. И тут напрашивается резонный вопрос, а зачем нам этот промежуточный слой в виде уже существующего /assets/components/extras/action.php, если у нас есть доступ к коду и можно сразу сформировать GraphQL

Насколько я понимаю, доступа к коду как раз и нет. У него же нет другой точки входа с описанными схемами или доступа к БД напрямую. Поэтому и пришлось юзать что дали. Или есть? )

И одна из них webonyx/graphql-php взята за основу для Railt

Хотя сам Кирилл её не хвалит )

Зацепил меня данный комментарий. Думал после видео что-нибудь кто-нибудь ответит, но нет)

Я ещё первое до конца не досмотрел. А второе вообще 3 часа. ))

Если мы берем за аксионму тот факт, что GraphQL это чисто JS, а проект на PHP, то реализация API потребует абсолютно другого технологического стека.

Я имел ввиду немного другое. Конечно не надо менять стеки. Я хотел сказать, что нет особой необходимости использовать GraphQL для PHP разработчиков. Если только у тебя не мега сервис с могущим API, как говорит Кирилл Несмеянов.Т.е.PHP разработчику вполне хватит REST-а.

А вот если посмотреть со стороны фронт разработчика, то ему GraphQL даёт больше плюшек. Он не знает ни схем, ни связей объектов в отличие от PHP разработчика (и любого другого бекэндера). И GraphQL даёт ему возможность самому строить запросы не зная этого.

Попробую пояснить мысль. Представим, что MODX — это сервис с API, как это изначально планировалось сделать в MODX3 — использовать Slim в качестве ядра и работать через API. Тогда можно подключать любую админку. Как мне кажется (!), тут GraphQL в качестве обёртки не нужен. Вполне хватит обычного REST-а.

П.С. Возможно, я говорю глупости. Просто ещё не до конца вкурил эту тему. :)

Посмотрел. Заинтересовало. Но… GraphQL — это как бы альтернатива REST-у. Придумана фронтэндерами. Удобно. Но в экосистеме MODX я не встречал даже какой-то толковой наработки по RESTful. Поэтому GraphQL вряд ли будет востребован разработчиками, использующими MODX. И это не удивительно. Могу ошибаться, но скорее всего и в WP, Joomla и т.п. CMS такого тоже не увидишь. Это другой уровень.
В свете сказанного, GraphQL выглядит немного неуместно для PHP. Как и для любого другого серверного языка. А вот для JS самое оно. Фронтэндеру не нужно разбираться в связях и типах. Всё прописано в схемах.
Но это, как требует говорить Николай, чисто моё мнение.

У меня было бы желание, я мог бы полностью переписать админку MODX-а, и это было бы во много раз удобней и перспективней

Без ложной скромности замечу,
Я — гениальный человек!
А то что ничего не создал…
Так я был занят и болел.
(ещё пирожков)

П.С. Извини, но мимо тёщиного дома… ))

А как насчет этого?

Ого! Шаманы, мать их.

А если пофантазировать, что могло бы тебя заставить вернкться на MODX?

сравнение == это беда не только PHP, но и JS.

Ты не понял. В js это «возможности», а в php — беда. )

Всё это субъективно. Меня эти «возможности» немного раздражают, но это не значит, что js отстой. В обычных языках тоже свои особенности. Но они как есть, так и будут.

Молодец!

PHP 25 лет — история и будущее.

История javascript .

<Часто ли ты используешь сравнение с null?

Не часто, но бывает. Я мыслю по другому. я так программирую, что мне достаточно isset и isEmpty. И я не припомню случая, когда мне нужно было бы проверять на undefined. А вот в js это частенько приходилось делать. Это потому что я плохой программист или просто подход к языкам разный?

3. instanceof.
4. typeof.

3 и 4 аналоги тоже есть в php, но я ими очень редко пользовался. В js повсеместно использую

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

П.С. какая же это боль писать комменты с телефона.

Еще один из примеров особенностей js.

Например, тип строки (Hello world) не совпадает с типом нового объекта String (new String('Hello world')). Это порой приводит к нежелательным последствиям, которые могут сбить с толку.

Вообще всё-таки некорректно сравнивать эти языки. У них разная история и предназначение. Если задаться целью, то ровно также можно найти миллион отличий между javascript и java, js и go, php и pyton. Только вот зачем? Js — уникальный скриптовый язык, который на данный момент невозможно ничем заменить в отличие от серверных, где альтернатив много. Но от этого он не становиться идеальным. Как раз наоборот
Столько этих «особенностей» нет ни в одном другом языке.

Возможно. Никогда не говори никогда. Но сейчас я не понимаю, почему описанные выше и ещё в тысячах статей выкрутасы в js это просто прикольные мелочи, а в php всё просто ужасно. Поэтому хочется пояснений, раскрывающих преимущества js. Ответ — когда-нибудь поймёшь, говорит только о субъективности. Никаких объективных причин нет.

Так и я про то же. Но почему-то жуть на php. Есть сайты с задачками для js именно про эти особенности.

Спасибо за статью. Глубоко ещё не вчитывался. Но так как она в векторе моего интереса, то мне уже интересно.

Просто для меня это заявление звучит противоречиво.
Говориться, что на JS приходится более внимательно работать с типами и условиями. Т.е. он менее требователен и типизирован. Что в дальнейшем может приводить к ошибкам. И следом идет

Я порой офигеваю от того, что я делал раньше на PHP. Жжжуть…

Т.е. всё наоборот.

Поэтому и просил уточнить.

П.С. А TS — это typescript?

Вот это неоспоримый факт! Я порой офигеваю от того, что я делал раньше на PHP. Жжжуть…

А можно уточнить в чём неоспоримость? Оба языка вроде как с динамической типизацией? А с PHP 7 появилась статическая типизация.

Еще интересен такой момент. Ты уже год не кодишь на php. Подзабывать начал или всё чётко? Это я к вопросу об использовании разных технологий для разных задач.

Ок. Будем подождать. А бекенд на чем? Самописный?

Ты только у себя используешь, а Николай на потоке.

А почему для генерации html нужна нода? Удобнее?