Комментарии 31
Почему человек из мира Java стал горячим сторонником Node.js и JavaScript?
Ну стал и стал. Если человеку что-то надоело и захотелось нового, то бесполезно его уговаривать и приводить какие-то доводы типа: есть же более простые фреймворки чем Spring и JavaEE, кроме maven есть еще и gradle и т.д. Хочется «свободы», ну почему нет-то?
Проблема программирования на языке со строгой типизацией столь велика, что программист, практически без вариантов, должен использовать большую сложную IDE.
Эм… почему? Звучит как-то очень не обосновано. Потому что ide для языков со статической типизацией удобнее, чем для языков с динамической?)
JS — очень хороший язык для сайтиков с объемом не больше 10 тысяч строк кода
JS — очень плохой язык для больших настоящих проектов.
Основной вопрос в том, что в больших проектах код в основном не пишут, а читают. Оптимизация по скорости написания не очень важна. Оптимизация по скорости чтения с использованием IDE, возможность автоматического анализа хоть чего-то, возможность стабильных недеструктивных рефакторингов — это самые важные приоритеты
Навскидку, десять тысяч строк кода для JS уже могут показаться сложными, требующими десятков джаваскриптеров (и тут вступает на сцену «мифический человеко-месяц», и утаскивает в пучину ада). Проект на сто тысяч строк кажется джаваскриптеру чем-то невероятно непредставимо сложным. Проект на десятки миллионов строк кода в JS существовать не может вообще
Большие проекты без IDE ты и не попишешь, вообще. Если IDE нет для языка, его просто не используют.
V8 — куда слабей как виртуальная машина, особенно в части сборки мусора (нет возможности работать с дейтсвительно большими объемами данных, или действительно маленькими объемами оперативной памяти)
Навскидку, десять тысяч строк кода для JS уже могут показаться сложными, требующими десятков джаваскриптеров (и тут вступает на сцену «мифический человеко-месяц», и утаскивает в пучину ада). Проект на сто тысяч строк кажется джаваскриптеру чем-то невероятно непредставимо сложным. Проект на десятки миллионов строк кода в JS существовать не может вообще
Работать с большой JS кодовой базоы помогает модульность, линтеры, строгие рамки в целом. 10к совсем не проблема для одного разработчика, да и 100к тоже, смотря как разработчик. Но я бы не стал писать более-менее серьезные и крупные проекты на JS, TypeScript ведь.
Есть такое высказывание (не помню автора), что в мире не существует задач, которые требуют миллион строк кода (хотя это и не совсем верно, есть же Linux Kernel с ~20 млн.)
github.com/apache/maven
PS только странно что именно просто JavaScript, а не TypeScript.
То есть могу предположить что теперь грубо говоря он может себе позволить работать по методологии «хуяк-хуяк и в продакшен» при этом не беря на себя ответсвенность. Либо проекты небольшие/одноразовые. Если это так, то я бы тоже глотал свежий воздух работая с JS.
Программирование для Node.js — это сплошное удовольствие
Сдается мне он все еще на той стадии, когда «очень приятно, и еще не вылетело исключение из черт знает какой подсистемы»…
До этого делал собственные мелкие проекты на джаве.
А еще это исчадие под названием мавен, которое «Мне надо скачать 200 Мб обновлений репозиториев ПРЯМО СЕЙЧАС, поэтому вот тебе стоп зе ворлд, пойди выпей чаю и съешь еще этих мягких французских булок»
а в джаве
Это не в «джаве», а в JavaEE. На SE тоже можно уложиться тупо кодом:
embeddedServer(CIO, 8080) {
get("/") { call.respondText("Hello World") }
}
На Java будет чуть подлинее конечно (нужно класс объявить, public static void main, /etc), но тоже довольно коротко.
справедливости ради — приведённый код это не сколько Java SE, сколько Kotlin over Java SE
public class Main {
public static void main(String[] args) throws Exception {
HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);
server.createContext("/", (t) => {
String response = "Hello World".getBytes();
t.sendResponseHeaders(200, response.length);
OutputStream os = t.getResponseBody();
os.write(response);
os.close();
});
server.start();
}
}
Можно наколдовать с более удобным api, взять более удобную библиотеку, /etc…
И… не буду говорить о Maven. Это — просто кошмарный инструмент.
Ну не знаю… Я как поглядел на webpack/gulp/babel/flow/ts/чотамещё у меня возникла только одна мысль — мамочка роди меня обратно.
Что сложного в управлении пакетами maven? Аналогично указываешь имя пакета (ну и его группу), version constraints там тоже есть — с этой точки всё аналогично npm/yarn, в чём трудности?
Работая в Sun, я верил в технологию Java. Я делал доклады на JavaONE,...
То есть чел реально не фигачил и не поддерживал ни одного проекта с достаточно большой кодовой базой. В лучшем случае делал демки и хелло ворлды для конференций. Поэтому весь остальной опус можно смело смывать в унитаз как малозначимый субъективный опыт.
Программы на Java полны шаблонного кода, который скрывает намерения программиста.
Пишите проще, вас никто не заставляет писать шаблонно.
Разработка с использованием Spring — это, до определённого момента, занятие приятное.
Spring — это инструмент. Если не умеете им пользоваться, то есть только два варианта: либо не пользуйтесь, либо учитесь.
Платформа Java EE была проектом, созданным, так сказать, «всеобщими усилиями»
JEE — это страшный сон для Java родом из конца 90-х, который слава богу скоро сдохнет.
Программирование для Node.js — это сплошное удовольствие.
Для человека, который и на джаве никогда серьезно не программировал впринципе все-равно на каком языке писать демку или "хелло ворлд". Он неизменно будет считать, что чем меньше букв в программе, тем лучше.
В JavaScript нет строгой типизации, характерной для Java. Это — благословение и проклятие языка.
Нет. Отсутствие типизации — это неизменный атрибут всех write-only language.
Обратная сторона строгой типизации Java — это необходимость в постоянном выполнении шаблонных действий. Программист постоянно производит приведение типов или занимается проверкой того, чтобы всё было в точности так, как ожидается.
Это вообще пальцем в небо. Программист на Java в первую очередь занимается ДИЗАЙНОМ приложения, когда описыавет интерфейсы, классы и методы. А частое приведение типов говорит как раз о плохом дизайне, и что программисту лучше вообще писать на JavaScript. С "шаблонным кодом" легко справляется любая IDE, а кроме того, с появлением лямбд он свелся к минимуму. "Проверкой как ожидается" занимается не программист, компилятор и IDE, причем прямо в реальном времени.
В JavaScript типы переменных не указывают при их объявлении, приведение типов обычно не используется, и так далее. В результате код легче читать,
Да нифига не легче. Когда вы видите переменную или параметр, который может быть всем чем угодно, и с "емким" однобуквенным именем… Да и писать тоже не легче, именно из-за отсутствия поддержки IDE и выпадающих пропертей объекта. Хорошо, когда знакомы по памяти с библиотекой...
Сообщество Node.js опубликовало в репозитории npm сотни тысяч пакетов. При этом использовать пакеты, которых нет в npm, так же легко, как и пакеты из npm.
Да, все очень круто. Мы все помним историю с "left-pad", который ВНЕЗАПНО! сломал тысячи проектов… И одно то, что куча JS-программеров испытывает нужду в стороннем "пакете" длиной 11 строчек, говорит о многом...
Выбор того или иного языка или фреймворка должен определяться техническими соображениями.
Выбор технологии должен определаться в большей степени эстетическими соображениями. А как известно, "о вкусах не спорят, не спорят вообще...".
Всё так (с).
Если вы, как и автор этой статьи, перешли на JavaScript с какого-то другого языка, или сменили какую-нибудь серверную платформу на Node.js, просим в двух словах об этом рассказать
Моя история, когда то начинал на java, когда появился c#, было не сложно освоить и его. Больше 10 лет я писал в основном на этих 2х языках с перевесом в c#. Это были серверные приложения, разброс большой от внутреннего пользования, до сервисов большой корпорации с миллионами клиентов. Клиентские приложения, тоже разброс большой, от вебсайтов, нативных приложений, до мобильных. Освоив какое то направление мне становилось скучно и я смотрел, что еще у нас тут есть. За это время я сделал много курсов повышения квалификации, в том числе и по внутренностям обоих платформ, нашел много неуловимых дедлоков и утечек памяти, подебагил крэш дампы с windbg и другие радости. Я не знаю всего и есть много програмистов, круче меня, но я знаю больше среднестатистического програмиста. Сейчас я fullstack, потому что «если хочешь что бы что то работало хорошо, сделай это сам». Сервер последний год тот самый spring boot, до этого пару лет был nodejs.
Итак все началось лет 5 назад, хайп про node js уже давно стоял, но не вызывал у меня ничего кроме рвотных позывов, javascript? Это тот язык, в котором нет типов, один поток и местами очень странное поведение, вы серьезно? Я С трудом заставлял себя писать клиенские скрипты для сайтов, а тут вообще все, да вы с ума сошли. Один такой сумасшедший коллега с моей работы, донимал меня на перекурах с этой нодой и что бы один раз и навсегда заткнуть ему рот, я решил написать версию одного нашего небольшого сервиса написанного на c#, на ноде. Синтетические тесты хорошо, но вот тебе пример из жизни и твоя нода сейчас причмокнет. Нет, нода не обогнала c# но она выдала туже производительность, при том что на c# мы вложили очень много в производительсть, мы отпрофилировали все блокировки, мы уменьшили количество context switch и прочие радости, мы выжали максимум из c# и поверьте мы знали как это сделать. Разумеется для ноды я не пытался делать никаких оптимизаций, зачем мне помогать врагу, что говорит о том, что код написанный програмистом, который не умеет правильно настроить многопоточное приложение на c# имеет большую вероятность, что будет работать хуже чем на ноде. Еще раз, в языках типа java и c#, неправильно написанное многпоточное приложение, будет выдавать худшую производительность, чем однопоточное. При этом если вы просто начнете писать многопоточное приложение без понимания, что там под капотом, вы напишете его неправильно. Конечно оно будет работать, но в разы или даже на порядки медленней чем могло бы. Первый бастион пал.
Ок, ну допустим говорил я, а что там с типами, как можно без типов вообще жить, появился typescript, который по началу был не очень, но очень быстро стал вау, это очень редкий случай когда получилось относительно безкомпромиссно. К сожалению мне не удалось убедить всех перейти на него, в большой команде всегда найдется своя баба яга, а тут если не все, то никто, сошлись хотябы на прикручивании babel, тут я начал замечать что мне лень писать типы в серверной части, без них прекрасно можно жить, код проверяется линтером и юниттестами, ошибок в типизации практически нет, если что их легко найти и исправить. Рефакторинг работает. Второй бастион пал незаметно, но сегодня я предпочту писать код в js, чем в java, он намного компактней.
Третий бастион, «странное поведение» после того как я разобрался с внутренностями js, а они на порядок проще внутренностей java или c#, все стало на свои места, некоторые спорные моменты можно не использовать.
Про spring, сейчас я его использую на сервере, это был не мой выбор, чем он плох, в нем слишком много магии, при этом вы очень быстро столкнётесь с тем, что вы все равно должны знать секреты всех фокусов. Хорошо хоть код открыт и хоть мой сервер достаточно примитивен, мне уже пришлось немного перелопатить сорс код спринга, дебагить это вообще жесть, куча слоев абстракции, что бы понять кто как связан, нужно много времени. Да да, разумеется с момента когда я научился пользоваться гуглом, документацией и стаковерфлоу, уже кто то родился, пошел и закончил школу, лучше способа понять, как оно работает, чем сорс код нет. Но если требование к серверу быть написанным на java другие варианты еще хуже.
И это просто мой опыт, никого ни в чем не убеждаю и не навязываю. Универсальной технологии нет, универсальной архитектуры тоже нет, хорошо, что есть многообразие. Всем хороших выходных.
Только бойлерплейт в виде анскильных крудов — достал из базки, фильтранул, показал в UI. Забрал из UI команду вида «удали элемент списочка», пропустил сквозь сервер, затолкал базу. Ну и там логика фильтрации-сохранения на сервере — из трех строчек.
По сути, всё что нужно от жизни — это быстрый обработчик хттп-запросов, и ура — его за вас уже написали самые наикрутейшие инженеры в мире. Достаточно чтобы этот сервер и ваша БД не тормозила, и приложение тоже не будет тормозить. Это IO-bound процесс, причём вы никак не можете повлиять на качество реализации этого IO, его делают за вас какие-то неизвестные внешние компании.
Но если залезть внутрь этого сервера, то там будет Си, Си++ и лютый кромешный ад с небезопасной многопоточностью, использованием возможностей ядра операционки, и так далее. Где теперь ваш JS бог? Поможет разобраться, если захочется запилить туда какую-нибудь фичу?
Вопросы возникают тогда, когда нужно писать код. Когда вы пишете реально много хитрой умной системной логики. Например, вы пишете базу данных, in-memory data grid, масшатбирующийся на произвольное количество узлов (такой как Apache Ignite). Не используете готовую базу данных, а пишете свою.
Или когда вы пишете какую-то бизнес-логику, финансовые расчёты с упором не на частоту, а на аналитику. Когда вам уже хочется программировать на матлабе вместо джавы и запускать нейросети. Когда хочется всё что можно переложить на GPU.
Или что-то более простое и близкое ынтерпайзу: например, когда у вас зависимостей на внешние пакеты — тысячи штук. Ну просто потому, что у вас в организации работают 10 тысяч джава-разработчиков, и они пишут очень много кода, и со всем этим кодом надо интегрироваться. Пример — банки.
Или у вас кластер из сотен микросервисов, и что-то там стало тормозить. Запускаешь — а оно запускается шесть часов вместо расчётных двух. Те же банки, облачные платформы, итп.
Удачи вам всё это писать и отлаживать на JS.
Хотя я знаю вариант хуже — попробовать использовать для этих задач Golang :)
Всегда полезно посмотреть на вещи с другой стороны.
Я понимаю боль автора
Меня весьма радовала динамичность динамических языков, но сейчас я на чистом JS не пишу ни одного проекта.
Нода покупает тем, что это событийно-ориентированный и при этом мультипарадигмальный язык/платформа.
Можно очень качественно утилизировать одно ядро, и при этом (благодаря промисам) писать эффективный "интернет код" для 95% задач всего веба.
А если это покрыть ещё и типами — получается весьма мощный инструмент.
Но вот писать без типизации у меня пальцы не поворачиваются, и я бы не сказал что это обуза.
Это больше проблемы джавы, которая сильно синтаксически упрощена и описывать даже "колбеки" нужно через реализацию отдельного класса имплементирующего отдельный интерфейс (привет даже от делегатов из C#), и фактически полное отсутствие автовывода типов (привет опять же от var из C#).
Наверное, Котлин — это спасение для джавы.
Но не об этом.
Я не согласен с автором на счёт динамической типизации, это не обуза, а дисциплина.
Лучше писать меньше тестов, но код более читабельный и IDE подскажет, чем писать динамично и потом покрывать все такими же динамичными тестами.
На JS без типов я больше не рискую писать что то даже среднеразмерное.
Для серьезного проекта без математики я могу выбрать ноду без зазрения совести и все будет отлично, но для проектов с большим количеством математики (в том числе банковские системы и прочее) нода противопоказана из-за несколько необычной реализации Number и всех всплывающих последствий в процессе маппинга числовых значений между БД и слоем приложения.
Но выбирая между джавой и C#, я уверенно выберу второе. Привет от делегатов, async/await, linq, автоматически выводимые типы и прекрасный cli (это я о .NET Core конечно же).
Почему человек из мира Java стал горячим сторонником Node.js и JavaScript?