Комментарии 44
Пакет
to-regex-range, речь о котором шла в начале статьи…
Где именно в начале статьи идет речь о пакете to-regex-range ? (Если конечно не переходить по ссылке на оригинальный mr)
После замены пакета
isNumberна собственное решение
На самом деле там нет собственного решения. Просто взяли код функции из пакета и сделали из него однострочник.
Чего-то я не понял. Чей траффик уменьшился? Как инлайн функции связан с траффиком?
Видимо трафик npmjs.com, который создавали разработчики. Но кого волнует трафик npmjs.com?
Связан так, что некоторые выкачивают десятки гигабайт заисимостей ежедневно при сборке, т.к не ставят кэш сервер.
Тут нужно уточнить, что кэширующий сервер нужен только для очень большой команды разработчиков. Для одного разработчика он не нужен (у npm есть свой кэш).
В стародавние времена люди подключали вундер-проги сжатия HTTP-трафика, потому что протокол позволял. Прокси сами, на своих сетях устанавливали провайдеры, кэшируя запросы в пределах своих сетей. Не без причины провайдеры-же организовывали сервисы в интранете, экономя трафик и создавая внутригородской движ. Разумеется, популярностью пользовался Bittorrent внутри ISP.
Это потом интернет стал быстрее и дешевле, государства наглее, а правоторговцы ярее. И лавочка прикрылась, а HTTP покрылся TLS.
Я бы не отказался от кэша Steam (программа есть), дистрибутивов Linux (по HTTP) и других. Да, не всем поможет (у меня последняя миля - VDSL). Банальнейший пример: обновлять три системы на дистрибутиве с rolling release. Большая часть времени уходит на скачивание. Так что может и сам себе прокси поставлю.
до меня не доходит, почему это сколько-нибудь важно
Проверка через v - v === 0 — это эффективный способ исключить NaN, так как для всех других чисел разница числа с самим собой всегда равна нулю.
Нет, здесь также бесконечности отсекаются (зачем-то).
~/isnumberCompr $ stat -c "%s %n" *
13824 is-number-7.0.0.tar
3703 is-number-7.0.0.tar.7z
3736 is-number-7.0.0.tar.gz
3612 is-number-7.0.0.tar.xz
3648 is-number-7.0.0.tar.zstd
3730 is-number-7.0.0.tgz // оригинал из npmСжатие по максимуму (-9). zstd и xz в плюсе.
Породили себе проблемы, построив платформу разработки поверх колосса на глиняных ногах, и решают проблемы теперь и решают, и решают и решают... 😂
Ждём краха всего интернета когда в очередной раз майнтейнер уберёт пакет isNumber.
Почему в JS разработке до сих пор о стандартной библиотеке никто не слышал?
Вместо всего этого геморроя с проверками было бы проще в цикле пройтись и проверить что Все символы в диапазоне [+0-9.]
+/- обработка их стандартного представления для NaN , Inf и что там у них ещё.
Кстати. Что такое Number вопрос философский. Впринципе строка это не number но кто же их JS-ников поймёт.
При этом поди есть функция конвертации. Строки в число которая выдачу код ошибки если не может ее преобразовать. Но это не круто, лучше пакет с зависимостями тянуть.
Ну нравится инди-товарищам решать проблемы, возникшие на пустом месте.
Ну будет вместо зависимости распухание стандартной библиотеки. Хватит плодить зависимости. Не лучше ли иметь проверенные независимые модульные решения, чтобы копипастить их в себе в кодовую базу?
Проверенные так хорошо, что незакрепление версии пакета - аж обременение по безопасности.
Плотно сидел на npm-ts-webpack-разработке с продвинутыми вещами типа worker threads, WASM и пр. Когда всё собрано и поставлено клиенту в браузер — всё конечно великолепно. Но цикл разработки для меня как инженера — это просто полнейший мрак. Впервые в жизни сборка-компиляция этих ваших webpack-ов у меня занимала больше времени, чем какая-нибудь компиляция С++ библиотек в далеких нулевых. Со всеми там кешами и т.д. Просто дичь полнейшая. Безумие хиппи мамкиных "прогеров", которые решили, что "и так сойдёт". Ну вот просто — по-инженерному, по чесноку: весь этот веб — ну это же ненормально всё построено. Чудеса эволюции вроде блуждающего нерва или кладущего яйца утконоса — это просто цеточки по сравнению с эволюционной **ратостью современной веб разработки (это я ещё не беру в расчёт серверную часть на nodejs).
Понимаю и сочувствую, правда, в последний раз работал с фронтом ещё во времена jQuery, но уже тогда это было дикостью.
Кстати, если так всё сложно в вашем стеке, то может взгляните на другие платформв по созданию WASM, но уже без JS и HTML.
Проблема там не в самом WASM, это решаемо. Проблема именно в этой всей экосистеме и как она работает, как там все эти чудо-вебпак пакеты компилируются, как резолвятся зависимости и их версии в пакетных менеджерах (что npm, что после него), все эти жуткие бабели, минификации, сорс-мапы и пр. Сделано всё это из ***на и **лок, всё очень медленно собирается и гораздо туже чем в любом нормальном нативном стеке. Всё это конечно приперчивается необходимостью плясок вокруг WASM-модулей, как там это всё друг в друга прописывать и т.д., там много магии и очень тонких знаний кишочков всей этой сборочной эпопеи. Но сама задумка, npm-webpack-ts... это ДИКАЯ ДИЧЬ. И нет, более быстрый компьютер не поможет, он и так очень дорогой и быстрый, и я 32 года уже в профессии если что. Дичь, и точка. Всё это то, что мы называем современной веб-разработкой, следует выбросить и начать заново, с first principles так сказать. Иначе мы платим людям за то, что они 90% тратят не на бизнес-логику и доставку ценности, а на эту дурную муму.
Вот-вот, в качестве предложения:
Если вам будет охота выучить C# и познакомиться с языком разметки XAML, то к вашим услугам Blazor Hybrid. Там есть функционал работы а-ля HTML/JS/CSS, а есть прямой XAML который реализует Model-View-ViewModel концепцию.
Я работал с XAML и по мне, это небо и земля для создания интерфейсов. При этом его функционала хватает, чтобы создать любой интерфейс.
В самом Blazor очень много чего решается внутренними компонентами, вам даже нет нужды знать, что такое бабель.
Да я-то знаком давно очень, но это к сожалению маргинальщина. Молодёжь хочет вот на том, что я выше написал, это для резюме круче 😊 Bad is the new good, общество постправды, gen-Z, ну вы понимаете. Они вон уже бегут айфоны новые покупать, которые хуже предыдущих, а вы говорите... Это, конечно, пройдёт, наверное, наверное... А пока нжуно делать тем, что есть мейнстрим.
Тогда сочувствую, на таких тасках выгораешь очень быстро.
Не "бежим" мы за новыми айфонами.
Интересно наблюдать то, как "старички" с 30+ стажем работы в IT поражаются с текущей обстановкой дел в разработке. Не получится вот так вот взять и все с нуля переписать. Вся та мешанина из тулзов и библиотек и составляет текущую веб-разработку. Долго собирается проект? А что вы там собираете так долго на «мощном» ПК? Если в нативной разработке есть стандарты и где-то разработчика могут бить по рукам за какие-то действия, то в веб разработке вы сами себе судья. Да, есть стандарты, но ты волен не придерживаться этих правил (осуждаю такое, но все же).
Мы, конечно же, будем на "поколение постправды" гнать бочку и ворчать как было круто на пентиуме сишную либу собирать.
Но текущее состояние дел во фронте — удручает и удручала всегда.
Были многочисленные попытки сделать что-то стандартное. Сейчас у нас появился WASM. При таких раскладах, я не вижу смысла цепляться за HTML/CSS/JS, а следует посмотреть по сторонам и поискать что-то цельное.
Да вы даже рассуждаете как новый айфон 😂 вам говорят, "плохо есть хорошо", а вы ведётесь. Отсутствие критического мышления и клиповость
Вместо "геморроя с проверками" проверять символы? Но зачем?
Ага, а еще abcdef, точки, еще e-запись, b010001, 0x… и так далее…
Тут ещё хотя бы пришлось писать замену для пакета. А ведь есть ещё is-array и isarray, у одного 76к еженедельных скачиваний, а у второго более 80 миллионов. Оба этих пакета не нужны, т.к. есть нативный Array.isArray. Понятное дело, что эта зависимость "историческая", т.к. раньше Array.isArray не было, но оно появилось лет 8 назад наверное. Если сейчас нужно кому-то поддерживать настолько старые браузеры или node.js, то ставить эти пакеты всё равно неправильно, т.к. нужно использовать полифилл.
Удалять такое нужно вовсе не из-за экономии трафика, а из-за безопасности. Да, сейчас с этими пакетами вроде бы всё ок. Но уже не раз были такие случаи, что кто-то как-то заполучает сопровождение над старым пакетом и зашивает туда вредонос. Со старыми ненужными пакетами такое происходит чаще, т.к. если старый мэйнтейнер уже потерял интерес или отошёл от дел, то его могут уговорить передать сопровождение, либо вообще взломать.
Следующий момент: если разработчик использует пакет вместо нативной функции, это говорит о том, что он не знает основы языка, на котором он пишет. То же самое с однострочниками: разработчик не смог сам написать простую функцию. И если мы даже не будем пользоваться такими пакетами, оно всё равно попадёт в node_modules как зависимость других пакетов. В свою очередь это говорит о низком качестве используемых пакетов. Либо, если это "историческая" зависимость, это значит, что в используемом пакете есть фрагменты кода, которые не актуализировались N лет, что тоже не есть хорошо. Ну и в целом, это отвечает на вопрос, почему папка node_modules такая большая.
npm - это еще и страшный сон безопасника, т.к. postinstall скрипты могут делать все что угодно (например профилактически очистить ваш диск). А учитывая невероятно большие графы зависимостей из-за таких вот микропакетов, сделать нормальный белый список пакетов, которым разрешено запускать скрипты при установке, представляется малореализуемым (да и все равно не защитит от захвата контроля над репозиторием «хороших» пакетов)
Почему они упустили возможность выпустить новый вариант npm без скриптов (и с исправлением других родовых болячек) после той истории с leftpad, я не понимаю. Да, было бы больно, но сейчас это будет в разы больнее. Так что сидим и ждем очередной взрыв.
Не очень понимаю что вы предлагаете для исправления, запретить скрипты вообще? Тогда невозможна будет установка огромного количества пакетов, которым требуется сборка (нативные модули, например) или докачка артефактов.
Кроме того, в большинстве случаев у злонамеренного пакета есть тысяча и один способ запустить любой код даже без скриптов: ни один фронт и почти ни один бэк сейчас не обходится без своего собственного этапа сборки, куда можно хоть чёрта лысого спрятать. И ничего с этим сделать нельза, кроме изоляции всего пайплайна. И NPM тут не при чём т.к. это общая проблема для всех систем сборок и установки зависимостей.
А какие другие "родовые болячки" вы имеете в виду?
Почему этот пост ещё не в минусах? Люди, вы действительно считаете, что делать подобные PR - хорошая идея?
Там в комментариях автор пакета is-number пытался объяснить, что это всё равно что удалять файлы README из пакетов, но его задизлайкали. По-моему автор этого PR ошибся с выбором профессии, он был бы крутым маркетологом, но программист из него плохой.
Почему он сделал именно однострочник? Ответ: Для экономии трафика! По-моему это эпичный пример некомпетентности, который нужно распечатать и повесить в рамочку.
Package info for "to-regex-range@5.0.1": 33 kB
Откуда он взял цифру 33 kB? Ответ: он измерил папку пакета в node_modules (вместе с файлом лицензии и README). В комментариях ему попытались объяснить, что его математика не верна хотя бы потому что npm не загружает пакеты в сыром виде, а загружает их сжатыми и распаковывает уже локально (не глупые люди проектировали). Но и даже это не подействовало и PR был принят.
Дайте все свой функции будем превращать в однострочники для экономии трафика! :))
Но ведь исходная функция тоже односторочник (если верить статье). Разве плохо убрать 10кб на пустом месте? Ладно какая-то польза была бы от этих 10кб, так нет же, лишний жир. Пусть даже эти 10кб просто на диске, но ведь миллионы программистов принимают миллионы решений добавить лишние килобайты (в разных случаях, не только в этом). Это не очень круто.
В целом пост "жээсников" такой же как и язык: ничего понятного и лучше я это трогать не буду...
Это конечно не история с похожим по функционалу пакетом чёт/нечёт, но все равно какой-то испанский стыд за программистов (как минимум на js) испытываю. Анекдот про первого залетевшего дятла актуален как никогда...
Даёшь для каждого рутинного чиха по пакету!
Не знаю, что меня пугает больше
То, что для такой проверки реально кто-то качает библиотеку?
То, что функция IsNumber в варианте со строкой "2" тоже возвращает true?
Или то, что про это пишут статьи?
А чем IsNaN() плоха?
Как удаление isNumber из зависимостей сэкономил 440 Гб еженедельного трафика