Комментарии 46
Я бы еще Biome добавил в раздел Senior. Однажды попробовав его, я навсегда отказался от eslint и prettier. Работает в разы быстрее чем ранее упомянутая пара и активно развивается.
Мне тоже сама идея кажется очень перспективной! Единственное, он пока не так широко используется.
Еще конечно пугает то, что он написан не на JS/TS (Rust). С одной стороны, именно это дает скорость, с другой стороны я уже не могу отлаживать код, если что-то идет не так
Как раз таки если все работает идеально, дебажить ничего не требуется. Вы пишете именно об этом про prettier.
Я уже год использую Biome и вижу, как он активно развивается, там появилось очень много недостающих фичей, в том числе и сортировка импортов. Круто, что все это из коробки идет, никаких кастомных плагинов.
Автор выше прав, способность к отладке, в данном случае, пала жертвой трейдоффа. Тот факт, что инструмент "просто работает" не означает, что не возникнет ситуации, когда на месте нужно будет разобраться, почему он работает не совсем так, как ожидается. В случае с да, можно легко поставить бряку в произвольном месте и начать дебаг даже минифицированного кода без особых проблем, а в случае с бинарями придется обмазываться ИДОй (или что там нынче в почёте у реверс инженеров), постоянно оглядываясь на сорцы (если они публичные) конкретной версии, да ещё сверху накатив тулчейн для компоновки этого бинаря.
Не поймите меня неправильно, я за всё хорошее против всего плохого, и блейзинг фаст (тм) перформанс меня тоже радует, но весь этот движ с внесением в жсную экосистему бинарных зависимостей вызывает лёгкий скепсис.
У Biome отличное коммьюнити в забаненном Discord. Если туда добраться, можно оперативно зарепортить багу. К тому же есть ру-коммьюнити.
Но самое худшее (на текущий момент) решение - это плагины. Это просто какой-то сабсет из разных языков. Неудачная попытка.
Сильная статья. jQuery - это у нас, оказывается Senior, а не антипаттерн (он вообще перестал быть нужен после querySelector), а express.js, который до сих пор самый easy-to-start web-сервер на ноде - это fail. А Next.js - это оказывается MVP, хотя это отраслевой стандарт. Про CRA я вообще не понял сути претензии - какая коробка, это буквально скриптец, который создает папочки и пишит начальных конфиг в файл Webpack - делай с ним что хочешь после. Typescript - тоже какие-то дженерики в дженериках, хотя это тоже отраслевой стандарт.
А самое главное, когда контекст подразумевает слова "это плохо, не используйте это", ожидается продолжение в виде "а используйте лучше вот это", а этого здесь нет. Вместо Next.js что использовать? А что лучше подойдет заместо TypeScript?
P.S. Архитекторы, выбирающие технологии, по моем субъективным ощущениям, как-будто не в себе частенько. Я буквально пару раз видел нормальные решения, а остальное - это когда хочется сделать не как обычно, яжархитектор. То JSON в SQL формируют, то REST на Erlange, то вон какое-то странное ранжирование технологий.
Давайте соберемся и сделаем свой тирлист!
Вы сами себе противоречите. Допустим, если что-то является стандартом, то оно должно высоко быть в тирлисте (NextJS). Если посмотреть на использование jQuery, то оно должно быть в самом верху (до сих пор самая популярная библиотека). Но вам jQuery не нравится. Противоречие решается просто: весь тирлист это просто способ хорошо провести время и синхронизироваться по ценностям. Не стоит воспринимать серьезно. Чистая субъективщина.
Архитекторы разные. И решения тоже разные. Скажу лишь одно: решения бывают подходящие и неподходящие. Хороших, плохих, странных, тупых решений нет. Вернее есть только отношение к решениям, которые характеризуются словами. А сами решения либо подходят или не подходят.
Вы сами себе противоречите. Допустим, если что-то является стандартом, то оно должно высоко быть в тирлисте (NextJS). Если посмотреть на использование jQuery, то оно должно быть в самом верху (до сих пор самая популярная библиотека). Но вам jQuery не нравится.
А вы понятия не подменяйте, и будет логично. jQuery используется много где, это legacy, поэтому в тирлисте для нового проекта ее не будет в принципе. А Next.JS - будет высоко, потому что это известная современная технология и стандарт. Cobol еще много где финансы гоняет, но в тирлисте нового сервиса для финансов его не будет, потому что он устарел. А уж время я предпочту хорошо проводить с семьей и друзьями :)
Архитекторы разные. И решения тоже разные. Скажу лишь одно: решения бывают подходящие и неподходящие. Хороших, плохих, странных, тупых решений нет. Вернее есть только отношение к решениям, которые характеризуются словами. А сами решения либо подходят или не подходят.
Это самая архитекторская вещь, которую я слышал. Очень художественно. Решения есть объективно хорошие, а есть объективно плохие. Есть те, которые объективно какие непонятно, и их надо изучать. Питаться через клизму - вполне подходящее решение, как и новый проект на jQuery начинать, только это объективно плохие решения.
"Арзитекторы разные. И решения тоже разные"
Толерантность - это, конечно, прогрессивно. Но нелогично. Если "архитектор" объективно месит говно, то и его проект будет говном. Можно сколько угодно оптимизировать движок рендера и внедрять крутые алгоритмы, но он всё равно обречен быть говном, если написан на python.
Для всего есть тонны технологий. Среди них есть объективно устаревшие. Среди них есть объективно плохие. То же самое касается архитектур. "Я художник, я так вижу" в проектировании систем неприменимо
ну да, как же это джейсон формировать в скл, еще небось и сразу анлоад в нужный бакет делать. пацаны на районе не поймут. другое дело несколько тысяч строк говнокода собираемого через мейк, потом дженкинс, октопус, еще пачка авс сервисов прицепом. боже упоси обойтись запросом на 20 строк
У меня всегда пригорало от того, что ESLint и Prettier годами конфликтовали "из коробки". Неужели годами не могли договориться, блин.
Не знаю, поменялось что-то в этом плане сейчас, так как пару лет назад я выпилил Prettier из всех своих проектов и всем советую это с тех пор.
Раньше можно было настроить автоформатирование в ESLint и забыть про Prettier. Но то ли в 8 то ли в 9 версии Закас выпилил эту штуку для упрощения поддержки, в итоге если нужно форматировать код, то Prettier в проекте теперь обязательный по-сути. Но в целом много новых интересных инструментов уже развиваются - те же oxlint и oxfmt, поэтому тут уже скорее сам ESLint медленно переходит в разряд устаревающих библиотек.
Так что использовать то вместо TS посоветуете?
Да нет советов. Typescript победил. Раньше был Flow, Dart. Сейчас остался только Typescript.
Если проект маленький, то можно писать на javascript и прикладывать файлы типизации. Но это на любителя конечно.
возможно JSDocs ( https://ru.wikipedia.org/wiki/JSDoc )
Если дядя предлагает вам свой тир лист, значит он хочет вас ментально изнасиловать.
Nest.js же поверх express работает
Слишком жирные набросы, какие-то непонятные и субъективные взгляды на технологии и фреймворки. То ли от неопытности, то ли просто пост ради поста написанный ИИ.
express это база для многих бекенд фреймворков. Но и для реста, он так же дает некую абстракцию от чистой ноды.
Реакт по сути своей мертв года с 2018, и поверх него другой кусок говна в виде next.js. Который, по сути стал имплементатором фичей реакта. С его вечными косяками, а на прошлой неделе с критом и выполнением стороннего кода на сервере.
Дяденька, вы застряли где-то в прошлом десятилетии. Есть bun + Elysia, есть srvx.
А для Next'а уже появился конкурент - TanStack Start. Сидеть сложа руки команда Next'а теперь точно не будет.
Я был на конференции где Райн (автор ноды), показывал нам новый прорывной райнтайм - Deno. Где он?)) Там же где и Bun)) Но конечно вопрос - причем тут Next.js, это разные вещи, молодой человек.
У Bun поддержка и распространение растёт стремительными темперами. Вот их на днях даже Anthropic купили. Вполне можно ожидать рост использования Bun среди пользователей Claude
Deno прекрасный рантайм, если требуется строгий контроль ресурсов. Bun прекрасный рантайм для высоконагруженных бэкендов (см. видео Антона Путры на ютубе). Поэтому я не могу сказать, что они где-то там, куда вы их положили. У них есть своя ниша и все рантаймы друг другу конкуренты, что только способствует росту каждого.
Про NextJS был ответ на ваш комментарий, но возможно не слишком очевидный. Пока NextJS оставался монополистом, они могли делать всё, что хотели, в особенности вендор-лок на Vercel. Cloudflare, увидев долю рынка, предложила свой рантайм и помимо vercel появился cf. Не так давно добавили и ноду (но она всё ещё отстаёт). А совсем недавно появилась альтернатива в виде TanStack Start, которые прямым текстом говорят об усталости от NextJS и более лучшем DX. Поэтому команда NextJS больше не сможет тупо забивать на простых (не enterprise) разработчиков.
Надеюсь, теперь вам стало понятнее.
Интересно, как автор предлагает заменить express на чисто реактовский фреймворк. Или по вашему мнению, весь мир только на реакте сидит?
Какие еще будут доводы, кроме того, что он "устарел"?
Зато Jquery, который до сих пор используют только на легаси 20 летней давности или динозавры, кому завтра на пенсию, в топе советов. Большего бреда давно не читал
уже давно есть Apline Js как минимум
и это не считая того, что в целом 99% современных проектов держатся на ангулар/реакт/вью/свелте, и где там использовать джквери, не понятно, когда сами фреймворки покрывают весь его функционал
Советовать next вместо express, это ж сколько ума надо? А если не нужен рендеринг? Более того, весь некст работает поверх экспресса.
Это приятный форматтер с минимальным количеством настроек, буквально несколькими флагами, которые сложно даже назвать «конфигурацией».
Список опций так-то уже внушительный. Я насчитал 27, из которых 2 экспериментальных и 1 объявлена устаревшей.
Когда нет настроек и бесконечных споров:
«а давайте поменяем отступы?»
tabWidth и useTabs, кажется, были почти с самого начала.
«а может, двойные кавычки?»
Так-то двойные кавычки и так установлены по умолчанию, но есть singleQuote и jsxSingleQuote.
А помимо этого можно поспорить о точке с запятой в конце строки, запятых в конце списков, скобках вокруг анонимных функций и т.д. и т.п.
У меня немало проектов с фронтендом, но из всего перечисленного в статье использую только TypeScript. И не понимаю, что у вас там за дженерики на дженериках и зачем они?
Другое дело C++, там можно нагородить многоэтажных и сложных шаблонов ради того, чтобы потом всё заинлайнилось и оптимизировалось компилятором, сгенерировав наиболее оптимальный код алгоритма или структуры данных для каждого типа.
Но в экосистеме JS типы TS - просто ограничения, проверки и подсказки, не влияющие на производительность. Не вижу смысла усложнять.
Не влияющие на производительность.
Это не верное утверждение. Исходя из принципа работа V8 написание типизирвоанного кода на JS в оболочке TS, очень даже влияет на производительность в райнтайме.
Хотя бы потому что динамическая оптимизация которая есть внутри движка не сбрасывает куски оптимизированного кода только потому, что в одну и ту же функцию приходят сначала строка, потом число, а потом объект...
Хотя в остальном, да, странно называть TA полноценно "языком".
TS никаким образом не мешает писать полиморфный код, иначе он был бы бесполезен.
В TS с тем же успехом можно сделать аргумент типа number|string|object. И в контексте тех же дженериков те же сбросы оптимизированного кода происходят, в отличие от шаблонов C++, где создаётся специализированная для типа оптимизированная функция. И наоборот, можно сам JS писать так, чтобы не допустить такой ситуации.
TS сам по себе не влияет на производительность, но может быть инструментом, который поможет своими подсказками и ограничениями упорядочить типы в коде, чтобы не только избежать багов в коде, но и избежать ситуации, когда V8 сбрасывает оптимизированный код. Всё равно это задача того, кто пишет код, которую он должен держать в уме, ограничивая типы.
То есть вебпак надо выкидывать, а некст оставить в мвп, хотя он сидит на вебпаке? Сильно
Я конечно, дико извиняюсь, но вы когда статью пишете на Хабре, вы хотя бы запоминайте, о чем говорили вначале, чтобы сравнить с тем, что пишете в конце. Вначале идет:
писать на express все равно что начинать проект на Jquery (т.е. Jquery - неактуально и утиль, запоминаем!).
Далее сравнение разных технологий, блок "Senior (до God ровно шаг)" - Jquery выверенная годами технология, как старое вино, очень годная и имеет большое коммьюнити (ну еще бы, столько легаси написано, с умы бы не сойти). А теперь вопрос - что там с пунктом первым?
Каждый раз читая статьи по каким либо инструментам фронта, начинает одолевать чувство, которое испытывает ГГ Идеократии. А именно - гиперфокус на React, и связанным с ним.
И эта тенденция неумолимо растёт. Какая-то локальная деградация front-end.
И замечаю я это не только в статьях, но и при общении с разработчиками. React-разрабы, даже senior уровня, зачастую ничего кроме react'а и не использовали. Напротив разрабы Vue, Angular, Svelte уровня от мидла знают минимум 2 фреймворка, а сеньоры (как это не странно) всё больше смотрят в сторону возвращения к нативным возможностям HTML/CSS, и уходу от фреймворков, создающих лишнюю прослойку.
Но только не React, там всё стабильно закостенело.
И даже данная статья, показывает узкий кругозор понимания текущего спектра инструментария. Чёт высрали про webpack, про vite даже не упомянули. Ставить в ряд Next и fastify - вообще не понял. Это как ставить в ряд Nuxt и Koa.
В общем советую всем выйти из "зоны комфорта", и посмотреть на то, куда развивается фронт и инструментарий, и расширить кругозор.
Подгорело от советов по переходу с express на next, учитывая что у них разные задачи…
Или можете объяснить как next заменит express, если мне нужно написать простое api, и я не хочу сам писать middleware которые уже есть в express и работают великолепно и понятно…
Какая же бредовая статья. Автор сравнивает теплое с мягким
Есть вопросы к статье, не совсем понял про что все таки речь, про пет проекты или про коммерческую разработку нагруженных приложений?
В начале статьи камни в огород rca, хотя это просто запуск скрипта на быстрое развертывание приложения на реакт и как раз для пет проекта это быстро, удобно и хватит за глаза. То есть здесь говорим о большом проекте. Но даже для большого проекта, почему он так низко, а сам реакт высоко, если что то не нравится в дефолтной настройке, это легко и быстро редактируется в конфигах. По сути это одно и то же.
А дальше идет про next, в преимуществах указываете, что на нем легко быстро собрать статику для GitHub-pages, то есть здесь речь уже про преимущества для быстрых решений. Но по мне так как раз next для своих проектов это как раз через чур, на реакте тоже очень легко собирается проект для GitHub-pages
Нет ничего про vue и angular, понятно, что вы отдаете предпочтение реакт, но странно не описать и разместить их в каких то категориях и описать причины, почему они хуже. На них также немалое количество коммерческого фронтенда.
Нет вывода итогового, итоговой подборки что тогда использовать. Короче, как то обо все и ни о чем одновременно.
Ps: видео не смотрел, возможно там подробнее проходитесь, это комментарий к статье
Дети, запомните: если дядя из туториала предлагает вам начать проект на Express.js… Рейтинг opensource для фронтенда