Секта джаваскриптеров

[ShadowMan]

Вот у меня возник вопрос по стеку node.js
Я как , старый вэбкодер, не пойму, чего народ на него так дрочит?
Чего нельзя сделать на php, python или golang и можно только на ноде?
Ну я бы понял какие то ну супер принципиальные различия, но что такого
заебического в яваскриптах, выполняемых на сервере?
Скорость исполнения на сервере, срок разработки, стоимость разработки и поддержки?
Так нет же этого.. По крайней мере, я только вижу стоимость разработки и поддержки,
увеличенную в 2-3 раза, не говоря даже об отсутствии нормальных специалистов.
Все западные маркетплейсы работают по технологии NoJavascript, чтобы усилить
приватность юзера, а тут мы наоборот пихаем яваскрипты, куда только можно и не можно.
Да и админкам ботнетов яваскрипты скорее вредны, чем жизненно-необходимы.
Я ,конечно, про нашу тематику говорю, в других местах может это и нормально.
Ваши мнения, господа кодеры?

 

[ch38urek]

- Тук, тук
- Кто там?
...Через 20 секунд...
- Javascript!

 

[DildoFagins]

Чего нельзя сделать на php, python или golang и можно только на ноде?

Нельзя иметь один и тот же стек и язык на клиенте и на сервере. Я, конечно, не беру в расчет всякую изотерику, типа Pyiodide, PyScript, Brython и тд.

 

[ch38urek]

По крайней мере, я только вижу стоимость разработки и поддержки,
увеличенную в 2-3 раза, не говоря даже об отсутствии нормальных специалистов.

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

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

Да да, только там на стороне работы в браузере JS отказываются, а не на серверной стороне, запустить фронт на NO-JS, но с беком на ноде никто не запрещал, но и поголовной любви к пользователю я если честно не очень часто вижу

Да и админкам ботнетов яваскрипты скорее вредны, чем жизненно-необходимы

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

 

[ppdonchiq]

Я как , старый вэбкодер, не пойму, чего народ на него так дрочит?

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

Эта теория не подтвердилась, потому что внезапно оказалось, что несмотря на некую общность синтаксиса, разлличие в процессе разработки никуда не делось. Есть фундаментальная разница, если фронт отрисуется в браузере позднее на 200 миллисекунд, все стерпят (браузеров много, они друг на друга не влияют), а лишние 200 миллисекунд при высокой нагрузке (прости за баззворд) на бэке могут привести к каскаду событий, в результате которых все встанет. Таким образом, для нормальной разработки бэка все равно требуется и алгоритмическая подготовка и знание системы и сетей, чего, конечно же, двадцатилетним фронт-сеньорам не нужно.

Очередная серебряная пуля не сработала, что ты будешь делать.

 

[team_RX]

скорость разработки, дешевизна разработки.

 

[pepel]

ТС, ты путаешь фронт и бэк, или мне показалось? Говоря про "нашу тематику", ты можешь написать бэк на ноде, и положить это в ТОР, или куда угодно. Просто не добавляй JS на фронт, стучит именно он, ссылаясь на CDN и генерируя всякие отпечатки. Бэк это просто логика сайта/апликухи и роуты к ней.

Нода сама-по-себе не язык, а среда исполнения того самого JS. Браузерный движок переделанный в интерпретатор. И его популярность по сравнению с пхп и питоном в своё время обусловленна асинхронностью. Он считается самым быстрым в числе этих троих (и прочих) языков. Для энтерпрайза тоже свои плюсы, хотя бы в том, что тебе не нужно разграничивать фронтов и бэкеров, а лишь переучить. Одна кодовая база для двух вещей. Ну и хайп, конечно, аля "как это серверный джс? Гоните?"

 

[DildoFagins]

Вообще, говоря о нашей теме, можно полноценную малварь под Венду написать на JS, исполняя через любой IActiveScript-хост (wscript/cscript, mshta, scrobj.dll и тд). Конечно, с AMSI могут возникнуть проблемы, с JS/VBS его не так просто скинуть, как с PowerShell'а, но все же. Вот вам и фуллстек по мамкин хацкесрке...

 

[ShadowMan]

Ну короче вывод - очередной хайп, типа Ruby on Rails.
Как по мне, GO очень неплохо заходит под бэкэнд и API высоконагруженных проектов.
Опять же насколько нагруженных?
Хотя я вспоминаю один славянский проект Tochka(маркетплейс), очень он хорошо держал
нагрузку и закрылся красиво, парни поняли, что попка начинает пригорать.

 

[gliderexpert]

Да нет нагрузки на эти дарк маркетплейсы, по количеству пользователей и обращениям к базе данных, это все детский сад.
Есть ДДОСы, да - но от них делается грамотная защита, мусорный траф и запросы вообще не должны попадать на основной сервер. Поэтому нагрузки на нем нет. Вы подсчитайте, сколько трафика можно прогнать через ноду тора - вот и предел вашей нагрузки. Любой бек справится, если нормально защита от ддоса сделана.
Это все равно что построить хайлоад сервак на 100500 ядерных тредрипперах, написать супер бекенд на нем, а вывести в интернет через u.s. robotics 56k - и что, сильно он будет нагружен?

Другое дело если на серваке запущены какие-то вычисления. Но зачем это на ДАРКНЕТ маркетплейсе?

 

[ShadowMan]

Про ноду ТОРа полностью согласен, а вот как насчет фейсбука и протонмейла в торе ?
Ну там явно трафика хватает, ну разве что свои какие то ноды и балансировщики нагрузки, хз.

u.s. robotics 56k

Ну ты вспомнил.. чувствуется, что давно тут землю топчешь

 

[gliderexpert]

Про ноду ТОРа полностью согласен, а вот как насчет фейсбука и протонмейла в торе ?

Условный "фейсбук" в торе невозможен по причине отсутствия достаточного количества выходных нод с хорошими каналами, чтобы тянуть такое количество трафа. Даже не говоря про то, сколько людей на него захотят пойти )
Протонмейл - это не хайлоад. И он не чистый hidden service, все таки это клирнет сервис, имеющий зеркало в торе.

 

[pepel]

Ну короче вывод - очередной хайп, типа Ruby on Rails.
Как по мне, GO очень неплохо заходит под бэкэнд и API высоконагруженных проектов.
Опять же насколько нагруженных?
Хотя я вспоминаю один славянский проект Tochka(маркетплейс), очень он хорошо держал
нагрузку и закрылся красиво, парни поняли, что попка начинает пригорать.

Go для этого и создавался, т.ч. да. Но тебе в любом случае нужен будет фронт.
Справляться с нагрузкой можно по разному, и это всегда вопрос денег. Код (идеальный) отработает как надо, но ляжет железо, или канал... Почитай про масштабируемость и два её вида

 

[DildoFagins]

Говоря о масштабируемости и высоких нагрузках, тут может пригодиться Elixir и Erlang со своей Beam VM. Опять же, цифорки на нем непокранчишь, как и на Петухоне, но в плане поддержки кучи параллельных соединений, он многих уделает.

 

[weaver]

Я как , старый вэбкодер, не пойму, чего народ на него так дрочит?
Чего нельзя сделать на php, python или golang и можно только на ноде?

Всё просто php на стороне сервера, js на стороне клиента. И тут погружаясь в дебри JS, а у не блядский синтаксис люди подумали, а почему бы его не использовать на стороне сервера? Так и произошло. Но это не точно))) В обще вот эти все фреймворки... я их могу сравнить только с Python'ом, по типу фласки, торнадо очень удобно все шкодится особого геморая нет. В силу того, что у каждой технологии бывает свой хайповый пик, вот оно и используется

 

[Encommerce]

я их могу сравнить только с Python'ом, по типу фласки

Да, фласк в своей простоте действительно великолепен. Но Fastapi вызывает больше интереса на данный момент. Безусловно, его целевое преминение это стрельба json'ами и их прием, однако и фронтик приклеить можно к нему, хоть и с небольшими костылями. Да это медленее ноды, но это в разы быстрее фласка и джанго, при этом довольно разгруженно в плане кода)

 

[ppdonchiq]

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

Да, все так, тор играет роль бутылочного горлышка и демпфера так сказать.

Есть ДДОСы, да - но от них делается грамотная защита, мусорный траф и запросы вообще не должны попадать на основной сервер. Поэтому нагрузки на нем нет. Вы подсчитайте, сколько трафика можно прогнать через ноду тора - вот и предел вашей нагрузки. Любой бек справится, если нормально защита от ддоса сделана.

Тут тоже согласен. Но если поднимаем домен .онион, то свои проблемы вносит как раз тор, слишком много луковых цепочек способны сожрать проц (там криптография) и в плохом варианте все блокируется, и онион домен перестает быть доступным, т.к. дескриптор вовремя не обновился.

Про ноду ТОРа полностью согласен, а вот как насчет фейсбука и протонмейла в торе ?
Ну там явно трафика хватает, ну разве что свои какие то ноды и балансировщики нагрузки, хз.

Я думаю, что у фейсбука (facebookcorewww...дальше не помню) очень малая доля пользователей лезет через скрытый сервис. Узнать, используется ли балансировка можно пронаблюдав дескриптор в течение нескольких часов.

 

[gliderexpert]

Тут тоже согласен. Но если поднимаем домен .онион, то свои проблемы вносит как раз тор, слишком много луковых цепочек способны сожрать проц (там криптография) и в плохом варианте все блокируется, и онион домен перестает быть доступным, т.к. дескриптор вовремя не обновился.

onion v2 так даже досили.

 

[Aels]

ради одного - server-side rendering.
Когда у тебя одностраничная аппликуха, а все компоненты тянутся с сервера поштучно по запросу - это очень удобно, быстро, и целостно для юзера.
Но. Если юзер пойдет не с главной, а например с /post235, то получится, что ему нужно выкачать главную, а затем тянуть все компоненты и содержимое поста.
И тут в игру вступает серверный рендеринг - мы собираем всю страницу как она есть на сервере в статический html, и отдаем юзеру.
Только ради этого.
Ну... в целом еще сама парадигма event-loop-а неплоха и ставит мозги на место говнокодерам, позволяет экономить ресурсы на форк процесса, и избавляет от непредсказуемого поведения в работе между потоками. У Go ко-рутины работают по тому-же принципу. Например по-этому успехом пользуется, например, haraka - smtp-шлюз, написанный на ноде - он пизда как быстр.

 

[ShadowMan]

Почему то на ноде я видел 1 форум, да и тот кривой