Что принципиально невозможно сделать на php

Столько баззвордов на квадратный сантиметр сообщения. Интересно, как они будут меняться и сколько времени проживут будут актуальны.

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

До тех пор, как партию новых гиниальных и пирспиктивных студиков из говноиститутиков выпустят.

Где с тобой пообщаться в более спокойном месте?

У НАС ТУТ ИНТИМ ЗАПРЕЩЕН

Внезапно, в питое есть async/await. И внезапно его используют в продакшенах. Опять мимо.

ты не понял главное — «завезли меньше чем за год»

Пхп вполне себе используется для написания долгоживущих демонов и асинхронщины(для тех же вебсокетов). Причем уже не первый год.

ты не до конца понимаешь, что такое асинхронщина.
что-то условно асиинхронное на пхп делают, даже многопоток на на 5ке делали (всего то нужно тредсейф сборку и подобрать тредсейф экстеншны).

но это совсем не та асинхронщина, с которой имеет дело js. по крайней мере, пока автолоадер не умеет делать в том числе и импорты асинхоронно.

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

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

Лол, то есть если работать легче, то это теперь недостаток?

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

То есть берем изначально более сложны подход и потом героически превозмогаем. Гениально.

просто современный фронтенд дорос в своих задачах и инструментах до зрелых подходов кровавого энтерпрайза, а пхп ещё нет

Например: отсутствие персистенции коннектов (в силу еще характерных коротких RT-запросов), постоянная авторизация и дерганье БД как следствие, таймауты...

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

я сам не в восторге от хайпа покруг фреймворков версии 0.0.3 c 3к звёзд на гитхабе.
но то, что фронденд дорос до понимания persistent data structure, CQRS и ивентсорсинга — это о многом говорит.

народ понимает издержки полного копирования при обмене сообщениями между вебворкерами (суть те же акторы), в es2017 будут atomic и shared memory.

то есть не то, чтобы это такой уж рокет-сайнс. но поразительно, что к этому всему пришли за пару лет.

в пхп об этом никто не думает

Да везде так предполагаю, особенно где нет долгоживущего RT, хотя и он еще ничего не значит.

не даст — можно перечитать документацию по strstr пока страничка рендерится.

и увидеть too many connections или словить огромное число сессий к БД

ты не до конца понимаешь, что такое асинхронщина.

А ты видимо телепат, раз решаешь что я понимаю а чего нет. Под асинхронщиной я подразумевал event-drived архитектуру с использованием libevent/libev и использование асинхронного i/o.

То есть один в один то, что есть в ноде.

я тебе не про ноду, я тебе про реалии, с которыми сталкивается js-приложения, будучи в браузере на медленном канале связи

я тебе не про ноду, я тебе про реалии, с которыми сталкивается js-приложения, будучи в браузере на медленном канале связи

ты давай или объясни, что не так с асихнронщиной в пхп или сиди молчи, ок?

асинхронная подгрузка исполняемого кода и компоновка его в то, что ты называешь «классами»

асинхронная подгрузка исполняемого кода и компоновка его в то, что ты называешь «классами»

ясно-понятно, увозите пациента

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

асинхронная подгрузка исполняемого кода

AJAX-ом или как в erlang?

AJAX-ом или как в erlang?

AMD

как в эрланге хот-релоад устроен не знаю кстати — вроде на уровне модулей, которым диспатчится поток сообщений.

AMD

? сейчас вроде тренды в сторону webpack, а там свой, весьма специфичный AMD, тот AMD как в requireJS существует как мне показалось для совместимости, legacy. Могу ошибаться конечно.

Но в любом случае надо AMD стыковать с webpack, насколько мне понятно.

Да и вообще сам по себе интересен вопрос интеграции webpack+AMD+PHP

как в эрланге хот-релоад устроен не знаю кстати — вроде на уровне модулей, которым диспатчится поток сообщений.

Устроен в лучшем виде.

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

Релоад в эрланге мало чего общего имеет с AMD в практическом смысле (на мой взгляд) - там нативный релоад, причем доведенный фактически до своеобразного индустриального стандарта (возможно управление релизами)

Главным образом hot reload возможен в первую очередь в иммутабельных системах и поддерживающих фактически нативное FP. В эрланге в частности и грубо говоря, обновление происходит как правило через супервизор(ы) (возможно на внутреннем уровне - это в общем можно проверить по исходникам), охватывающее все дерево RT-зависимостей...

Благодаря такому релоаду, сервисы работают годами без холодной перезагрузки, но с апдейтами.

Я о браузерных играх не подумал.

? сейчас вроде тренды в сторону webpack, а там свой, весьма специфичный AMD, тот AMD как в requireJS существует как мне показалось для совместимости, legacy. Могу ошибаться конечно.

AMD — это requirejs и асинхронные зависимости, поставляются через bower.
CommonJS — это nodejs и синхронные зависимости, кторые протащили в браузеры, поставляются через npm.

сам по себе webpack не совсем про js — это упаковщик веб-приложениё. да, в том числе он позволяет использовать и AMD и CommonJS и SystemJS (переосмысление AMD и CommonJS) при упаковке и процессинге js. но также он пакует стили, ресурсы и тд — то есть даёт готовые минифицированные бандлы.

Да и вообще сам по себе интересен вопрос интеграции webpack+AMD+PHP

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

Главным образом hot reload возможен в первую очередь в иммутабельных системах и поддерживающих фактически нативное FP.

что характерно, комьюнити js уже крепно смотрит в сторону fp. уже сейчас правило хорошего тона — это не использовать итеративные конструкции вроде for/while. это было со времён lodash и во многом закрепилось в es6. набирает популярность ramda.

Здравствуйте. Пожалуйста, отпишитесь мне на почту taiska98@yandex.ru . Хочу с Вами пообщаться. Пожалуйста.

Хочу с Вами пообщаться.

Говори тут. Все свои.