RUVDS.com corporate blog
Website development
JavaScript
Java
Node.JS
Comments 30
+2
Почему человек из мира Java стал горячим сторонником Node.js и JavaScript?

Ну стал и стал. Если человеку что-то надоело и захотелось нового, то бесполезно его уговаривать и приводить какие-то доводы типа: есть же более простые фреймворки чем Spring и JavaEE, кроме maven есть еще и gradle и т.д. Хочется «свободы», ну почему нет-то?
+8
Честное слово, автор данного опуса некоторые проблемы java с миру по нитке собирал.
За 10 лет пользования maven мои сборки не падали при его обновлении. npm — может начать падать при обновлении даже на минорную версию, время сборки билда тоже меняется от версии к версии.
Проблемы с hibernate, spring – несколько дней на то чтобы понять «detached entity passed to persist»? Я уже вижу уровень полнейшего джуна. Любой джавист это видел при первом использовании hibernate и больше обычно осознанно такую ошибку не делает.

Автор жалуется на скрытие сложных вещей, но сам не способен разобраться в тривиальнейших вещах, которые обычно написаны в начале документации, а уж про stackover&google driven development вообще умолчу.

Статья из разряда оправдать свою никчемность, нежели привести реальные кейсы, когда node.js действительно помогает что-то решить быстрее.

Ах да, Eclipse vs Netbeans? Какого года статья? )
0
ну так видимо чувак и был джуном в начале карьеры и запомнил какая java «поганая» а js «мощный»
+5
Проблема программирования на языке со строгой типизацией столь велика, что программист, практически без вариантов, должен использовать большую сложную IDE.

Эм… почему? Звучит как-то очень не обосновано. Потому что ide для языков со статической типизацией удобнее, чем для языков с динамической?)

+8
Предатель!

JS — очень хороший язык для сайтиков с объемом не больше 10 тысяч строк кода

JS — очень плохой язык для больших настоящих проектов.

Основной вопрос в том, что в больших проектах код в основном не пишут, а читают. Оптимизация по скорости написания не очень важна. Оптимизация по скорости чтения с использованием IDE, возможность автоматического анализа хоть чего-то, возможность стабильных недеструктивных рефакторингов — это самые важные приоритеты

Навскидку, десять тысяч строк кода для JS уже могут показаться сложными, требующими десятков джаваскриптеров (и тут вступает на сцену «мифический человеко-месяц», и утаскивает в пучину ада). Проект на сто тысяч строк кажется джаваскриптеру чем-то невероятно непредставимо сложным. Проект на десятки миллионов строк кода в JS существовать не может вообще

Большие проекты без IDE ты и не попишешь, вообще. Если IDE нет для языка, его просто не используют.

V8 — куда слабей как виртуальная машина, особенно в части сборки мусора (нет возможности работать с дейтсвительно большими объемами данных, или действительно маленькими объемами оперативной памяти)
+1
Навскидку, десять тысяч строк кода для JS уже могут показаться сложными, требующими десятков джаваскриптеров (и тут вступает на сцену «мифический человеко-месяц», и утаскивает в пучину ада). Проект на сто тысяч строк кажется джаваскриптеру чем-то невероятно непредставимо сложным. Проект на десятки миллионов строк кода в JS существовать не может вообще

Работать с большой JS кодовой базоы помогает модульность, линтеры, строгие рамки в целом. 10к совсем не проблема для одного разработчика, да и 100к тоже, смотря как разработчик. Но я бы не стал писать более-менее серьезные и крупные проекты на JS, TypeScript ведь.
0

Действительно, практически все проекты на JS весьма небольшие. С помощью утилиты sloc подсчитал количество строк кода в показавшихся наиболее объёмными:


Babel — 100K
Webpack — 63K
Angular.js — 120K
React — 85K
ExtJS — 1M

0
И при том они столько всего делают! Может быть, типичный код на Java слишком раздут без необходимости?
Есть такое высказывание (не помню автора), что в мире не существует задач, которые требуют миллион строк кода (хотя это и не совсем верно, есть же Linux Kernel с ~20 млн.)
+3
Потому что этот джавист долго не хотел сам себе признаться что он скрипт-кидди.

PS только странно что именно просто JavaScript, а не TypeScript.
0
Очень хорошая. Свобода головы от лишней перегрузки, потому что модель данных, сигнатуры и прочее можно один раз выразить в коде, а не каждый раз загружать в голову. Другое дело что не все готовы «выражать в коде», но это приходит с опытом и необходимостью работать над крупными проектами и в командах размером более одного человека.
+1
Это шутка была. Человек вырвался из проклятой статической типизации Java и что опять в типизацию что ли?
+1
Могу предоложить что мнимаю свободу человек ощутил поменяв тип проектов, компанию, возможно степень ответственности, а не просто Java => JS. Потому что ответственно работать с большой кодовой базой на JS и при этом глотать свежий воздух обычно не получается.

То есть могу предположить что теперь грубо говоря он может себе позволить работать по методологии «хуяк-хуяк и в продакшен» при этом не беря на себя ответсвенность. Либо проекты небольшие/одноразовые. Если это так, то я бы тоже глотал свежий воздух работая с JS.
+1
Программирование для Node.js — это сплошное удовольствие

Сдается мне он все еще на той стадии, когда «очень приятно, и еще не вылетело исключение из черт знает какой подсистемы»…
+6
До сих пор помню ту ярость, когда оказалось, что простейший сервер на node.js возвращающий «Hello, world!» пишется в 5 строчек, а в джаве это здоровенный сервлет + еще томкат развернуть не забудь и деплой собери и web.xml проверь…
До этого делал собственные мелкие проекты на джаве.
А еще это исчадие под названием мавен, которое «Мне надо скачать 200 Мб обновлений репозиториев ПРЯМО СЕЙЧАС, поэтому вот тебе стоп зе ворлд, пойди выпей чаю и съешь еще этих мягких французских булок»
0
что это за обновления такие? у вас весь проект на снэпшотах?
0
а в джаве

Это не в «джаве», а в JavaEE. На SE тоже можно уложиться тупо кодом:
embeddedServer(CIO, 8080) {
  get("/") { call.respondText("Hello World") }
}

На Java будет чуть подлинее конечно (нужно класс объявить, public static void main, /etc), но тоже довольно коротко.
0

справедливости ради — приведённый код это не сколько Java SE, сколько Kotlin over Java SE

0
Просто у Kotlin так сказать есть «дефолтный сервер» — это ktor. Для чистой Java встаёт вопрос «а что собсно у нас будет запросы обрабатывать?». Вот пример с com.sun.net.httpserver:
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…
0
И… не буду говорить о Maven. Это — просто кошмарный инструмент.

Ну не знаю… Я как поглядел на webpack/gulp/babel/flow/ts/чотамещё у меня возникла только одна мысль — мамочка роди меня обратно.

Что сложного в управлении пакетами maven? Аналогично указываешь имя пакета (ну и его группу), version constraints там тоже есть — с этой точки всё аналогично npm/yarn, в чём трудности?
0
Работая в 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 строчек, говорит о многом...


Выбор того или иного языка или фреймворка должен определяться техническими соображениями.

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

0
Как человек, сделавший примерно то же самое — ушедший с явовских бекэндов на фронтэнд (а потом и на Node.js вдогонку) — согласен со всеми основными пунктами статьи без исключения.

Всё так (с).
+2
Если вы, как и автор этой статьи, перешли на 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 другие варианты еще хуже.
И это просто мой опыт, никого ни в чем не убеждаю и не навязываю. Универсальной технологии нет, универсальной архитектуры тоже нет, хорошо, что есть многообразие. Всем хороших выходных.
0
Что же это за пример из жизни, который вы полировали на c#, а на ноде – оно работало сразу без проблем?
0
Да это не особо важно, сервис получил запрос, обработал, отдал ответ, можете попробовать свой вариант из жизни. Нод выдает высокую производительность. Даже тяжелые вычисления, для которых нод не ремендуют, обычно можно разбить на части.
-3
Имхо, нода это хорошо, когда вы не пишете никакого кода.

Только бойлерплейт в виде анскильных крудов — достал из базки, фильтранул, показал в UI. Забрал из UI команду вида «удали элемент списочка», пропустил сквозь сервер, затолкал базу. Ну и там логика фильтрации-сохранения на сервере — из трех строчек.

По сути, всё что нужно от жизни — это быстрый обработчик хттп-запросов, и ура — его за вас уже написали самые наикрутейшие инженеры в мире. Достаточно чтобы этот сервер и ваша БД не тормозила, и приложение тоже не будет тормозить. Это IO-bound процесс, причём вы никак не можете повлиять на качество реализации этого IO, его делают за вас какие-то неизвестные внешние компании.

Но если залезть внутрь этого сервера, то там будет Си, Си++ и лютый кромешный ад с небезопасной многопоточностью, использованием возможностей ядра операционки, и так далее. Где теперь ваш JS бог? Поможет разобраться, если захочется запилить туда какую-нибудь фичу?

Вопросы возникают тогда, когда нужно писать код. Когда вы пишете реально много хитрой умной системной логики. Например, вы пишете базу данных, in-memory data grid, масшатбирующийся на произвольное количество узлов (такой как Apache Ignite). Не используете готовую базу данных, а пишете свою.

Или когда вы пишете какую-то бизнес-логику, финансовые расчёты с упором не на частоту, а на аналитику. Когда вам уже хочется программировать на матлабе вместо джавы и запускать нейросети. Когда хочется всё что можно переложить на GPU.

Или что-то более простое и близкое ынтерпайзу: например, когда у вас зависимостей на внешние пакеты — тысячи штук. Ну просто потому, что у вас в организации работают 10 тысяч джава-разработчиков, и они пишут очень много кода, и со всем этим кодом надо интегрироваться. Пример — банки.

Или у вас кластер из сотен микросервисов, и что-то там стало тормозить. Запускаешь — а оно запускается шесть часов вместо расчётных двух. Те же банки, облачные платформы, итп.

Удачи вам всё это писать и отлаживать на JS.

Хотя я знаю вариант хуже — попробовать использовать для этих задач Golang :)
0
>findUserByFirstName, учитывая то, что программист не писал код подобного метода
можно и руками писать такие методы, кто же его заставлял. можно не пользоваться сложными и автоматизированными фишками.

И само сравнение JS vs Java достаточно странное. Это принципиально разные инструменты.
Only those users with full accounts are able to leave comments. , please.