Суть не в обліпленому профайлі, а в тому щоб були якісь репозиторії, щоб людина щось писала.
Радий чути.
Та хоч із 80х, яка різниця якщо я його зараз не веду. Та й часу не розробку і підтримку нема.
Там все продумано, і проблем не буде — по перше. По друге, це лише приклад коли пишеться запит чисто на SQL. Зазвичай використовуєтсья якась ORM, та ж SupaBase все робить через сдк і працює норм.
Погоджуюсь. Маркетинг вирішує. У будь якому випадку все крутиться навколо грошей. І ми тут теж їх заробляємо, тому яка б не було «жахлива» технологія, якщо за неї платять то на ній ми всі радісно писатимемо.
React Server Components зробили люди з Facebook які і розробляють React. На скільки я знаю, вони хостинг не продають. Якщо помиляюсь то скиньте посилання на їхні тарифні плати. Next з Vercel (які і продають хостинг) перші (а може і не перші, але найпопулярніші) на практиці реалізували цей підхід.
Коли Реакт появився, всі плювалися від того що в один файл знову запихнули CSS, HTML та JS. Я теж плювався. Всі роки і практики до цього розповідали як потрібно все розділяти. Але нічого, все чудово працює зараз.
Запити в БД пишуться і виконуються на сервері. Просто тепер не треба створювати напряму окремо сервіс який робитиме запити. По суті до CSS, HTML, JS додали ще і запити в БД, але так додали що цей код завжди виконується і залишається на сервері.
Рішення це все ще «canary» в Реакті, тому цікаво буде поспостерігати за розвитком.
І на паскалі писав) Але то уже навчання було.
Фреймворків то багато, але хто ж їх усі буде вчити. Тут уже всіма відомий і популярний Реакт (порівняйте кількість вакансій на нього і riot.js). Величезна екосистема, кача модулів та бібліотек. React Server Components дозволяють і оптимізувати бібліотеки. Як я писав уже в статті, якщо треба бібліотеку для фоматування дат, яка важить десятки кілобайт, то замість неї ми отримаємо уже відформатований рядок.
У будь-якому випадку RSC це ще одне рішення однієї з проблем на фронті. Хочете використовуєте, хочете — ні. Головне що є вибір.
Якщо стільки мінусів, то навіщо придумали Next.js і активно розробляють його?
Проблеми з sql інʼєкціями в цьому підході нема. Думаєте у Facebook сидять ідіоти і не врахували це коли розробляли дану технологію. На цю тему в YouTube уже є багато відео.
Взагалі то концепція «товстого клієнта» уже відходить в минуле. Сервер то ми розвантажили, але проблеми з SEO та швидкістю відображення сторінок нікуди не ділися, а місцями тільки збільшились. Ніхто не викидає цей підхід в смітник, але для тих кому треба, щоб все було швидше і краще SEO, а вартість сервера не особливо хвилює, приходить на допомогу серверний рендеринг в усіх його реалізаціях (incremental та static).
Все нове це добре забуте старе. На PHP ми не могли писати фронт. Треба було якийсь jQuery використовувати. Тут же Реакт все робить, безшовна звязка.
JS на беку — це ж не прибульці, щоб вірити в них чи ні. NodeJS уже цілу вічність працює на сервері і проблем нема. Для швидкої роботи не завжди потрібна багатопоточність. Рекомендую ознайомитися з JavaScript — будете дуже здивовані як він працює і чи блокування потоків взагалі існує.
Оскільки в нас нода на сервері то grpc підтримується. Але треба не забувати, що Next.js це лише фреймворк для реакта. Тому треба дивитися чи це релевантна для нього задача.
Звісно ні. Все залишається на беку. На клієнт лише результат роботи.
Ну тому React server component все ще «canary» в межах Реакту. І ми як розробники тільки тестуємо це все і шукає проблеми і недоліки. Тому це майбутнє, а не сьогодення.
Не так щоб сильно зацепила. Перегляди на моєму відео не сильно ростуть.