Посмотрим, как они будут терпеть голод, ибо родители рано или поздно умрут, а еду без денег почему-то не дают.
А работодатели без работников не зарабатывают деньги, и так же будут терпеть голод если никто не будет работать на их условиях. Замкнутый круг. Будут выживать работодатели которые относятся к работникам как к людям, а не как к отбросам. А работодатели которые предлагают так себе условия труда - это временная работа и как только подвернется что-то адекватное, с этой работы сразу сваливают. Так было всегда, только слабо выражено, сейчас это будет с каждым годом все сильнее и сильнее выражено. И если на то пошло, всегда есть легкий пусть быть при деньгах не имея никаких навыков - такси, курьер, и т.п. И ни что не мешает искать работу которая будет по душе пока ты работаешь на времянке просто тупо чтобы деньги платили.
И как заметили выше
Просто зумеры в отличии от старого поколения не терпят эту хрень. И по моему это хорошо.
Я полностью с этим согласен и 2мя руками поддерживаю, при этом я сам не зумер, а родившийся в 90 году. И я тоже не терплю эту хрень) Как только начинается перегибания палок - аривидерчи.
Да, всё верно. KISS должен быть всегда превыше всего. Вся остальная сложность должна быть обусловлена лишь сложностью бизнес логики, а не оверинженерингом.
Ну обычно раз в 5 минут и так в фоне все страницы обновляются, поэтому они "устаревают" в среднем на 5 минут при самом простом исполнении. Но если нужно реагировать быстро, то опять же не проблема, webhook/rabbitmq и т.п. нотификация о том, что надо обновить кэш для такого-то урла и тогда задержка условно в пару секунд, что для 99.99999% случаем более чем достаточно
если это биржа, обменник , аукцион??
Так при открытии страницы на блоках с катировками лоадер "инитного получения данных", а дальше работает как обычно websocket и т.п. и обновляется в real time.
Можно кешировать SSR результат допустим для неавторизированных пользователей
А для авторизованных он как бы вообще не нужен, от слова совсем. Для авторизованных просто режим SPA (Client Side Rendering). Более того и Next.js вообще нафиг не нужен для SSR. Это задача решается элементарно, один раз в жизни пишется сервис который на вход получает набор урлов потом будет puppeteer ходить и класть результат в кэш, а при запросах отдавать ответ напрямую из кэша. Никаких ограничений и костылей next.js'a, гигантская производительность ибо все отдается из кэша и одна виртуалка за 5$ обслужит много тысяч RPS.
Мне кажется, что ни один разработчик, сколько бы он ни был компентым, не сможет написать класс/функцию один раз и пользоваться дальше на протяжении всей жизни проекта
Её можно написать один раз на проекте X в каком ни будь 2018 году и пользоваться ей на проектах Y,Z и т.д. по сей день.
В начале не нужен кеш — потом стал нужен. Сначала не нужны ретраи — потом стали нужны.
И что? Это проблема? Просто реализуйте этот функционал, это элементарно. Это же операционную систему написать.
В нашем случае проект развивается уже больше полутора лет
И что? Потратить суммарно 8 часов на для реализации класса обертки для API запросов с ретраями и кэшем это проблема?
1) Продолжать реализовывать свои решения, теряя ресурсы (деньги, время) на отладку и доведение до идеала (не сомневаюсь, спустя N итераций мы бы всё же дошли до идеала);
Понятно, классические отговорки и отмазки. Вы что, считаете react-query идеалом? :D Ну я думаю очевидно что нет. А значит аргумент сразу теряет силу. Ибо если бы реально был идеал, то и да, я полностью соглашусь что смысла делать свою реализацию нет. Но как бы идеала нет из готовых решений. Так что...
2) Использовать готовое, проверенное сообществом решение
Типичная не компитентность. Это всё равно, что складывать 5 + 5 на калькуляторе говорить что ты умеешь считать. Перед вами не задача 3х тел, где нужно учесть всё, и гравитацию и магнитное поле и т.д и т.п. А реально перед вами задача 5 + 5, а вы даже её не в состоянии решить. Зато называете себя разработчиками.
Это значит, что для наших конкретных нужд старый подход себя изжил
Ну если вы не состоянии решить 5 + 5 без сторонней библиотеки, и на этом фоне вы отказываетесь от MobX, то да, вашему проекту уже без разницы, можно максимально сильно его втаптывать в землю. Ибо он всё равно обречен быть похоронен с таким подходом.
Ничего удивительного, слабые и некомпетентные разработчики не в состоянии написать 1 раз класс/функцию для работы с АПИ как удобно именно именно им, если нужен кэш, то с кэшем, если ретрай. то с ретраем и т.д. Для этого они просто берут корявые готовые решения, а свою некомпетентность маскируют классикой которой уже десятилетия - они просто говорят, не хочу изобретать велосипед. Но на сама деле не хочу у них означает - не могу я это реализовать.
Ну т.е. просто взять и отказаться от MobX просто так, ну тут как бы ничего кроме сочувствия даже на ум не приходит.
Иммутабельность не обязательна для Реакта. Это лишь один из способов оптимизации
Иммутабильность - оптимизация?) Интересненько) С каких это пор постоянное копирование объектов в памяти на каждый чих это оптимизация?
Это расходование процессорных тактов в холостую, а значит это замедление работы. А если это происходит на мобильном устройстве, то и увеличенное потребление энергии в холостую.
А главное иммутабильность даёт ноль профита.
Я понимаю когда мы жертвуем производительностью, расходом памяти и энергии когда пишем на JS вместо Assembler'a, потому что это даёт вполне себе огромный буст в скорости и простоте разработки.
Но если для вас падение производительности, увеличенных расхода памяти и энергии, не оправданное ничем это оптимизация, то мне очень жаль.
Фреймворк Steroids подходит для создания полноценного SPA приложения с продуманной архитектурой
управление состоянием, в том числе с использованием Redux, React Context;
Вы сделали 11 ошибок в слове плохой. Вместо SPA приложения с плохой архитектурой, вы по ошибке написали с продуманной.
Очнитесь, все адекватные люди последние 9 лет используют MobX в связке с React. В противном случае это просто очередной говнокод. React нужно использовать по назначению, рендер html и жизненный цикл компонента, а управление состоянием, как глобальным, так и локальным - MobX.
Тогда это будет: a) Надежно. б) Пользователю не нужно будет об этом думать, оно просто работает. в) А других вариантов и нет, чтобы при этом пользовательский код оставался чистым и красивым.
Я сам несколько плагинов написал себе, чтобы жизнь упростить и оставлять код чистым, поэтому сразу подсказка - https://astexplorer.net/ Там выбираете JavaScript, @babel/parser Вставляете код и наслаждаетесь этой прекрасной утилитой, которая архи круто помогает при написании code transformers
1) БЭМ не используется как минимум с 2015 года, когда во всю уже использовались SCSS + CSS Modules. 2) А использовать Tailwind это вообще самая фатальная ошибка.
Вызывает смех да и только. Не буду мешать жить в розовом мире
Да да, оправдывайте свою некомпетентность в качестве разработчика и говнокод тем, что я якобы не ведаю о чем говорю и живу в розовом мире)
Я как раз живу в реальном мире и прикладываю все усилия чтобы моя жизнь была максимально легка и без сложностей. Поэтому и использую react+mobx+css modules+классическую архитектуру чтобы максимально легко и непринуждённо разрабатывать любые проекты, вместо того чтобы страдать, решать надуманные проблемы и т.п..
кто эти плохие практики с мобх, сасс записал в классику?
Они не плохие, они лучшие для фронта.
Их туда записано сообщество настоящих разработчиков и адекватных людей.
Понятное дело для говнокодеров и тех кто сам себе выдумывает проблемы, а потом героически пытается их решить эти инструменты не подойдут, потому что они напротив избавляют разработчика от всех проблем.
Не нужно свои фантазии выдавать как за идеальный выбор.
Это не фантазии, это объективная реальность. На данных момент безальтернативная. Альтернативы хуже с точки зрения удобства разработки, качества кода и красоты этого самого кода. А это золотая середина.
используя связку FSD, TanStack Router, TanStack Query и Effector
Вы конечно собрали комбо из самых худших подходов. Зачем?
Классическая архитектура, React, MobX, SCSS + CSS modules - идеальный выбор ещё с 2016 года и по сей день. Для роутинга либо самописное решение. Из готовых, всё гуано. Для АПИ запросов самописная обертка, которая использует axios. Из готовых, всё гуано. Для работы с формами и валидацией, то же самописное решение. Из готовых, всё гуано.
Более того, React нужно использовать исключительно как View слой, а не как средство для управления состоянием и т.п.
Почему Feature-Sliced Design (FSD) не спасет ваш проект
Потому что его предназначение - уничтожить ваш проект. И довести ущербность структуры файлов и папок до максимума убогости. Всё для того, что вы и все остальные кто будет работать с этим "чудо" проектом страдали.
Tailwind легко можно назвать «смертью ручного CSS»
Очень смешно. Tailwind легко можно назвать позорной попыткой заменить CSS. Tailwind это жесточайший говнокод, причем это настолько очевидно, что только слепой не замечает.
Это просто одна сплошная уродливая помойка. Видимо разработка совсем загнулась и уровень разработчиков достиг исторического минимума и пробил дно, потому что есть те, кто считает что это круто.
RTK Query принес конец эре ручного управления данными, как, например, Redux Thunk/Saga/Axios. Именно их мы и сравним.
Откройте глаза, MobX существует 10 лет. Redux и вся что около и вокруг него, в том числе RTK Query это так же шлак, который провоцирует писать говнокод и уничтожать проект.
P.S. при использовании CSS modules, никакого БЭМ нет даже в намеках, он автоматически генерируется на выходе.
import styles from './styles.module.scss';
//...
const Test = () => {
return <div className={styles.wrap}>test</div>
}
превращается в src-layouts-main-___styles-module__wrap___dazN7
Вот и все дела. И никаких конфликтов стилей и т.п. при таком подходе быть не может, в каждом компоненте будет класс .wrap / .title и т.п., и конфликт исключен. А удобство написания стилей у SCSS + CSS modules возведено в абсолют.
Я тестил по классике через apache bencmark замеряя RPS, сделал endpoint, который делает 3 запроса в БД, парсит json, преобрзаует объект в json и отдает ответ. Получается усредненный сценарий работы бэкенда, именно реальный, а не просто кто быстрее в цикле посчитает до миллиарда.
Дальше запускаем наше микро приложение-эндпоинт без докера и замеряем, раз 5, чтобы усреднить результат
ab -c 1000 -n 50000 http://localhost:3000
Потом то же самое микро приложение-эндпоинт запускаем в докере (полностью без ограничений) и так же замеряем раз 5
ab -c 1000 -n 50000 http://localhost:3000
Сравниваем циферки, вот и все методика.
При этом сама БД у меня была в обоих случая без докера.
Можно сделать ещё лучше, добавить ещё сценарии и БД тоже завернуть в докер и замерить.
Docker файл
FROM node:22-alpine
WORKDIR /app
COPY . ./
RUN npm install
CMD node ./master.js
EXPOSE 8080
Где master.js
const cluster = require('cluster');
const os = require('os');
const numCPUs = os.cpus().length;
(async () => {
// If process is master
if (cluster.isMaster) {
console.log(`Master ${process.pid} is running`);
// Fork workers.
for (let i = 0; i < numCPUs; i++) {
cluster.fork();
}
// When worker dies we do new fork
cluster.on('exit', (worker, code, signal) => {
console.log('worker %d died (%s). restarting...',
worker.process.pid, signal || code);
cluster.fork();
});
}
// If process is worker
else {
console.log('Worker is forked...');
require('./index.js');
}
})();
Без докера так же запускался этот файл node ./master.js
Да, эта методология (FSD) абсолютное говно. Классическая архитектура как была самой оптимальной 10 лет назад, так и остается по сей день.
А работодатели без работников не зарабатывают деньги, и так же будут терпеть голод если никто не будет работать на их условиях. Замкнутый круг. Будут выживать работодатели которые относятся к работникам как к людям, а не как к отбросам. А работодатели которые предлагают так себе условия труда - это временная работа и как только подвернется что-то адекватное, с этой работы сразу сваливают. Так было всегда, только слабо выражено, сейчас это будет с каждым годом все сильнее и сильнее выражено. И если на то пошло, всегда есть легкий пусть быть при деньгах не имея никаких навыков - такси, курьер, и т.п. И ни что не мешает искать работу которая будет по душе пока ты работаешь на времянке просто тупо чтобы деньги платили.
И как заметили выше
Я полностью с этим согласен и 2мя руками поддерживаю, при этом я сам не зумер, а родившийся в 90 году. И я тоже не терплю эту хрень) Как только начинается перегибания палок - аривидерчи.
Да, всё верно. KISS должен быть всегда превыше всего. Вся остальная сложность должна быть обусловлена лишь сложностью бизнес логики, а не оверинженерингом.
Ну обычно раз в 5 минут и так в фоне все страницы обновляются, поэтому они "устаревают" в среднем на 5 минут при самом простом исполнении. Но если нужно реагировать быстро, то опять же не проблема, webhook/rabbitmq и т.п. нотификация о том, что надо обновить кэш для такого-то урла и тогда задержка условно в пару секунд, что для 99.99999% случаем более чем достаточно
Так при открытии страницы на блоках с катировками лоадер "инитного получения данных", а дальше работает как обычно websocket и т.п. и обновляется в real time.
А для авторизованных он как бы вообще не нужен, от слова совсем. Для авторизованных просто режим SPA (Client Side Rendering). Более того и Next.js вообще нафиг не нужен для SSR. Это задача решается элементарно, один раз в жизни пишется сервис который на вход получает набор урлов потом будет puppeteer ходить и класть результат в кэш, а при запросах отдавать ответ напрямую из кэша. Никаких ограничений и костылей next.js'a, гигантская производительность ибо все отдается из кэша и одна виртуалка за 5$ обслужит много тысяч RPS.
A few moments later...
Её можно написать один раз на проекте X в каком ни будь 2018 году и пользоваться ей на проектах Y,Z и т.д. по сей день.
И что? Это проблема? Просто реализуйте этот функционал, это элементарно. Это же операционную систему написать.
И что? Потратить суммарно 8 часов на для реализации класса обертки для API запросов с ретраями и кэшем это проблема?
Понятно, классические отговорки и отмазки. Вы что, считаете react-query идеалом? :D Ну я думаю очевидно что нет. А значит аргумент сразу теряет силу. Ибо если бы реально был идеал, то и да, я полностью соглашусь что смысла делать свою реализацию нет. Но как бы идеала нет из готовых решений. Так что...
Типичная не компитентность. Это всё равно, что складывать 5 + 5 на калькуляторе говорить что ты умеешь считать. Перед вами не задача 3х тел, где нужно учесть всё, и гравитацию и магнитное поле и т.д и т.п. А реально перед вами задача 5 + 5, а вы даже её не в состоянии решить. Зато называете себя разработчиками.
Ну если вы не состоянии решить 5 + 5 без сторонней библиотеки, и на этом фоне вы отказываетесь от MobX, то да, вашему проекту уже без разницы, можно максимально сильно его втаптывать в землю. Ибо он всё равно обречен быть похоронен с таким подходом.
Ничего удивительного, слабые и некомпетентные разработчики не в состоянии написать 1 раз класс/функцию для работы с АПИ как удобно именно именно им, если нужен кэш, то с кэшем, если ретрай. то с ретраем и т.д.
Для этого они просто берут корявые готовые решения, а свою некомпетентность маскируют классикой которой уже десятилетия - они просто говорят, не хочу изобретать велосипед. Но на сама деле не хочу у них означает - не могу я это реализовать.
Ну т.е. просто взять и отказаться от MobX просто так, ну тут как бы ничего кроме сочувствия даже на ум не приходит.
Иммутабильность - оптимизация?) Интересненько) С каких это пор постоянное копирование объектов в памяти на каждый чих это оптимизация?
Это расходование процессорных тактов в холостую, а значит это замедление работы. А если это происходит на мобильном устройстве, то и увеличенное потребление энергии в холостую.
А главное иммутабильность даёт ноль профита.
Я понимаю когда мы жертвуем производительностью, расходом памяти и энергии когда пишем на JS вместо Assembler'a, потому что это даёт вполне себе огромный буст в скорости и простоте разработки.
Но если для вас падение производительности, увеличенных расхода памяти и энергии, не оправданное ничем это оптимизация, то мне очень жаль.
Вы сделали 11 ошибок в слове плохой. Вместо SPA приложения с плохой архитектурой, вы по ошибке написали с продуманной.
Очнитесь, все адекватные люди последние 9 лет используют MobX в связке с React. В противном случае это просто очередной говнокод.
React нужно использовать по назначению, рендер html и жизненный цикл компонента, а управление состоянием, как глобальным, так и локальным - MobX.
React + MobX
React + MobX
React + MobX
Лучше смотрите в сторону плагина для Vite/Webpack, который будет используя babel превращать это:
Вот в это:
Тогда это будет:
a) Надежно.
б) Пользователю не нужно будет об этом думать, оно просто работает.
в) А других вариантов и нет, чтобы при этом пользовательский код оставался чистым и красивым.
Я сам несколько плагинов написал себе, чтобы жизнь упростить и оставлять код чистым, поэтому сразу подсказка - https://astexplorer.net/
Там выбираете JavaScript,
@babel/parserВставляете код и наслаждаетесь этой прекрасной утилитой, которая архи круто помогает при написании code transformers
1) БЭМ не используется как минимум с 2015 года, когда во всю уже использовались SCSS + CSS Modules.
2) А использовать Tailwind это вообще самая фатальная ошибка.
"Замечательный" вырви глаз.
Да да, оправдывайте свою некомпетентность в качестве разработчика и говнокод тем, что я якобы не ведаю о чем говорю и живу в розовом мире)
Я как раз живу в реальном мире и прикладываю все усилия чтобы моя жизнь была максимально легка и без сложностей.
Поэтому и использую react+mobx+css modules+классическую архитектуру чтобы максимально легко и непринуждённо разрабатывать любые проекты, вместо того чтобы страдать, решать надуманные проблемы и т.п..
Да, классическую.
Они не плохие, они лучшие для фронта.
Их туда записано сообщество настоящих разработчиков и адекватных людей.
Понятное дело для говнокодеров и тех кто сам себе выдумывает проблемы, а потом героически пытается их решить эти инструменты не подойдут, потому что они напротив избавляют разработчика от всех проблем.
Это не фантазии, это объективная реальность. На данных момент безальтернативная. Альтернативы хуже с точки зрения удобства разработки, качества кода и красоты этого самого кода. А это золотая середина.
Вы конечно собрали комбо из самых худших подходов. Зачем?
Классическая архитектура, React, MobX, SCSS + CSS modules - идеальный выбор ещё с 2016 года и по сей день.
Для роутинга либо самописное решение. Из готовых, всё гуано.
Для АПИ запросов самописная обертка, которая использует axios. Из готовых, всё гуано.
Для работы с формами и валидацией, то же самописное решение. Из готовых, всё гуано.
Более того, React нужно использовать исключительно как View слой, а не как средство для управления состоянием и т.п.
P.S. React way === Худший путь.
Потому что его предназначение - уничтожить ваш проект. И довести ущербность структуры файлов и папок до максимума убогости. Всё для того, что вы и все остальные кто будет работать с этим "чудо" проектом страдали.
А CSS можно использовать без громоздких Tailwind. На гораздо более чистом веб, выражаясь вашими определениями.
Очень смешно. Tailwind легко можно назвать позорной попыткой заменить CSS. Tailwind это жесточайший говнокод, причем это настолько очевидно, что только слепой не замечает.
Это просто одна сплошная уродливая помойка. Видимо разработка совсем загнулась и уровень разработчиков достиг исторического минимума и пробил дно, потому что есть те, кто считает что это круто.
Откройте глаза, MobX существует 10 лет. Redux и вся что около и вокруг него, в том числе RTK Query это так же шлак, который провоцирует писать говнокод и уничтожать проект.
P.S. при использовании CSS modules, никакого БЭМ нет даже в намеках, он автоматически генерируется на выходе.
превращается в
src-layouts-main-___styles-module__wrap___dazN7Вот и все дела. И никаких конфликтов стилей и т.п. при таком подходе быть не может, в каждом компоненте будет класс .wrap / .title и т.п., и конфликт исключен. А удобство написания стилей у SCSS + CSS modules возведено в абсолют.
Я тестил по классике через apache bencmark замеряя RPS, сделал endpoint, который делает 3 запроса в БД, парсит json, преобрзаует объект в json и отдает ответ. Получается усредненный сценарий работы бэкенда, именно реальный, а не просто кто быстрее в цикле посчитает до миллиарда.
Дальше запускаем наше микро приложение-эндпоинт без докера и замеряем, раз 5, чтобы усреднить результат
Потом то же самое микро приложение-эндпоинт запускаем в докере (полностью без ограничений) и так же замеряем раз 5
Сравниваем циферки, вот и все методика.
При этом сама БД у меня была в обоих случая без докера.
Можно сделать ещё лучше, добавить ещё сценарии и БД тоже завернуть в докер и замерить.
Docker файл
Где master.js
Без докера так же запускался этот файл
node ./master.js