Комментарии 19
Lodash на бэкенде не моветон?
Lodash где угодно - моветон.)
https://github.com/you-dont-need/You-Dont-Need-Lodash-Underscore
Так эта ссылка прекрасно демонстрирует несистемное написание своих забагованных функций очередного common/utils вместо того, чтобы взять готовое. Да, в жс появились некоторые методы типа [].includes, но в лд есть куча функций, которые облегчают жизнь и которые никогда не будут встроены в стандартную библиотеку
Да вы исходники лодаша почитайте, посмотрите что там происходит. Сразу спойлерну, что ничего хорошего вы там не обнаружите. Любая функция использует большую часть самого лодаша для максимально банальных операций и добавляет такое количество оверхеда (проверки типов, копирования массивов, лишние обходы массивов) что становится страшно за наш родненький фронтенд.
[].includes появился в стандарте уже лет 10 назад, как и все остальные функции, которые до сих пор поставляет этот ваш лодаш.
И зачем писать свои функции, если все проблемы решаются стандартной библиотекой? Ссылка именно это и демонстрирует, что вы конечно можете запустить огромный, не оптимальный, перегруженный конвейер лодаша чтоб мапнуть объект, или же написать Object.entries(obj).map(...) где всё максимально оптимально и прозрачно.
Ну а если вы такие маленькие снипеты пишите изначально с багами, то у меня для вас плохие новости.)
И вот ещё накину статейку, в которой хорошо расписано, почему лодаш - это очень плохо:
Конечно моветон, лучше на каждом проекте писать свои костыли и складывать в папочку utils/. Тесты, кстати, писать не обязательно.
Бох с ним с lodash. В комментариях подобрались разные мнения на его счёт, но цель его добавления в проект понятна.
Но зачем в этом списке vite?
Неделю назад перевод этой статьи так заминусили, что её сняли с публикации: https://habr.com/ru/articles/891612
Видимо, нужна статья «16 статей, о которых должен знать каждый Node.js разработчик, которые не надо переводить, и постить на Хабре».
Как минимум, для сотрудников Otus.
Всем привет. Мы обратили внимание на комментарии и сняли статью с публикации, чтобы ее исправить. Переписали её, актуализировали данные.
Мы благодарны читателям, которые заметили эту нашу ошибку. Просим прощения.
Благодаря вам, мы можем делать более качественный контент.
Конечно, если разработчик достаточно давно в этом варится, то так или иначе всё или почти всё из этого знает.
Но какая-то странная выборка. Похоже, что случайная.
А как же пакет is-even
После добавления в node.js scrypt и PBKDF2, bcrypt уже не нужен, разьве что для совместимости или особых случаев.
Socket io уже не столь актуален как раньше
Prisma - распиаренное поделие. Неюзабельно в проектах чуть более масштабных чем TodoList. Достаточно того что схема всей БД в одном файле! Когда таблицы две - три, еще норм, но когда их >10 да еще с кучей полей и индексов, поддержка файла на несколько тысяч строк - такое себе удовольствие. Лучше уж Sequelize, или, если нужен TS - TypeOrm.
Так разнеси по разным файлам, в чем беда? Да, Призма это позволяет.
Ваш комментарий к статье «16 NPM-пакетов, о которых должен знать каждый Node.js-разработчик» был отклонен.
Текст комментария: (тут как бы пусто, ага)
окей... спасибо хабру за площадку, на которой нельзя указать ссылку на призму документацию...
@Cobalt в призме уже можно дробить схему на отдельные файлы схем, ссылку указывать не буду, иначе опять коммент затрут... =(
16 NPM-пакетов, о которых должен знать каждый Node.js-разработчик