Comments 33
к тому же у ноды ниже порог вхождения
неплохо бы упомянуть что можно как подтянуть декларации как 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 адово проигрывает.
Ммм. А ява зачастую сливает ноде ) Да да… Потому что на асинхронщине типа дернуть базу или пульнуть в queue быстродействие особо не играет (хотя оно и так уже неплохое) — все равно все рабочие лошадки написаны на С семействе и оттюнингованы, а вот по скорости разработки/стоимости специалистов/стоимости поддержки проекта — да, ява сливает. И можно до потери пульса биться в оргазме от своей элитарности и возвышенности — но бизнесу нужно не это. Бизнесу нужны простые практичные решения проблем. И мир js вполне уверенно последнее время эти решения дает.
Проводили эксперимент. Брали микросервис и делали его на JS (NodeJS -> expressJS, sync/await и прочие плюшки) и Java (Spring Boot).
Результат:
Время, затраченное на JS — 4 часа
Время, затраченное на Java — 12 часов
Вы мне напоминаете ребят, которые делали простые микросервисы на Spring + tomcat и каждый завернули в отдельный docker контейнер, а потом перешли на go и, о чудо, у них внезапно упало потребление памяти и выросла скорость работы.
Почему вы взяли spring boot, а не то, что советуют для написания микросервисов на java?
Вы сравниваете по скорости разработки штуку для микросервисов и гиганский enterprise комбайн, вам не кажется, что это немного неправильно?
А что с чем сравнивать если бизнес заказывает микросервисы а не монолитных диплодоков?
ага, понял, вопрос снят, я погорячился.
Окей, тогда если я проведу такой же тест, только с пожеланием от заказчика о том, что бы программист, который будет работать с nodejs будет привязан к дереву и набирать текст будет с завязанными глазами левой ногой, а потом скажу, что на nodejs разрабатывать в 100 раз дольше, чем на java будет считатся за пример?
Разумеется, я гиперболизировал ситуацию, но как минимум, странно было делать такой вывод, как вы сделали из такой ситуации.
Я согласен с тем, что на слаботипизированном языке писать быстрее, чем на сторого типизированном, что в краткосрочной перспективе сказывается. Но не в 3 раза.
Если из "скорости разработки" не выкидывать "время отладки", то со статической типизацией получается всё же быстрее.
Слабо похоже на правду. Не потому, что у вас так не могло получиться — наоборот, могло (хотя это сильно зависит от базового опыта работы), а скорее потому, что вы наверняка не учли развития. А в развитии типизированные языки как правило выигрывают на раз-два, потому что рефакторинг автоматический лучше работает, например. Ну т.е. собственно потому же в конечном счете, почему TS вместо JS.
Это потому что вы сравниваете фреймворки типо spring + hibernate и что-то простое на nodejs?
Зачем засовывать их туда, где они не нужны?
К примеру, у меня стартует проект. Я хочу, что бы бек был написал красиво, с типизацией, компиляцией и прочей красотой. В команде у меня есть как JS девелоперы так и Java девелоперы.
Теперь один из команды предлагает — «а давайте запилим на TypeScrypt».
У меня резонный вопрос — зачем типизация в JS, если есть Java?
PS проект на одного двух человек не рассматриваем, так как тогда это бы имело резон.
Сосед купил машину, Вы к нему подходите с вопросом — нафига покупал, у меня вон есть машина, мне хватает.
А нафига типизация в яве? Вот для этих же целей она в js. мир js перенимает неплохой накопленный опыт — что в этом плохого и почему Вам это не нравится?
JS это скриптовый нетипизированный язык. И задумывался он не как что-то мега крутое. И вот из-за простоты его выбирают люди. Только когда люди упираются в проблемы языка, они вместо того что бы сменить язык, пытаются в JS внести надстройки. И ладно бы, если это браузерная часть, где все связаны по рукам и ногам только JS. Но ведь, на серверной части вы не связаны. Есть же другие языки — Java, C#, Go (которые здесь приводили). Там почему просто не перейти на них?
Вот пока внятного ответа я не получил.
Единственная адекватная причина — потому что программистов тогда можно пихать и на фронт, и на бек.
TypeScript — это не просто "надстройка" над JS, а самостоятельный язык программирования с интересной системой типов.
Можно ли на тех же Java, C# или Go взять и типизировать переменную объединением нескольких типов? А их пересечением?
Можно на скале. Собственно, как я понимаю, вопрос-то стоит понимать не столько конкретно "почему не java", а "почему не другой язык", более пригодный для бэкенда. Ну хотя бы потому, что задачи все-таки бывают сильно разные. Ну вот просто живой пример — у меня почти в 75% проектов была в том или ином виде работа с файлами Офиса — как правило, генерились отчеты в Word/Excel. И тут сразу возникает вопрос — а где у нас поддержка лучше? В идеале — и под Linux тоже. И выясняется, что она сильно разная, и стоимость разработки одной части проекта вдруг резко вырастает.
В Java можно такое делать с интерфейсами, что оказалось довольно внезапно для меня.
Что-то типа
Interface1 a = (Interface1 & Interface2) b;
TypeScript на сервере