vasIvas: если вы используете чисто react, а не в связке с каким-нибудь redux или что-то эдакое, то конечно же у вас будут проблемы. react это библиотека для организации UI и только. За маршрутизацию и прочее оно отвечать вообще не должно. Это уж как сделаете. Примеров как можно делать в сети навалом.
vasIvas: эффект даунов это когда вы делаете какие-то выводы основываясь... ниначем. Я не знаю где откуда вы генерите эту чушь. Разберитесь с вопросом прежде чем делать какие-то выводы.
vasIvas: я не работаю с реактом как бы, погуглите. На все эти вопросы легко ответит документация и статьи о том как разворачивать сервер-сайд пререндеринг приложения на реакте.
Finesse: у меня половина проектов IE11+ так что я то как раз их активно использую. Да даже на проектах IE10+ их можно уже использовать. Поддержка браузерами у них неплохая - заведется у 79% пользователей.
Finesse: на всякий случай, если контейнер имеет display: flex то паддинги начинают свой отсчет уже нормально (паддинги по ширине будут привязаны именно к ширине, и по высоте к высоте). Но не думаю что у автора там флексбоксы.
fman2: нет, можете взять babel.js - это транспайлер ES6 в ES5. Последняя ссылка в моем ответе - скелет проекта с babel.js. То есть после сборки оно будет работать везде.
nick1m: описались в чем? Я говорил про милисекунды, и именно в таких порядках идут выйгрышы при смене одного маршрутизатора на другой. В вашем примере (десятые доли милисекунд) это без учета работы самого php, только выполнение запроса (без учета fetch result и т.д.)
vasIvas: упростите свою модель восприятия. Представьте просто что у вас клиент мысленно перенесся на сервер что бы уменьшить накладные расходы на доставку контента с сервера на клиент. Приложенька отработала и сгенерила вам какой-то DOM, который мы дампим в строку и отправляем как результат работы обратно на клиент. За счет этого мы получаем существенный выйгрыш во времени, когда пользователь увидит реально наше приложение.
vasIvas: я когда-то так говорил? Вы видимо обознались. socket-io это прекрасно, если вам нужно делать websockets то только socket-io (покрывает 99% юзкейсов).
php7 перестал поддерживать устаревшее расширение ext-mysql в пользу ext-mysqli.
vasIvas: ну то есть с точки зрения php разницы никакой нет. С точки зрения приложения на клиенте DOM подменяется на работу со строками и выполняется все это добро не на клиенте а на сервере.
vasIvas: апишка на php. Но она может быть и на питоне или еще где. Запросы просто ваше приложение на реакте будет слать на локалхост а не на какой-то сервер с клиента. + странички потом кешировать можно даже.
vasIvas: калькуляторы разные бывают. Обратная польская запись это конечно хорошо и правильно (я надеюсь автор вкурсе о ней, но упоминуть буде все же не лишним), но бывают так же зависимости по данным и куча других мелочей. Иначе у автора думаю не возникло бы проблем с поиском готового решения.
1) вы делаете запрос на сервер, например на nginx
2) nginx проксирует запрос на node.js
3) node.js запускает ваше приложение с js-ками на сервере (изоморфность же), и вместо DOM вы начинаете работать с текстом (виртуальный DOM абстракция).
4) ваше приложение НА СЕРВЕРЕ дергает запросы к апишке на этом же сервере.
5) nginx-у отправляется результат - html страница отренденная
6) страница приходит на клиент, уже готовая, отренденная и красивая
7) подгружается реакт, видит что у нас уже что-то готово и пытается синхронизироваться с тем что мы на сервере наплодили
8) приложение готово к работе.
Профит тут в том что нет оверхэда на ожидание загрузки реактов и прочего + потом не надо ждать еще сколько нибудь времени пока совершатся запросы на сервак с клиента. Вместо секунды ожидания красивой странички получаем 100-200 милисекунд. Но работать с ней полноценно всеравно можем только через секунду.
Это оптимизация позволяющая пользователю быстрее увидеть приложение, получить лучший UX.
nick1m: вы сравниваете производительность MySQL (штуки написанной на сях) с библиотеками для маршрутизации (штуки написанные на php и выполняющие чуть чуть другие вещи).
Мой аргумент - бессмысленно оптимизировать что-то, если это капля в море (1 милисекунда или 2-е при общем времени выполнения http запроса на сервере в сотню милисекунд).
Ну и да, вы учитываете только время выборки, скорее всего по индексу. Данные же всеравно надо будет считать с диска, перекинуть в пых и скорее всего как-то обработать.
D' Normalization: все глобальное плохо. Другое дело что можно делать ивент стримы какие-нибудь между компонентами или еще как... Вот честно, на бэкэнде с этим все хорошо (доменные ивенты), а на клиенте пока не пробовал.
В целом же я пока явные зависимости использую и меня все устраивает.
