Здравствуйте, Pauel, Вы писали:

P>Смотри сам
P>https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html

Это синтетические бенчмарки, которые не имеют никакой связи с реальными сценариями использования, не учитывают расходы на IO/сеть. Я проверял в более приближенных условиях. На моих типичных сценариях, REST и Websocket API, Нода проигрывала вхлам. При этом я далеко не эксперт ни в Java, ни в Node.js, то есть начальные условия были более-менее равные.

Посмотри бенчмарки techempower, они хотя бы чуть-чуть ближе к реалиям backend разработки. Там твой любимый Nest + Fastify сейчас на 211-й строчке, но в жизни все обстоит еще хуже.

P>Ты ошибся. Next и Nuxt это не для сервер-сайд, а для фулстек разработки на ноде.

Lol, я в курсе что это. С Nuxt даже приходилось имет дело в реальном проекте. Исправлял за человеком, который не знал что Nuxt не подходит для сервер-сайд и втулил REST API прямо в Nuxt приложение.

P>Тем не мнее, значительная часть библиотек используются и там и там.
VK>>В своей практике я не видел случаев, когда можно было переиспользовать много кода между фронтом и бэком. Если можешь мне показать успешный пример такого подхода хотя бы среди open-source проектов — мне было бы интересно посмотреть.
P>Я же сказал — почти все клиентские библиотеки. Что тебя не устраивает?

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

По факту серверная и клиентская экосистема TS/JS значительно различаются, почти все библиотеки заточены под что-то одно и переиспользования кода не наблюдается. Успешных примеров обратного я не видел даже в open-source, но хотелось бы увидеть раз это декларируется как преимущество TS/Node.js.

P>Убили не просто так, а потому что была хорошая альтернатива.

Не было и нет никакой хорошей альтернативы. HTML5 игры и анимация так до сих пор и не взлетели, несмотря на многочисленные попытки.

Здравствуйте, Pauel, Вы писали:

P>Смотри сам
P>https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html

Это синтетические бенчмарки, которые не имеют никакой связи с реальными сценариями использования, не учитывают расходы на IO/сеть. Я проверял в более приближенных условиях. На моих типичных сценариях, REST и Websocket API, Нода проигрывала вхлам. При этом я далеко не эксперт ни в Java, ни в Node.js, то есть начальные условия были более-менее равные.

Посмотри бенчмарки techempower, они хотя бы чуть-чуть ближе к реалиям backend разработки. Там твой любимый Nest + Fastify сейчас на 211-й строчке, но в жизни все обстоит еще хуже.

P>Ты ошибся. Next и Nuxt это не для сервер-сайд, а для фулстек разработки на ноде.

Lol, я в курсе что это. С Nuxt даже приходилось иметь дело в реальном проекте. Исправлял за человеком, который не знал что Nuxt не подходит для сервер-сайд и втулил REST API прямо в Nuxt приложение.

P>Тем не мнее, значительная часть библиотек используются и там и там.
VK>>В своей практике я не видел случаев, когда можно было переиспользовать много кода между фронтом и бэком. Если можешь мне показать успешный пример такого подхода хотя бы среди open-source проектов — мне было бы интересно посмотреть.
P>Я же сказал — почти все клиентские библиотеки. Что тебя не устраивает?

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

По факту серверная и клиентская экосистема TS/JS значительно различаются, почти все библиотеки заточены под что-то одно и переиспользования кода не наблюдается. Успешных примеров обратного я не видел даже в open-source, но хотелось бы увидеть раз это декларируется как преимущество TS/Node.js.

P>Убили не просто так, а потому что была хорошая альтернатива.

Не было и нет никакой хорошей альтернативы. HTML5 игры и анимация так до сих пор и не взлетели, несмотря на многочисленные попытки.