Comments 116
Тот факт что вам что-то чем-то кажется не означает что это так.
Кроме того, в случае с js, я не уверен что будет выполняться условие работой на ближайшие 10-15 лет вы точно будете обеспечены ибо уже сейчас количество выброшенных на рынок js разработчиков намного выше чем в любом другом языке и, в силу простоты и популярности языка, их количество только растёт, так что есть шанс что предложение превысит таки спрос.
Вы действительно полагаете что JS в плане будущего трудоустройства хуже чем C++ или C#? Это абсурд. Объективно области применения JS шире (с точки зрения рынка труда) чем у этих двух языков. У них так же есть негативные факторы, как то сужающаяся ниша у C++ и появление конкуренции, так и вендор-лок у C#.
Почему-то ваши претензии к JS вы не применяете к Java. Её тоже пытались использовать для всего (и сейчас кстати много для чего используют и пытаются использовать в той же манере). И точно так же у неё огромная популярность, хотя про порог входа ничего не могу сказать.
а строится на субъективном негативе к JS.
Эм, да. И что? Человек пожаловался на невозможность выучить все существующие нынче языки программирования, я предположил что все учить и не нужно, достаточно одного, но хорошо выученного.
Если вы хотите писать приложения под мобилки учите java, десктопный софт C++/C# и т.д.
ИМХО лучше хорошо знать язык подходящий под вашу область интересов, чем пытаться один и тот же язык натянуть на все области программирования сразу. Всё равно объём труда и сил затраченный на получение экспертных знаний даже в одной области много больше чем объём необходимый на изучение плюс/минус одного языка.
И если в каком-то языке есть инструментарий позволяющий качественно решить какую-либо задачу не лучше ли воспользоваться этим инструментарием, чем ждать появления подобного под js?
И да, субъективный негатив к js вполне может у меня быть, я никогда не претендовал на роль беспристрастного эксперта. Но наблюдать как на сайтах становятся нормой бандлы по мегабайту кода, а на десктопы приходит тормозной софт на электроне и иже с ним, несколько утомляет. Эти люди вполне могли потратить свои силы и талант на разработку куда более совершенных решений. А в итоге куча сил уходит в разработку писаного на коленке кода, который приносит доход вотпрямща, в ущерб моему железу и времени. Да, таки эта ситуация вызывает во мне негативный отклик и советовать людям учить js я не могу, как бы хорош он ни был.
И им плевать на то сколько вы языков знаете если вашу команду можно заменить одним человеком
Если команду из 5 человек заменить одним универсалом, то скорость разработки упадет в 5 раз даже если инструмент позволяет так же эффективно решать задачу, а обычно это не так.
Нанимать же 10 универсалов вместо 5 специалистов это уже более интересный размен. Бизнес как-то додумался, что вместо фуллстеков лучше разделять бек и фронт. И что девопса лучше отдельного нанять, а не требовать от разработчиков среду конфигурировать. Зачем вы предлагаете двигаться в обратном направлении? Не представляю.
Есть у нас бек, фронт, и мобильное приложение
для этого надо 4 разные команды узких специалистов, или одну команду специалистов на жс.
Вторые будут выгодней с точки зрения бизнеса, ибо могут подменять друг друга и обучаться вместе при надобности, да, они (возможно) будут хуже знать свое дело чем того же уровня узкий специалист, но в большинстве случаев не нужно идеально знать инструмент.
И вот будут ли 8 универсалов дешевле 4 специалистов — вопрос.
нейронные сети можно обучать на жс
Их хоть на брейнфаке обучать можно. Только никому это всерьёз не нужно. Сколько у вас будет обучаться сеть на js? Пару веков? А все «взрослые» нейросети по факту на C/C++ с пробросом хвостов в другие языки для упрощения использования.
Почему же штук 8? Вы оперируете странными терминами. Если жс менее эффективный, значит надо больше лудей?
Потому же почему 9 женщин не смогут родить ребёнка за месяц. То что вы напишете один код ко всем платформам не избавит от необходимости его тестировать на каждой отдельно и учитывать все специфики при написании.
И в большинстве задач жс может заменить другой язык 1 к 1.
Я не согласен с этим утверждением по большому счету. Можно сравнить телеграм и какой-нибудь слак. Если бы телега лагала так же, она бы никогда не взлетела. Но я до сих пор помню, что для меня определяющей фичей стало, что я могу в метро достатть телефон и с нестабильным соединением посмотреть что там мне написали, и ответить.
В итоге на последних моих двух работах мы пользуемся для внутренней переписки исключительно телеграм, просто потому что он не тормозит. Вот вам и «неидеальный» слак. Причем, я так думаю, оптимизировать там особо нечего с прикладной стороны, это сам электрон такой.
По поводу тормозов на медленном инете спорное заявление, вы думаете жс требует больше данных от апи для работы при условии что все загружено (привет PWA) и закешировано? Слак тупит по другим причинам :) Зато кодовая база у них одна на несколько платформ, что очень сильно уменьшает время разработки, а значит сильно экономит деньги, а значит более плагоприятно для держателей бизнеса, и значит добавляет быстрей и больше фич и удобства пользователям.
Безусловно есть варианты где натив лучше, но это не частое требование, но всегда более дорогое, иногда на порядок дороже.
Есть софт выбор которого определяется корпоративными стандартами и количеством людей в нём сидящих. Если нужно работать в обществе от него никуда не денешься.
То есть я понимаю что вы имеете ввиду поднимая тему не удобности софта. Но не понимаю почему вас это действительно так задевает и вы ничего не делаете что бы облегчить себе моральные страдания. Мыши плакали, кололись, но продолжали грызть кактус?
Вы свободный человек, только вам решать что использовать и с чем работать.
React, Anular, Vue, Node и всё вот это
добавьте туда react-native и electron до кучи уже. Только зачем вам этот человек-комбаин который типа знает всё? Сказать что ты хорошо знаешь и владеешь какой-то технологией можно, думаю, через год-два плотной работы с ней. Если у вас синьёр одновременно отлично знает все существующие js фреймворки то либо ему 100 лет, либо он 3,14дит.
сеньора на JS (который, естественно, + React, Anular, Vue, Node и всё вот это)
который сразу сеньор, а не переучится. Работодатель будет оплачивать время переучивания?)
Типа зная Vue, вы за несколько часов запустите какой-нибудь hello-world на ангуляре. Но на то чтоб разобраться в существующих решениях/модулях и выбрать из них лучшие для себя уйдут опять же годы, не?
Так то зная js можно быстро переучиться на rust, ага. Паттерны в принципе такая штука которая кочует от языка к языку, а вот тот дьявол, который кроется в деталях познаётся только в процессе работы имхо.
отлично знаете сам js
Что конкретно вы подразумеваете под «сам js»? Сотню операторов? Десяток api разных браузеров? Паттерны? Общепринятые подходы и методы? Чего там запоминать и «знать»-то?
Знание языка никак не избавляет от необходимости глубокого понимания области применения.
Для того чтоб «перейти» да, достаточно нескольких часов, я написал.
Для того чтоб начать писать чистый код на уровне синьора в соответствии с идеологией конкретного фреймворка нужно гораздо больше времени.
ps. Мне тут очередная девочка-хрюша прислала вакансию, требования — Angalar 6 опыт от года. Я ей ответил, что он вообще вышел в прод в мае 2018. Что-то не пожелала продолжить диалог
Что конкретно вы подразумеваете под «сам js»? Сотню операторов?? Десяток api разных браузеров? Паттерны? Общепринятые подходы и методы? Чего там запоминать и «знать»-то?
Подходы и паттерны как раз. Большинство веб-фрейморков все равно делают одинаковые вещи, биндинг (одно-двухсторонний), реактивное программирование, деление на компоненты и прочее.
blog.acolyer.org/2017/11/20/dejavu-a-map-of-code-duplicates-on-github
Интересно почитать всю статью, но краткая выдержка такая:
у JavaScript 261 миллиона файлов, из которых только 6%(всего 16 миллионов файлов) не дубликаты.
У той же Java не дубликатов 60 % или 43 миллиона файлов.
Так что скорее можно назвать JavaScript лидиром по копи-пасту.
В случае JS экосистема меняется очень быстро. Каждый год-два приходится переучиваться под новый фреймворк. Если этого постоянно не делать, то ценность программиста будет снижаться.
Каждый год-два приходится переучиваться под новый фреймворкСовременный стек в топе уже года четыре минимум. И пока не видно ему альтернатив.
Я помню, потому что в конце 2015-ого менял работу и тогда уже на каждом собеседовании спрашивали про разницу между Реактом и Ангуларом, про то, зачем нужен Редакс, когда пользоваться props, а когда — state.
Вот, к примеру, статья четытерхлетней давности о том, почему нужно использовать ES6 и где использование Вебпака описывается как само собой разумеющееся:
Типичный сценарий, чтобы проиллюстрировать эти недостатки это генерация связки модулей для браузера, с помощью таких инструментов, как browserify или webpack
Хотя о нем на Хабре писали еще в 2014-м и, судя, по комментариям, никто особо не удивлялся, как Редаксу в 2015-ом.
О том, какой будет Angular 2 и то, что он будет на Тайпскрипте было ясно точно так же в 2015. Да, популярности Вью не 4, а три года, но он сейчас не обязательный.
Ну и самое главное — пока не видно, чтобы это был закат всех этих фреймворков. Минимум года два они еще точно будут активно использоваться и тогда, через два года может какой-то другой фреймворк на собеседованиях станет обязательным. Но цикл явно не год-два, как сказали ранее.
1) Js, пожалуй единственный язык который позволяет реализовать полностью весь стек ИТ систем. Фронтенд, бекенд, мобильные и десктопные приложения. Простыми словами, владея Js вы можете создать полностью законченное решение.
2) Я работал фуллстек программистом, писал на C#, Golang, JS. Но решил выбрать специализацию фронтенд, и в том числе по причине того, что фронтенд программистам платят не меньше и зачастую больше. И к тому же вакансий больше.
Основной вопрос в том, какого качества получается этот "весь стэк". Сравните телеграм и слак для Андроид. Разница не то, что очевидна, слака прям плакать хочется. А альтернативы нет, поскольку корпоративный мессенджер. На том и играют. А пользователи страдают. По мне, так лучше качественный софт, чем тормознутый монстр
"Вполне справляется" и "приятно пользоваться" — это разные вещи. У нас тоже справляется, но если у меня есть возможность лишний раз не запускать его на мобильнике, я с облегчением не буду этого делать. В отличие от того же телеграмма, когда там и запуск быстрее, и интерфейс намного отзывчивее и выглядит не как веб страница, и текст можно выделить и скопировать частями, а не все сообщение без возможности выделения.
Её же не набрать на клавиатуре
Alt + 0181
А если бы наши программисты все названия пакетов на кириллице писали?
У нас не только названия пакетов пишут кириллицей, у нас целый код порой кириллицей пишут:
В npm есть ограничения на имена пакетов (разрешается только латиница и немного пунктуации). Мне кажется, что если бы не это ограничение, то пакет бы тоже назывался µWebsockets.
Как бы да.
Приятность того же Go в легком программировании любых конкуррентных задач, а не только HTTP или вебсокетов.
Тут же на Си реализовали какую то небольшую часть сетевых протоколов и заявили что Node стал быстрее.
Не стал.
И при этом совсем не раскрыта тема, что рулит, по сути, низкоуровневое "ядро". Которое, как я понимаю, при этом ещё и достаточно универсально.
Завтра сделают биндинг к нему для Go — и всё, тема статьи снова станет неактуальной.
И это уже происходит с Python и PHP — серьёзные и интересные проекты вдобавок к этим языкам требуют знание Go (иногда C++).
А сама статья — довольно шаблонный пиар: «Я залез в дебри ядра Linux, скурил всего Майкла Керриска, выучил C как сам Керниган, кучу времени потратил на оптимизации и даже написал несколько ассмеблерных вставок и вот результат: самый быстрый веб-сервер на Python/JS/you-name-it, который умеет 100500 запросов в секунду». Для Python был japronto. Слышал, он сейчас заброшен, говорят, что автор работу так искал.
А есть разница на реальных проектах? Все равно львиная доля ресурса уйдет на сериализацию/десериализацию json и бизнес логику. Да и на проектах с нагрузкой больше 1к уже инфраструктура состоит не из 1 ядра, и масштабировать придется все равно бизнес логику а не реализацию ws
Точно так же. Только ресурсов нужно по-больше.
Jit бесспорно помогает значительно увеличить производительность программы. Но в сферическом вакууме интерпретируемый язык с большим рантаймом никогда не догонит низкоуровневые компиллируемые и изначально типизированные языки (да простят меня адепты js, java, питона и иже с ними)
Любопытно. А с аналогичным решением на go https://github.com/gobwas/ws пробовали сравнивать?
1. Брать сторонюю либу — зависимость от стороннего разработчика.
2. Если разбираетесь в с\с++ — есть возможность чтото подпилить\под себя подкрутить
3. Если разбираетесь в с\с++ — зачем клеить в nodejs с\с++ и продолжать писать на js?
это все как то странно выглядит… утверждение и сравнение в томже числе.
Если мне нужен очень-очень-очень быстрый вебсервер то с подходом автора я бы вообще железку купил, в которой нужный мне протокол будет реализован нативно. Быстрее будет просто некуда.
А так автор, как и многие другие, пожертвовал гибкостью и получил скорость. И чего пиарится?
Когда уже люди прийдут к тому, что меряется rps'ами довольно бестолково?)
Типа rps'ы сами по себе не особо полезная метрика. Но обычно корреляция между rps и общей «отзывчивостью» приложения таки соблюдается.
Между двумя одинаковыми решениями выиграет то, которое будет быстрее работать.
Между двумя одинаковыми решениями выиграет то, которое будет быстрее работать.
То-то все пользуются телеграмом как корпоративным чатом, а не слаком. А нет, черт, все равно наоборот, потому что пользоватся телеграмом как корпоративным чатом невозможно, его ui просто не заточен под это.
В реальном мире достаточно, что бы приложение работало приемлемо быстро для пользователя. И стоит учитывать, что существует тысяча и один способ выполнить долгую операцию в фоне, что бы пользователя это все еще оставалось приемлемо быстро. Не говоря уже о том, что в довольно большом количестве случаев время ожидания ответа от той же бд в приложении будет занимать 50-80% времени запроса.
Я потому и написал одинаковыми. Скорость не определяющий фактор при выборе решения, но и отбрасывать её нельзя.
Типа запустите вы слак, insomnia, VSCode, chrome, скайп и привет оперативка. Потом появятся у нас sftp клиенты на электроне, какой-нибудь electon-git, оболочки на js. Пока карман позволяет докупать память вы будете оправдывать эти решения, а потом просто пойдёте искать что-то менее прожорливое.
Типа если выйдет аналогичный слаке продукт с нативной поддержкой большинства платформ вы продолжите делать ставку на слак?
Типа если выйдет аналогичный слаке продукт с нативной поддержкой большинства платформ вы продолжите делать ставку на слак?
В реальности такого же не просходит. И не происходит в основном потому что при разработке слака сделали в том числе фокус на фичи и интеграции, пожертвовав производительностью. Разумеется, если будет приложение как слак, но еще и оно будет быстрее работать, я выберу его, а не слак.
Но такого выбора мне никто не предоставит, и меряя языки по rps, а не скажем, по "сколько строк (выражений) мне понадобится на реализацию этой бизнес-фичи" вы возносите менее важную метрику.
вы возносите менее важную метрику
Для кого менее важную? Для бизнеса и скорости разработки? да, допустим.
А для конечного пользователя и развития индустрии в целом — большой вопрос. Доступный объём памяти и производительность компьютеров в пределе — конечная величина. У нас уже, кажется, не выполняется закон Мура.
Типа ок, сейчас бум электронов и spa, вы наплодите js-разработчиков и чатиков по 200мб. А дальше куда?
конечного пользователя
Отвечу как "конечный пользователь" — да, для конечного пользователя. Если в продукте нет какой-то нужной мне фичи, я им не пользуюсь. Если в продукте она есть, но он приемлемо тупит, то можно попробовать.
И со мной согласны, например, большинство программистов, которые испозуют pycharm или vscode.
А дальше очевидно куда, к кросс-платформенным нативным приложениям, типо flutter, qt и так далее. Что бы оно еще и быстренько работало.
Если в продукте она есть, но он приемлемо тупит, то можно попробовать.
Ну ок, если вы комфортно чувствуете себя в тормозящих приложениях, мне нечего вам возразить.
Ну ок, если вы комфортно чувствуете себя в тормозящих приложениях, мне нечего вам возразить.
Мне нравится, как вы рассказываете про эти приложение не так, что они "ну, немного подтупливают в конкретных местах", а прямо тормозят.
На практике тот же vscode тупит исключительно в некритичных местах, а все важное, например, ввод текста работает в нем очень быстро.
Но вот что будет через 5-10 лет ваять на qt (тоже весьма жирненьком) толпа нынешних js-синьоров прям хочется посмотреть.
Всегда классно троллить программистов, которые сидят на других технологиях, пока не понимаешь, что по факту свою технология еще хуже.
На практике тот же vscode тупит исключительно в некритичных местах, а все важное, например, ввод текста работает в нем очень быстро.
Ну ок, я сужу по тому железу с которым приходится работать. Пробовал vscode — вернулся к sublime. Ибо на +- больших файлах было видно как построчно рендерится разметка. Может за год оно поменялось и ускорилось, но тут уже на вкус и цвет.
классно троллить программистов
дальше очевидно куда, к кросс-платформенным нативным приложениям, типо flutter, qt и так далее
Я троллю или вы? Типа по вашим словам гора написанного ныне электронового кода со временем будет переходить на флаттеры и кьюти. Вы в этой ситуации хотите чтоб js-разработчики отказывались от поддержки собственных приложений и участвовали только в стартапах или чего?
Типа да, выгодно какой-то прототип сваять на электроне и подцепить на него готовую вёрстку с работающего сайта. А поддержкой всего этого когда оно выйдет на промышленные масштабы будет заниматься кто?
Пробовал vscode — вернулся к sublime.
Да, sublime классный. Но я не смог на него вернутся из-за конфигов, которые слишком не типизированы.
Типа по вашим словам гора написанного ныне электронового кода со временем будет переходить на флаттеры и кьюти
Ну, вы спросили — что дальше. Раньше вот были приложения на java, теперь все обмазано электроном, я думаю, что в дальнейшем новые приложения уже будут писать на чем-то, что собирается в нативный код. Разумеется, старые приложение останутся на своем стеке, как и старые приложения на java.
Типа rps'ы сами по себе не особо полезная метрика. Но обычно корреляция между rps и общей «отзывчивостью» приложения таки соблюдается.
И возвращаясь к теме. Не знаю, как у вас, у меня опыт показывает, что обычно тупит неоптимальный код разработчиков, в духе "ой, вместо одного запроса к бд нахренашим 50", и каким бы классным не был язык, вас от такого ничего не спасет. А сами языки, ну, дадут вам 100 мс максимум.
А сами языки, ну, дадут вам 100 мс максимум.
Вот тут как раз и применимы всякие бенчмарки, типа benchmarksgame-team.pages.debian.net/benchmarksgame/faster/node-gpp.html
Вроде как код на всех языках там пытаются писать оптимальный, ан нет. На одних и тех же тестах разница между реализациями достигает десятков и сотен раз.
Так же и с любым крупным проектом у вас будет выбор — либо докупить пару-тройку десятков серверов, либо переписать серверную часть на более эффективном языке.
Где-то даже конференцию от того же яндекса находил. «Как вы оптимизировали обработку big-data на питоне? Нуууу мы переписали нагруженные места на c++ и выкинули питонячьи апишки для аналитиков»
Да, я не отрицаю, интерпритируемые языки с высоким уровнем абстракций весьма полезны в своей нише, например когда сисадмину надо написать скрипт бэкапов или аналитику дёрнуть данные из базы. Но массовый переход разработки на это добро неизбежно приведёт к проблемам.
О, класс, ссылки на бенчмарк гейм подъехали. В той репе, которую вы приводите в пример, например, аж один контрибьютор (хотя если ссылки на кучу других людей, которые вроде бы и писали этот код).
Да и даже без них, сравните ту же n-body задачу на С++ и python.
То есть в С++ люди опускаются до ассемблера и -03, который никто не использует в проде, а для питона использовать какой-то cython или numba уже нельзя, разумеется? Звучит как двойные стандарты на самом деле.
Когда вам нужен перформанс, вы опускаетесь на уровень ниже (Python -> C++/С -> Assembler -> hardware optimization), не совсем понятно, почему вы считаете это странным.
А сами языки, ну, дадут вам 100 мс максимум.
теперь вы говорите
Когда вам нужен перформанс, вы опускаетесь на уровень ниже (Python -> C++/С -> Assembler -> hardware optimization)
В итоге-то что? Зависит скорость программы от языка или нет?
В итоге-то что? Зависит скорость программы от языка или нет?
Опять же, в силу того, что статья про веб я говорил про веб-приложения и запросы. Напомните, когда веб-приложения выполняют синхронно бенчмарки? Мой тезис в том, что в веб-приложении не особо зависит.
С тем, что числодробилки стоит писать на низком уровне и прокидывать интерфейсы вроде никто особо не спорит.
1) Если у вас сурово ограничен объем памяти.
Или
2) Если вам нужен суровый риалтайм
Или
3) Если вам недоступно горизонтальное масштабирование, а новая крутая железка стоит сильно дороже вашего времени
=> Вы опускаетесь ниже на уровень абстракции.
Честно говоря, у меня очень крупные сомнения касательно того, что в случае с пунктов 1 или 3, особенно с 3, вы делаете все правильно. К первому пункту обычно можно прицепить какой-то IoT, но, честно говоря, их пишут на всем подряд и оно даже как-то работает.
Касательно пункта 2 в целом тоже, но там я хотя бы знаю условные области применения (типо алгоритмических торгов, онлайн игр и так далее).
Можно, в принципе, так для чего угодно сделать — пишем быстрый код на c++/c/asm -> выбрасываем в js апишку типа runMyProgram() -> радуемся какой js быстрый и оптимальный.
Мой тезис в том, что в веб-приложении не особо зависит.
Ну на сайте формата магазин — 10к товаров/2к посетителей в сутки мб и не зависит. На больших объёмах уже будет чувствоваться.
Веб-приложение — понятие растяжимое.
Ну на сайте формата магазин — 10к товаров/2к посетителей в сутки мб и не зависит. На больших объёмах уже будет чувствоваться.
Все так же не будет. Потому что вы, скорее всего, не будете делать поиск в приложении, а будете делать в базе данных и кешировать результаты. В противном случае на чем бы вы не писали, всегда будет мало.
Приложение на js не будет тормозить, если узкие места не писать на js.
Блин, с этим тезисом я даже поспорить не могу.
Вообще, если по-сути, я считаю что основные преимущества js — дешевизна мультиплатформенной разработки и большое количество рабочей силы благодаря крайне низкому порогу входа, остальное — компромисы на которые бизнес идёт ради первых двух преимуществ. Что вы пытаетесь мне доказать я уже не понимаю.
Какая-то странная статья, вроде как по заголовку должно быть дофига сравнение, в конкретном направлении для node.js vs golang.
А по факту немножко описывается биндинг имплементации WebSockets на крестах, который "значительно обходит по производительности лучшие решения, написанные на Golang"
Поэтому я люблю метод pipe() у стримов — если возникает backpressure во writable стриме, pipe() автоматически поставит на паузу readable стрим до события drain. Т.е. с pipe() в норме буферы не могут съесть памяти больше некоторой константы.
Правда, это полностью верно только для стандартных стримов. Если самому создать класс с интерфейсом Readable Stream и не позаботиться, чтобы у него pipe() работал корректно, то на жор памяти нарваться очень легко.
Библиотека µWebSockets.js ab не смог протестировать её, а JMeter показал результаты хуже чем обычный встроенный http на node.js.
Вы можете склонировать репозиторий и повторить тесты самостоятельно, пишите в issue пожелания и свои результаты.
P.S. uWS тоже проверить не смог, но у меня она просто не собирается.
Даже поднял один продакшн на uWS. Вроде стоит, как скала.
По производительности пустых запросов у меня uWS в 3-4 раза быстрее нативного нодовского HTTP/WS и может легко соревноваться с не нодовскими серваками.
И при этом я все таки считаю, что для сетевого транспорта JS не нужен и лучше уж взять Actix на Rust и раз уж хочется логику писать на JS, то вызывать JS микросервисы из Rust.
Ну или если нет дружбы с ржавчиной, то взять Cишный uWebSockets
Всегда ли Node.js будет медленнее, чем Golang?