Если фронтенд часть (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/
Товарищ, для начала тебе нужно узнать, как работает браузер и сервер, чтобы не задавать такие жёсткие вопросы. Оставь в покое реакт и ssr. Чтобы научится бегать, для начала нужно хотя бы научится ходить.
