Comments 33
Скажите, а зачем все это? Ведь на сервере можно использовать Java. Серверная разработка вас не ограничивает выбором языка. Мне кажется, более разумным брать Java и делать на нем приложение или компоненты приложения.
во многих случая в проекте много клиентского кода. удобно, когда серверный код на том же языке и можно шарить модули.
к тому же у ноды ниже порог вхождения
>и можно шарить модули.

типы же, типы! Типизируем апи и используем одни и те же дефиниции как на клиенте так и на бэке. Тесты — все на одном языке, юнит тестирование вообще можно считать в одной среде.
Порой возникает необходимость совместить SPA-подход на клиенте (навигация без перезагрузки страницы) с серверным рендерингом (для SEO), с нодом это сделать проще. Angular Universal как раз решает эту задачу
Если речь об интеграции Angular Universal с ASP.Net Core, то существующее решение вызывает node для рендеринга шаблона. Если всё же есть решение без нода, то тут не обойтись без дублирования шаблонов для двух платформ
так это все работает в автоматическом режиме. надо три строчки прописать
Думаю, что если знаешь TS и не знаешь java, но знаешь node,js, то ответ на ваш вопрос очевиден.
>Начиная с TypeScript 2.0 можно использовать npm для загрузки файлов деклараций.

неплохо бы упомянуть что можно как подтянуть декларации как npm-пакет так и нормально собрать npm пакет сразу с декларациями (c 1.6 доступны strongly-typed npm packages) что отменяет танцы с бубнами при импорте.

Про типизацию — а чего не упомянули type guards, discriminated unions, index types и mapped types (бомба!) Тайпскрипт уже вырос и возмужал и превратился во вполне серьезный инструмент но народ по инерции относится к нему как к нашлепке к js. Если уж освещать — то освещать именно эти вещи, да и на бэке они хорошо востребованы, если говорить о специфике статьи.

Но в целом спасибо за обзор, да и ответ Aries_ua — типичный проект — фронт, бэк, экстеншин для броузеров. Все на typescript. Это надо попробовать для того что бы понять. Ну и то же самое можно сказать про яву — нафига ява если есть пых?
Ну и то же самое можно сказать про яву — нафига ява если есть пых?

Потому что это два разных языка с довольно разным life cycle, например. PHP ведь born-to-die, а работа с java совершенно другая. Если вам нужно хранить состояния, или инициализация вашего приложения довольно долгая, или прочее — php адово проигрывает. Разумеется, можно играть с кешем, но зачем? Ведь есть java/c# (тут уже выбор на свой вкус).


А зачем typescript или javascript, кроме общей кодовой базы?

>PHP ведь born-to-die — FPM?

>Если вам нужно хранить состояния, или инициализация вашего приложения довольно долгая, или прочее — php адово проигрывает.

Ммм. А ява зачастую сливает ноде ) Да да… Потому что на асинхронщине типа дернуть базу или пульнуть в queue быстродействие особо не играет (хотя оно и так уже неплохое) — все равно все рабочие лошадки написаны на С семействе и оттюнингованы, а вот по скорости разработки/стоимости специалистов/стоимости поддержки проекта — да, ява сливает. И можно до потери пульса биться в оргазме от своей элитарности и возвышенности — но бизнесу нужно не это. Бизнесу нужны простые практичные решения проблем. И мир js вполне уверенно последнее время эти решения дает.
Кстати, да. Java в скорости разработки проигрывает.

Проводили эксперимент. Брали микросервис и делали его на JS (NodeJS -> expressJS, sync/await и прочие плюшки) и Java (Spring Boot).

Результат:
Время, затраченное на JS — 4 часа
Время, затраченное на Java — 12 часов

Вы мне напоминаете ребят, которые делали простые микросервисы на Spring + tomcat и каждый завернули в отдельный docker контейнер, а потом перешли на go и, о чудо, у них внезапно упало потребление памяти и выросла скорость работы.


Почему вы взяли spring boot, а не то, что советуют для написания микросервисов на java?


Вы сравниваете по скорости разработки штуку для микросервисов и гиганский enterprise комбайн, вам не кажется, что это немного неправильно?

>гиганский enterprise комбайн

А что с чем сравнивать если бизнес заказывает микросервисы а не монолитных диплодоков?

ага, понял,  вопрос снят, я погорячился.
Spring boot — было пожелание заказчика. Для NodeJS не было никаких пожеланий, так что выбор был за нами.

Окей, тогда если я проведу такой же тест, только с пожеланием от заказчика о том, что бы программист, который будет работать с nodejs будет привязан к дереву и набирать текст будет с завязанными глазами левой ногой, а потом скажу, что на nodejs разрабатывать в 100 раз дольше, чем на java будет считатся за пример?


Разумеется, я гиперболизировал ситуацию, но как минимум, странно было делать такой вывод, как вы сделали из такой ситуации.


Я согласен с тем, что на слаботипизированном языке писать быстрее, чем на сторого типизированном, что в краткосрочной перспективе сказывается. Но не в 3 раза.

Данный тест был больше для нас самих. Что бы решить, на чем лучше сделать следующий микросервис. Это не делалось для бенчмакров или публикаций. В команды мы знаем, что теоретически один микросервис на Java займет день, на NodeJS 3-4 часа. Далее клиенту предлагаются варианты. А ж что он выберет — то и будем делать.

Но вы же понимаете, что очень странно ссылатся на тест тут, учитывая, что он неправильный.

Если из "скорости разработки" не выкидывать "время отладки", то со статической типизацией получается всё же быстрее.

Думаете, выигрыш был только за счёт типизации? И на Typescript разработка заняла бы столько же времени, сколько на Java?

Странный вывод. Java много чем отличается от TS. А вот JS от TS только типизацией и ещё парой мелочей. И тут TS здорово экономит время на отладке.

Так я про это и говорю, что разница между JS и Java — не только в отсутствии статической типизации.

Слабо похоже на правду. Не потому, что у вас так не могло получиться — наоборот, могло (хотя это сильно зависит от базового опыта работы), а скорее потому, что вы наверняка не учли развития. А в развитии типизированные языки как правило выигрывают на раз-два, потому что рефакторинг автоматический лучше работает, например. Ну т.е. собственно потому же в конечном счете, почему TS вместо JS.

Это потому что вы сравниваете фреймворки типо spring + hibernate и что-то простое на nodejs?


Зачем засовывать их туда, где они не нужны?

Наверное стоит более уточнить вопрос.
К примеру, у меня стартует проект. Я хочу, что бы бек был написал красиво, с типизацией, компиляцией и прочей красотой. В команде у меня есть как JS девелоперы так и Java девелоперы.

Теперь один из команды предлагает — «а давайте запилим на TypeScrypt».

У меня резонный вопрос — зачем типизация в JS, если есть Java?

PS проект на одного двух человек не рассматриваем, так как тогда это бы имело резон.
>У меня резонный вопрос — зачем типизация в JS, если есть Java?

Сосед купил машину, Вы к нему подходите с вопросом — нафига покупал, у меня вон есть машина,  мне хватает.
А нафига типизация в яве? Вот для этих же целей она в js. мир js перенимает неплохой накопленный опыт — что в этом плохого и почему Вам это не нравится?
Мне кажется вы сравниваете сейчас мягкое с холодным.

JS это скриптовый нетипизированный язык. И задумывался он не как что-то мега крутое. И вот из-за простоты его выбирают люди. Только когда люди упираются в проблемы языка, они вместо того что бы сменить язык, пытаются в JS внести надстройки. И ладно бы, если это браузерная часть, где все связаны по рукам и ногам только JS. Но ведь, на серверной части вы не связаны. Есть же другие языки — Java, C#, Go (которые здесь приводили). Там почему просто не перейти на них?

Вот пока внятного ответа я не получил.

Единственная адекватная причина — потому что программистов тогда можно пихать и на фронт, и на бек.

Не соглашусь. Фронт и бек — это разные логики поведения. Даже если писать на одном языке.

Особенно учитывая, что наборы библиотек будут абсолютно разные.
Но значительное количество людей так считает + все-таки знакомый язык лучше, чем незнакомый.


Но профит в целом эфемерен, как мне кажется.

TypeScript — это не просто "надстройка" над JS, а самостоятельный язык программирования с интересной системой типов.


Можно ли на тех же Java, C# или Go взять и типизировать переменную объединением нескольких типов? А их пересечением?

Можно на скале. Собственно, как я понимаю, вопрос-то стоит понимать не столько конкретно "почему не java", а "почему не другой язык", более пригодный для бэкенда. Ну хотя бы потому, что задачи все-таки бывают сильно разные. Ну вот просто живой пример — у меня почти в 75% проектов была в том или ином виде работа с файлами Офиса — как правило, генерились отчеты в Word/Excel. И тут сразу возникает вопрос — а где у нас поддержка лучше? В идеале — и под Linux тоже. И выясняется, что она сильно разная, и стоимость разработки одной части проекта вдруг резко вырастает.

В Java можно такое делать с интерфейсами, что оказалось довольно внезапно для меня.


Что-то типа


Interface1 a = (Interface1 & Interface2) b; 
Only those users with full accounts are able to leave comments. Log in, please.