Если фронтенд часть (React) живёт на сервере — это всё ещё фронтенд?
Привет всем
Вопрос, кстати, вовсе не о формулировках, а об устройстве современных веб-приложений
Всегда думал что фронтенд на то и фронтенд, чтоб крутиться на стороне клиента. И что babel и webpack и прочие - нужны чтоб упаковать наработку и дать клиенту, у которого это добро будет работать на (почти) всех браузерах и общаться с бэкендом на сервере через эндпоинты.
Но столкнулся с примером: бэкенд запускаю командой npm run, фронт енд - грубо говоря - в соседнем окошке той же командой. Общаются друг с другом запросами GraphQL. И это порождает целый ряд под-вопросов:
1. Зачем нужен babel, зачем нужна транспиляция и код мапы, если это добро всё равно работает у тебя на сервере, в известном окружении? Зачем вообще тайпскрипт транспилировать в джаваскрипт, если браузер получает готовые команды что и где рисовать и не читает твой джаваскрипт?
2. Как происходит (происходил?) деплой приложения, в котором React классическим образом работал у клиента в браузере? Prod-кусок собирался, а потом по какому-нибудь старому доброму FTP заливался на сервер в папочку public_html?
3. Зачем если всё считается на сервере, а от клиента мы получаем только запросы - сохранять деление на фронтенд и бек? Не профанирует ли это всю пользу от разнесения фронта и бека?
4. Можем ли мы сказать, что SSR нужен чтобы: Не отдавать клиенту ни грамма бизнес логики? + Ускорить работу даже на слабой клиентской машине?
5. Если SSR подход довлеет - не значит ли это что веб-страницы скоро будут отдаваться в виде видео или что-то в связке с вебассембли? Насколько это "правильно", с учётом что совокупная мощность клиентских машин растёт быстрее (т.к. люди покупают мощные смартфоны)?
Strannyk, Тут скорее про "зачем в джаваскрипт", а не "зачем из тайпскрипта".
Если бы у нас клиент выполнял, то ответ "потому что браузер понимает только джаваскрипт", а при SSR - уже не понятно. Потому что у нас всё остальное на джаваскрипте? У нас джаваскрипт ради джаваскрипта, получается?
Strannyk,
JS everywhere - это хороший подход если у нас сплошные фулстэки в команде, люди пилят фронт и бэк и страхуют друг друга. А если у нас всё на сервере, то вовсе не обязательно привязываться к движку хрома. А писать на чём угодно.
Если выбор джаваскрипта/тайпскрипта обоснован наличием кадров/их зарплатой/наличием библиотек, то эта экосистема - вещь переходящая (php), особенно если снимается жёсткое требование сделать всё под JS для локального исполнения в браузере. Джаваскрипт ради джаваскрипта чистой воды.
Figma вон - корректно работает на чём попало. Фишка для браузера искаропки "compiles JS" может стать сродни фишке "compiles R", если большинство веб приложений будет как Фигма.
Strannyk, У TypeScript есть свой сайт в интернете, там пишется что TypeScript — это строго типизированный язык программирования, основанный на JavaScript https://www.typescriptlang.org/
Вы нам из 2040 пишете? Такое ощущение что в вашем мире JS код в браузере никто не запускает уже лет 15.
SSR используется в 1% случаев, и то - практически всегда этот же код потом попадет в браузеры и будет там работать, поэтому ему нужен бабель, вебпак и все прочее.
1. Браузер получает JS и выполняет его. Заэтим и нужно все перечисленное.
2. в 2040 это наверное уже не важно, а в нашем 2020 все еще существует куча методов деплоить и разворачивать браузерные приложения.
3. Я не знаю где это у вас все считается на сервере, в нашем 2020 99% кода веб приложений все еще запускается в браузере. 1% - это сборка-транспиляция-дев-серверы.
4. не можем, SSR не для этого, он для того чтобы отдавать клиенту изначально отрендеренный HTML и потом туда грузить приложение. Есть проекты которые рендерят веб-аппы в статические HTML, которые потом отдаются браузеру, но в нашем 2020 это пока еще экзотика.
5. Если довлеет. Но он нет. Хотя идея супер тонких видео клиентов витает в воздухе еще с тех времен когда люди, помнящие теплые ламповые майнфреймы закупились первыми ПК и стали предаваться ностальгии. Такие проекты тоже есть, но они в нашем 2020 еще большая экзотика чем SSR без активного клиента. Хотя я в подобном участвовал лично.
Выразятся ли они в чем-то массовом или нет - время покажет. Мое мнение - нет, заметно проще и дешевле и эффективнее по многим параметрам нарисовать миллион веб страничек на миллионах клиентах, чем на одном большом сервере и отдать всем в виде видео.
Не знаю как у вас в 2020, но у нас в 2020 SSR пользуется как минимум больше 1% пользователей. Примерами которые сразу приходят мне в голову являются Next.js и Sapper. Однако их сильно больше.
К тому же если человек пользуется веб-фреймворком, который
А) Компилируется в рантайме
Б) Компилируется во время сборки
он имеет проблемы с SEO, и это SSR как раз таки и решает.
Kizzeon, ну, моя цифра от балды такая, ваша цифра от балды такая.
Не вижу что тут обсуждать. обе цифры крайне далеки от представлений автора что "в браузере JS уже никто не запускает".
Или у вас есть какие-то фактические серьезные исследования доли приложений с SSR против всех веб-приложений? с удовольствием почитаю
Backend, на котором специализируюсь, в моем понимании программирование серверов. Сервер обслуживает много клиентов, иногда очень много 24/7 и обязан обеспечить предсказуемое качество этого обслуживания. Клиент обязан обеспечить дружелюбный интерфейс человек-машина. Клиент-сервер конечно не единственная(например есть еще bitcoin, bittorrent, webrtc, tox и всякие p2p), но популярная сетевая модель. В GraphQL умею для хобби, но оплаченных заказов мне не доставалось, может не повезло...
Товарищ, для начала тебе нужно узнать, как работает браузер и сервер, чтобы не задавать такие жёсткие вопросы. Оставь в покое реакт и ssr. Чтобы научится бегать, для начала нужно хотя бы научится ходить.
Средний
Простой
Средний
