Вы видите копию треда, сохраненную вчера в 18:13.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Больше пары строк кода в посте или на скриншоте ведут в ад.
Для программирования на HTML https://codesandbox.io
Для Node.js с консолькой https://repl.it/languages/nodejs
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если/когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
Документация - https://developer.mozilla.org
Руководство для вката - https://github.com/acilsd/wrk-fet#javascript
Значит вы что-то делаете не так. Если использовать простую и примитивную (в хорошем смысле) дефолтную архитектуру, где каждая папка (помимо какой-нибудь shared/common/utils) обозначает какую-либо фичу, то бывает уже этого достаточно. А так-то можно и DDD делать, "чистую архитектуру" и т.д., короче всё то, что есть и в больших приложениях на дотнете или спринге.
>или альтернативно в schema.ts для gql
Никто не запрещает писать на графкл в несте. Но графкл это очень убогая, вредная и мертворождённая технология, так что лучше так не делать.
>Второе, давно уже перекатываются все на сокеты
Ты имеешь в виду графкл, или что? Не вижу, чтобы какие-то "все" на вебсокеты перекатывались. Кто эти все? Феникс эликсировский и всё?
В прямом смысле, дурачок, ты носишься с каким-то нестом, будто это какой-то фреймворк, который кроме его разработчиков в твиттере и тебя кто-то использует. Сколько можно уже объяснять дуралею одно и то же, ты и с четвертого раза не понимаешь?
Я говна не ем, потому что я использую общепринятые инструменты, которыми пользуются миллионы людей. А ты жрешь говно полутора анонимных разработчиков из Твиттера.
Так ты и не смог выдавить из себя, какое секретное говно вы там в своей миллионой секте жрете. Боишься в слух произнести, сектантишка. Наверное что-то на реакте..
А, так ты нитакой как все, особенный у мамки, поэтому ты говно и ешь, назло клятому быдлу окружающему, вопрос только в этом и был, вопросов больше нет
Но если серьезно говорить без перекидывания говном, то зачем мне реакто-нексты, если я хочу пилить интеграцию одного апи с другим, что является самой частой задачей у бекендра? На чистом экспресе я поддерживал проекты, но там обычно через пару лет после создания проектна черт ногу сломит, особенно при текучке. Надо стразу нормальную структуру проекта делать и правила куда коды писать по регламенту. Как раз проблему организации кода нест решает.
>зачем мне использовать самые распространенные инструменты, на которых можно быстро и дешево решить любую задачу, если можно ебаться с ноунейм-говниной?
Я не понимаю, что ты хотел спросить?
Мейнстрим используют, потому что он решает задачи
Твои илитарные поделия используют, чтоб выделиться из толпы
Бывают случаи, когда люди по незнанке встревают на илитарной говнине.
Вот например в твоем случае - ты очевидно, имеешь какой-то бекграунд из других средств разработки, и ошибочно полагаешь, будто в ноду нужно тянуть оттуда "архитектуру", вместо того, чтоб изучать принятые здесь подходы.
Тебе уже тыщу раз сказали. Нест, экспресс, фастифай.
Какие продаваны неста в твиттере, ты ебанутый? Таблетки забыл выпить? Он не популярен у соевиков в твиттере, ты может читать не умеешь и путаешь нест и некст?
Экспресс самый популярный, нест чуть меньше, это и есть мейнстрим. Даже фастифай отдельно от неста довольно нечасто берут.
Нест - это клоунская попытка изобразить "MVC-архитектуру" на воде, которая здесь нахуй не нужна
>ты носишься с каким-то нестом, будто это какой-то фреймворк, который кроме его разработчиков в твиттере и тебя кто-то использует
>>287532
>нест не нужен, он не популярный, я скозал
node backend express
97 вакансий
https://hh.ru/search/vacancy?text=node+backend+express
node backend nest
86 вакансий
https://yaroslavl.hh.ru/search/vacancy?text=node+backend+nest
Дооооооооооооо, никто не использует, ты же скозал, лол!
node express 151 вакансия
node nest 126 вакансий
Ты можешь сколько угодно заниматься перефорсом, от этого говноедом ты быть не перестаешь
>MVC-архитектуру
Кловн? При разработке на несте нету никакого вью, на нём делают REST/GraphQL монолиты и микросервисы, вью в 99.999999999999% случаев это отдельное Реакт/Ангуляр/Вью фронтенд приложение.
Каким ещё перефорсом? Я просто доношу правдивую информацию до треда.
Наличие вакансии лишь означает, что старший покрасчик кнопок в этой организации прочитал в твиттере и на хабре про модный фреймворк и решил тратить время разработчиков своей организации для своего развлечения, наебывая кабанчика.
На несте спокойно делается DDD, чистая архитектура, event sourcing и CQRS, гексагональная и онион архитектура. Про нахуй здесь не нужна это твоё субъективное видение, выдающее в тебе обыкновенную крудошлёп-макаку, ничего серьёзного в своей жизни не разрабатывавшую.
Бредни пишешь. Нест не является "модным" в твиттере и на хабре. Жду очередной манявр от тебя.
Там точно есть DI, контроллеры и прочая хуйня, которую спиздили у "взрослых" сначала в ангуляр, а потом, без понимания зачем это нужно, сделали и для ноды. А мы говорим о том, что в ноде есть общепринятые подходы к архитектуре приложений, и тянуть говнище из джавы ради самого процесса - нахуй не нужно
что это за подходы? где про них почитать?
>А мы говорим о том, что в ноде есть общепринятые подходы к архитектуре приложений
И они прекрасным образом реализованы в несте.
>спокойно делается DDD, чистая архитектура, event sourcing и CQRS, гексагональная и онион архитектура
А делать-то ты что умеешь, кроме того, что срать кабанчику баззвордами в уши? Если в этом состоит твоя задача - вопросов нет, тебе нужен нест.
Перечисленный тобой мусор из 70-х не имеет никакого отношения к разработке на ноде
Могу и крупный модульный монолит сделать, который будет удобно поддерживать, могу и микросервисы.
>я скозал
Да мы уже поняли, что ты никакого отношения к разработке на ноде не имеешь, иначе не писал бы такие бредни.
Ну видишь, ты срешь околоайтишными баззвордами, а не перечислением того, какие задачи ты можешь решать.
а что имеет?
Так разработка на ноде это по сути два варианта: костыляние велосипеда вокруг экспресса, либо нест. Всё. Отдельный илитарные нитакусики вроде тебя делают что-то другое, не являющееся мейнстримным и общепринятым.
Ты уже весь тред засрал про общепринятое и мейнстримное, но не в состоянии перечислить что это такое в твоём представлении. Про задачи я уже написал в посте, на который ты ответил, так что соболезную, если у тебя проблемы с пониманием текста.
Зачем делать что-то другое, глупый ты перефорсер тупостью? Нет никакой проблемы в экспрессе, я тебе и рассказываю про мейнстрим.
Ты или решаешь задачи на экспрессе, или кормишь кабанчика баззвордами
В посте ты айтишные баззворды написал. Ты делать-то что умеешь? Магазин там? Приложение банка? Что ты решал в своей жизни своей "правильной архитектурой"?
>перефорсер
Что значит этот баззворд, эксперт по баззвордам?
Многие начинают делать что-то другое кроме экспресса по той причине, что это не фреймворк, а тупо голый роутер, вокруг которого нужно костылять огромный велосипед чтобы всё это было похоже на нормальный бекенд. Ты не разбираешься в мейнстриме, либо твои знания отстали на лет 5, потому что нест уже давно им стал.
>>287568
Магазин и приложение банка это либо монолит, либо микросервисы. Всё это я умею делать. Делал биллинги, приложения для управления рекламой в соцсетях, букмекера, аудио стриминг, маркетплейст автомобилей, коллаборативный редактор документов и многое другое в крипте.
Как же ору с этого копиума. Покрасчику кнопок экспресс в разы проще и ближе, их от неста воротит, они же на 80-90% реактеры, на ангуляре мало кто пишет, какой им нест, лол.
Перефорсер - это не баззворд, это сленг двачика, когда пациент начинает срать тупостью, переиначивая слова собеседника, думая что он так "троллит". Так понятнее?
> что-то другое кроме экспресса по той причине, что это не фреймворк
Так какую задачу ты решаешь-то? Ты только не рассказывай, что ты организуешь "правильную архитектуру" ради правильной архитектуры. Когда ты поймешь, что архитектура - это инструмент, а не самоцель, тогда к тебе и просветление придет.
> Ты не разбираешься
Опять от обидки на собеседника любитель "правильной архитектуры" начал агриться. Ты не говном кидайся, ты голову включай, ты же сам хотел дискуссию, а не говнометание? Я вот не упрекаю тебя в том, что ты не разбираешься, ты отлично разбираешься в "правильной архитектуре", я лишь рассказываю, что здесь она не нужна и все решается гораздо проще на "голом роутере". Это в Джаве невозможен "голый роутер" из-за убогости и невыразительности инструментов, тут-то зачем ты сам себе придумываешь сложности?
>Перефорсер - это не баззворд, это сленг двачика, когда пациент начинает срать тупостью, переиначивая слова собеседника, думая что он так "троллит".
Так твои слова про популярность неста в твиттере вместо реальной разработки это буквально троллинг, потому что всё обстоит наоборот, его часто используют в разработке, а в твиттере на него всем похуй, в твиттере модно писать бекенд прямо на NEXT'е.
>Так какую задачу ты решаешь-то?
Создание и поддержка крупного REST API, например. Я как раз знаю, что архитектура это полезный инструмент, благодаря которому моя задача будет выполнена эффективнее.
>здесь она не нужна
>и все решается гораздо проще на "голом роутере"
В мелком круде для 1.5 человек - да.
>тут-то зачем ты сам себе придумываешь сложности
Но я не придумываю себе сложности, не вижу ничего сложного как в самом несте, особенно если юзать дефолтный подход с одна папка = одна фича, так и не вижу сложности в построении архитектуры по общепринятым популярным паттернам. К слову, в большинстве случаев достаточно дефолтного подхода, прямо как написано в доках неста, он супер простой. А на экспрессе получается в каждом проекте свои костыли, где-то проект организован так, где-то этак, нужно тратить время на разбирательство, а в несте в любом проекте всё понятно сходу, очень быстро и просто.
Нитакусик, твое мнение нам неинтересно, мы тупое быдло и ничего плохого в покраске кнопок не видим.
Я тоже ничего не вижу плохого в покраске кнопок. И я не нитакусик, я обычный бекендер, использую классику и стандартые в индустрии инструменты. Если мнение не интересно, то можно и не держать в курсе.
> часто используют в разработке
Еще раз - мы уже договорились, что нест часто используют в разработке те, кто пытается тянуть громоздкие подходы из джавы и прочего дотнета в разработку на ноде. Здесь же все делается много проще.
>>Так какую задачу ты решаешь-то?
>Создание и поддержка крупного REST API
Так что в "голом экспрессе" тебе мешает это сделать? Ты не знаешь куда положить папочку с роутами, в разных проектах папка не так называется, все, пиздец, нужно DI, контролеры с декораторами и прочее говнище тянуть? Нахуя, блять?
Ты не понимаешь, что в Джаве это было вынужденными мерами, потому что там тупо нельзя импортировать функцию из файла нормально? И что там повторный импорт заново инициализирует модуль, поэтому там пришлось городить контейнеры с синглтонами?
У тебя все работает из коробки, зачем ты делаешь говно как там?
>в твиттере модно писать бекенд прямо на NEXT'е
Это каким это интересно образом ты напишешь бэк на реакте?
Опять эти проекции деда с трехколёсными контейнерами и синглтонами абстрактных фабрик
зачем серверный рентеринг, чтобы чтобы хлебнуть из телеграм апи и пукнуть в рэббитэмку?
Вот есть массив строк. Нужно проверить, есть ли элемент в этом массиве. Но элемент может быть не только строкой. Делаю.. через includes и хуй, ошибка. Казалось бы - какая тебе нахуй разница? Если элемент не строка - верни false, значит. Нет, сука проверяй на тип, проверяй-проверяй, вот как надо проверять!
даже если и так, то тебе после пука придется отрендерить компонент на пхп, а потом подключить реакт и перерисовать его заново. А с реактом на сервере это делается один раз
В момент рендера на сервере ты можешь сделать что угодно на сервере, очевидно
>а где почитать какие подходы приняты в ноде
Нигде, там ничего не принято. "Принято" - это значит существование конвенций. Конвенции могут существовать там, где есть культура и цивилизация. нода - это веб макакинг в худшем его проявлении, нод жсеры это буквально дикари, зачастую вчерашние версталы. Откуда им знать как делать бэк?
Тут мне советовали это
https://github.com/mattpocock/ts-reset
но я смирился с тайпскриптом потому что не люблю мелкие зависимости
Почитай про папки, файлы, импорты, видимость импортов. Этого достаточно, чтобы не городить контейнеры и синглтоны с декораторами инъекций зависимостей, как пример. Если ты приведешь какую-то другую задачу, для которой тебе нужен нест - я расскажу про нее.
Выше написали про структурирование папок - люди боятся, что в каждой проекте папки называются по-разному, и хотят, чтобы фреймворк их заставлял делать КОНТРОЛЛЕРЫ, спеки, и прочие папки строго в той иерархии, как задумано в нем. Если тебе нужно, чтоб фреймворк тебя вынуждал складывать файлы единообразно - тут проблема не в фреймворке.
Говори правильно СКЕДЖУЛЕР
Да, ты можешь положить скрипт на ноде в крон и пукать в базу им, а и основного приложения читать. У тебя по-прежнему на один язык меньше, чем в решении на пхп, в котором без дублирования на жс не обойтись
>В момент рендера на сервере ты можешь сделать что угодно на сервере, очевидно
Ну ок, да, это можно сделать, но зачем?
Соответственно, команда разработчиков на жс масштабируется еще лучше, чем один.
>Затем, чтобы не покупать второго программиста на пхп, а обойтись одним
А запросы в базу кто писать?
js-фреймворки для этого есть, сотни, явно больше чем на пхп и любом другом "классическом бекенде", хочешь орм, хочешь sql, выбора полно
>js-фреймворки для этого есть
Мы уже внутри фреймворка
>сотни, явно больше чем на пхп и любом другом "классическом бекенде"
Можно хотя бы пару примеров?
>хочешь орм, хочешь sql, выбора полно
Я правильно понимаю, что верстала будет писать SQL запросы?
> Мы уже внутри фреймворка
Ну и что? В пхп тоже так бывает
> пару примеров?
postgres.js, mysql.js - пиши себе запросы "по классике"
knex, prisma, drizzle - вот тебе orm
> верстала будет писать SQL
Или бекендер будет верстать, или они будут друг друга заменять, а главное они будут друг друга понимать без лишней прослойки в пхп и прочем нахуй не нужном лет 10 как спринге
>Откуда им знать как делать бэк?
Кек в том, что именно в ноде есть одна простая конвенция, благодаря которой один и тот же код работает на express, next.js api, aws lambda, firebase functions и любом другом бекенд-фреймворке практически без изменений. Боль "классических бекендеров", которые "знают как надо", невозможно измерить ни в градусах, ни в децибелах.
>Ну и что? В пхп тоже так бывает
Ну так пхп - это мягко говоря не образец для подражания
>postgres.js, mysql.js - пиши себе запросы "по классике"
Какова производительность этих решений по сравнению с аналогами на нормальных языках?
>Или бекендер будет верстать, или они будут друг друга заменять, а главное они будут друг друга понимать без лишней прослойки в пхп и прочем нахуй не нужном лет 10 как спринге
Ну то есть вместо SOC с нормальным фронтом, отдельно нормальным бэком и каналом между ними мы получаем:
репозиторий в виде свалки в одном месте всяких нечистот, недофронта, которому приходится пердолиться с бэком, толком не умея в него нормально, бэкендера, которому почему-то приходится верстать, протекающие во вью модели, отсутствие возможности сделать нормальную апиху и вот это вот все?
Для сельского интернет магазина это может и прокатит, но для чего-то более серьезного - не думаю
какая?
Так можно и про пехепе код сказать что он просто работет на любом пехепе фреймворке. Это не конвенция о том куда писать коды.
> не образец для подражания
А ты какой "классический бекенд" тут продаешь, старец?
> аналогами на нормальных языках?
nodejs-модули для SQL-баз обычно написаны на С и C++, я тебя очень расстрою, держись за стул, может взорваться
> свалки в одном месте
Не очень понимаю что ты сейчас хочешь продать, "микросервисы"? Именно на ноде с ними нет никаких проблем, по вышеописанным причинам, которые ты не читал, потому что держался за стул.
> недофронта, которому приходится пердолиться с бэком
> бэкендера, которому почему-то приходится верстать
Зачем ты это придумал, чтобы что? Ты прекрасно можешь масштабировать команду как тебе угодно
> протекающие во вью модели
Ааа, я понял, ты себя описал, когда рассказывал про недофронтов и недобеков. Объясняю. "Протекание" в принципе здесь невозможно, серверный код никак не может выполниться на клиенте.
> сделать нормальную апиху
именно здесь это можно сделать с минимумом головной боли
> для чего-то более серьезного
Именно поэтому все крупнейшие интернет-проекты перешли на ноду.
Года идут, а старцы с пхп, спрингом и прочей питонопарашей, ума не набираются, повторяют все те же мантры из 2013
>Кек в том, что именно в ноде есть одна простая конвенция
Конвенцию в студию, пожалуйста
>один и тот же код работает на express, next.js api, aws lambda, firebase functions
Один и тот же Java код работает на Spring, Micronaut, Quarkus и любом другом фрейворке практически без изменений.
>next.js api
>бекенд-фреймворк
Это какое-то запредельное орейро.
>Боль "классических бекендеров"
Подскажи, пожалуйста в каких децибелах или градусах можно измерить боль "ноджс бэкендера", который решая простейшую задачу
- разбирался в архитектуре унаследованного говнокода, высранного его предшественником безо всякого намека на MVC, в попытке вообще понять, где там сервис, а где модель,
- потом пытался понять, почему у него опять cannot read property null of undefined,
- когда он наконец заборол динамическую типизацию, настало время пердолиться с кнексом, который отвалился по таймауту из-за переполнения пула соединений, потому что наш "ноджс бэкендер" является обычным версталой и о том, что такое транзакции он даже не слышал,
- вишенкой на тортике стали падения подов на проде каждые несколько часов из-за переполнения памяти, искать причину которых кабан заставил на выходных
Это поддается измерению?
А "классический бекендер" в 6 часов вечера закрыл крышку ноута и пошел пить пиво в бар с пацанами.
> существование конвенций. Конвенции могут существовать там, где есть культура и цивилизация
В бекенде на ноде всё это есть.
почитать бы хоть шо-то про эти конвенции а то тут про них все время пишут а когда я прошу ссылку или прямо спрашиваю меня игнорят
это ты меня игноришь?
>Java код работает
Ооо, нам пришли продавать фабрики абстрактных контейнеров! Нет, это не так работает.
> запредельное орейро.
Измерь температуру стула
> описание какой-то хуеты из его сельского магазина
Здорово, что тебе пока еще везет копаться в классическом легаси-говнеце, переводя проекты со спринга на микронаут и обратно, в надежде что они наконец начнут работать, держись за эту работу, найти новый проект на этой параше уже очень сложно и с каждым годом все сложнее, а мозг уже высох и переучиться на next не получится. Если даже и попытаешься, ты же обязательно притащишь фабрику абстрактных контейнеров и все будет работать через такую жопу, как в слышанных тобой байках.
>Конвенцию в студию, пожалуйста
Всё те же конвенции, которые есть в бекенде на других языках.
>- разбирался в архитектуре унаследованного говнокода, высранного его предшественником безо всякого намека на MVC, в попытке вообще понять, где там сервис, а где модель,
В несте нит никаких проблем из перечисленных.
>- потом пытался понять, почему у него опять cannot read property null of undefined,
В 2024 не слышал про тайпскрипт?
>- когда он наконец заборол динамическую типизацию, настало время пердолиться с кнексом, который отвалился по таймауту из-за переполнения пула соединений, потому что наш "ноджс бэкендер" является обычным версталой и о том, что такое транзакции он даже не слышал,
Про typeorm, prisma, drizzle, kysely не слышал? Кнекс это что-то из 2018. Про транзакции слышал любой бекендер.
>- вишенкой на тортике стали падения подов на проде каждые несколько часов из-за переполнения памяти, искать причину которых кабан заставил на выходных
При чём тут нода, это проблема разрабов, которые не знаю как работает память, как легко детектить утечки, как легко одной строкой тюнить ограничения.
Опять этот любитель тупорылой кальки с джавы рассказывает нам, что его кривое говно это и есть нода.
Именно в твоем несте из развестистой "правильной архитектуры" и нельзя запустить рабочий код для express и любого другого фреймворка, потому что он ожидает фабрику абстрактных контроллеров
>Какова производительность этих решений по сравнению с аналогами на нормальных языках?
Пикрелейтед.
>Ну то есть вместо SOC с нормальным фронтом, отдельно нормальным бэком и каналом между ними мы получаем:
>репозиторий в виде свалки в одном месте всяких нечистот, недофронта, которому приходится пердолиться с бэком, толком не умея в него нормально, бэкендера, которому почему-то приходится верстать, протекающие во вью модели, отсутствие возможности сделать нормальную апиху и вот это вот все?
В несте ничего из этого нет.
Напоминаю, есть люди, которые разбираются в ноде, они используют express, next, aws lambda, firebase functions, их код работает везде.
Есть люди, которые не разбираются в ноде, они используют nest и прочие кривые копии mvc-фреймворков типа рельс, спринга и прочего ларавеля. Их код работает только в их пузыре, из которого они не хотят выбираться по своей зашоренности и привычкам.
> Можно запустить, просто и быстро
Нахуярить контроллеров, синглтонов, заинжектить в нужные места, разложить по папочкам из инструкции? Спасибо, дорогой
Ты типичный школьник с бинарным максималистским мышлением. В твой ограниченный манямирок не влезает мысль о том, что бекенд инженер на ноде может некоторые проекты писать на фуллстек серверлесс нексте, а другие на несте без вью.
Я объяснил тебе почему кривым говном являются твои китайские реплики спринга - они реализуют то, что отсутствует в Джаве как класс, то есть нормальная система модулей и импортов
Ты хотел дискуссии, но кажется понял в чем дело и обиделся, снова начал кидаться говном?
У тебя нет ни единого аргумента в защиту своего подхода кроме "мммм это правильная архитектура так делают во взрослых бекендах потому что делают так правильно мам уберите его от меня!"
Ты типичный долбоеб, который делает выводы из пальца. Бекенд-инженеру может быть необходимо по работе в том числе ковыряться в говне на фреймворках с абстрактными инъекциями синглтонов, но если он в своем уме, он объяснит тебе, почему этот каменный век в ноде не нужен.
Говном тут больше всех ты кидаешься, не приводя ни одного внятного аргумента, вместо них у тебя метание говном, необоснованное мнение и классическое врёти с маневрами.
То есть все же надо все переписать "по конвенциям фреймворка"? А у людей это просто работает
Зачем в них ковыряться, если можно из использовать для удобной разработки? Если у тебя не получается, то может бекенд это не твоё?
Ну это буквально то о чем я говорил, пхп-гной восстал из мертвых. Веб-макаки просто необучаемы.
>>287652
>А ты какой "классический бекенд" тут продаешь, старец?
Любой классический бэкэнд, и да, я никому ничего не продаю. Мало того, я даже буду очень рад понять, каким образом впендюривание SQL запроса во фронтовый код сделает мою жизнь как веб разработчика легче и приятней.
>nodejs-модули для SQL-баз обычно написаны на С и C++, я тебя очень расстрою, держись за стул, может взорваться
Аддоны ты имеешь в виду? Ок, держусь за стул, взорваться пока что не получается никак от слова совсем (пик 1)
>Не очень понимаю что ты сейчас хочешь продать, "микросервисы"?
Повторюсь, никому ничего не продаю, тем более "микросервисы", а лишь пытаюсь понять, как в сформированную тобой концепцию вписывается такое понятие как MVC. С примером кода было бы прям очень круто.
>Именно на ноде с ними нет никаких проблем, по вышеописанным причинам, которые ты не читал, потому что держался за стул.
Продолжая держаться за стул, никак не могу взять в толк, в чем принципиальное преимущество микросервисов написанных на языке, созданном для манипуляции содержимым HTML-тегов, перед микросервисами написанными перед, например, на специально для этого созданном Go.
>Зачем ты это придумал, чтобы что? Ты прекрасно можешь масштабировать команду как тебе угодно
Я этого не придумывал, это твои слова. Давай проследим цепочку диалога. Ты начал с того, что бэкэнд будет писаться на нексте. Я логичным образом уточнил, как будет осуществляться работа с базой данных, на что ты ответил, что SQL код будет писаться на сервере версталой либо бэкэндером. От сюда вытекает два вопроса, первый из которых я задавать тогда не стал, но задам сейчас
- верстала ("ноджс бэкендер") напишет общее табличное выражение с несколькими таблицами подзапросов с оконными функциями с офсетами в финальном запросе?
- поскольку ответ на первый вопрос очевидно нет, мне придется подключать к моему проекту нормального бэкэндера, который хотя бы понимает, что означают термины, которые я употребил в предыдущем выражении. Вопрос, зачем мне онбордить человека на проект, объяснять ему куда впендюрить код, что такое жаваскрипт и прочее, если мне от него нужна просто ручка? Зачем мне это, чтобы что?
>"Протекание" в принципе здесь невозможно, серверный код никак не может выполниться на клиенте.
Я говорю не про выполнение кода, я говорю про говнокод, изображенный пикрил>>287648
У тебя работа с базой данных впендюрена в хтмль разметку. Зачем, чтобы что?
>именно здесь это можно сделать с минимумом головной боли
Зачем мне вообще этим заниматься?
>Именно поэтому все крупнейшие интернет-проекты перешли на ноду.
Эти проекты сейчас с тобой в комнате, ты их видишь?
Ну это буквально то о чем я говорил, пхп-гной восстал из мертвых. Веб-макаки просто необучаемы.
>>287652
>А ты какой "классический бекенд" тут продаешь, старец?
Любой классический бэкэнд, и да, я никому ничего не продаю. Мало того, я даже буду очень рад понять, каким образом впендюривание SQL запроса во фронтовый код сделает мою жизнь как веб разработчика легче и приятней.
>nodejs-модули для SQL-баз обычно написаны на С и C++, я тебя очень расстрою, держись за стул, может взорваться
Аддоны ты имеешь в виду? Ок, держусь за стул, взорваться пока что не получается никак от слова совсем (пик 1)
>Не очень понимаю что ты сейчас хочешь продать, "микросервисы"?
Повторюсь, никому ничего не продаю, тем более "микросервисы", а лишь пытаюсь понять, как в сформированную тобой концепцию вписывается такое понятие как MVC. С примером кода было бы прям очень круто.
>Именно на ноде с ними нет никаких проблем, по вышеописанным причинам, которые ты не читал, потому что держался за стул.
Продолжая держаться за стул, никак не могу взять в толк, в чем принципиальное преимущество микросервисов написанных на языке, созданном для манипуляции содержимым HTML-тегов, перед микросервисами написанными перед, например, на специально для этого созданном Go.
>Зачем ты это придумал, чтобы что? Ты прекрасно можешь масштабировать команду как тебе угодно
Я этого не придумывал, это твои слова. Давай проследим цепочку диалога. Ты начал с того, что бэкэнд будет писаться на нексте. Я логичным образом уточнил, как будет осуществляться работа с базой данных, на что ты ответил, что SQL код будет писаться на сервере версталой либо бэкэндером. От сюда вытекает два вопроса, первый из которых я задавать тогда не стал, но задам сейчас
- верстала ("ноджс бэкендер") напишет общее табличное выражение с несколькими таблицами подзапросов с оконными функциями с офсетами в финальном запросе?
- поскольку ответ на первый вопрос очевидно нет, мне придется подключать к моему проекту нормального бэкэндера, который хотя бы понимает, что означают термины, которые я употребил в предыдущем выражении. Вопрос, зачем мне онбордить человека на проект, объяснять ему куда впендюрить код, что такое жаваскрипт и прочее, если мне от него нужна просто ручка? Зачем мне это, чтобы что?
>"Протекание" в принципе здесь невозможно, серверный код никак не может выполниться на клиенте.
Я говорю не про выполнение кода, я говорю про говнокод, изображенный пикрил>>287648
У тебя работа с базой данных впендюрена в хтмль разметку. Зачем, чтобы что?
>именно здесь это можно сделать с минимумом головной боли
Зачем мне вообще этим заниматься?
>Именно поэтому все крупнейшие интернет-проекты перешли на ноду.
Эти проекты сейчас с тобой в комнате, ты их видишь?
То есть объяснение, как работает система импортов в жс и в жабе - не является для тебя объяснением? А что тебе нужно объяснить?
Зачем всё переписать? Наоборот ничего не надо, просто подключил в модуль и всё.
Ну давай, расскажи чего конкретно по-твоему нету.
>Еще раз - мы уже договорились, что нест часто используют в разработке те, кто пытается тянуть громоздкие подходы из джавы и прочего дотнета в разработку на ноде. Здесь же все делается много проще.
Его много кто использует, а не только не, кто пытается тянуть классические подходы из других языков. И самое главное, намного проще это как раз нест. Разработка бекенда на несте это намного проще, чем разработка бекенда на велосипедах из экспресса.
>Так что в "голом экспрессе" тебе мешает это сделать? Ты не знаешь куда положить папочку с роутами, в разных проектах папка не так называется, все, пиздец, нужно DI, контролеры с декораторами и прочее говнище тянуть? Нахуя, блять?
В экспрессе нету никакого функционала кроме роутинга. Каждый новый проект на экспрессе выглядит по-своему из-за уникальных для этого проекта костылей и велосипедов.
>Ты не понимаешь, что в Джаве это было вынужденными мерами, потому что там тупо нельзя импортировать функцию из файла нормально? И что там повторный импорт заново инициализирует модуль, поэтому там пришлось городить контейнеры с синглтонами?
Да мне в принципе похуй что там в джаве. В несте это удобно и упрощает разработку когда проект огромный, и упрощает переход в новые проекты.
>У тебя все работает из коробки, зачем ты делаешь говно как там?
В экспрессе практически нихуя нету из коробки кроме роутинга.
>Всё те же конвенции, которые есть в бекенде на других языках.
Ожидаю услышать хотя бы названия этих конвенций.
>В несте нит никаких проблем из перечисленных.
Оу, стоп, стоп, стоп. Только что был же некст? Ты уж определись.
>В 2024 не слышал про тайпскрипт?
Каким образом тайпскрипт помешает твоему коллеге впендюрить any везде, где он захочет? //eslint-disable-next-line слышал что-нибудь про такие приемы?
>Про typeorm, prisma, drizzle, kysely не слышал?
Чел просто уже в передозе копиумом имплаит что
>ВОТ ТАМ-ТО ТОЧНО ТАКИХ ПРОБЛЕМ НЕТ, КЛИНУСЬ!!!1111
>Про транзакции слышал любой бекендер.
Верстала слышал про транзакции?
>При чём тут нода, это проблема разрабов, которые не знаю как работает память
При том, что утечки памяти - это отличительная черта ноды, это ее фирменная фишка, торговая марка, если хочешь. Про это написаны килобайты текстов, миллиарды комментов, а воз и ныне там: в8 течет как решето.
>как легко детектить утечки, как легко одной строкой тюнить ограничения.
Поделись с нами, сэнсей и мы перейдем на нодную сторону силы
>пик 1
Эти пик модерновой библиотеки, которая заявляет 100% js как фичу, и наверняка у нее тоже есть свои бенчмарки. Ты можешь использовать обычный node-postgres на С.
> никому ничего не продаю
Ну да, ты просто бомбишь и оберегаешь свой легаси-мирок от разрыва шаблона.
> такое понятие как MVC
Не имеет никакого отношения к ноде. Ты можешь использовать nest и что там еще в треде продают mvc-инвалиды для ноды, речь же о том, что в ноде подход другой и эти костыли тут не нужны.
> на языке, созданном для манипуляции
> перед, например, на специально для этого созданном
Мы это только что обсуждали, тебе не нужен лишний язык, этот язык выполняет абсолютно те же задачи, а необходимость "специально написанных" ты сам себе придумал, чтобы жопа не взорвалась от осознания бессмысленности потраченного на них времени.
> верстала ("ноджс бэкендер")
Опять прохладные истории из 2013 года, держись за эту работу, больше такой не будет
> зачем мне онбордить человека на проект
Зачем онбордить тебя, предпенсионера, который застрял в 2013 и не умеет в современную разработку, на новый проект? Правильно, тебе остается гнить в твоем легаси-проекте
> работа с базой данных впендюрена в хтмль разметку. Зачем, чтобы что?
это главный разрыв жопы предпенсионеров. Объясняю.
Работа с базой данных никак не связана с хтмл-разметкой, несмотря на то, что sql-запрос отображается на одном экране с ней.
Дальше надо объяснять, или ты сможешь размочить мозг?
>>> АААА НЕЛЬЗЯ НАПИСАТЬ АПИХУ
>>именно здесь это можно сделать с минимумом головной боли
>Зачем мне вообще этим заниматься?
Комментарии излишни
> Эти проекты сейчас с тобой в комнате, ты их видишь?
Да, бери любую компанию из любого рейтинга, первую сотню, не ошибешься. Да, в них во всех в том числе еще используются легаси, на которых сидят такие пердуны как ты, неспособные понять зачем хтмл и sql отображать вместе.
>Каким образом это является минусом неста?
Еще раз. Я могу в жс просто импортировать модуль и он инициализируется один раз как "синглтон" в di-фреймворке.
Я могу экспортировать из него функцию инициализации и "инжектить" его в любом месте сколько угодно раз через нее.
В жс решена проблема, для которой в жабе городили огород с декораторами, контроллерами и инъекцией зависимостей, без всяких фреймворков.
Ты тянешь это говнище в язык, который от него избавился, чтобы тебе было привычно. Окей, а остальным-то это зачем?
>Работа с базой данных никак не связана с хтмл-разметкой, несмотря на то, что sql-запрос отображается на одном экране с ней.
Но ведь на пхп3 тоже самое было. Скл выполняется на беке, результат запроса встраивается в шаблон где было mysql_query и уже шаблонизатор генерит верстку. И там ту там проблема в отсутствии конвенции разделения предстваления и логики, а не вто что хтмл элементы "влияют" на запрос.
>Эти пик модерновой библиотеки, которая заявляет 100% js как фичу
Заявлять собственное говноедство как фичу - это перефорс уровня /b.
>Ну да, ты просто бомбишь и оберегаешь свой легаси-мирок от разрыва шаблона.
Абсолютно не бомблю, веду с тобой психиатрическую беседу в стиле МЕДФИЛЬМ и пытаюсь найти хотя бы одно преимущество в написании бэка на нексте. Пока что не получается. Если ты стараешься мне что-то объяснить - старайся лучше.
>речь же о том, что в ноде подход другой и эти костыли тут не нужны.
И какой подход в ноде императивный спагетти код на свалке нечистот?
>этот язык выполняет абсолютно те же задачи
Твой язык пока что не выполняет даже задачи склеивания строк за разумное время. О чем речь?
>Опять прохладные истории из 2013 года, держись за эту работу, больше такой не будет
>Инъекция копиума
>Зачем онбордить тебя, предпенсионера, который застрял в 2013 и не умеет в современную разработку
В разработку чего? Где зафиксировано что это - современная разработка?
>Работа с базой данных никак не связана с хтмл-разметкой, несмотря на то, что sql-запрос отображается на одном экране с ней.
- Проснись, ты серишь
- А я и не сплю
Комментировать НАСТОЛЬКО отборную шизу я уже просто не могу. Просто задам вопрос, а с чем же она связана? У тебя прокидывается переменная в функцию, которая рендерит HTML и там же в этом html конструирует запрос.
>Дальше надо объяснять, или ты сможешь размочить мозг?
Конечно, надо.
>Да, бери любую компанию из любого рейтинга, первую сотню, не ошибешься.
Достаточно будет ссылочки на гитхаб, спасибо. Компания FAANG уровню меня устроит. У них много опен сорса, я думаю тебе не составит труда поделиться ссылочкой.
>неспособные понять зачем хтмл и sql отображать вместе.
Это в принципе невозможно понять человеку без органического поражения головного мозга.
>Эти пик модерновой библиотеки, которая заявляет 100% js как фичу
Заявлять собственное говноедство как фичу - это перефорс уровня /b.
>Ну да, ты просто бомбишь и оберегаешь свой легаси-мирок от разрыва шаблона.
Абсолютно не бомблю, веду с тобой психиатрическую беседу в стиле МЕДФИЛЬМ и пытаюсь найти хотя бы одно преимущество в написании бэка на нексте. Пока что не получается. Если ты стараешься мне что-то объяснить - старайся лучше.
>речь же о том, что в ноде подход другой и эти костыли тут не нужны.
И какой подход в ноде императивный спагетти код на свалке нечистот?
>этот язык выполняет абсолютно те же задачи
Твой язык пока что не выполняет даже задачи склеивания строк за разумное время. О чем речь?
>Опять прохладные истории из 2013 года, держись за эту работу, больше такой не будет
>Инъекция копиума
>Зачем онбордить тебя, предпенсионера, который застрял в 2013 и не умеет в современную разработку
В разработку чего? Где зафиксировано что это - современная разработка?
>Работа с базой данных никак не связана с хтмл-разметкой, несмотря на то, что sql-запрос отображается на одном экране с ней.
- Проснись, ты серишь
- А я и не сплю
Комментировать НАСТОЛЬКО отборную шизу я уже просто не могу. Просто задам вопрос, а с чем же она связана? У тебя прокидывается переменная в функцию, которая рендерит HTML и там же в этом html конструирует запрос.
>Дальше надо объяснять, или ты сможешь размочить мозг?
Конечно, надо.
>Да, бери любую компанию из любого рейтинга, первую сотню, не ошибешься.
Достаточно будет ссылочки на гитхаб, спасибо. Компания FAANG уровню меня устроит. У них много опен сорса, я думаю тебе не составит труда поделиться ссылочкой.
>неспособные понять зачем хтмл и sql отображать вместе.
Это в принципе невозможно понять человеку без органического поражения головного мозга.
>В экспрессе нету никакого функционала кроме роутинга
А в чем проблема-то? Он выполняет свою задачу. Берешь любую библиотеку и решаешь свою задачу и она работает с экспрессом как влитая. Захотел - поменял. Поменялась задача - поменял на другую.
Тогда как со своим all-in-one фреймворком ты привязан к нему навсегда.
> новый проект на экспрессе выглядит по-своему
Ты понимаешь что ты все, поехавший? Еще раз, читаем твои слова:
>В экспрессе нету никакого функционала
> новый проект на экспрессе выглядит по-своему
Давай еще раз:
>В экспрессе нету никакого функционала
> новый проект на экспрессе выглядит по-своему
Вдумайся, плиз.
Ладно, я избавлю читателей от мучений, объясню им. Этот кадр приписывает структуру папок и файлов своего проекта к экспрессу. Ему не нравится, что папки и файлы можно раскладывать произвольно. Нету, блять, порядка, говорит!
Окей, но, сука, почему ты тогда приписываешь это ЭКСПРЕССУ? Если в нем нет правил по раскладыванию файлов, значит это не его проблема. Почему проекты должны выглядеть одинаково? Они разные, блять.
Окей, тебе нужны правила по раскладыванию файлов. Бери Next.js, там это есть. Зачем брать костыли абстрактных контроллеров с декораторами?
>на пхп3 тоже самое было
Нет, там была каша, в которой не было
> разделения предстваления и логики
А здесь server actions никак не связаны с "представлением", тебе просто показали минимальный пример для наглядности. serverAction может быть совершенно другим файлом в совершенно другом репозитории.
>Где зафиксировано что это - современная разработка?
> FAANG устроит
Вот именно во всех них и используется бекенд на ноде последние 10 лет как основной инструмент разработки всех новых проектов, а ты - некомпетентный пенсионер из 2013 года, напомню
>Ожидаю услышать хотя бы названия этих конвенций.
Так не я речь про конвенции начал. Джавист пришёл и говорит, что в ноде нет конвенций. Пусть скажет названия конвенций, которых ему не хватает в ноде и которые есть в джаве.
>Оу, стоп, стоп, стоп. Только что был же некст? Ты уж определись.
Я конкретно про нест говорю. В нексте ничего кроме роутинга нету.
>Каким образом тайпскрипт помешает твоему коллеге впендюрить any везде, где он захочет?
Строгий tsconfig. За //eslint-disable-next-line на кодревью жёстко попустят.
>Чел просто уже в передозе копиумом имплаит что ВОТ ТАМ-ТО ТОЧНО ТАКИХ ПРОБЛЕМ НЕТ, КЛИНУСЬ!!!1111
Я преимущественно typeorm и prisma использую, проблем с памятью из-за них не было.
>Верстала слышал про транзакции?
При чём тут версталы? Речь про бекендеров.
>При том, что утечки памяти - это отличительная черта ноды, это ее фирменная фишка, торговая марка, если хочешь
Trust me bruh, мамой клянусь V8 течёт как решето?
>Поделись с нами, сэнсей и мы перейдем на нодную сторону силы
Сначала поделись конкретикой про проблемы с памятью, которые у тебя были.
>За //eslint-disable-next-line на кодревью жёстко попустят.
О, наш нестодебил еще и тайпскриптодебил.
Дорогой тс-дебил, код без кодревью тебе засунет а) тот самый проверяющий, когда захочет малость поговнокодить и запушит мимо всех проверок б) он у тебя будет в сторонних библиотеках, хотя казалось бы, именно в сторонних библиотеках в первую очередь нужно иметь корректные типы параметров, а там any сидит.
Тайпскрипт - это такой же костыль для тех, кто пришел из других языков, и человеку, разбирающемуся в жс - он не нужен.
Я бы тебе мог рассказать про loose coupling и separation of concerns, удобство тестирования и моков благодаря DI, централизованное управление зависимостями, но у тебя во-первых начнётся мантра про баззворды, во-вторых у тебя походу синдром утёнка и ты привык к костылям на экспрессе, где всё делается через import, и учиться новому тебе тяжело, так что смысла становится мало. Я вот не против экспресса, если нужно простой и тупой круд шлёпнуть, или сделать бекенд на серверлесс нексте, у меня нет дурацких рамочек и ограничений.
Ты как будто исходишь из того, что бекенд на ноде это только некст, хотя некст почти всегда используется только для фронта, иногда сделают пару роутов для обработки авторизации и аутентификации, на западе иногда делают серверлесс. Но дефолтный бек на ноде это экспресс и нест, а не некст.
Я тебе как раз и расписал, как все описанные тобой задачи решаются в жс без каких либо фреймворков, всего лишь классной и современной системой импортов. Продолжай бомбить от того, что понимание этого к тебе пришло только что.
>Мам скажи им нест дефектный ну мам правда
Нестодебил продолжает продавать нам ноунейм-фреимворк от своих протыков из Твиттера
Ах да, скоро ты еще узнаешь, что в жабе ближайших версий тоже все это будет, и твоя жопа сгорит, когда ты поймешь, что в жс это было много лет, а ты ел говно.
>А в чем проблема-то? Он выполняет свою задачу. Берешь любую библиотеку и решаешь свою задачу и она работает с экспрессом как влитая. Захотел - поменял. Поменялась задача - поменял на другую.
>Тогда как со своим all-in-one фреймворком ты привязан к нему навсегда.
На экспрессе нужно костыли писать чтобы нормально сделать работу с БД, с реббитом или кафкой, с валидацией, с кронами, с обработкой ошибок, со сваггером, с кешированием, с загрузкой файлов и минио/s3, с событиями, с вебсокетами, с логированием... И какие библиотеки тебе нужно часто менять, ORMки/квери билдеры? Логгеры?
>Окей, но, сука, почему ты тогда приписываешь это ЭКСПРЕССУ
Потому что экспресс не предоставляет функционал и любям на каждом проекте приходится писать костыли и велосипеды для функциаонала, который я перечислил выше. Это характерно дл проектов на экспрессе.
>Почему проекты должны выглядеть одинаково? Они разные, блять.
Потому что это очень удобно. Пришёл на новый проект и всё организовано просто, понятно, и привычно, онбординг быстрый и без напряга, не нужно разбираться в бесконечных костылях как на экспрессе, достаточно разобраться только в самой бизнес-логике.
>О, наш нестодебил еще и тайпскриптодебил.
Динамикодриснявая макака, ты пишешь бекенд на экспрессе, да ещё и на чистом жс? Не верю, что ты работаешь где-либо кроме как тир 3 галеры, куда нормальных людей не берут, только вот таких вчерашних верстальщиков, хз как попавших в бекенд.
>запушит мимо всех проверок
Не запушит, ему его начальство насуёт за это и остальная команда тоже.
>он у тебя будет в сторонних библиотеках
Это проблема сторонник бибилотек, но вообще большинство необходимых библиотек отлично типизированы.
Нет, я ответил человеку, который именно про некст спорит, и в нексте как и в экспрессе нихуя для бекенда нету по сути, голый роутинг да и только.
> Динамикодриснявая макака
>Не запушит, ему его начальство насуёт
> тир 3 галеры
Тайпскриптодебилы - это такие блаженные существа, которые всегда рассказывают про идеальные проекты, идеально типизированные типами которые идеально написаны идеально без единого any, но в природе таких еще никто не встречал.
>Вот именно во всех них и используется бекенд на ноде
>всех
>неможет показать ни одного
Ясно, это узел явасценарий-программист порвался, тащите следующего.
>>287713
>Джавист пришёл и говорит, что в ноде нет конвенций.
1) "джавист" - это я
2) я фронтендер
>Пусть скажет названия конвенций, которых ему не хватает в ноде и которые есть в джаве.
Начнем с первого. Конвенция принудительной фулл тайм статической типизации. Такая конвенция в ноде есть?
>Я конкретно про нест говорю. В нексте ничего кроме роутинга нету.
КАК?!! А ПАПОЧКА /api?!?!?!?!?!? ТЫ ЧЕ ПЕС!!!111
>Строгий tsconfig. За //eslint-disable-next-line на кодревью жёстко попустят.
Каком код ревью, кто опустит? Ты пришел лидить проект с одним челиком на поддержке, которому этот кал пилил с двумя аутсорсерами. Никакого код ревью там в помине не было, там блять плагинов еслинта не было, ало. Тебе нужно пофиксить ряд критических фич. Ты открываешь таск на выгрузку в эксель, и видишь код function buildXlsx(items: any[]). Проекту 2 года. В проекте 50к SLOC. Твои действия?
>Я преимущественно typeorm и prisma использую, проблем с памятью из-за них не было.
Потому что у тебя бд из 10 таблиц с двумя реляциями и запросы уровня SELET * FROM products WHERE hui=pisya. У у меня 34 коллекции, 250 таблиц и и 200+ реляций. И запросы уровня
>общее табличное выражение с несколькими таблицами подзапросов с оконными функциями с офсетами в финальном запросе?
>При чём тут версталы? Речь про бекендеров.
>Я этого не придумывал, это твои слова. Давай проследим цепочку диалога. Ты начал с того, что бэкэнд будет писаться на нексте. Я логичным образом уточнил, как будет осуществляться работа с базой данных, на что ты ответил, что SQL код будет писаться на сервере версталой либо бэкэндером. От сюда вытекает два вопроса, первый из которых я задавать тогда не стал, но задам сейчас
Не понимаю, почему мне приходится литералли все повторять по два раза.
Чел, плиз...
>Сначала поделись конкретикой про проблемы с памятью, которые у тебя были.
Какой конкретикой, мне сюда дампы с прода принести или что? Я тебе только что обрисовал ситуацию на словах, накидал ссылок в гугле, ты, вместо того, чтобы идти обсыхать после уринотерапии, продолжаешь вскукареки про отсутствие оных.
>Вот именно во всех них и используется бекенд на ноде
>всех
>неможет показать ни одного
Ясно, это узел явасценарий-программист порвался, тащите следующего.
>>287713
>Джавист пришёл и говорит, что в ноде нет конвенций.
1) "джавист" - это я
2) я фронтендер
>Пусть скажет названия конвенций, которых ему не хватает в ноде и которые есть в джаве.
Начнем с первого. Конвенция принудительной фулл тайм статической типизации. Такая конвенция в ноде есть?
>Я конкретно про нест говорю. В нексте ничего кроме роутинга нету.
КАК?!! А ПАПОЧКА /api?!?!?!?!?!? ТЫ ЧЕ ПЕС!!!111
>Строгий tsconfig. За //eslint-disable-next-line на кодревью жёстко попустят.
Каком код ревью, кто опустит? Ты пришел лидить проект с одним челиком на поддержке, которому этот кал пилил с двумя аутсорсерами. Никакого код ревью там в помине не было, там блять плагинов еслинта не было, ало. Тебе нужно пофиксить ряд критических фич. Ты открываешь таск на выгрузку в эксель, и видишь код function buildXlsx(items: any[]). Проекту 2 года. В проекте 50к SLOC. Твои действия?
>Я преимущественно typeorm и prisma использую, проблем с памятью из-за них не было.
Потому что у тебя бд из 10 таблиц с двумя реляциями и запросы уровня SELET * FROM products WHERE hui=pisya. У у меня 34 коллекции, 250 таблиц и и 200+ реляций. И запросы уровня
>общее табличное выражение с несколькими таблицами подзапросов с оконными функциями с офсетами в финальном запросе?
>При чём тут версталы? Речь про бекендеров.
>Я этого не придумывал, это твои слова. Давай проследим цепочку диалога. Ты начал с того, что бэкэнд будет писаться на нексте. Я логичным образом уточнил, как будет осуществляться работа с базой данных, на что ты ответил, что SQL код будет писаться на сервере версталой либо бэкэндером. От сюда вытекает два вопроса, первый из которых я задавать тогда не стал, но задам сейчас
Не понимаю, почему мне приходится литералли все повторять по два раза.
Чел, плиз...
>Сначала поделись конкретикой про проблемы с памятью, которые у тебя были.
Какой конкретикой, мне сюда дампы с прода принести или что? Я тебе только что обрисовал ситуацию на словах, накидал ссылок в гугле, ты, вместо того, чтобы идти обсыхать после уринотерапии, продолжаешь вскукареки про отсутствие оных.
Откуда же тогда ты притащил ioc/di-дрисню? дотнетоопущенец, выходит? Там такая же проблема с импортами, там тоже приходится жрать говно, верно. Вот в какой версии починят - не знаю, но знаю, что ты будешь рад
>>всех
FAANG - это пять компаний, какую букву тебе раскрыть? Все пять компаний активно используют ноду во всех новых проектах минимум с 2013 года
>Ты как будто исходишь из того, что бекенд на ноде это только некст
Так мне нексто-протык продает бэкенд на нексте. Вот я и пытаюсь понять преимущества этого велосипеда.
>>287729
>Не запушит, ему его начальство насуёт за это и остальная команда тоже.
Начальству строго похуй на твои типы, ему надо, чтобы таски на доске вправо ехали
В моём проекте нет ни одного any. Динамикодриснявой макаке из тир 3 галеры на понять, ей даже сложно это представить, и тем более сложно представить грамотную организацию процесса командной разработки.
>>287739
Нет, на дотнете тоже не писал. В несте я впервые столкнулся с ioc/di-годнотой, до этого писал на экспрессе, фастифае и много на го.
>Так мне нексто-протык продает бэкенд на нексте. Вот я и пытаюсь понять преимущества этого велосипеда.
Бекенд на нексте это смешно, кроме разве что отдельных случаев с серверлесс. Но всё равно адеюсь, никогда не столкнусь с этим снова.
>Начальству строго похуй на твои типы, ему надо, чтобы таски на доске вправо ехали
В галере с потогонкой может быть. В тир 1 команиях тоже надо чтобы было быстро, но там обычно работают сильные инженеры, которые быстро делают таски и тайпскрипт им в этом не мешает, а часто даже помогает избежать множества проблем, из-за которых потом время на таски потенциально умножилось бы в несколько раз.
>экспресс не предоставляет кривые самодельные на коленке либы для какого-либо функционала, и люди на каждом проекте используют проверенные годами nodejs-библиотеки, не прибитые гвоздями к кривому фреймворку
Исправил этого любителя пакетиков 10-in-1
> Пришёл на новый проект и всё организовано просто, понятно, и привычно
Я даже не против, если ты начнешь пользовать какой-то другой 10-in-1 пакетик, у меня претензии в первую очередь к контроллерам с декораторами и остальной ioc/di-параше. Я утверждаю, что говенность и основная проблема именно в ней.
>Начнем с первого. Конвенция принудительной фулл тайм статической типизации. Такая конвенция в ноде есть?
Есть, и на фронтенде тоже, на чистом жс пишут только маргиналы и отщепенцы, либо совсем мелкие проекты, либо пет-проекты (хотя тут тоже у кого ни глянь - тайпскрипт).
>Ты пришел лидить проект с одним челиком на поддержке, которому этот кал пилил с двумя аутсорсерами
Я в такой аутсорс-конюшне не работаю и никому не советую, там получатели получки и стажа сидят, а не инженеры. Чтобы еслинта не было в проекте это вообще неслыханно. В том же несте он есть по дефолту из коробки, даже экспресс-макаки обычно его подключают.
>у меня 34 коллекции, 250 таблиц и и 200+ реляций. И запросы уровня
>общее табличное выражение с несколькими таблицами подзапросов с оконными функциями с офсетами в финальном запросе
Не вижу проблемы, ORM предоставляет квери билдер либо вообще возможность писать raw sql.
>Я этого не придумывал, это твои слова. Давай проследим цепочку диалога. Ты начал с того, что бэкэнд будет писаться на нексте
Это другой чел, это динамикодриснявая экспресс-макака, которой ещё и закономерным образом нравится идея писать бекенд на нексте.
>Какой конкретикой, мне сюда дампы с прода принести или что? Я тебе только что обрисовал ситуацию на словах, накидал ссылок в гугле, ты, вместо того, чтобы идти обсыхать после уринотерапии, продолжаешь вскукареки про отсутствие оных.
Каких ссылок, ты только сказал, что у вас прод падал из-за OOM, которых происходил из-за кнекса.
>FAANG - это пять компаний, какую букву тебе раскрыть?
Любую на твой выбор. Я тебе разрешаю даже другие конторы брать, например Microsoft. Неси мне проект микрософта с бэкэндом на нексте, жду.
>Все пять компаний активно используют ноду во всех новых проектах минимум с 2013 года
В каком соотношении?
>В несте я впервые столкнулся с ioc/di-годнотой
Ебало этого любителя Банды Четырех представили?
Это примерно как любитель СССР 2010 года рождения.
>Исправил этого любителя пакетиков 10-in-1
В несте как раз из коробки используются те самые проверенные годами nodejs-библиотеки, только ещё и с качественной обёрткой. В экспрессе ты эту обёртку васянишь сам.
Что не так с контроллерами? Они не сильно отличаются от экспрессовских. Декораторы тоже не сильно меняют картину, они просто изолируют функционал, который в экспрессе выносится в функции и накидывается огромным скопом через запятую в хенделы роутов.
Я не строгий приверженец этого подхода, мне и на фастифае нормально, и на гошке, лишь бы не васянись каждый раз костыли и велосипеды, и не сталкиваться с этими васянскими поделями в каждом очередном проекте на экспрессе.
>В каком соотношении?
Если все новые проекты на ноде, а новых проектов на "классических бекендах" ноль, это какое отношение, бесконечность? Окей, стремится к бесконечности. Допускаю, что один из тебе подобных пенсионеров сумел протолкнуть необходимость легаси-говна воспользовавшись служебным положением. В любом случае - отношение с каждым годом стремится к бесконечности.
> В моём проекте нет ни одного any
Есть только некорректные типы, да. Ну кого ты наебать-то хочешь, тс-дебил?
> сильные инженеры, которые быстро делают таски и тайпскрипт им в этом не мешает, а часто даже помогает
В голос верещал полчаса, как бешеный.
ТС-дебил, а знаешь что еще помогает решению тасков? Знание жс и правил приведения типов в нем. Помогает очень, сокращает в 10 раз время разработки по сравнению с долбоебами, которые занимаются написанием системы типов вместо решения задач.
>Есть, и на фронтенде тоже, на чистом жс пишут только маргиналы и отщепенцы
Ну то есть большинство нодо-макак. Пик 1.
>Я в такой аутсорс-конюшне не работаю и никому не советую, там получатели получки и стажа сидят, а не инженеры.
Нет, контора нормальная, просто на проект временно брали двух аутсорсеров, которые наговнякали, пока за ними не было присмотра.
>Чтобы еслинта не было в проекте это вообще неслыханно.
Он был, не было плагинов @typescript плагина, представь себе.
>В том же несте он есть по дефолту из коробки, даже экспресс-макаки обычно его подключают.
А некст джс макаки - нет.
>Не вижу проблемы, ORM предоставляет квери билдер либо вообще возможность писать raw sql.
Так и не тебе вопрос изначально, а нексто-додику, который меня уверяет, что реакто-макака напишет запрос с оконными функциями.
>Это другой чел, это динамикодриснявая экспресс-макака, которой ещё и закономерным образом нравится идея писать бекенд на нексте.
Тот челик просто сказочный петух.
>Каких ссылок, ты только сказал, что у вас прод падал из-за OOM, которых происходил из-за кнекса.
У тебя сущность с большим количеством реляций, у которых свои реляции. Делаешь популейт, чуть вырастает рпс, под падает с
Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call?
directed by Robert Weide
>Если все новые проекты на ноде, а новых проектов на "классических бекендах" ноль, это какое отношение, бесконечность?
Если все новые проекты на ноде - это тебе, сынок, продали какого-то уж очень отборного копиума.
И да, я все еще жажду увидеть хоть один. Или ты пиздобол?
>Что не так с контроллерами? Они не сильно отличаются от экспрессовских
В экспрессе нет никаких контроллеров и нет никаких оберток, которые надо "васянить", просто подключаешь любую библиотеку и все, она работает.
> накидывается огромным скопом через запятую в хенделы роутов.
Это зачем? Я еще раз напоминаю - просто импортируй функцию, ничего писать не надо.
В несте кроме мвс и сервисов с ди есть котексты, есть скоупы, есть способ свой скоуп запилить, в котором зависимости в контейнере будут билдится по другой логике. Потому что проблема зависимостей делегирована специальному коду, а не ad hoc делается. Пример есть в той же документации неста c мультитенантами. https://docs.nestjs.com/fundamentals/injection-scopes#durable-providers
В велосипеде если тебе понадобятся не статические зависимости а зависящие от реквеста, или даже реквеста в определенном контексте, например реквестов в одном тенанте, ты будешь свои костыли городить.
С более общей точки зрения нельзя инжектирование зависимостей заменить простым импортом. Зависимости надо инициализировать и они не всегда инициализирутся статически при импорте.
1) Тебе придется логику инициализации и выполнять в каждом файле куда ты импортируешь зависимость как функцию от начальных значений
2) Каскадность этого эффекта, потому что у зависимостей тоже могут быть зависимости которые надо инициализировать.
То есть вместо импорта объекта, ты будешь импортировать функции из размных модулей и делать их композицию с новыми значениями аргументов. При простом импорте без изобретения своего внедрения зависимостей ты будешь таскать ворох функций - композиций этих импртируемых функций и подставлять начальные значения
В нормальном DI это решается фабриками (фабрики в самом DI)
Вот конкретный пример нормального DI. Смотри на список фич. https://inversify.io/
Например https://github.com/inversify/InversifyJS/blob/master/wiki/tagged_bindings.md
Как это ты реализуешь простым импортом?
Ты не увидишь хоть один, потому что ты закрыл глаза и надеешься что Оно исчезнет. Никуда с 2013 года оно не исчезает, а стремится к бесконечности, ты можешь изучить вопрос самостоятельно, и убедиться в этом без какой-либо посторонней помощи. А аппелировать к авторитету - это ложный аргумент демагогии, стыдно, в твоем предпенсионном возрасте этого не знать, милок.
Кажется, здесь навоняло Бандой Четырех, проветрите помещение, плиз
> В несте кроме мвс и сервисов с ди есть котексты, есть скоупы, есть способ свой скоуп запилить, в котором зависимости в контейнере будут билдится по другой логике.
Вот только в реальной жизни ни один GoF-дурачок это не использует, но он дрочит на это всю жизнь, ведь когда-нибудь он точно попадет на Настоящий Проект. В котором сделано Все По Уму.
В итоге же все заканчивается моками в тестах
В нексте серверная функция с пропсами связана, как ЭТО ДРУГОЕ? https://nextjs.org/docs/pages/building-your-application/data-fetching/get-server-side-props
>Где зафиксировано что это - современная разработка?
В России во многих крупных компаниях используют ноду
С какими же именно пропсами клиентского компонента она связана? Правильно, ни с какими, ей просто надо вернуть данные в props, соглашение такое. А клиентская функция - по этим данным рисует отображение, то есть и логика, и данные, и отображение - абсолютно и полностью разделены и перемешать их никак не получится. Ты зря пересрался, увидев их в одном файле.
Ты пилишь срмку, кабаныч хочет чтобы у каждого клиента была своя БД. В B2B клиентами являются другие компании, а не отдельные пользователи этой CRM. Что тут необычного? Строить все зависимости в жирной срмке для каждого запроса нода загнется. Так как зависимости отличаются не от запроса к запросу, от выбранной БД, то ты создаешь несколько DI контейнеров по количеству тенантов. Фича в том что это почти никак не влияет на код приложения, он об этом ничего не знает, потому что задача инициалиализации зависимостей абстрагирована и делегирована в специальный код
Конечно же, нормальный код об этом не знает, это же статический конфиг твоего "тенената", а вот gof-говнокоду придется знать, ведь импортировать конфиг он не может.
>Есть только некорректные типы, да. Ну кого ты наебать-то хочешь, тс-дебил?
Классическое врёти. Ясно.
>ТС-дебил, а знаешь что еще помогает решению тасков? Знание жс и правил приведения типов в нем. Помогает очень, сокращает в 10 раз время разработки по сравнению с долбоебами, которые занимаются написанием системы типов вместо решения задач.
Разработка большого проекта на чистом жс занимает больше времени потому что без типизации динамикодэбилы потратят больше времени на дебаггинг, чем инженеры в проекте с тс на типизацию.
>Ну то есть большинство нодо-макак. Пик 1.
Как ты из пик 1 сделал вывод, что большинство пишет на чистом жс? За последние лет 5 я не видел ни одного проекта в коммерческой разработке, который был бы без тайпскрипта. Алсо зачем ты древнее говно мамонта в виде кнекса принёс? Вот самые актуальные, все на тайпскрипте:
https://github.com/prisma/prisma
https://github.com/typeorm/typeorm
https://github.com/mikro-orm/mikro-orm
https://github.com/drizzle-team/drizzle-orm
https://github.com/kysely-org/kysely
>А некст джс макаки - нет.
Неправда, даже у них есть eslint в дефолтном аппе из npx create-next-app.
>У тебя сущность с большим количеством реляций, у которых свои реляции. Делаешь популейт, чуть вырастает рпс, под падает с
Не использовать knex и вообще иногда привыкать писать raw sql.
Об этом знает только DI пример из доков неста. И там прстой пример из одного метода как с этим работать. Ты еще будешь отрицать полезность абстракций. Как с таким спорить - ХЗ
>В экспрессе нет никаких контроллеров
Есть, просто экспресс-макаки их так не называют.
>нет никаких оберток, которые надо "васянить", просто подключаешь любую библиотеку и все, она работает.
О, толстота пошла. Я видел какое спагетти вы пишете чтобы нормально настроить работу вебсокетов, или кронджобы, или кафку, можно продолжать бесконечно.
GoF-дристня - это не абстракции, это костыли из-за отсутствия нормальной системы модулей и импортов в языке, напомню еще раз.
Много лет был тренд на толстый ui в одном по сути скомпилипованном жс
Сейчас вроде как докатилось до того что решили от этого отказаться, я так понимаю что современные js фреймворки умеют, например, рендерить реакт на сервере и оживлять его по ходу дела.
А что делают те, кто использует не жс фреймворки на сервере? Проблемы то никуда не ушли, и create-react-app депрекейтед. Просто vite используют и мирятся с компиляцией-загрузкой большого жс куска говна?
>Просто vite используют и мирятся с компиляцией-загрузкой большого жс куска говна
Не мирятся, деление большого куска говна на чанки была придумана еще задолго до vite и даже самого рякта
виляет жопой и боится ответить на вопрос. Я в ахуе. Кормите его ещё.
>>287608
Ты должен понимать зачем это тащишь.
Из очевидных минусов:
- нужно знать раст
- нативные вебвью могут давать разный результат в разном окружении (да, электрон тебя этой проблемы лишает, так как везде будет хромиум)
Плюсы:
- бэкенд на расте, который полноценно компилится в нативку
- размер бандла
- выигрыш и по памяти
Пересадить макаку на электрон проще, будет писать там на том же JS/TS.
Есть ещё секьюрные аспекты, но это уже погуглишь сам, если большой мальчик.
мимо
сРаст пропаганда. Раст - это секта, которая, подкармливаясь деньгами Мозилы, пиарит любое говно
Ого, адекват в треде
>есть массив строк
>Но элемент может быть не только строкой
У тебя через предложение баг в тексте
>Если элемент не строка - верни false\
А если элемент объект? А если массив строк? Библиоткека должна предугадывать каждый твой пук что ли? Нет, напридумывал - пиши сам. Заводи цикл и проходись по массиву, как мужик. TS тут не при чём
Я, кстати даунам объяснял, что сегодня не надо делать серверный рендеринг для основного приложения. Надо делать приложение, а отдельно делать для поисковиков страницы с текстом для индексации, которые будут вести в приложение. А то, получается вы для того, чтобы угодить Яндексу тащие в приложение кучу ненужного мусора. Смотрите, как делает телега. Есть приложение телеги - которое статика, и никак не индексируется. А есть куча сайтов, на которых можно прочитать посты из телеги, полученные через API, они индексируются и ведут в саму телегу. Таким образом приложение остаётся незамусорреным и задача индексации решается даже лучше и меньшими усилиями
SSR - это отзвук PHP разработки. Это, как буд-то вы надели чисты трусы на обосранную жопу
>create-react-app
>vite
Да разберитесь уже с вебпаком один раз. Хватит говно кушать. Там под капотом всёравно он
>докатилось до того что решили от этого отказаться
Никто ничего не решал. Просто менеджеры сделали пок-пок, надо индексацию в браузере. Програмисты сделали йес-сир, и пошли за черпаком к чану с говном. Ты слишком хорошего мнения о людях и интелекте индустрии в целом
Ты таких не видел? Значит таких не существует?
>SSR - это отзвук PHP разработки. Это, как буд-то вы надели чисты трусы на обосранную жопу
Обосранная жопа это когда без жс сайт не грузится.
Первым делом должен быть контент, а уже потом свистоперделки.
SSR не нужен только там, где человек создаёт контент, а не читает.
Например онлайн редакторы всякой херни, панельки с кучей функционала, прочее говно.
На сайтах типа реддита, идеальный UX это когда страница загрузилась и больше ничего не происходит. Ты уверен в том что теперь можно спокойно читать, сохранять, переходить на другие страницы и возвращаться назад - и с контентом ничего не произойдёт.
Нет. Увеличивает. Думай, почему
Я устал уже тут объяснять в предыдущем треде, у меня ещё свои дела есть. Хочу, чтобы вы тоже включили мозг
>Обосранная жопа это когда без жс сайт не грузится.
Нет. Меньше одного процента, если не считать ботов, не пользуются JS - это мои данные за 2015. С тех пор я не интересовался этой темой, так как она для меня стала закрыта. Ты тащишь тезисы из начала двухтысячных, кода с JS в браузере действительно были проблемы
>SSR не нужен только там, где человек создаёт контент, а не читает
Нет. Он не нужен везде, кроме поисковиков
>На сайтах типа реддита, идеальный UX это когда страница загрузилась и больше ничего не происходит. Ты уверен в том что теперь можно спокойно читать, сохранять, переходить на другие страницы и возвращаться назад - и с контентом ничего не произойдёт
Да, это самое кайфовое. Поэтому я и предлагаю не использовать SSR, точнее использовать его для отдельного приложения, которое скармливается поисковику, потому, что поисковики тупые и до сих пор работают с интренетом, как с текстом
Почему вы не хотите думать? Попробуйте прочитать моё сообщение не как тролинг или отрицание, а как задачку. А как сделать так, чтобы и SSR не было, и всё, что ты описываешь было, да ещё и лучше
>Почему вы не хотите думать?
Наверно потому что сейчас любой уважающий себя фреймворк поддерживает сср из коробки и делать нихуя не надо, всё и так работает.
>поддерживает сср из коробки
В хететепе запросах специальный хедер добавляет
X-SSR: Proletarians of all countries unite
Нет, идиот. SSR никак не решает проблему, которую ты обозначил. Было сказано это:
>На сайтах типа реддита, идеальный UX это когда страница загрузилась и больше ничего не происходит. Ты уверен в том что теперь можно спокойно читать, сохранять, переходить на другие страницы и возвращаться назад - и с контентом ничего не произойдёт
SSR не решает эту проблему. То есть ты даже на вопрос, почему ты не хочешь думать, отвечаешь, что там какой-то фреймворк за тебя всё решил изкаропки, хотя ничего он не решил. Охуеть, диалоги. То есть ты даже на 1 вопрос не можешь дать ответ
Тебе какая сука разница?
Ишач сука нах если хочешь связать жить с айти отдыха не будет, учи все языки все фреймворки все что есть
>SSR не решает эту проблему
Схуяли.
>То есть ты даже на 1 вопрос не можешь дать ответ
Потому что я тупой. Мне поебать, главное что пишу код на жс деньги платят, а за ответы на вопросы не платят. В общем - тупой, но логичный.
>пользак смотрит на пустой экран дольше
>зато бесполезная циферка FCP меньше
>пользак качает бандл SPA и пустую html
>фууу ну и хуйня
>пользак качает тот же бандл SPA и сгенерированную html
>вот это заебись
>пользак смотрит на пустой экран дольше
Наоборот меньше, дольше при CSR
>зато бесполезная циферка FCP меньше
Она полезная
>пользак качает бандл SPA и пустую html
И смотрит на пустой экран дольше
>пользак качает тот же бандл SPA и сгенерированную html
И быстрее получает контент на странице, меньше смотрит на пустой экран
>SSR уменьшает first contentful paint
Нет. Ты вообще не хочешь думать
>>288418
>пользак смотрит на пустой экран дольше
>зато бесполезная циферка FCP меньше
Да, лол. В целом логика верная, но FCP с SSR больше, а не меньше
Почему вы не хотите думать?
Что, такое First Contentful Paint - это говно для идиотов. Почему? Да потому, что есть в мире реальные метрики - время проведённое пользователем на сайте, деньги и т.д. Реальные метрики всегда максимально понятны, и чётко, как Кама Пуля, отвечают на вопросы, зачем они нужны. First Contentful Paint не обладает этими свойствами - ты не скажешь, как эта метрика влияет на доход, и зачем ты её меряешь, кроме того, что посоны из гугла сказали, что это важно, и надо у них зелёную галочку на сайте получить. Но даже в этой бессмысленной метрике, то, что делаю, я лучше
Давайте посмотрим определение с сайта developer.chrome.com: "FCP measures how long it takes the browser to render the first piece of DOM content after a user navigates to your page". Другими словами - это время, до отображения первых HTML элементов
Теперь смотрите за руками. Я делаю SPA. Показываю минимальный статический HTML с прелоадером и плейсхолдерами и справочной информацией, чтобы пользователь не скучал, потом асинхронно гружу основной JS - при первой загрузке мой FCP близок к минимально возможному - PageSpeed Insights грит малаца. При повторной загрузке у пользователя уже закеширован HTML, JS и полученный по API контент в IndexedDB - FCP близок к нулю. Твой же подход подразумевает пердолинг сервера КАЖДЫЙ раз, когда пользователь открывает страницу, и на странице с большим количеством контента ты будешь плакать, и жаловаться, что у тебя декотаторы фремворка пожрали все ресурсы. Далее, когда у меня пользователь ходит по экранам - FCP равен нулю. Когда у тебя пользователь ходит по страницам - каждый раз пердолится сервер. Моё решение с экранами работает даже без интернета, твоё - нет, если пользователь пытается открыть страницу, которую не посещал
Но самое главное, зачем? Зачем? Во имя чего? Какой злой рок движет тобой? Почему, когда поисковик требует, чтобы ты выполнял его условия, ты, вместо того, чтобы сделать так, чтобы поисковик со своим устаревшим шизовосприятием интернета, как большой перелинкованной книги, от тебя отъебался, скормив ему специально сделанные для индексации болванки, как это делают приложения, и не мешал тебе делать удобный продукт, полностью морфируешь всю свою кодовую базу и сам превращаешься в гидралиска
>главное что пишу код на жс деньги платят
Обезьянку в цирке кормят за прыжки в кольцо
>SSR уменьшает first contentful paint
Нет. Ты вообще не хочешь думать
>>288418
>пользак смотрит на пустой экран дольше
>зато бесполезная циферка FCP меньше
Да, лол. В целом логика верная, но FCP с SSR больше, а не меньше
Почему вы не хотите думать?
Что, такое First Contentful Paint - это говно для идиотов. Почему? Да потому, что есть в мире реальные метрики - время проведённое пользователем на сайте, деньги и т.д. Реальные метрики всегда максимально понятны, и чётко, как Кама Пуля, отвечают на вопросы, зачем они нужны. First Contentful Paint не обладает этими свойствами - ты не скажешь, как эта метрика влияет на доход, и зачем ты её меряешь, кроме того, что посоны из гугла сказали, что это важно, и надо у них зелёную галочку на сайте получить. Но даже в этой бессмысленной метрике, то, что делаю, я лучше
Давайте посмотрим определение с сайта developer.chrome.com: "FCP measures how long it takes the browser to render the first piece of DOM content after a user navigates to your page". Другими словами - это время, до отображения первых HTML элементов
Теперь смотрите за руками. Я делаю SPA. Показываю минимальный статический HTML с прелоадером и плейсхолдерами и справочной информацией, чтобы пользователь не скучал, потом асинхронно гружу основной JS - при первой загрузке мой FCP близок к минимально возможному - PageSpeed Insights грит малаца. При повторной загрузке у пользователя уже закеширован HTML, JS и полученный по API контент в IndexedDB - FCP близок к нулю. Твой же подход подразумевает пердолинг сервера КАЖДЫЙ раз, когда пользователь открывает страницу, и на странице с большим количеством контента ты будешь плакать, и жаловаться, что у тебя декотаторы фремворка пожрали все ресурсы. Далее, когда у меня пользователь ходит по экранам - FCP равен нулю. Когда у тебя пользователь ходит по страницам - каждый раз пердолится сервер. Моё решение с экранами работает даже без интернета, твоё - нет, если пользователь пытается открыть страницу, которую не посещал
Но самое главное, зачем? Зачем? Во имя чего? Какой злой рок движет тобой? Почему, когда поисковик требует, чтобы ты выполнял его условия, ты, вместо того, чтобы сделать так, чтобы поисковик со своим устаревшим шизовосприятием интернета, как большой перелинкованной книги, от тебя отъебался, скормив ему специально сделанные для индексации болванки, как это делают приложения, и не мешал тебе делать удобный продукт, полностью морфируешь всю свою кодовую базу и сам превращаешься в гидралиска
>главное что пишу код на жс деньги платят
Обезьянку в цирке кормят за прыжки в кольцо
А я веб макак, мне платят за калопроводы
Да похуй на FCP, благодаря SSR пользователь получает HTML и CSS быстрее, чем с CSR, то есть пользователю приходитcя дольше ждать, если нету SSR, а это хуёвый UX. А ещё с CSR очень часто происходит layout shifting, это ещё более хуёвый UX.
>Твой же подход подразумевает пердолинг сервера КАЖДЫЙ раз, когда пользователь открывает страницу
>и на странице с большим количеством контента ты будешь плакать, и жаловаться, что у тебя декотаторы фремворка пожрали все ресурсы
Про SSG и ISG слышал? Про кеширование может?
>Когда у тебя пользователь ходит по страницам - каждый раз пердолится сервер
Ты на next / nuxt что-нибудь хоть раз писал? Похоже, что нет.
>Но самое главное, зачем? Зачем? Во имя чего?
Чтобы у пользователя был лучше UX, мне вообще поебать на поисковики и что там они хотят.
>А ещё с CSR очень часто происходит layout shifting, это ещё более хуёвый UX
С SSR ты хотел сказать. НА сервере у тебя нет нормальной возможности писать полноценные стили.
>Ты на next / nuxt что-нибудь хоть раз писал? Похоже, что нет
Буквально проблема некста с его серверными компонентами. Так что один дудос - и пользователь вообще никуда не зайдет, в отличии от CSR, где ты ретраями на фронте еще можешь что-то высрать.
>то есть пользователю приходитcя дольше ждать, если нету SSR
Я же выше объяснил, почему нет
>А ещё с CSR очень часто происходит layout shifting
Между этими вещами нет связи
>Твой же подход подразумевает пердолинг сервера КАЖДЫЙ раз, когда пользователь открывает страницу
>и на странице с большим количеством контента ты будешь плакать, и жаловаться, что у тебя декотаторы фремворка пожрали все ресурсы
>Про SSG и ISG слышал? Про кеширование может?
О, боги, аллахи! Кто, генерирует SSG и ISG? Папа римский? Сервер генерирует. То, что ты взял говноподход генерации того, что генерировать не нужно, а потом обмазал это кешами, снизив нагрузку на проц, и насрав в оперативку сервера, не отменяет твоей тупости. Ты всерьёз возомнил, что ты что-то знаешь, чего я не знаю?
>Ты на next / nuxt что-нибудь хоть раз писал?
Не пишу на говне. Я беру React, MOBX и uWebSocket и делаю всё, что мне нужно и отдаю это при помощи NGINX с sendfile on. В серверной части я беру C++ или express с graphql и ещё рядом билиотек, и делаю, всё, что надо. Мне не нужен мусор
>Чтобы у пользователя был лучше UX
Но он хуже. Ты пердолишь сервер, на каждой новой для пользователя странице, заставляя ждать. SPA позволяет этого не делать вообще - 0 секунд
У тебя подходы пыхи времён двухтысячных. Ты так и не стал человеком
>С SSR ты хотел сказать.
Нет, именно с CSR, потому что при CSR нужно фетчить контент с клиента, и пока происходит фетчинг, то максимум что можно сделать - отображать скелетоны с точно таким же размером, который будет у загруженного контента, но размер контента не всегда заранее известен т.к. контент бывает динамическим
>НА сервере у тебя нет нормальной возможности писать полноценные стили.
Кто ему расскажет про next / nuxt?
>>288539
>ну расскажите мне что такое SSG и ISG
Чел, загугли уже
>Я же выше объяснил, почему нет
Неправильно объяснил, при CSR нужно сделать больше работы прежде чем у юзера появится страница с HTML и CSS
>Между этими вещами нет связи
При CSR нужно фетчить контент с клиента, и пока происходит фетчинг, то максимум что можно сделать - отображать скелетоны с точно таким же размером, который будет у загруженного контента, но размер контента не всегда заранее известен т.к. контент бывает динамическим
>О, боги, аллахи! Кто, генерирует SSG и ISG? Папа римский? Сервер генерирует.
И пусть генерирует, это не вызывает большой нагрузки
>То, что ты взял говноподход генерации того, что генерировать не нужно
Нужно чтобы у пользователя быстро была готовая страница с готовым контентом
>а потом обмазал это кешами, снизив нагрузку на проц, и насрав в оперативку сервера, не отменяет твоей тупости. Ты всерьёз возомнил, что ты что-то знаешь, чего я не знаю?
Ррряяя стоимость хостинга вырастиет на 2 бакса потому что нужно больше оперативки, она ведь такая дорогая в 2024, да и кеш не обязательно ин-мемори если ты не в курсе
>Не пишу на говне
Но ты же перечислил кучу неактуального говна
>Но он хуже. Ты пердолишь сервер, на каждой новой для пользователя странице
Нет не пердолю, схуяль ты это взял мне не известно, плюс юзеру строго похуй на сервер
>заставляя ждать. SPA позволяет этого не делать вообще - 0 секунд
Заставляя ждать это когда приходится ждать пока CSR приложение на клиенте весь жс выполнит, а при SSG/SSR этого не нужно ждать
>У тебя подходы пыхи времён двухтысячных. Ты так и не стал человеком
Забавно когда такое говорят приверженцы неактуального говна
>Я же выше объяснил, почему нет
Неправильно объяснил, при CSR нужно сделать больше работы прежде чем у юзера появится страница с HTML и CSS
>Между этими вещами нет связи
При CSR нужно фетчить контент с клиента, и пока происходит фетчинг, то максимум что можно сделать - отображать скелетоны с точно таким же размером, который будет у загруженного контента, но размер контента не всегда заранее известен т.к. контент бывает динамическим
>О, боги, аллахи! Кто, генерирует SSG и ISG? Папа римский? Сервер генерирует.
И пусть генерирует, это не вызывает большой нагрузки
>То, что ты взял говноподход генерации того, что генерировать не нужно
Нужно чтобы у пользователя быстро была готовая страница с готовым контентом
>а потом обмазал это кешами, снизив нагрузку на проц, и насрав в оперативку сервера, не отменяет твоей тупости. Ты всерьёз возомнил, что ты что-то знаешь, чего я не знаю?
Ррряяя стоимость хостинга вырастиет на 2 бакса потому что нужно больше оперативки, она ведь такая дорогая в 2024, да и кеш не обязательно ин-мемори если ты не в курсе
>Не пишу на говне
Но ты же перечислил кучу неактуального говна
>Но он хуже. Ты пердолишь сервер, на каждой новой для пользователя странице
Нет не пердолю, схуяль ты это взял мне не известно, плюс юзеру строго похуй на сервер
>заставляя ждать. SPA позволяет этого не делать вообще - 0 секунд
Заставляя ждать это когда приходится ждать пока CSR приложение на клиенте весь жс выполнит, а при SSG/SSR этого не нужно ждать
>У тебя подходы пыхи времён двухтысячных. Ты так и не стал человеком
Забавно когда такое говорят приверженцы неактуального говна
>У тебя через предложение баг в тексте
Имеется в виду не элемент массива, а отдельная переменная, наличие значения которой я проверяю в массиве.
>А если элемент объект? А если массив строк?
Если не строка - значит false, значит нет такого элемента в массиве строк,
>Библиоткека должна предугадывать каждый твой пук что ли?
Что не даёт возвращать сразу false, если проверяемый элемент не совпадает по типу с типом массива?
>фетчить контент
Стань человеком, качай обновление через сокеты, хорош насиловать сервер фетчами
>пока происходит фетчинг, то максимум что можно сделать - отображать скелетоны с точно таким же размером
Нет. Ты всегда отображаешь основной интерфейс приложения. Если есть контент с прошлых заходов, то ты отображаешь его, беря из IndexedDB. Моментально. Сразу. Мнгновенно! Без запросов на сервер. Всё потому, что клиент закеширован браузером. Если контента нет, то грузишь его сразу же при старте приложения и визуализируешь процесс загрузки. При этом у тебя в SSR контент срётся в HTML теги и парсится при помощи JS, а у меня прилетает чистенький и складывается в локальную базу бысрее, чем твой HTML, так как сериализовать данные в JSON быстрее пердолинга NEXT / NUXT
Скелетоны говно. Ты правильно сказал, что ты не знаешь, какой у тебя будет контент и сколько он займёт места, поэтому скелетон не имеет смысла - это мертворождённая идея. Визуализируй процесс подгрузки контента иначе
>максимум что можно сделать - отображать скелетоны с точно таким же размером, который будет у загруженного контента, но размер контента не всегда заранее известен т.к. контент бывает динамическим
И в чем проблема? Индексаторы нормально такое поведение отрабатывают.
>Чел, загугли уже
Причем тут ISG и SSG? Ты вообще понимаешь, что некст/накст/свелткит и прочий тулинг для сср МГНОВЕННО упадет или уйдет в рейтлимитер при малейшем ддосе, в отличии от nginx'а, который в сотни тысяч раз большие RPS может переваривать на том же хосте
>Неправильно объяснил, при CSR нужно сделать больше работы прежде чем у юзера появится страница с HTML и CSS
Нет, меньше. Ты уже порядком поднадоедаешь своей тупостью. Сначала ты писал про FCP - я тебе объяснил, что FCP файковый параметр, который легко похакать, чтобы получить нужные метрики
Дальше ты начал новую шизу про то, что "Нужно чтобы у пользователя быстро была готовая страница с готовым контентом". Кому нужно, зачем это нужно, что это за метрика такая? Как это влияет на доходы, ты конечно же не сообшишь, как и в прошлый раз с FCP
Теперь ты начал ещё какую-то шизу про UX, в котором ты ничего не понимаешь, какие-то скелетоны, которые мусор
Последний раз на эту тему в треде объясняю. Веб сегодня - это не, как я упомянул, "шизовосприятие интернета, как большой перелинкованной книги", а интерактив. Нахуй мне превью видео, если я не могу сразу воспроизвести. Нахуй мне пост, если я не могу поставить лойс. Нахуй надо видеть последние сообщения, если я не могу на них отреагировать эмоджи. Нахуй мне вёрстка игры, если я не могу поиграть. Нахуй мне графики, если по ним нельзя возить курсором или пальцем. Статика - эта отрыжка веба времён PHP. Это дно. Если я не могу сразу взаимодействовать с объектом - это максимальное говно, а не UX. Поэтому показывай прелоадер, пока не готов к тапам, и прекрати слать неинтерактивное говно. Ты ещё не стал человеком
К тому же твой подход усложняет логику, увеличивает время загрузки приложения, так как один и тот же код пердолится два раза, сначала у тебя на сервере, потом качается новый HTML у меня на клиенте, а это будет происходить всегда, так как приложения интерактивны и контет всё время меняется, никакие кеши тебе не помогут, когда контент персонализирован, а потом после всего этого ешё раз исполняется JS уже на клиенте. Весь этот серверный пердолинг можно выкинуть - ты таким образом только увеличиваешь время до момента, когда можно пользоваться приложением
Всегда, когда что-то делается, существует вопрос: "Зачем". И почти всегда есть чёткие ответ. Моё зачем - это интератив, максимальная скорость работы приложения, минимум передачи данных, минимум время ожидания до возможности пользоваться приложением
Ты же хочешь наебать пользователя, выдав ему пораньше нерабочий фейк приложения, увеличив общее время загрузки, а ещё поисковики скажут, что я ты хороший, но это не точно. А думаешь ты так, потому что пропаганда говна в интернете и окружение убедили тебя, что так правильно, сам ты, конечно, ничего не анализировал. Или я плохо понял? Реагировать уже не буду.
>Неправильно объяснил, при CSR нужно сделать больше работы прежде чем у юзера появится страница с HTML и CSS
Нет, меньше. Ты уже порядком поднадоедаешь своей тупостью. Сначала ты писал про FCP - я тебе объяснил, что FCP файковый параметр, который легко похакать, чтобы получить нужные метрики
Дальше ты начал новую шизу про то, что "Нужно чтобы у пользователя быстро была готовая страница с готовым контентом". Кому нужно, зачем это нужно, что это за метрика такая? Как это влияет на доходы, ты конечно же не сообшишь, как и в прошлый раз с FCP
Теперь ты начал ещё какую-то шизу про UX, в котором ты ничего не понимаешь, какие-то скелетоны, которые мусор
Последний раз на эту тему в треде объясняю. Веб сегодня - это не, как я упомянул, "шизовосприятие интернета, как большой перелинкованной книги", а интерактив. Нахуй мне превью видео, если я не могу сразу воспроизвести. Нахуй мне пост, если я не могу поставить лойс. Нахуй надо видеть последние сообщения, если я не могу на них отреагировать эмоджи. Нахуй мне вёрстка игры, если я не могу поиграть. Нахуй мне графики, если по ним нельзя возить курсором или пальцем. Статика - эта отрыжка веба времён PHP. Это дно. Если я не могу сразу взаимодействовать с объектом - это максимальное говно, а не UX. Поэтому показывай прелоадер, пока не готов к тапам, и прекрати слать неинтерактивное говно. Ты ещё не стал человеком
К тому же твой подход усложняет логику, увеличивает время загрузки приложения, так как один и тот же код пердолится два раза, сначала у тебя на сервере, потом качается новый HTML у меня на клиенте, а это будет происходить всегда, так как приложения интерактивны и контет всё время меняется, никакие кеши тебе не помогут, когда контент персонализирован, а потом после всего этого ешё раз исполняется JS уже на клиенте. Весь этот серверный пердолинг можно выкинуть - ты таким образом только увеличиваешь время до момента, когда можно пользоваться приложением
Всегда, когда что-то делается, существует вопрос: "Зачем". И почти всегда есть чёткие ответ. Моё зачем - это интератив, максимальная скорость работы приложения, минимум передачи данных, минимум время ожидания до возможности пользоваться приложением
Ты же хочешь наебать пользователя, выдав ему пораньше нерабочий фейк приложения, увеличив общее время загрузки, а ещё поисковики скажут, что я ты хороший, но это не точно. А думаешь ты так, потому что пропаганда говна в интернете и окружение убедили тебя, что так правильно, сам ты, конечно, ничего не анализировал. Или я плохо понял? Реагировать уже не буду.
>Нужно чтобы у пользователя быстро была готовая страница с готовым контентом". Кому нужно, зачем это нужно, что это за метрика такая?
Чем быстрее приложение грузится, тем лучше, это очевидно кому угодно
>Стань человеком, качай обновление через сокеты, хорош насиловать сервер фетчами
Я тут при чем, скажи это бекенд макакам, какую апиху они отдают такую и юзаю
>Нет. Ты всегда отображаешь основной интерфейс приложения. Если есть контент с прошлых заходов, то ты отображаешь его, беря из IndexedDB. Моментально. Сразу. Мнгновенно! Без запросов на сервер. Всё потому, что клиент закеширован браузером.
С SSG контент есть ещё до первого захода
>Если контента нет, то грузишь его сразу же при старте приложения и визуализируешь процесс загрузки. При этом у тебя в SSR контент срётся в HTML теги и парсится при помощи JS, а у меня прилетает чистенький и складывается в локальную базу бысрее, чем твой HTML, так как сериализовать данные в JSON быстрее пердолинга NEXT / NUXT
Ничего не просится при помощи жс, готовый html css приходит, это намного быстрее CSR, которому нужно с помощью жс рендерить всё начиная с div#root
>Скелетоны говно. Ты правильно сказал, что ты не знаешь, какой у тебя будет контент и сколько он займёт места, поэтому скелетон не имеет смысла - это мертворождённая идея. Визуализируй процесс подгрузки контента иначе
Иногда размер известен и скелетоны уместны, уж куда лучше всех заебавших крутящихся лоадеров, которые вызывают layout shift
>>288602
>И в чем проблема? Индексаторы нормально такое поведение отрабатывают.
Layout shift, прыгают блоки по страницам
>Причем тут ISG и SSG? Ты вообще понимаешь, что некст/накст/свелткит и прочий тулинг для сср МГНОВЕННО упадет или уйдет в рейтлимитер при малейшем ддосе, в отличии от nginx'а, который в сотни тысяч раз большие RPS может переваривать на том же хосте
Не уйдёт, потому что практически все страницы отдаются именно с SSG, есть клаудфлер и аналоги. Компании с огромной аудиторией без проблем используют SSR где нужно
>>288765
>Нет, меньше. Ты уже порядком поднадоедаешь своей тупостью. Сначала ты писал про FCP - я тебе объяснил, что FCP файковый параметр, который легко похакать, чтобы получить нужные метрики
Нет, это ты надоедаешь своей тупостью, ты даже не понимаешь, почему html+ css рендерится браузером быстрее, чем рендерится обычный реакт в div#root
>Дальше ты начал новую шизу про то, что "Нужно чтобы у пользователя быстро была готовая страница с готовым контентом". Кому нужно, зачем это нужно, что это за метрика такая? Как это влияет на доходы, ты конечно же не сообшишь, как и в прошлый раз с FCP
Чем быстрее работает приложение, тем приятнее его использовать
>Теперь ты начал ещё какую-то шизу про UX, в котором ты ничего не понимаешь, какие-то скелетоны, которые мусор
Нет, ты не понимаешь, у тебя ожидание рендеринга реакт приложения через жс это нормальный UX, а потом ты прокручиваешь говноскелетоны чтобы отображать загрузка контента, в то время как некст пререндерит это в статику html + css ещё при билде и потом при ISR, то есть при авторевалидации кеша по времени / ревалидации через revalidateTag по запросу
>Последний раз на эту тему в треде объясняю. Веб сегодня - это не, как я упомянул, "шизовосприятие интернета, как большой перелинкованной книги", а интерактив. Нахуй мне превью видео, если я не могу сразу воспроизвести.
Согласен, но в нексте можно сделать одновременно и превью для сео, и чтобы видео сразу воспроизводилось
>Нахуй мне пост, если я не могу поставить лойс. Нахуй надо видеть последние сообщения, если я не могу на них отреагировать эмоджи. Нахуй мне вёрстка игры, если я не могу поиграть. Нахуй мне графики, если по ним нельзя возить курсором или пальцем. Статика - эта отрыжка веба времён PHP. Это дно. Если я не могу сразу взаимодействовать с объектом - это максимальное говно, а не UX.
Так при чём тут некст? Всё интерактивно. Гугли что такое hydration
>Поэтому показывай прелоадер, пока не готов к тапам, и прекрати слать неинтерактивное говно. Ты ещё не стал человеком
Не, пусть CSR-дебилы занимаютс этой хуетой из 2015 года
>К тому же твой подход усложняет логику, увеличивает время загрузки приложения
Усложняет логику это когда тебе фреймворк предоставляет всё готовое? Про увеличивает время загрузки ты в очередной раз выдаёшь желаемое за действительное
>так как один и тот же код пердолится два раза, сначала у тебя на сервере
Всем похуй что там на сервере. А SSG вообще при билде делается, неужели это настолько сложно для понимания
>потом качается новый HTML у меня на клиенте, а это будет происходить всегда, так как приложения интерактивны и контет всё время меняется, никакие кеши тебе не помогут, когда контент персонализирован а потом после всего этого ешё раз исполняется JS уже на клиенте. Весь этот серверный пердолинг можно выкинуть - ты таким образом только увеличиваешь время до момента, когда можно пользоваться приложением
Для персонализированного контента SSR использовать не обязательно, некст не заставляет везде делать SSR. Но часто даже для персонаизированного контента будет лучше и быстрее с SSR, потому что клиент сразу получает html + css с контентом и затем супербыструю гидратацию, а при CSR белый экран и рендеринг реакт аппа в div#root
>Всегда, когда что-то делается, существует вопрос: "Зачем". И почти всегда есть чёткие ответ. Моё зачем - это интератив, максимальная скорость работы приложения, минимум передачи данных, минимум время ожидания до возможности пользоваться приложением
Я уже сказал, чтобы у юзеров был лучше UX. Быстрее загрузка приложения, меньше лоадеров, меньше лейаут шифтинга, меньше тормозов для клиентов на слабых мобилках
>Ты же хочешь наебать пользователя, выдав ему пораньше нерабочий фейк приложения, увеличив общее время загрузки, а ещё поисковики скажут, что я ты хороший, но это не точно. А думаешь ты так, потому что пропаганда говна в интернете и окружение убедили тебя, что так правильно, сам ты, конечно, ничего не анализировал. Или я плохо понял? Реагировать уже не буду.
Ты дурачок который с самодовольным видом рассуждает о том, в чём не разбирается, тебе один раз на курсах хтмлакадемии по реакту в 2018 году вдолбили про CSR, с тех пор ты с ним носишься как утёнок, не пытаясь даже разобраться как устроены современные фронтенд инструменты в 2024
>Стань человеком, качай обновление через сокеты, хорош насиловать сервер фетчами
Я тут при чем, скажи это бекенд макакам, какую апиху они отдают такую и юзаю
>Нет. Ты всегда отображаешь основной интерфейс приложения. Если есть контент с прошлых заходов, то ты отображаешь его, беря из IndexedDB. Моментально. Сразу. Мнгновенно! Без запросов на сервер. Всё потому, что клиент закеширован браузером.
С SSG контент есть ещё до первого захода
>Если контента нет, то грузишь его сразу же при старте приложения и визуализируешь процесс загрузки. При этом у тебя в SSR контент срётся в HTML теги и парсится при помощи JS, а у меня прилетает чистенький и складывается в локальную базу бысрее, чем твой HTML, так как сериализовать данные в JSON быстрее пердолинга NEXT / NUXT
Ничего не просится при помощи жс, готовый html css приходит, это намного быстрее CSR, которому нужно с помощью жс рендерить всё начиная с div#root
>Скелетоны говно. Ты правильно сказал, что ты не знаешь, какой у тебя будет контент и сколько он займёт места, поэтому скелетон не имеет смысла - это мертворождённая идея. Визуализируй процесс подгрузки контента иначе
Иногда размер известен и скелетоны уместны, уж куда лучше всех заебавших крутящихся лоадеров, которые вызывают layout shift
>>288602
>И в чем проблема? Индексаторы нормально такое поведение отрабатывают.
Layout shift, прыгают блоки по страницам
>Причем тут ISG и SSG? Ты вообще понимаешь, что некст/накст/свелткит и прочий тулинг для сср МГНОВЕННО упадет или уйдет в рейтлимитер при малейшем ддосе, в отличии от nginx'а, который в сотни тысяч раз большие RPS может переваривать на том же хосте
Не уйдёт, потому что практически все страницы отдаются именно с SSG, есть клаудфлер и аналоги. Компании с огромной аудиторией без проблем используют SSR где нужно
>>288765
>Нет, меньше. Ты уже порядком поднадоедаешь своей тупостью. Сначала ты писал про FCP - я тебе объяснил, что FCP файковый параметр, который легко похакать, чтобы получить нужные метрики
Нет, это ты надоедаешь своей тупостью, ты даже не понимаешь, почему html+ css рендерится браузером быстрее, чем рендерится обычный реакт в div#root
>Дальше ты начал новую шизу про то, что "Нужно чтобы у пользователя быстро была готовая страница с готовым контентом". Кому нужно, зачем это нужно, что это за метрика такая? Как это влияет на доходы, ты конечно же не сообшишь, как и в прошлый раз с FCP
Чем быстрее работает приложение, тем приятнее его использовать
>Теперь ты начал ещё какую-то шизу про UX, в котором ты ничего не понимаешь, какие-то скелетоны, которые мусор
Нет, ты не понимаешь, у тебя ожидание рендеринга реакт приложения через жс это нормальный UX, а потом ты прокручиваешь говноскелетоны чтобы отображать загрузка контента, в то время как некст пререндерит это в статику html + css ещё при билде и потом при ISR, то есть при авторевалидации кеша по времени / ревалидации через revalidateTag по запросу
>Последний раз на эту тему в треде объясняю. Веб сегодня - это не, как я упомянул, "шизовосприятие интернета, как большой перелинкованной книги", а интерактив. Нахуй мне превью видео, если я не могу сразу воспроизвести.
Согласен, но в нексте можно сделать одновременно и превью для сео, и чтобы видео сразу воспроизводилось
>Нахуй мне пост, если я не могу поставить лойс. Нахуй надо видеть последние сообщения, если я не могу на них отреагировать эмоджи. Нахуй мне вёрстка игры, если я не могу поиграть. Нахуй мне графики, если по ним нельзя возить курсором или пальцем. Статика - эта отрыжка веба времён PHP. Это дно. Если я не могу сразу взаимодействовать с объектом - это максимальное говно, а не UX.
Так при чём тут некст? Всё интерактивно. Гугли что такое hydration
>Поэтому показывай прелоадер, пока не готов к тапам, и прекрати слать неинтерактивное говно. Ты ещё не стал человеком
Не, пусть CSR-дебилы занимаютс этой хуетой из 2015 года
>К тому же твой подход усложняет логику, увеличивает время загрузки приложения
Усложняет логику это когда тебе фреймворк предоставляет всё готовое? Про увеличивает время загрузки ты в очередной раз выдаёшь желаемое за действительное
>так как один и тот же код пердолится два раза, сначала у тебя на сервере
Всем похуй что там на сервере. А SSG вообще при билде делается, неужели это настолько сложно для понимания
>потом качается новый HTML у меня на клиенте, а это будет происходить всегда, так как приложения интерактивны и контет всё время меняется, никакие кеши тебе не помогут, когда контент персонализирован а потом после всего этого ешё раз исполняется JS уже на клиенте. Весь этот серверный пердолинг можно выкинуть - ты таким образом только увеличиваешь время до момента, когда можно пользоваться приложением
Для персонализированного контента SSR использовать не обязательно, некст не заставляет везде делать SSR. Но часто даже для персонаизированного контента будет лучше и быстрее с SSR, потому что клиент сразу получает html + css с контентом и затем супербыструю гидратацию, а при CSR белый экран и рендеринг реакт аппа в div#root
>Всегда, когда что-то делается, существует вопрос: "Зачем". И почти всегда есть чёткие ответ. Моё зачем - это интератив, максимальная скорость работы приложения, минимум передачи данных, минимум время ожидания до возможности пользоваться приложением
Я уже сказал, чтобы у юзеров был лучше UX. Быстрее загрузка приложения, меньше лоадеров, меньше лейаут шифтинга, меньше тормозов для клиентов на слабых мобилках
>Ты же хочешь наебать пользователя, выдав ему пораньше нерабочий фейк приложения, увеличив общее время загрузки, а ещё поисковики скажут, что я ты хороший, но это не точно. А думаешь ты так, потому что пропаганда говна в интернете и окружение убедили тебя, что так правильно, сам ты, конечно, ничего не анализировал. Или я плохо понял? Реагировать уже не буду.
Ты дурачок который с самодовольным видом рассуждает о том, в чём не разбирается, тебе один раз на курсах хтмлакадемии по реакту в 2018 году вдолбили про CSR, с тех пор ты с ним носишься как утёнок, не пытаясь даже разобраться как устроены современные фронтенд инструменты в 2024
Так у тебя не приложение грузится, а мусор, с которым ничего нельзя сделать. Вы какие-то идиоты воспринимаете кусок html за приложение
Почему у меня не масштабируется rem? я в хтмл и боду прописал фонтсайз 10, в нав прописал фонтсайз 1.4рем, но шрифт не масштабируется. Я что, один такой лох? в стаковерфлоу по рем всего 4 вопроса. Что делать?
Сайт переполнения стека мне дал ответы про просто ftp, а sftp?
У тебя же перечеркнутый базовый размер, это значит он не применен. Где-то еще ты еще переопределил, смотри стили ниже
Убрал в хтмл фонт-сайз. Все заработало (хотя и криво, придется с медиа замарачиваться). Но ради интереса вопрос оставлю. Почему это, если явно указать размер шрифта в хтмл, то рэм не будет работать (браузер сам задает размер)? Хотя в гайдах четко говорят, что нужно указать.
>Layout shift, прыгают блоки по страницам
Если у тебя корректно задан размер спиннера/скелетона, то никакого layout-shift'а не будет
>все страницы отдаются именно с SSG, есть клаудфлер и аналоги
Во первых, все страницы на SSG это явно какой-то говнопроект уровня микробложика. Во вторых, использование облачных сервисов говорит о том, что это тоже какой-то говнопроект или начинающий стартапт.
Если хост умеет в сфтп, то справится и с нжинксом.
>ряяяяя арендовать стойку это же так дорого и не по смузихлебски, давайте подключим 10 облак за 100x прайс, соединим их костылями и потом съебем и напишем какие мы охуенные разрабы?
Кто-нибудь объясните ему что такое гидратация
>>289335
>Если у тебя корректно задан размер спиннера/скелетона, то никакого layout-shift'а не будет
Если размер блока с контентом заранее неизвестен, то будут шифты, и часто размер бывает как раз неизвестен заранее
>Во первых, все страницы на SSG это явно какой-то говнопроект уровня микробложика.
Ты цитату обрезал, не все, а практически все. SSG не противоречит динамичности и интерактивности, потому что после гидратации страницы сгенеренные через SSG ничем не отличаются от обычного CSR реакта, в котором можно делать любую интерактивность. Что надо, то отдаётся с SSR, но использование SSR избегается по максимуму, самый оптимальный вариант это SSG с формированием готовых страниц при билде и с ревалидацией по запросу через revalidatePath или revalidateTag
>Во вторых, использование облачных сервисов говорит о том, что это тоже какой-то говнопроект или начинающий стартапт.
Ты рофлишь? Клаудфлер по-твоему используют говнопроекты или начинающие стартапы по-твоему? Почти у всех крупнейших проектов стоит различная защита от ддоса, скрапинга и тд, часто это именно клаудфлер
>SSG с формированием готовых страниц при билде
Т.е. опять говнобложик. Имагинировал ебало CI, когда ему придется прогонять джобу на рендеринг 1кк страниц в SSG? Которые еще и инвалидируются в процессе билда.
>Клаудфлер по-твоему используют говнопроекты или начинающие стартапы по-твоему?
У клаудфлера много сервисов. Большая часть из них смузиговно.
>различная защита от ддоса, скрапинга и тд, часто это именно клаудфлер
Это как раз вполне рабочая тема. Вот только отдавать саму страничку то будет твой сервис, а не ддос защита от кф
Формы Бекуса-Наура похоже выглядят. Теперь что их не использовать?
>Т.е. опять говнобложик
Нет, большинство приложений. Какие-нибудь маркетплейсы это небольшая часть приложений
>Имагинировал ебало CI, когда ему придется прогонять джобу на рендеринг 1кк страниц в SSG? Которые еще и инвалидируются в процессе билда.
Для этого есть ISR, можно сделать чтобы первая генерация происходила когда страницу впервые откроет первый пользователь. Статик генерация в рантайме очень быстрая, можно установить ревалидацию по времени, или опять же по запросу
https://www.youtube.com/watch?v=h2pCxj_Fkdc
В общем, я покушол и отдрхнул, поэтому моё настроение улучшилось, и я готов немного избирательно повоевать с тупняком
>SSG не противоречит динамичности и интерактивности, потому что после гидратации страницы сгенеренные через SSG ничем не отличаются от обычного CSR
Начнём с того, что ты ничего не знаешь, про UI и UX. Ничего не знаешь про разработку. Гидрируешь себе на лицо
Как ты на сервере определил, поставлен у меня плагин в браузере или нет? В зависимости от того, стоит ли метамаск или нет показывается разный контент. Также в зависимости от localStorage, в котором, например, лежит информация о том, подключен у меня кошелёк через ton-connect или нет, показывается абсолютно разный контент. Как ты это учтёшь в SSR. Также в зависимости от текущих настроек приложения, которые обычно также хранятся в localStorage показывается разное. Решение? А? М? Также контент зависит от IndexedDB. Также есть буфер запросов, куда попадает неотправленный на сервер контент, при перезагрузке страницы твой SSR его тоже проебёт, а потом подъедет, когда гидрация по губам произойдёт - ой, что это у нас, лайаут шизтинг в SSR, как же так
Это базовые вопросы, которые возникают в первый же день, когда ты начинаешь о думать о UX приложения
Далее, я объяснял, что сегодня интернет динамический, ты согласился, но, видимо, в твоём понимании - динамика - это отправить фетч запрос, иначе ты бы не продолжал свою шизу. Динамика подразумевает, что ты на сервере вообще не знаешь, запрос на какой контент прилетит от клиента, а также то, что ответы каждую секунду разные и отличаются у всех пользователей, так как пресонализация. Поэтому ни revalidatePath, ни revalidateTag не иммют смысла - они будет пердолится всегда. Кстати, само по себе наличие этих двух методов - шиза. Идиоты зачем-то обычное хранение по ключю зачем-то заделили на два метода. А что комбинация патча и типа не может быть тагом, лол, ну да ладно, решения макак не поддаются логике
>Клаудфлер по-твоему используют говнопроекты или начинающие стартапы по-твоему?
Клаудфлер использует любой бомж, у которого есть карта мир виза. Свои сервера используют только те, у кого есть компетенция. Как минимум тебе нужен инженегр и сисадмин, чтобы такое подерживать - это уже уровень выше почти всех рядовых стартапов. Любой адекватный проект держит своё железо, а проксирует запросы на него через VPS и того же Cloudflare, используя его, как прокладку. Держать данные на VPS, где васяны могут сделать с ними что угодно, можно только от тотальной глупости и нищеты. Так что другой анон всё правильно написал
Ща тут начнётся имплаинг, а чё такого ты там скрываешь. Или пуки про договор о неразглашении, мол мы данные - то мы всё таки не хотим разглашать, но не умеем это делать технически, поэтому понадеемся на закон. У меня таких разговоров были десяки, поэтому на всякий случай сообщаю дальнейшие неперспективные ветки диалога, чтобы не тратить время
В заключении своей ремарки скажу, что у тебя опять плохо с тем, чтобы быть человеком, ты мартышка, которая бегает за общественным мнением. При этом у тебя есть возможность стать человеком, потому, что видно, что ты пытаешься аргументировать, что-то читал. Но ты категорически отказываешься думать
В общем, я покушол и отдрхнул, поэтому моё настроение улучшилось, и я готов немного избирательно повоевать с тупняком
>SSG не противоречит динамичности и интерактивности, потому что после гидратации страницы сгенеренные через SSG ничем не отличаются от обычного CSR
Начнём с того, что ты ничего не знаешь, про UI и UX. Ничего не знаешь про разработку. Гидрируешь себе на лицо
Как ты на сервере определил, поставлен у меня плагин в браузере или нет? В зависимости от того, стоит ли метамаск или нет показывается разный контент. Также в зависимости от localStorage, в котором, например, лежит информация о том, подключен у меня кошелёк через ton-connect или нет, показывается абсолютно разный контент. Как ты это учтёшь в SSR. Также в зависимости от текущих настроек приложения, которые обычно также хранятся в localStorage показывается разное. Решение? А? М? Также контент зависит от IndexedDB. Также есть буфер запросов, куда попадает неотправленный на сервер контент, при перезагрузке страницы твой SSR его тоже проебёт, а потом подъедет, когда гидрация по губам произойдёт - ой, что это у нас, лайаут шизтинг в SSR, как же так
Это базовые вопросы, которые возникают в первый же день, когда ты начинаешь о думать о UX приложения
Далее, я объяснял, что сегодня интернет динамический, ты согласился, но, видимо, в твоём понимании - динамика - это отправить фетч запрос, иначе ты бы не продолжал свою шизу. Динамика подразумевает, что ты на сервере вообще не знаешь, запрос на какой контент прилетит от клиента, а также то, что ответы каждую секунду разные и отличаются у всех пользователей, так как пресонализация. Поэтому ни revalidatePath, ни revalidateTag не иммют смысла - они будет пердолится всегда. Кстати, само по себе наличие этих двух методов - шиза. Идиоты зачем-то обычное хранение по ключю зачем-то заделили на два метода. А что комбинация патча и типа не может быть тагом, лол, ну да ладно, решения макак не поддаются логике
>Клаудфлер по-твоему используют говнопроекты или начинающие стартапы по-твоему?
Клаудфлер использует любой бомж, у которого есть карта мир виза. Свои сервера используют только те, у кого есть компетенция. Как минимум тебе нужен инженегр и сисадмин, чтобы такое подерживать - это уже уровень выше почти всех рядовых стартапов. Любой адекватный проект держит своё железо, а проксирует запросы на него через VPS и того же Cloudflare, используя его, как прокладку. Держать данные на VPS, где васяны могут сделать с ними что угодно, можно только от тотальной глупости и нищеты. Так что другой анон всё правильно написал
Ща тут начнётся имплаинг, а чё такого ты там скрываешь. Или пуки про договор о неразглашении, мол мы данные - то мы всё таки не хотим разглашать, но не умеем это делать технически, поэтому понадеемся на закон. У меня таких разговоров были десяки, поэтому на всякий случай сообщаю дальнейшие неперспективные ветки диалога, чтобы не тратить время
В заключении своей ремарки скажу, что у тебя опять плохо с тем, чтобы быть человеком, ты мартышка, которая бегает за общественным мнением. При этом у тебя есть возможность стать человеком, потому, что видно, что ты пытаешься аргументировать, что-то читал. Но ты категорически отказываешься думать
Очепяток очень много. Прости меня анон, который это читает. Писал сонный
>Как ты на сервере определил, поставлен у меня плагин в браузере или нет? В зависимости от того, стоит ли метамаск или нет показывается разный контент. Также в зависимости от localStorage, в котором, например, лежит информация о том, подключен у меня кошелёк через ton-connect или нет, показывается абсолютно разный контент. Как ты это учтёшь в SSR. Также в зависимости от текущих настроек приложения, которые обычно также хранятся в localStorage показывается разное. Решение? А? М? Также контент зависит от IndexedDB.
С чего ты взял, что перечисленные вещи я собрался делать на сервере? Они делаются после гидратации страницы, отданной через SSR/SSG. Просто весь этот функционал выделяется в клиентские компоненты, которые сидят в глубине дерева компонентов
>Также есть буфер запросов, куда попадает неотправленный на сервер контент, при перезагрузке страницы твой SSR его тоже проебёт, а потом подъедет, когда гидрация по губам произойдёт - ой, что это у нас, лайаут шизтинг в SSR, как же так
Где буфер, в локалсторедже, IndexedDB? Тогда не проебётся
>Динамика подразумевает, что ты на сервере вообще не знаешь, запрос на какой контент прилетит от клиента, а также то, что ответы каждую секунду разные и отличаются у всех пользователей, так как пресонализация
Если на сервере не знаешь, то делаешь всю динамику в клиентских компонентах после гидратации как в обычном CSR реакте. Ты зачем-то отказываешься от пререндеренного хтмл при этом не получая ничего взамен
>В заключении своей ремарки скажу, что у тебя опять плохо с тем, чтобы быть человеком, ты мартышка, которая бегает за общественным мнением. При этом у тебя есть возможность стать человеком, потому, что видно, что ты пытаешься аргументировать, что-то читал. Но ты категорически отказываешься думать
Нет ты. Ты привык всё делать по-старому и не хочешь учиться новому, отказываешься понимать почему на нексте/ремиксе/астро/nuxt и тд большинство приложений будут быстрее и в целом лучше с большинства сторон.
>метамаск
Если ты работаешь как и я в крипте, то должен знать, что огромная доля проектов делается на нексте, заметно больше половины проектов
>Как ты на сервере определил, поставлен у меня плагин в браузере или нет? В зависимости от того, стоит ли метамаск или нет показывается разный контент. Также в зависимости от localStorage, в котором, например, лежит информация о том, подключен у меня кошелёк через ton-connect или нет, показывается абсолютно разный контент. Как ты это учтёшь в SSR. Также в зависимости от текущих настроек приложения, которые обычно также хранятся в localStorage показывается разное. Решение? А? М? Также контент зависит от IndexedDB.
С чего ты взял, что перечисленные вещи я собрался делать на сервере? Они делаются после гидратации страницы, отданной через SSR/SSG. Просто весь этот функционал выделяется в клиентские компоненты, которые сидят в глубине дерева компонентов
>Также есть буфер запросов, куда попадает неотправленный на сервер контент, при перезагрузке страницы твой SSR его тоже проебёт, а потом подъедет, когда гидрация по губам произойдёт - ой, что это у нас, лайаут шизтинг в SSR, как же так
Где буфер, в локалсторедже, IndexedDB? Тогда не проебётся
>Динамика подразумевает, что ты на сервере вообще не знаешь, запрос на какой контент прилетит от клиента, а также то, что ответы каждую секунду разные и отличаются у всех пользователей, так как пресонализация
Если на сервере не знаешь, то делаешь всю динамику в клиентских компонентах после гидратации как в обычном CSR реакте. Ты зачем-то отказываешься от пререндеренного хтмл при этом не получая ничего взамен
>В заключении своей ремарки скажу, что у тебя опять плохо с тем, чтобы быть человеком, ты мартышка, которая бегает за общественным мнением. При этом у тебя есть возможность стать человеком, потому, что видно, что ты пытаешься аргументировать, что-то читал. Но ты категорически отказываешься думать
Нет ты. Ты привык всё делать по-старому и не хочешь учиться новому, отказываешься понимать почему на нексте/ремиксе/астро/nuxt и тд большинство приложений будут быстрее и в целом лучше с большинства сторон.
>метамаск
Если ты работаешь как и я в крипте, то должен знать, что огромная доля проектов делается на нексте, заметно больше половины проектов
Берешь next и он все делает, как ты ему скажешь, хочешь ssg - getstaticprops, хочешь ssr - getserversideprops
>>328978
В моем случае nuxt, я хочу быть и стать вуедебилом
>он все делает, как ты ему скажешь
А мне откуда узнать что надо делать? Я вообще не понимаю этих SSR и SSG поэтому я не знаю, что мне нужно. Где можно прочитать качественную инфу про SSR и SSG, чтоб всё осознать будучи не профессором, а простым вкатудоном с Лоу ай си кью?
>С чего ты взял, что перечисленные вещи я собрался делать на сервере?
>Просто весь этот функционал выделяется в клиентские компоненты, которые сидят в глубине дерева компонентов
Так, начались мазы про клиентские компоненты. То есть проблема всё-таки существует. Часть мы отдаём статикой, часть нет. Вот, мы инпуты нарисовали, содержимое которых сохранено в локальное хранилище, но не отправлены на сервер, и при перезагрузке страницы хочется, чтобы они не сбрасывались - выносим в компоненты. Пользователь будет смотреть на экран без инпутов, а потом при гидрации они подъедут. Вот, у нас экран полностью зависит от плагина: показывать кнопку подключением кошелька или контент - в компоненты. Вот, у нас история транзакций, новые получаем с сервера, но старые берём из IndexedDB и это всё надо показать в одном списке - в компоненты. Один большой клиентский компонент. Сам факт существования клиентских компонентов тебе просто кричит, что твоя концепция нерабочая
>Где буфер, в локалсторедже, IndexedDB? Тогда не проебётся
Ты не поняВ. Я написал коммент. Коммент отправился в очередь на сохранение на сервер. Сеть отвалилась или я перезагрузил страницу - коммент в локальном хранилише есть, но сервер про него не знает. Сервер присылает мне страницу с чужими комментами без моего - а потом, когда происходит гидрация, коммент внезапно появляется, посреди других комментов, так как он существует и отправился на сервер - случается тот самый шизтинг слоя
>Ты зачем-то отказываешься от пререндеренного хтмл при этом не получая ничего взамен
Я отказываюсь от мусора, не имеющего смысла, который увеличивает кодовую базу, делает хуже UX, увеличивает время до того, как можно пользоваться приложением
>Нет ты. Ты привык всё делать по-старому и не хочешь учиться новому, отказываешься понимать почему на нексте/ремиксе/астро/nuxt и тд большинство приложений будут быстрее и в целом лучше с большинства сторон
То, что ты рассказываешь - это не новое. Сходи к PHP господам. Они тебе расскажут, что они в нулевых тебе выдавали HTML, в котором уже был нужный контент, и потом браузер подкачивал JS, и этим становилось возможно пользоваться. Поэтому я тебе сразу сообщил, что у тебя пыхаподход. Второе, я не взываю к новизне, меня интересует только то, что работает. Обрати внимание, я ни разу не апеллировал к новизне, я апеллирую к думанью
>отказываешься понимать почему на нексте/ремиксе/астро/nuxt и тд большинство приложений будут быстрее
Не будут. Я тебе сообщил. Для тебя приложение - это HTML текст. Для меня приложение - это интерактив, взаимодействие с плагинами, локальная база на гиг, сохранение действий пользователя, даже если отвалилась сеть или страница перезагружена
И ты их раб поисковиков, раб их концепции приложение = html текст, так как берёшь на вооружение инструмент, который существует, исключительно, как я тебе выше продемонстрировал, лишь для удовлетворения ленивых поисковиков. Next.js и его клоны как раз родились в период расцвета популярности React и неумений поисковиков работать с таким фронтом
Мой подход решает все проблемы и не имеет исключений, работает быстро, чётко. Твой просто пищит о том, что он говно. Я же отлично могу проследить, как мыслят макаки. Так, поисковики нас не индексируют, давайте выдавать HTML пораньше - рождается NEXT. Потом, ой, а чёт сервер тормозит - давайте кешами обмазываться. Потом, ой, а чём контент динамический, давайте пользовательские компоненты введём. Ой, пользоваться приложением нельзя с голым HTML, пока JS не загрузился - скажем, что гидрация. Каждый шаг макак - латание дыр. А потом всё это выдаётся за достижение
И мир так работает. Одни придумали херню - милилонны кушают. Петухонистам не завезли типы - рассказывают, что это ради свободы. Гошниками, растовикам и прочим не завезли исключений - рассказывают про безопасность. Криптобабуину не завезли программистов - рассказывают про скорость рендера HTML и СЕО
>Если ты работаешь как и я в крипте, то должен знать, что огромная доля проектов делается на нексте
Мне безразлично, что делают бомжи, разводя очередной Hui DAO Foundation. Ты пришёл в сферу кормиться и не хочешь думать - у меня нет претензий к этому. У меня есть претензии, когда ты на моих двачах начинаешь свой подход выдавать, как что-то стоящее. Рассказывать примитивные хаки, как какое-то знание, которое можно не осилить. Тем самым ты забираешь у анонов месяцы жизни. Они пойдут всё это учить, и кто-то, кто окажется способен делать передовой фронт, например, как делает телега, обнаружит, что он занимался хернёй. Мой посыл направлен этих людей - я хочу помочь им, как хотел бы помочь себе некоторое время назад. Даже если читающий человек неспособен в силу отсутствия опыта сам решить, кто из нас прав, он как минимум будет иметь мои слова в голове - это может его сподвигнуть пойти и разобраться
>С чего ты взял, что перечисленные вещи я собрался делать на сервере?
>Просто весь этот функционал выделяется в клиентские компоненты, которые сидят в глубине дерева компонентов
Так, начались мазы про клиентские компоненты. То есть проблема всё-таки существует. Часть мы отдаём статикой, часть нет. Вот, мы инпуты нарисовали, содержимое которых сохранено в локальное хранилище, но не отправлены на сервер, и при перезагрузке страницы хочется, чтобы они не сбрасывались - выносим в компоненты. Пользователь будет смотреть на экран без инпутов, а потом при гидрации они подъедут. Вот, у нас экран полностью зависит от плагина: показывать кнопку подключением кошелька или контент - в компоненты. Вот, у нас история транзакций, новые получаем с сервера, но старые берём из IndexedDB и это всё надо показать в одном списке - в компоненты. Один большой клиентский компонент. Сам факт существования клиентских компонентов тебе просто кричит, что твоя концепция нерабочая
>Где буфер, в локалсторедже, IndexedDB? Тогда не проебётся
Ты не поняВ. Я написал коммент. Коммент отправился в очередь на сохранение на сервер. Сеть отвалилась или я перезагрузил страницу - коммент в локальном хранилише есть, но сервер про него не знает. Сервер присылает мне страницу с чужими комментами без моего - а потом, когда происходит гидрация, коммент внезапно появляется, посреди других комментов, так как он существует и отправился на сервер - случается тот самый шизтинг слоя
>Ты зачем-то отказываешься от пререндеренного хтмл при этом не получая ничего взамен
Я отказываюсь от мусора, не имеющего смысла, который увеличивает кодовую базу, делает хуже UX, увеличивает время до того, как можно пользоваться приложением
>Нет ты. Ты привык всё делать по-старому и не хочешь учиться новому, отказываешься понимать почему на нексте/ремиксе/астро/nuxt и тд большинство приложений будут быстрее и в целом лучше с большинства сторон
То, что ты рассказываешь - это не новое. Сходи к PHP господам. Они тебе расскажут, что они в нулевых тебе выдавали HTML, в котором уже был нужный контент, и потом браузер подкачивал JS, и этим становилось возможно пользоваться. Поэтому я тебе сразу сообщил, что у тебя пыхаподход. Второе, я не взываю к новизне, меня интересует только то, что работает. Обрати внимание, я ни разу не апеллировал к новизне, я апеллирую к думанью
>отказываешься понимать почему на нексте/ремиксе/астро/nuxt и тд большинство приложений будут быстрее
Не будут. Я тебе сообщил. Для тебя приложение - это HTML текст. Для меня приложение - это интерактив, взаимодействие с плагинами, локальная база на гиг, сохранение действий пользователя, даже если отвалилась сеть или страница перезагружена
И ты их раб поисковиков, раб их концепции приложение = html текст, так как берёшь на вооружение инструмент, который существует, исключительно, как я тебе выше продемонстрировал, лишь для удовлетворения ленивых поисковиков. Next.js и его клоны как раз родились в период расцвета популярности React и неумений поисковиков работать с таким фронтом
Мой подход решает все проблемы и не имеет исключений, работает быстро, чётко. Твой просто пищит о том, что он говно. Я же отлично могу проследить, как мыслят макаки. Так, поисковики нас не индексируют, давайте выдавать HTML пораньше - рождается NEXT. Потом, ой, а чёт сервер тормозит - давайте кешами обмазываться. Потом, ой, а чём контент динамический, давайте пользовательские компоненты введём. Ой, пользоваться приложением нельзя с голым HTML, пока JS не загрузился - скажем, что гидрация. Каждый шаг макак - латание дыр. А потом всё это выдаётся за достижение
И мир так работает. Одни придумали херню - милилонны кушают. Петухонистам не завезли типы - рассказывают, что это ради свободы. Гошниками, растовикам и прочим не завезли исключений - рассказывают про безопасность. Криптобабуину не завезли программистов - рассказывают про скорость рендера HTML и СЕО
>Если ты работаешь как и я в крипте, то должен знать, что огромная доля проектов делается на нексте
Мне безразлично, что делают бомжи, разводя очередной Hui DAO Foundation. Ты пришёл в сферу кормиться и не хочешь думать - у меня нет претензий к этому. У меня есть претензии, когда ты на моих двачах начинаешь свой подход выдавать, как что-то стоящее. Рассказывать примитивные хаки, как какое-то знание, которое можно не осилить. Тем самым ты забираешь у анонов месяцы жизни. Они пойдут всё это учить, и кто-то, кто окажется способен делать передовой фронт, например, как делает телега, обнаружит, что он занимался хернёй. Мой посыл направлен этих людей - я хочу помочь им, как хотел бы помочь себе некоторое время назад. Даже если читающий человек неспособен в силу отсутствия опыта сам решить, кто из нас прав, он как минимум будет иметь мои слова в голове - это может его сподвигнуть пойти и разобраться
блять, ssg - это когда жс-компонент рендерится в статический html-файлик, лежащий на сервере. ssr - это когда он генерится динамически.
Ну потому что какая разница высрать жсончик или высрать страничку, всё равно там под капотом сто слоёв кишок
Значит у меня появилась идея переписать свой проектик с джанго рест на ноджс. Потому что я устроился таки вкатился в ойти почти уже год назад, фронтенд разрабом, почти что с нуля, ну и с тех пор только жсом (тсом точнее) и занимался, ну и вот хочу чтобы мой пет проектик был целиком на тайпскрипте.
Вопрос в чем, какую технологию лучше выбрать для написания рест апи на ноде? А то чем там много всякого. Что сейчас популярно? Нестжс норм?
Только если у тебя gof головного мозга и ты любишь обмазываться контроллерами и фабриками абстрактных синглтонов
Ну я не особо там разбираюсь во всяких этих штуках. Хочу что-нибудь такое повысокоуровневее как бы, а то я не слишком крутой погромист. Ну вот джанго мне нравился. А экспресс как я понимаю, это типа фласк, то есть самый минимум предоставляет, а для всего остального нужно самому накатывать библиотеки и придумывать структуру приложения итд.
>>290013
>нест
Ну эти штуки я вообще чет не понимаю что такое. И я на вью работаю на работе (второй версии с класс компонентами). Ну тут я буду третий использовать, постараюсь композишн освоить, но жопа подгорает конечно. Не понимаю, зачем оно нужно, если есть такие хорошие класс компоненты. А эти несты нуксты я тем более не понимаю, че это такое вообще, для чего нужно.
А обязательно обфусцировать код на клиенте?
У меня небольшой проектик, фреймворки тащить не хочу, чисто пара страниц будет, на ванилле хочу наговнокодить
Сап, /pr, есть вопросец, нужен совет.
Есть желание и время пилить пет.
Есть знание и опыт с ангуляр, некст, вуе.
Но как-то в практике с приложениями особо и не сталкивался, вообе не шарю что там происходит. Только на ангуляре с иоником пилил говно.
Что выбрать для создание приложения?
Ангуляр-Ионик, Некст-Таури, РеактНатив-Протон?
Есть другие варианты?
Приложение большое. Особой нагрузки на сервер не будет, по большей части оффлайн аппа. Серверсайд рендеринги от шайтана - не будет, юай либы тоже скорее всгео не будет, будет самописная.
На реддите пишут таури бомба, защита-хуита, билд сразу на разные ос, легкость в конфигурации, т.д.
С Иоником чет страданул когда зеленый был, страшно в него вновь лезть.
Остальное и не слышал.
Или лучше отринуть JS и перекатиться в плюсы/шарп?
А, еще электрон есть. У меня Обсидиан на нем.
Обязательно делать бандл по хэшу клиентского кода, чтобы при изменениях браузер автоматически скачивал новый, а не показывал старый из кэша
Да потому что тайпскрипт атакует саму причину, по которой JS стал популярен. Тайпскрипт скоро будет по сложности как C++, а потом MS его тихо подменит чем-нибудь попроще и попроприетарнее.
я до конца не вкуриваю, до этого тыкал пхп говно и микроскопические проекты на ноде. по ощущениям любая кодовая база ноды будет так выглядеть.
там монорепа, состоящая из кучи разных приложений, которые хуй пойми как связаны, хуй пойми за что отвечают. и экспресс и коа используют, куча самописных решений (буквально изобретают велосипед, валидация к примеру через декораторы). постоянно нарушают паттерны (где-то могут создать синглтон). я уже молчу о том что везде и всюду захардкожены 127.0.0.1 & localhost. еще есть прикол с каким-то непонятным типа-rpc, который на самом деле вебсокеты (даже не socket.io). никаких конвенций, все в куче, буквально спагетти. если бы мне доверили писать настолько большой проект, я бы написал примерно так же думаю. и это всё только то что лично я нарыл за эти две недели.
Сейчас пробежит местный экспресс-шиз и скажет тебе, что так всё и должно быть, особенно вот это:
>куча самописных решений
>буквально изобретают велосипед
На моём последнем месте работе программистов штук 20 вылетело с проекта в первые пару месяцев. Не потянули объём и "качество" кодобазы. Я и ещё два других смогли остаться. Про других не знаю, но мне очень нужна была работа, поэтому я сидел и вкуривал, пока не вкурил наконец.
Любую кодобазу можно разбить на крупные логические блоки, потом снова разбить, потом нарисовать схему и прикинуть, что было в башке у тех, кто это проектировал. Ну и общение со "старичками" на проекте тоже помогает, если есть возможность.
Но, повторяю, 90% вылетает в первые месяц-полтора, будучи брошены в большой и не очень документированный проект, так что не удивляйся, если вылетишь.
Вы создали объект, что происходит с ним в gc?
Вот, хорошая задача на понимание типов, в чате увидел:
Solution<0>; // 0
Solution<10>; // 1
Solution<42>; // 6
Solution<123>; // 6
Solution<123456>; // 3
Solution<111111111>; // 9
Solution<999999999>; // 9
Сколько по умолчанию воркерпулов открывает V8 и зачем?
Парсили в большой массив текста на предмет дубликатов строк, хеши строк сохраняли Object, случился лимит ключей, что делать?
Сколько бит занимает null, а undefined на уровне V8?
UDP в браузере, нужен ли, почему до сих пор не подвезли? Изучали ли WebRTC, QUIC?
Какие можно собрать фингерпринты о пользователе?
Event loop lag - зачем нужон, как боротся, что делать если прям очень надо что-то выполнить вовремя?
Опишите из каких компонентов будет состоять
https://dribbble.com/shots/7945236-Micro-Animation-Range-Slider
WASM, пользовались ли, чем дебажили?
Какие инструменты есть, чтобы оценить рендеринг приложения в браузере?
Какие инструменты есть, чтобы просмотреть работу вашего сайта на разных устройствах?
Как сделать так, чтобы сайтом можно было продолжать пользоваться в случает падения сети?
Почему мемоизация - это плохой путь?
Какие есть способы распараллелить код?
Есть приватники крипты на $10M, как её хранить и пользоваться с учётом того, что всё дырявое, железо, операционки, и, возможно, разработчики
Как правильно делать бэкапы? Что делать, если в данные, которые надо быкапить, быстро меняются, пробовали ли btrfs/zfs?
DNS - что знаете при сертификаты?
Накидал, немного из того, что меня интересовало, что-то меня спрашивали. Вопросы дискуссионные, придумываются на ходу, что-то из практики, по ответам и их глубине можно понять интересы. Стандартные вопросы по синтаксису языка спрашивать про промисы, замыкания, хуки в реакте, базы и тому подобное спрашивать максимально неинтересно
Вы создали объект, что происходит с ним в gc?
Вот, хорошая задача на понимание типов, в чате увидел:
Solution<0>; // 0
Solution<10>; // 1
Solution<42>; // 6
Solution<123>; // 6
Solution<123456>; // 3
Solution<111111111>; // 9
Solution<999999999>; // 9
Сколько по умолчанию воркерпулов открывает V8 и зачем?
Парсили в большой массив текста на предмет дубликатов строк, хеши строк сохраняли Object, случился лимит ключей, что делать?
Сколько бит занимает null, а undefined на уровне V8?
UDP в браузере, нужен ли, почему до сих пор не подвезли? Изучали ли WebRTC, QUIC?
Какие можно собрать фингерпринты о пользователе?
Event loop lag - зачем нужон, как боротся, что делать если прям очень надо что-то выполнить вовремя?
Опишите из каких компонентов будет состоять
https://dribbble.com/shots/7945236-Micro-Animation-Range-Slider
WASM, пользовались ли, чем дебажили?
Какие инструменты есть, чтобы оценить рендеринг приложения в браузере?
Какие инструменты есть, чтобы просмотреть работу вашего сайта на разных устройствах?
Как сделать так, чтобы сайтом можно было продолжать пользоваться в случает падения сети?
Почему мемоизация - это плохой путь?
Какие есть способы распараллелить код?
Есть приватники крипты на $10M, как её хранить и пользоваться с учётом того, что всё дырявое, железо, операционки, и, возможно, разработчики
Как правильно делать бэкапы? Что делать, если в данные, которые надо быкапить, быстро меняются, пробовали ли btrfs/zfs?
DNS - что знаете при сертификаты?
Накидал, немного из того, что меня интересовало, что-то меня спрашивали. Вопросы дискуссионные, придумываются на ходу, что-то из практики, по ответам и их глубине можно понять интересы. Стандартные вопросы по синтаксису языка спрашивать про промисы, замыкания, хуки в реакте, базы и тому подобное спрашивать максимально неинтересно
>ангуляр, некст, вуе
React
>Что выбрать для создание приложения?
Dart Flutter
>плюсы/шарп
Плюсы - база, но только те, что после ++20 - её в принципе надо знать. Шарп сделан Билли для своих рабов, пиздит фишки у крестов. Если очень хочется кушать, и насрать на всё в этой жизни, то второе, если нет, то первое
Всё верно. При этом на голом жиэс никто не пишет. Придётся учить ещё и фреймворк, и не один. И TS почти обязательно. Это при том, что ты уже должен знать html и css.
Для любителей писать на Js его прямая функция совсем не в приоритете)
Если честно то хз что сейчас можно посоветовать учить чтоб прям без напрягов вкатиться. Когда-то джава была неплохим вариантом, но не сейчас.
>пыха. 0 конкуренции
Наоборот, сейчас пыху начали сильно хайпить. Весь клуб этих бояр уже трясется
посмотри какой-нибудь другой видос где другой протыкласник говорит что жс это тема и вообще. делов-то
>То есть проблема всё-таки существует
Не существует. Для каждой задачи свои инструменты
>Пользователь будет смотреть на экран без инпутов, а потом при гидрации они подъедут
Повторю в десятый раз, изучи что такое гидрация. Инпусты подъедут сразу, при гидрации подъедут данные из локалстореджа, это всё будет быстрее, чем на обычном реакте
>Один большой клиентский компонент
Нет, много маленьких
>Сам факт существования клиентских компонентов тебе просто кричит, что твоя концепция нерабочая
Нет, просто у тебя проблемы с пониманием концепции, а всё непонятное для тебя = нерабочее
>Сервер присылает мне страницу с чужими комментами без моего - а потом, когда происходит гидрация, коммент внезапно появляется, посреди других комментов, так как он существует и отправился на сервер - случается тот самый шизтинг слоя
В обычном реакте тоже будет шифтинг, только помимо шифтинга ещё будет долгий лоадер, если у тебя сделано так, чтобы при маунте фетчились комменты из бд и потом к загруженным комментам ещё оптимистично прибавлялся бы коммент из локалстореджа. А если сделать чтобы при маунте фетч сначала дождался отправки коммента из локалстореджа, то так и в нексте можно сделать
>Я отказываюсь от мусора, не имеющего смысла, который увеличивает кодовую базу, делает хуже UX, увеличивает время до того, как можно пользоваться приложением
Увеличение кодовой базы незначительное, да и если посчитать все фичи некста из коробки, то может и уменьшение будет, в остальном одни плюсы - лучше DX, лучше UX, быстрее загрузка, намного больше гибкости - больше вариантов рендеринга, как раз уменьшает время до того, как можно пользоваться приложением, хз как ты этого не можешь понять, статик хтмл + гидрация быстрее рендеринга целого реакт аппа в div#root
>Сходи к PHP господам. Они тебе расскажут, что они в нулевых тебе выдавали HTML, в котором уже был нужный контент, и потом браузер подкачивал JS, и этим становилось возможно пользоваться
Я знаю, только тогда это реализовано было в 1000 раз хуже. А относительно подхода из 2010-х, когда всё делалось наклиенте, некст это новый подход
>Для меня приложение - это интерактив, взаимодействие с плагинами, локальная база на гиг, сохранение действий пользователя, даже если отвалилась сеть или страница перезагружена
Для меня тоже. У тебя очень большая проблема с пониманием того, почему получение статик хтмл + гидрация происходит быстрее рендеринга реакта в div#root, и ты похоже не понимаешь, что в итоге получается одинаковое по интерактивности приложение, только первый вариант быстрее
>И ты их раб поисковиков, раб их концепции приложение = html текст, так как берёшь на вооружение инструмент, который существует, исключительно, как я тебе выше продемонстрировал, лишь для удовлетворения ленивых поисковиков. Next.js и его клоны как раз родились в период расцвета популярности React и неумений поисковиков работать с таким фронтом
Нет, тут откровенный strawman, мне по большом счёту похуй на поисковики, это даже не вторичная важность, и главное - большинство приложений, которые я разрабатывал на нексте огорожены логином
>Мой подход решает все проблемы и не имеет исключений, работает быстро, чётко. Твой просто пищит о том, что он говно.
Наоборот твой подход ограничен, а некст более гибок, он может абсолютно всё то же самое, что обычный CSR реакт на vite, и в довесок ещё много чего другого. Мантры про поисковики на которые похуй большинство высокодинамичных/высокоинтерактивных приложений - смешные
>Одни придумали херню - милилонны кушают
Вот именно. Придумали CSR миллионы макак начали жрать не задумываясь о развитии инстрмуентов, им нормально на органиченных и устаревших сидеть
>Мне безразлично, что делают бомжи, разводя очередной Hui DAO Foundation.
Да, coinmarketcap типичные бомжи, например, или топовые дексы типа curve, pancake, sushi, особенно такие ноунеймовые бомжи как kraken и mexc, и самые бомжи из всех - raydium и jupiter
>Ты пришёл в сферу кормиться и не хочешь думать - у меня нет претензий к этому. У меня есть претензии, когда ты на моих двачах начинаешь свой подход выдавать, как что-то стоящее. Рассказывать примитивные хаки, как какое-то знание, которое можно не осилить. Тем самым ты забираешь у анонов месяцы жизни. Они пойдут всё это учить, и кто-то, кто окажется способен делать передовой фронт, например, как делает телега, обнаружит, что он занимался хернёй. Мой посыл направлен этих людей - я хочу помочь им, как хотел бы помочь себе некоторое время назад. Даже если читающий человек неспособен в силу отсутствия опыта сам решить, кто из нас прав, он как минимум будет иметь мои слова в голове - это может его сподвигнуть пойти и разобраться
Мой подход это стандарт последних лет в индустрии, твой подход ограниченный и ригидный, застрял в 2015 году. И ты не имеешь сильных аргументов потому что споришь со strawman'ами и в принципе не понимаешь как устроен некст и подобные фреймворки. Телега вообще на чистом жс сделана, и правильно, а для остального большинства приложений нужен фреймворк, и голый CSR реакт далеко не лучший выбор в большинстве случаев, он устарел и неактуален, из-за ограниченности в первую очередь, это знаю и сами создатели реакта, не зря у них такая плотная коллаборация с создателями некста, а некоторые из разработчиков работают одновременно в команде и некста, и реакта https://react.dev/learn/start-a-new-react-project#production-grade-react-frameworks
>То есть проблема всё-таки существует
Не существует. Для каждой задачи свои инструменты
>Пользователь будет смотреть на экран без инпутов, а потом при гидрации они подъедут
Повторю в десятый раз, изучи что такое гидрация. Инпусты подъедут сразу, при гидрации подъедут данные из локалстореджа, это всё будет быстрее, чем на обычном реакте
>Один большой клиентский компонент
Нет, много маленьких
>Сам факт существования клиентских компонентов тебе просто кричит, что твоя концепция нерабочая
Нет, просто у тебя проблемы с пониманием концепции, а всё непонятное для тебя = нерабочее
>Сервер присылает мне страницу с чужими комментами без моего - а потом, когда происходит гидрация, коммент внезапно появляется, посреди других комментов, так как он существует и отправился на сервер - случается тот самый шизтинг слоя
В обычном реакте тоже будет шифтинг, только помимо шифтинга ещё будет долгий лоадер, если у тебя сделано так, чтобы при маунте фетчились комменты из бд и потом к загруженным комментам ещё оптимистично прибавлялся бы коммент из локалстореджа. А если сделать чтобы при маунте фетч сначала дождался отправки коммента из локалстореджа, то так и в нексте можно сделать
>Я отказываюсь от мусора, не имеющего смысла, который увеличивает кодовую базу, делает хуже UX, увеличивает время до того, как можно пользоваться приложением
Увеличение кодовой базы незначительное, да и если посчитать все фичи некста из коробки, то может и уменьшение будет, в остальном одни плюсы - лучше DX, лучше UX, быстрее загрузка, намного больше гибкости - больше вариантов рендеринга, как раз уменьшает время до того, как можно пользоваться приложением, хз как ты этого не можешь понять, статик хтмл + гидрация быстрее рендеринга целого реакт аппа в div#root
>Сходи к PHP господам. Они тебе расскажут, что они в нулевых тебе выдавали HTML, в котором уже был нужный контент, и потом браузер подкачивал JS, и этим становилось возможно пользоваться
Я знаю, только тогда это реализовано было в 1000 раз хуже. А относительно подхода из 2010-х, когда всё делалось наклиенте, некст это новый подход
>Для меня приложение - это интерактив, взаимодействие с плагинами, локальная база на гиг, сохранение действий пользователя, даже если отвалилась сеть или страница перезагружена
Для меня тоже. У тебя очень большая проблема с пониманием того, почему получение статик хтмл + гидрация происходит быстрее рендеринга реакта в div#root, и ты похоже не понимаешь, что в итоге получается одинаковое по интерактивности приложение, только первый вариант быстрее
>И ты их раб поисковиков, раб их концепции приложение = html текст, так как берёшь на вооружение инструмент, который существует, исключительно, как я тебе выше продемонстрировал, лишь для удовлетворения ленивых поисковиков. Next.js и его клоны как раз родились в период расцвета популярности React и неумений поисковиков работать с таким фронтом
Нет, тут откровенный strawman, мне по большом счёту похуй на поисковики, это даже не вторичная важность, и главное - большинство приложений, которые я разрабатывал на нексте огорожены логином
>Мой подход решает все проблемы и не имеет исключений, работает быстро, чётко. Твой просто пищит о том, что он говно.
Наоборот твой подход ограничен, а некст более гибок, он может абсолютно всё то же самое, что обычный CSR реакт на vite, и в довесок ещё много чего другого. Мантры про поисковики на которые похуй большинство высокодинамичных/высокоинтерактивных приложений - смешные
>Одни придумали херню - милилонны кушают
Вот именно. Придумали CSR миллионы макак начали жрать не задумываясь о развитии инстрмуентов, им нормально на органиченных и устаревших сидеть
>Мне безразлично, что делают бомжи, разводя очередной Hui DAO Foundation.
Да, coinmarketcap типичные бомжи, например, или топовые дексы типа curve, pancake, sushi, особенно такие ноунеймовые бомжи как kraken и mexc, и самые бомжи из всех - raydium и jupiter
>Ты пришёл в сферу кормиться и не хочешь думать - у меня нет претензий к этому. У меня есть претензии, когда ты на моих двачах начинаешь свой подход выдавать, как что-то стоящее. Рассказывать примитивные хаки, как какое-то знание, которое можно не осилить. Тем самым ты забираешь у анонов месяцы жизни. Они пойдут всё это учить, и кто-то, кто окажется способен делать передовой фронт, например, как делает телега, обнаружит, что он занимался хернёй. Мой посыл направлен этих людей - я хочу помочь им, как хотел бы помочь себе некоторое время назад. Даже если читающий человек неспособен в силу отсутствия опыта сам решить, кто из нас прав, он как минимум будет иметь мои слова в голове - это может его сподвигнуть пойти и разобраться
Мой подход это стандарт последних лет в индустрии, твой подход ограниченный и ригидный, застрял в 2015 году. И ты не имеешь сильных аргументов потому что споришь со strawman'ами и в принципе не понимаешь как устроен некст и подобные фреймворки. Телега вообще на чистом жс сделана, и правильно, а для остального большинства приложений нужен фреймворк, и голый CSR реакт далеко не лучший выбор в большинстве случаев, он устарел и неактуален, из-за ограниченности в первую очередь, это знаю и сами создатели реакта, не зря у них такая плотная коллаборация с создателями некста, а некоторые из разработчиков работают одновременно в команде и некста, и реакта https://react.dev/learn/start-a-new-react-project#production-grade-react-frameworks
>при гидрации подъедут
Не подъедут. Либо их не будет, либо они будут без обработки событий до окончания всех этих реактогидраций. Иначе у тебя будет расхождение в вертске и реакт сделает пук среньк
мимо
Подъедут, гидрация делает из хтмл интерактивное реакт приложение, где спокойно можно дёргать LS
А что, если у тебя в зависимости от состояния локалсторейджа зависит состояние приложения? Тут твой сср сделает пук среньк и его придется выборочно отрубать.
> гидрация делает из хтмл
Гидрация работает только если у тебя на стороне сервера и клиента получилась идентичная верстка. Если у тебя компоненты завязаны на LS, то идентичность на стороне сервера недостижима, т.к. там нет LS. Туда же идет динамическая стилизация JS'ом.
>>290478
Я неправильно сказал, не при гидрации, а сразу после неё, когда компоненты уже полностью интерактивы. Суть в том, что клиентские компоненты некста с гидрацтей всё равно быстрее рендеринга реакт аппа в div#root, и пока реакт пропёрживает рендеринг всего дерева, клиентский компонент некста уже давно будет полностью готов к работе с браузерными апи
Ну как бы да. Но есть ньюансы.
1) Больше объем передаваемых данных по сети. Меньше эффект от кеширования.
2) К SSR коду идут повышенные требования. Особенно в части использования web-api.
3) Время, затраченное реактом на .createElement на стороне клиента плавно перетечет в время затраченное на сериализацию на стороне сервера. А за счет того, что реакт изначально просектирован что бы высирать нестроготипизированные mixed объекты, то оптимизациям v8 его работа слабо подвержена.
4) Для SSR тебе нужно держать свой сервис, следить за его работой, настраивать алерты, выкатывать сразу 2 билда (front/ssr), в сравнении с CSR подходом, где тебе достаточно выгрузить тарник из джобы.
5) Никто не запрещает тебе использовать псевдо-SSR на SW. Будет работать даже быстрее чем некст, но до такого не дойдем, потому что верселю надо как-то облака продавать, а с таким подходом никто их покупать не будет.
А ну еще один поинт забыл: сср пока что плохо дружит с микрофронтендами.
Тогда уж лучше 1С. Там и зп норм и спрос не падает.
>Не существует
Существует. Это в нормальном подходе её нет. Мне не надо выдумывать какие-то клиентские компоненты. У меня просто приложение, просто работает. Ты выдумывашь, и сидишь определяешь их
>Для каждой задачи свои инструменты
Нет. Это риторика раба. Там выше ты сообщам про fetch, который ты не выбирал. Это всё проявление одного и того же. Объясняю. Есть универсальные инструменты - их ценность в том, что они могут всё или почти всё. А есть инструменты для рабов, не могущих в универсальность. Есть деньги и речь - они могу почти всё, и дом тебе построить, и машину собрать, а есть говночист с инструментом под шкабление говна. Вот, люди всегда выбирают инструменты и подходы, который позволяют им делать то, что нужно, при этом максимально универсально. А рабы выбирают инструмент под задачу
Поэтому люди берут C++/TS и React с сокетами, и делают всё, что нужно в рамках браузера. И им не надо выделять отдельные компоненты, заучивать кучу базвордов - это просто ненужный мусор
>Инпусты подъедут сразу, при гидрации подъедут данные из локалстореджа, это всё будет быстрее, чем на обычном реакте
Фейк инпуты подъедут с неверными данными, которыми до гидрации нельзя будет пользоваться. И всё будет медленнее. Разбирали уже, выше читай
>Один большой клиентский компонент
>Нет, много маленьких
Один большой. Я же выше объяснял. Веб - это не текст. Это динамика. Она подразумевает, что приложение завист от окружения - локального хранилища, настроек и т.п. Поэтому у тебя что угодно может стать клиентским компонентом, ну, или другими словами SSR не работает. В том числе, приложение может быть загружено, как WebView. Пошёл мне рассказал, как ты в Telegram mini apps сделаешь SSR, где данные о пользователе ты получаешь исключительно из JS. Потом то же самое с мобильным приложением делаешь. Ой, опять инструмент не может, какой там базворд для этого случая в документации заготовлен? SCH - Shizting Client Hydration?
>В обычном реакте тоже будет шифтинг
Не будет. Я же тебе сообщил, что твой шифтинг - шизтинг. Я не видел его за 10 лет нигде, кроме, как в SSR. И это термин, как и прочие твои аббревиатуры из документации к этому подходу
У меня универсальных подход - отрендерился JS, показался интерфейс с закешированными данными - подгрузились свежие данные - показались они. Никакого шифтинга. В интерфейсе уже всем объектами есть своё место. Твой же подход - это выдать HTML, а потом, намазать сверху JS - внезапно приводит к тому, что иногда отрендеренный HTML может отличаться от того, что произошло после парсинга JS - это и есть тот самый шизтинг. Он существует только в рамках твоего говноподхода
>быстрее рендеринга реакта в div#root
Не быстрее, а медленее, выше писал, так как помимо парсинга JS тебе надо пропарсить HTML
>Наоборот твой подход ограничен, а некст более гибок, он может абсолютно всё то же самое, что обычный CSR реакт на vite
Нет, не может. Тебя я уже ткнул носом в нерабочие инпуты. Ткнул носом в Telegram mini app. Я думал, общих концепций хватит, но ты упёртый, возможно тролль, поэтому приходится опускаться до конкретики
>Придумали CSR
Никакого CSR не придумывали. Это термин исключительно документации твоего инструмента под задачу. Люди просто делают приложение, как делали тысячу лет на десктопе и на мобилке, только оно в браузере. И так же, как исполняется код любого другого приложения - JIT-итится и исполняется код JS. Ты пышаешься в эту концепцию притащить пыхаподходы с текстом и СЕО. Я уже устал это писать в очередной раз
>Да, coinmarketcap типичные бомжи, например
При чём тут coinmarketcap и прочие. Зачем ты опять пошёл кидаться базвордами? Бомжи не сами компании - компании как раз красавы, а бомжи, что внутри компании развели начальника на SSR. Бомжи те, кто next двигает. Если я говорю, что мне безразлично, как там делают уборку нищие - ты мне начнёшь заливать, а вот, в Сбербанке, а вот в Goldman Sachs моют в перчатках и с тряпками, они что бомжи? Да, бомжи те, кто там работает уборщиками, а у меня дома ездит робот
>Мой подход
У тебя нет подхода, ты накушался
>Мой подход это стандарт последних лет в индустрии
Нет, твой подход - говно, бомжи индустрии не интересуют, это ты когда будешь заказчику продавать используй, меня то зачем этим атакуешь
>твой подход ограниченный и ригидный, застрял в 2015 году
Мой подход был невозможен примерно до 2020 - потому, что React был куском говна, и потому, что не было TSX, GraphQL не поддерживал TS и куча инструментов были сырыми
>И ты не имеешь сильных
Мои аргументы можно выдалбливать в камне, так как ваши пыхаподходы ещё лет 10 будут атаковать людей
>для остального большинства приложений нужен фреймворк
Фреймворк нужен не для остальных приложений. Телега делает норм, все кто делает норм - делает также. Для норм приложений и нужен подобный подход
Фреймворк нужет для совсем тупых, которые не умеют писать код. Создатели фреймворка им поставляют уже все актуальные либы, делают удобную конфигурацию и говорят, куда какой код писать. То есть выполнил всю работу лида, и теперь можно сажать вкатунов за это. Задача любого фреймворка сложность вынести на создателя фреймворка, тем самым дав кабану возможность нанимать людей дешевле
>https://react.dev/learn/start-a-new-react-project#production-grade-react-frameworks
Лол, ты там уже поддержку в доке ищешь? Это просто список популярных фреймворков. Ты, когда являешься разрабом либы, очень раздуешься, если её используют другие - это делает тебя популярнее
>Не существует
Существует. Это в нормальном подходе её нет. Мне не надо выдумывать какие-то клиентские компоненты. У меня просто приложение, просто работает. Ты выдумывашь, и сидишь определяешь их
>Для каждой задачи свои инструменты
Нет. Это риторика раба. Там выше ты сообщам про fetch, который ты не выбирал. Это всё проявление одного и того же. Объясняю. Есть универсальные инструменты - их ценность в том, что они могут всё или почти всё. А есть инструменты для рабов, не могущих в универсальность. Есть деньги и речь - они могу почти всё, и дом тебе построить, и машину собрать, а есть говночист с инструментом под шкабление говна. Вот, люди всегда выбирают инструменты и подходы, который позволяют им делать то, что нужно, при этом максимально универсально. А рабы выбирают инструмент под задачу
Поэтому люди берут C++/TS и React с сокетами, и делают всё, что нужно в рамках браузера. И им не надо выделять отдельные компоненты, заучивать кучу базвордов - это просто ненужный мусор
>Инпусты подъедут сразу, при гидрации подъедут данные из локалстореджа, это всё будет быстрее, чем на обычном реакте
Фейк инпуты подъедут с неверными данными, которыми до гидрации нельзя будет пользоваться. И всё будет медленнее. Разбирали уже, выше читай
>Один большой клиентский компонент
>Нет, много маленьких
Один большой. Я же выше объяснял. Веб - это не текст. Это динамика. Она подразумевает, что приложение завист от окружения - локального хранилища, настроек и т.п. Поэтому у тебя что угодно может стать клиентским компонентом, ну, или другими словами SSR не работает. В том числе, приложение может быть загружено, как WebView. Пошёл мне рассказал, как ты в Telegram mini apps сделаешь SSR, где данные о пользователе ты получаешь исключительно из JS. Потом то же самое с мобильным приложением делаешь. Ой, опять инструмент не может, какой там базворд для этого случая в документации заготовлен? SCH - Shizting Client Hydration?
>В обычном реакте тоже будет шифтинг
Не будет. Я же тебе сообщил, что твой шифтинг - шизтинг. Я не видел его за 10 лет нигде, кроме, как в SSR. И это термин, как и прочие твои аббревиатуры из документации к этому подходу
У меня универсальных подход - отрендерился JS, показался интерфейс с закешированными данными - подгрузились свежие данные - показались они. Никакого шифтинга. В интерфейсе уже всем объектами есть своё место. Твой же подход - это выдать HTML, а потом, намазать сверху JS - внезапно приводит к тому, что иногда отрендеренный HTML может отличаться от того, что произошло после парсинга JS - это и есть тот самый шизтинг. Он существует только в рамках твоего говноподхода
>быстрее рендеринга реакта в div#root
Не быстрее, а медленее, выше писал, так как помимо парсинга JS тебе надо пропарсить HTML
>Наоборот твой подход ограничен, а некст более гибок, он может абсолютно всё то же самое, что обычный CSR реакт на vite
Нет, не может. Тебя я уже ткнул носом в нерабочие инпуты. Ткнул носом в Telegram mini app. Я думал, общих концепций хватит, но ты упёртый, возможно тролль, поэтому приходится опускаться до конкретики
>Придумали CSR
Никакого CSR не придумывали. Это термин исключительно документации твоего инструмента под задачу. Люди просто делают приложение, как делали тысячу лет на десктопе и на мобилке, только оно в браузере. И так же, как исполняется код любого другого приложения - JIT-итится и исполняется код JS. Ты пышаешься в эту концепцию притащить пыхаподходы с текстом и СЕО. Я уже устал это писать в очередной раз
>Да, coinmarketcap типичные бомжи, например
При чём тут coinmarketcap и прочие. Зачем ты опять пошёл кидаться базвордами? Бомжи не сами компании - компании как раз красавы, а бомжи, что внутри компании развели начальника на SSR. Бомжи те, кто next двигает. Если я говорю, что мне безразлично, как там делают уборку нищие - ты мне начнёшь заливать, а вот, в Сбербанке, а вот в Goldman Sachs моют в перчатках и с тряпками, они что бомжи? Да, бомжи те, кто там работает уборщиками, а у меня дома ездит робот
>Мой подход
У тебя нет подхода, ты накушался
>Мой подход это стандарт последних лет в индустрии
Нет, твой подход - говно, бомжи индустрии не интересуют, это ты когда будешь заказчику продавать используй, меня то зачем этим атакуешь
>твой подход ограниченный и ригидный, застрял в 2015 году
Мой подход был невозможен примерно до 2020 - потому, что React был куском говна, и потому, что не было TSX, GraphQL не поддерживал TS и куча инструментов были сырыми
>И ты не имеешь сильных
Мои аргументы можно выдалбливать в камне, так как ваши пыхаподходы ещё лет 10 будут атаковать людей
>для остального большинства приложений нужен фреймворк
Фреймворк нужен не для остальных приложений. Телега делает норм, все кто делает норм - делает также. Для норм приложений и нужен подобный подход
Фреймворк нужет для совсем тупых, которые не умеют писать код. Создатели фреймворка им поставляют уже все актуальные либы, делают удобную конфигурацию и говорят, куда какой код писать. То есть выполнил всю работу лида, и теперь можно сажать вкатунов за это. Задача любого фреймворка сложность вынести на создателя фреймворка, тем самым дав кабану возможность нанимать людей дешевле
>https://react.dev/learn/start-a-new-react-project#production-grade-react-frameworks
Лол, ты там уже поддержку в доке ищешь? Это просто список популярных фреймворков. Ты, когда являешься разрабом либы, очень раздуешься, если её используют другие - это делает тебя популярнее
>отрендерился JS, показался интерфейс с закешированными данными - подгрузились свежие данные - показались они. Никакого шифтинга. В интерфейсе уже всем объектами есть своё место.
И тут внезапно оказывается, что ui/ux твоего приложения чуть посложнее и твои закешированные данные совсем не релевантные свежим данным (в этом месте должен отобразиться другой компонент или вообще половина дом дерева должно быть другое) и ты получишь ровно тот же самый шифтинг.
>внезапно
>твои закешированные данные совсем не релевантные свежим данным
Это не внезапно, это базовый сценарий. Так работает любое приложение, есть то, что загружено, есть новое. Загрузилось новое - отрисовали. Вы там вообще что ли в думанье не хотите?
>ты получишь ровно тот же самый шифтинг
Нет не получу
>ui/ux твоего приложения чуть посложнее
Посложнее чего?
У тебя было одно дерево на кешированных данных. Прилетело обновление - получил совсем другое дерево совсем с другими размерами элементов на реальных данных. Как результат - получил layout shift.
То, что у тебя данные и макеты строго и всегда однозначные и с таким ты не сталкивался - это не более чем частный случай и не более того.
Всё так. JS действительно говняк, TS - хорошо. По поводу конкуренции - да, это в силу востребованности области, становись скилловым, будешь нужен. На хлеб с маслом будет. По поводу того, что на JS не программисты, TS по выразительности нагибает почти все языки, по возможностям и скорости V8 стоит рядом с JVM. Так что ты пришёл к лучшим скриптомакакам. Поэтому если тебе что-то говорит C/C++ программист, иногда стоит послушать, если нет, то шли нахуй
А, ну депра - это норм, когда сложно. Хули, наше тело создано ходить и еду искать на свежем воздухе, а не вот это вот всё
new Null()
new List()
new Five()
new Kek()
если
class Null { constructor() { return null } }
class List { constructor() { return [] } }
class Five { constructor() { return 5 } }
class Kek { constructor() { return new String('kek') } }
Зачем без гугла? Ты бы еще мелом на доске попросил
Специально написал "если", чтобы было понятно, что это не сплошной код.
>становись скилловым, будешь нужен
Как если вакансии на джуна это казино ебаное под 3к откликов?
>На хлеб с маслом будет
Айти 2024 итоги.
>Айти 2024 итоги
Так IT всё лет 10 назад. Иногда бывают хайпы. Был бум доткомов, бум соцсетей, мобилок, ща бум крипты отгремел (я в начало опоздал, но немного поразвлекался), нейроночки тоже как будт-то бы всё. Сидим пердим, будет новый движ - закатимся, пошиплем инвесторов и хомяков. Так и живём. Такчто копи скиллы и готовься наёбывать неграмотных, то есть неумеющих программировать людей. Ща IT-специалист это такой же челик, как сантехник или бухгалтер. А что ты хотел? В браузеры даже UDP не завезли - гоняется в пять раз больше данных по сети миллиардами людей и норм, всем вообще похуй на какие-то технологии. Так и живём
То есть лейаут шифт у тебя есть, но просто ты посчитал что можешь забить на него.
Так бы сразу и написал, а то что-то выебываешься, нет его у тебя типа.
Это самый популярный инструмент в сабже
>выкатывать сразу 2 билда (front/ssr)
Зачем два? Если тот же некст, то один, front и ssr в одном сервисе
>Мне не надо выдумывать какие-то клиентские компоненты. У меня просто приложение, просто работает. Ты выдумывашь, и сидишь определяешь их
У меня тоже просто приложение, где нужны те же реакт хуки, то это клиентский компонент, или где нужен доступ к браузерным апи. Не знаю что тут выдумывать, всё даже слишком просто
>Это риторика раба. Там выше ты сообщам про fetch, который ты не выбирал. Это всё проявление одного и того же. Объясняю.
Риторика раба это привязанность к одному инсутрменту и одному подходу. Точнее риторика макаки фронтошлёпа, а не инженера, который свободно выбирает инструмент под задачу, в то время как фанат технологии ограничен своим фанатизмом
>Есть универсальные инструменты - их ценность в том, что они могут всё или почти всё. А есть инструменты для рабов, не могущих в универсальность. Есть деньги и речь - они могу почти всё, и дом тебе построить, и машину собрать, а есть говночист с инструментом под шкабление говна. Вот, люди всегда выбирают инструменты и подходы, который позволяют им делать то, что нужно, при этом максимально универсально.
Согласен, потому что некст более универсален, он может больше
>Поэтому люди берут C++/TS и React с сокетами, и делают всё, что нужно в рамках браузера. И им не надо выделять отдельные компоненты, заучивать кучу базвордов - это просто ненужный мусор
То, что ты описываешь, это редкие и довольно уникальные случаи, где бекенд на плюсах и всё общение с фронтендом идёт по вебсокетам
>Фейк инпуты подъедут с неверными данными, которыми до гидрации нельзя будет пользоваться. И всё будет медленнее. Разбирали уже, выше читай
Обычные инпуты как в обычном реакте, которым можно будет пользоваться быстрее, чем пользователь успеет что-то сделать. Пока обычный реакт рендерит инпут в div#root, некст успеет отдать уже отрисованный инпут и навесить на него интерактивность
>Один большой. Я же выше объяснял. Веб - это не текст. Это динамика. Она подразумевает, что приложение завист от окружения - локального хранилища, настроек и т.п. Поэтому у тебя что угодно может стать клиентским компонентом, ну, или другими словами SSR не работает.
У клиентских компонентов есть пререндеринг хтмл на сервере с помощью реактовского апи, RSC вышли уже несколько лет назад, а ты до сих пор не знаешь как они работают, с ними не нужно ждать пока клиент загрузит бандл, распарсит его, срендерит реакт в div#root, они вообще стримятся с сервера
>В том числе, приложение может быть загружено, как WebView. Пошёл мне рассказал, как ты в Telegram mini apps сделаешь SSR, где данные о пользователе ты получаешь исключительно из JS. Потом то же самое с мобильным приложением делаешь. Ой, опять инструмент не может, какой там базворд для этого случая в документации заготовлен? SCH - Shizting Client Hydration?
Обтекай https://github.com/Telegram-Mini-Apps/nextjs-template
>Не будет. Я же тебе сообщил, что твой шифтинг - шизтинг. Я не видел его за 10 лет нигде, кроме, как в SSR. И это термин, как и прочие твои аббревиатуры из документации к этому подходу
В SSR его наоборот намного меньше, а в CSR дёрганные лоадеры лепят по любому поводу постоянно
>У меня универсальных подход - отрендерился JS, показался интерфейс с закешированными данными - подгрузились свежие данные - показались они. Никакого шифтинга.
Лол, ты буквально описал шифтинг. Сначала показался интерфейс с одними данными, а потом через полсекунды с другими
В интерфейсе уже всем объектами есть своё место. Твой же подход - это выдать HTML, а потом, намазать сверху JS - внезапно приводит к тому, что иногда отрендеренный HTML может отличаться от того, что произошло после парсинга JS - это и есть тот самый шизтинг. Он существует только в рамках твоего говноподхода
Много лет пишу на нексте и такое встречал только в процессе разработки, в процессе имплементации фичи, в проде - нет
>Не быстрее, а медленее, выше писал, так как помимо парсинга JS тебе надо пропарсить HTML
Парсинг браузером готовой хтмл страницы и последующая гидрация быстрее чем рендеринг реакта в div#root, тут парсинг хтмл тоже будет если что
>Нет, не может. Тебя я уже ткнул носом в нерабочие инпуты. Ткнул носом в Telegram mini app. Я думал, общих концепций хватит, но ты упёртый, возможно тролль, поэтому приходится опускаться до конкретики
Так они нерабочие только в твоей голове, про telegram mini app тоже твоя некомпетентная шиза потому что ты пытаешься спорить про то в чем не разбираешься
>Никакого CSR не придумывали. Это термин исключительно документации твоего инструмента под задачу. Люди просто делают приложение, как делали тысячу лет на десктопе и на мобилке, только оно в браузере. И так же, как исполняется код любого другого приложения - JIT-итится и исполняется код JS. Ты пышаешься в эту концепцию притащить пыхаподходы с текстом и СЕО. Я уже устал это писать в очередной раз
Приложение как тысячу лет назад это серверный рендеринг на пыхе, как ты и сам знаешь, только тогда этот подход был намного тупее, потому что сейчас можно совмещать серверный рендеринг с полной интерактивностью на клиенте
>При чём тут coinmarketcap и прочие. Зачем ты опять пошёл кидаться базвордами? Бомжи не сами компании - компании как раз красавы, а бомжи, что внутри компании развели начальника на SSR. Бомжи те, кто next двигает. Если я говорю, что мне безразлично, как там делают уборку нищие - ты мне начнёшь заливать, а вот, в Сбербанке, а вот в Goldman Sachs моют в перчатках и с тряпками, они что бомжи? Да, бомжи те, кто там работает уборщиками, а у меня дома ездит робот
Когда что-то не нравится - назови баззвордом. Бомжи - этой такой баззворд, под которым ты подразумеваешь что-то понятное одному тебе? Потому что некст двигают такие же по сути инженеры, что двигают и остальные технологии.
>Нет, твой подход - говно, бомжи индустрии не интересуют, это ты когда будешь заказчику продавать используй, меня то зачем этим атакуешь
В чём смысл называть пользователей стандарта индустрии бомжами? Это такой копиум, отборное врёти?
>Мой подход был невозможен примерно до 2020 - потому, что React был куском говна, и потому, что не было TSX, GraphQL не поддерживал TS и куча инструментов были сырыми
Может твой подход это просто как раз и есть подход бомжа? У тебя привязаннасть к ограниченному инструменту, тебе хочется бекенд на плюсах и вебсокетах, а какбнчики тебе не особо хотят выделять деньги на это. По сути подход бомжа. А адекватные инженеры гибко используют стандарты индустрии тем временем
>Фреймворк нужет для совсем тупых, которые не умеют писать код. Создатели фреймворка им поставляют уже все актуальные либы, делают удобную конфигурацию и говорят, куда какой код писать. То есть выполнил всю работу лида, и теперь можно сажать вкатунов за это. Задача любого фреймворка сложность вынести на создателя фреймворка, тем самым дав кабану возможность нанимать людей дешевле
Так пиши на чистом жсе, зачем тебе реакт? Твой CSR реакт с кучей либ из экосистемы это свой велосипедный фреймворк, зачем ты делаешь как совсем тупые?
Это самый популярный инструмент в сабже
>выкатывать сразу 2 билда (front/ssr)
Зачем два? Если тот же некст, то один, front и ssr в одном сервисе
>Мне не надо выдумывать какие-то клиентские компоненты. У меня просто приложение, просто работает. Ты выдумывашь, и сидишь определяешь их
У меня тоже просто приложение, где нужны те же реакт хуки, то это клиентский компонент, или где нужен доступ к браузерным апи. Не знаю что тут выдумывать, всё даже слишком просто
>Это риторика раба. Там выше ты сообщам про fetch, который ты не выбирал. Это всё проявление одного и того же. Объясняю.
Риторика раба это привязанность к одному инсутрменту и одному подходу. Точнее риторика макаки фронтошлёпа, а не инженера, который свободно выбирает инструмент под задачу, в то время как фанат технологии ограничен своим фанатизмом
>Есть универсальные инструменты - их ценность в том, что они могут всё или почти всё. А есть инструменты для рабов, не могущих в универсальность. Есть деньги и речь - они могу почти всё, и дом тебе построить, и машину собрать, а есть говночист с инструментом под шкабление говна. Вот, люди всегда выбирают инструменты и подходы, который позволяют им делать то, что нужно, при этом максимально универсально.
Согласен, потому что некст более универсален, он может больше
>Поэтому люди берут C++/TS и React с сокетами, и делают всё, что нужно в рамках браузера. И им не надо выделять отдельные компоненты, заучивать кучу базвордов - это просто ненужный мусор
То, что ты описываешь, это редкие и довольно уникальные случаи, где бекенд на плюсах и всё общение с фронтендом идёт по вебсокетам
>Фейк инпуты подъедут с неверными данными, которыми до гидрации нельзя будет пользоваться. И всё будет медленнее. Разбирали уже, выше читай
Обычные инпуты как в обычном реакте, которым можно будет пользоваться быстрее, чем пользователь успеет что-то сделать. Пока обычный реакт рендерит инпут в div#root, некст успеет отдать уже отрисованный инпут и навесить на него интерактивность
>Один большой. Я же выше объяснял. Веб - это не текст. Это динамика. Она подразумевает, что приложение завист от окружения - локального хранилища, настроек и т.п. Поэтому у тебя что угодно может стать клиентским компонентом, ну, или другими словами SSR не работает.
У клиентских компонентов есть пререндеринг хтмл на сервере с помощью реактовского апи, RSC вышли уже несколько лет назад, а ты до сих пор не знаешь как они работают, с ними не нужно ждать пока клиент загрузит бандл, распарсит его, срендерит реакт в div#root, они вообще стримятся с сервера
>В том числе, приложение может быть загружено, как WebView. Пошёл мне рассказал, как ты в Telegram mini apps сделаешь SSR, где данные о пользователе ты получаешь исключительно из JS. Потом то же самое с мобильным приложением делаешь. Ой, опять инструмент не может, какой там базворд для этого случая в документации заготовлен? SCH - Shizting Client Hydration?
Обтекай https://github.com/Telegram-Mini-Apps/nextjs-template
>Не будет. Я же тебе сообщил, что твой шифтинг - шизтинг. Я не видел его за 10 лет нигде, кроме, как в SSR. И это термин, как и прочие твои аббревиатуры из документации к этому подходу
В SSR его наоборот намного меньше, а в CSR дёрганные лоадеры лепят по любому поводу постоянно
>У меня универсальных подход - отрендерился JS, показался интерфейс с закешированными данными - подгрузились свежие данные - показались они. Никакого шифтинга.
Лол, ты буквально описал шифтинг. Сначала показался интерфейс с одними данными, а потом через полсекунды с другими
В интерфейсе уже всем объектами есть своё место. Твой же подход - это выдать HTML, а потом, намазать сверху JS - внезапно приводит к тому, что иногда отрендеренный HTML может отличаться от того, что произошло после парсинга JS - это и есть тот самый шизтинг. Он существует только в рамках твоего говноподхода
Много лет пишу на нексте и такое встречал только в процессе разработки, в процессе имплементации фичи, в проде - нет
>Не быстрее, а медленее, выше писал, так как помимо парсинга JS тебе надо пропарсить HTML
Парсинг браузером готовой хтмл страницы и последующая гидрация быстрее чем рендеринг реакта в div#root, тут парсинг хтмл тоже будет если что
>Нет, не может. Тебя я уже ткнул носом в нерабочие инпуты. Ткнул носом в Telegram mini app. Я думал, общих концепций хватит, но ты упёртый, возможно тролль, поэтому приходится опускаться до конкретики
Так они нерабочие только в твоей голове, про telegram mini app тоже твоя некомпетентная шиза потому что ты пытаешься спорить про то в чем не разбираешься
>Никакого CSR не придумывали. Это термин исключительно документации твоего инструмента под задачу. Люди просто делают приложение, как делали тысячу лет на десктопе и на мобилке, только оно в браузере. И так же, как исполняется код любого другого приложения - JIT-итится и исполняется код JS. Ты пышаешься в эту концепцию притащить пыхаподходы с текстом и СЕО. Я уже устал это писать в очередной раз
Приложение как тысячу лет назад это серверный рендеринг на пыхе, как ты и сам знаешь, только тогда этот подход был намного тупее, потому что сейчас можно совмещать серверный рендеринг с полной интерактивностью на клиенте
>При чём тут coinmarketcap и прочие. Зачем ты опять пошёл кидаться базвордами? Бомжи не сами компании - компании как раз красавы, а бомжи, что внутри компании развели начальника на SSR. Бомжи те, кто next двигает. Если я говорю, что мне безразлично, как там делают уборку нищие - ты мне начнёшь заливать, а вот, в Сбербанке, а вот в Goldman Sachs моют в перчатках и с тряпками, они что бомжи? Да, бомжи те, кто там работает уборщиками, а у меня дома ездит робот
Когда что-то не нравится - назови баззвордом. Бомжи - этой такой баззворд, под которым ты подразумеваешь что-то понятное одному тебе? Потому что некст двигают такие же по сути инженеры, что двигают и остальные технологии.
>Нет, твой подход - говно, бомжи индустрии не интересуют, это ты когда будешь заказчику продавать используй, меня то зачем этим атакуешь
В чём смысл называть пользователей стандарта индустрии бомжами? Это такой копиум, отборное врёти?
>Мой подход был невозможен примерно до 2020 - потому, что React был куском говна, и потому, что не было TSX, GraphQL не поддерживал TS и куча инструментов были сырыми
Может твой подход это просто как раз и есть подход бомжа? У тебя привязаннасть к ограниченному инструменту, тебе хочется бекенд на плюсах и вебсокетах, а какбнчики тебе не особо хотят выделять деньги на это. По сути подход бомжа. А адекватные инженеры гибко используют стандарты индустрии тем временем
>Фреймворк нужет для совсем тупых, которые не умеют писать код. Создатели фреймворка им поставляют уже все актуальные либы, делают удобную конфигурацию и говорят, куда какой код писать. То есть выполнил всю работу лида, и теперь можно сажать вкатунов за это. Задача любого фреймворка сложность вынести на создателя фреймворка, тем самым дав кабану возможность нанимать людей дешевле
Так пиши на чистом жсе, зачем тебе реакт? Твой CSR реакт с кучей либ из экосистемы это свой велосипедный фреймворк, зачем ты делаешь как совсем тупые?
>Всём нормальным людям строго похуй. Потому, что смещение элементов есть везде
Не везде оно есть, в качественных приложениях стараются сократить его по максимуму, вплоть до полного отсутствия. Дёрганый интерфейс нормальным людям обычно неприятнет, кому-то как минимум подсознательно, а кому-то вполне осязаемо.
>Поэтому ни revalidatePath, ни revalidateTag не иммют смысла - они будет пердолится всегда.
В смысле они будут пердолиться всегда? Это императивные методы, ты их пердолишь. Обычно по выстрелу вебхука. У тебя в бэке что-то случилось, ты дернул вебхук. Как напишешь код, так и будут предолиться.
>React был куском говна
А чо что-то поменялось? Ты же не будешь дефать реакт или ты на приколе?
>Фреймворк нужет для совсем тупых, которые не умеют писать код.
Зачем ты тогда Среактом пользуешься, ты тупой?
>Обтекай https://github.com/Telegram-Mini-Apps/nextjs-template
Во-первый это говно багованная параша, которая не собирается, смотри пик 1. Во вторых это писали бомжи, что видно по стилю кода, один только .eslintrc.json, когда уже давно eslint.config.mjs говорить о том, что это какой-то обоссаный бомжи писал
Что это на пик2? Человек просто не умемет в программировать, там такого мосора полпроекта. Там также он не уммет пользоваться типами. И далее, я починил это говно, чтобы оно собиралось, и что вы думаете, смотрите пик3, как я и говрил, у нас случился лоадер, потому, что пока мы не получим данные от tma и ton-connect, мы не знаем, что показывать
Спасибо, что рассмешил, думал, этот тупняк ещё долго будет продолжаться, но ты мне помог
На остальную шизу мне лень реагировать
>это говно багованная параша
Может и так, я сам её не юзал в своих проектах, просто скинул как пример, но она работает, для запуска потребовалось всего лишь сделать:
git clone
npm i
npm run dev:https
Прокинул https://127.0.0.1:3000
Всё.
>как я и говрил, у нас случился лоадер, потому, что пока мы не получим данные от tma и ton-connect, мы не знаем, что показывать
Если ты не понимаешь почему тут лоадер, может тебе не стоит про такие вещи говорить? Почему ты будучи некомпетентным в некоторых вещах пытаешься говорить о них?
Ты в итоге просто доебался до говнокода просто ради того чтобы доебаться. А мой посыл ты проигнорил, потому что он правдивый и тебе нечем оправдываться. А я напомню, что конкретно в текущем конрексте посыл был в том, что на нексте спокойно можно делать миниаппы телеграма, потому что функционал некста включает в себя всё то, что может обычный реакт на vite
>На остальную шизу мне лень реагировать
Нет аргументов
@
Скажи что тебе лень и приправь очередной атакой личности собеседника, неуклюже маняврируя и атакуя strawmanы (жду когда ты назовёшь этот термин баззвордом)
ЧТД
1072x736, 0:14
подскажите такие топ плагины есть для VUE чтобы делать как на видео.
то я гуглю drag and drop и меня какието из 2013 плагины для jquery пихает вместо VUE
>Если тот же некст, то один, front и ssr в одном сервисе
Ты реально только говнобложики разрабатывал? Тебе еще статику на s3 надо заливать.
> где нужны те же реакт хуки, то это клиентский компонент
Ты вообще в курсе, что т.н. "клиентские компоненты" рендерятся и на сервере в том числе?
>то я гуглю drag and drop и меня какието из 2013 плагины для jquery пихает вместо VUE
Блять, какие же вкатуны дегенераты, пиздец просто. Вот что творит пропоганда вкатунских курсов вайти.
название какое
Но js все равно выглядит более перспективным в нынешних условиях, учитывая количество областей, где можно его применить. А в случае с теми же мобилками (если речь про нативный код), то ты пишешь либо под айос, либо под андроид, а здесь огромный выбор, хоть мини-приложения в телеге делай. В чем я не прав?
>Тебе еще статику на s3 надо заливать
И? Это как правило делается на отдельном бекенде. Никто в своём уме не будет разрабатывать серьёзное приложение на фуллстек нексте.
>Ты вообще в курсе, что т.н. "клиентские компоненты" рендерятся и на сервере в том числе?
Да, о чём я уже много раз повторил тому шизу, который со мной спорит, не зная этого.
>залить статику на s3
>как правило делается на отдельном бекенде
Блять. Чел, как бы тебе сказать, у тебя явно недостаточно экспертизы. Ты же даже не знаешь что такое s3 и статика, с тобой бесполезно разговаривать. Приходи через пару лет, когда станешь джуном+.
А платежеспособным клиентам упали в хуй мои дашборды и страницы магазинов? Сейчас всякие миниаппы в телегеи прочих мессенджерах ощутимо набирают обороты, так что тема для вката отличная. И я сейчас даже без учета наеба гоевкрипты.
Ощутимо набирают обороты с 0.00001% рынка до 0.00005%? Рост в пять раз, но есть нюанс.
Ни в чем кроме крипты в странах третьего мира - эти телеговые приложения не всрались.
>Ни в чем кроме крипты в странах третьего мира - эти телеговые приложения не всрались.
Ты скозал? Дохуя бигтеха сейчас залетают в мессенджеры, глово, яндех, убер и дохуя кого еще. Учитывая, как взлетает концепция супераппов - мессендежры явно отвоюют часть аудитории у нативных приложений.
Ты дурак? Запилить новостной канал !== сделать в телеге приложение управляющее деньгами клиента. Вроде Тиньк или Альфа попытались после бана в апсторе, пока по еблу регулятор не настучал. На этом бигтех в телеге за рамками новостных ботов и закончился.
Понятно, это из разряда криптанов с их альтернативной финансовой системой и концом всех фиатных валют подконтрольных государству.
Теперь у альтернативно одаренных джиэсерев - победа телеграм веб апов над всем остальным интернетом.
В том посте иллюстрируется неочевидное поведение JS, суть в том что внутри функции-конструктора можно написать return чтобы вернуть какое-либо значение. При этом если значение является объектом, то вернётся этот самый объект, а если нет (например return 123;), то вернётся объект который и является экземляром класса.
А пиздюли за то, что в конструкторе в принципе не должно быть никаких return т.к. он и так возвращает this, вот что должен держать в голове разработчик, а возможность написать хуйню и получить такую же хуйню в ответ, это уже "особенность" жс примерно в духе складывания чисел со строками, да это есть, но нахуя такое тащить к себе в код.
Всё что тебе надо знать - тайпскрипт победил в биг и фин техе. Если в вакансии не написано про тайпскрипт, то будь уверен, что на собеседовании точно спросят.
Ещё года три-четыре назад знание тса было просто плюсом, то сейчас обязательно.
В эту же копилку идиотские задачи с эвент лупом про "что первым выведется в консоли", так любимые на 99% собеседований.
После ответа надо смело говорить, что если бы на ревью пришел пулл реквест опирающийся на подобную логику, то автор отправился бы переделывать на более очевидное поведение. Если это принципиально не возможно (по сути это будут костыли и хаки, чтобы обойти другие костыли и хаки крайне неудачных решений по архитектуре приложения) - то обязательно в коде расписать комментарии, почему именно сделан такой подход и почему именно по другому не возможно было сделать.
Это только добавит плюсов, что кандидат разбирается в теме и понимает это полный говнокод и так писать совершенно не следует.
Но говорят, что происходит обратное
https://www.youtube.com/watch?v=5ChkQKUzDCs
Мнение нашего бигтеха не интересует, они как флюгер, тупо перенимают западный мейнстрим, только с замедлением
в пару лет.
Это глупости пары попенсорсных проектов, разрабы которых боролись боролись с багами типизации, но так и не осилили инферы и женерики, что пришлось притягивать за хвост другие причины, типа "зато у нас чуть быстрее стала сборка".
Для сколько-нибудь важного проекта, от которого зависят доходы компании - гарантии тайпскрипта на этапе компиляции куда важнее нескольких лишних минут на сборку. Да и для разработки всякие автокомплиты, линтинги да рефакторинги с тайпскиптом работают куда лучше и качественнее, чем с jsdoc.
Ну если ты всё покрываешь игнорами и эни, то конечно тебе уже ничего не поможет.
>Но говорят, что происходит обратное
Какое? То, что авторы двух каких-то очень нишевых штук слезли с ТС ну вообще ни о чем не говорит.
В реальности люди отказываются от JS в целом, например вся инфра вокруг Vue, которая void zero, весь тулинг уже переписан на расте. Следующим шагом, это произойдет не завтра, не в следующем году, но это обязательно произойдет, весь фронтовый код будет писаться на условно том же расте и компилиться в JS.
Ты тот же наркоман с мини приложениями в телеге или другой?
Меня лично от перехода на васм останавливает только требование компании по поддержке всякого старого дерьма, на котором васм либо ограничен, либо вообще его нет.
Васм лет 13 натягивают и что-то все тухло. Даже если выстрелит не удивлюсь что в васме будут на js писать.
Так никто не говорит про финтех и прочие супераппы. В сторах есть огромное количество примитивных приложений, которые в таком виде нахуй не нужны. Зачем устанавливать какое-то приложение из стора, если можно мгновенно запустить то же самое из телеги, которой постоянно пользуешься? Да, это все равно подойдет не для всех видов приложений, но какие-то из них сможет заменить.
>крипта
Да всем похуй на эту крипту. Я тебе про обычный бигтех говорю.
>победа телеграм веб апов над всем остальным интернетом.
Где упоминалась "победа"? Таблетки прими, шизофреник выдумывающий.
>>291584
>управляющее деньгами клиента
Ебанат, причем тут деньги клиента вообще? В чем проблема за тот же нал, к примеру, заказать такси или еду?
>>291570
>денег там нет
Есть. Платят выше типичного дашбордошлепа
>3 миллиарда пользователей пользуются ватсаппами и прочими вайберами
>ряяя там денег нет!!! А вот у дяди кабана, для которого я ебашу лендинги на вордпрессе есть!!! сосите хуй быдло
>На этом бигтех в телеге за рамками новостных ботов и закончился.
Бигтех посмотрел на количество гоев, которые тапали хомяка и побежал роняя кал пилить свои миниаппы, так то.
>Есть. Платят выше типичного дашбордошлепа
И опять ты ничего не понял.
Нет денег для бизнеса, а не на зарплату паре разрабов в крипто-стартапе, который сжигает полученные инвестиции с прицелом в лучшем случае потом соскамиться.
Мимо.
Для бигтеха подобные скам-аппы - непозволительные репутационные риски.
Максимум на что способен сейчас бигтех в телеге - это новостной бот или мини-игры со "скидками" (у одного магазина (лол, бигтех) на многие многие тысячи).
Побежали пилить очередных хомяков - обычные стартапы в расчете на продажу или скам.
Открываешь hh и скидываешь сюда десяток вакансий от бигтеха, в которых говорится про интеграции с телегой.
3 миллиарда пользуются ватсаппами и им похуй на твою телегу, дурачок
490x360, 0:05
Что скажете?
https://codepen.io/dubeloqj-the-reactor/pen/YzmGPXN
Какую статику? То, что генерирует ssg next'a? Зачем тебе для этого отдельный второй сервис?
Кто говорит, один ютубер один раз год назад? Это же та история, в которой известный руби-шиз отказался от TS в своём бизнесе. Кто кроме него отказывается?
- Нету валидации на телефон, емейл.
- Названия инпутов не видны после заполнения.
- Стиль обзывания некорректный.
- Вертикальный скролл должен отсутствовать.
- У полей один и тот же евент, но на каждое поле прописывается свой, можно и нужно уменьшить код.
- Вместо лет должны быть конст.
- В одних и тех же случаях используются обычные или стрелочные функции.
- Цвета и отступы, и повторяющиеся значения в стилях должны быть в переменных.
- Куча лишних переменных, нужно подхватывать по общему классу и по атрибуту работать в массиве.
Лол, блять, а когда появилась возможность в кссе класс внутри класса писать? Хуя ебать.
Почему идиотские? Хорошие вопросы, быстро проверяют, макака ли перед собеседующим, или нормальный человек, который потратил чуть-чуть времени чтобы разобраться в на самом деле простой концепции.
>Лол, блять, а когда появилась возможность в кссе класс внутри класса писать? Хуя ебать.
Полтора года назад. Наконец-то SCSS/Sass отправлены в помойку.
https://www.w3.org/TR/css-nesting-1/
Нет, проверяет только то, что кандидат выучил ответ на очередной вопрос из "топ-1 вопросов на собеседованиях фронденд разработчика". Топ-1 потому что он есть на всех собеседованиях, в минимальных вариациях, разнообразие которых стремится к нулю.
1. Дизайн формы говно. Надо было в два столбика инпуты выстроить (и преобразовывать в один столбик на мобильнике).
2. Везде input type="text", как будто других типов кроме текста нет. Неудобно на мобильнике вводить.
3. Ну и по классике, все идентификаторы жёстко привязаны к контенту. То есть, вместо того чтобы писать допустим class="container full-width" или "fields two-columns", ты делаешь привязку к содержанию. Типа "ExperienceBlock", "ResetBlock" и т.д. это ебаный стиль всех говнокодеров-новичков.
Осталось затянуть миксины и экстендеды.
>потратил чуть-чуть времени
Когда я был ждуном, я дохуя всего этого дерьма держал в голове, опять же от задрачивания интервью-вопросов. Всякую хуйню типа пикрелейтеда, приведение к числу через ~~"123" и так далее.
А щас я большую часть не вспомню, это пространство в голове заменили более полезные знания, чем "удиви сеньора своими выебонами"
Если собеседующий нормально задаёт вопросы, раскрывает их, спрашивает про task queue, web api, очерёдность выполнения, то просто заучить будет недостаточно.
>это ебаный стиль всех говнокодеров-новичков
Проиграл. Будто новички могут писать НЕ говно код)
Двачую, никогда не писал на TypeScript, но уже прекрасно прохожу на нём собеседования. Просто заучил частые вопросы.
> пикрил
вместо delete может быть !, + или скобки
короче, я даже сам едва понял, чё в первом варианте ты хотел сделать, неудивительно что интерпретатор тебя послал.
Если лизнете мне ладонь, расскажу новый движ, который скоро взлетит, но вкатываться надо уже сейчас.
>- Вертикальный скролл должен отсутствовать.
Не понял тебя.
>- Цвета и отступы, и повторяющиеся значения в стилях должны быть в переменных.
Тут тоже
>- Куча лишних переменных, нужно подхватывать по общему классу и по атрибуту работать в массиве.
Это вообще как?
>Лол, блять, а когда появилась возможность в кссе класс внутри класса писать? Хуя ебать.
Без понятия когда конкретно появилась, но у меня всегда работало.
>>292010
>1. Дизайн формы говно. Надо было в два столбика инпуты выстроить (и преобразовывать в один столбик на мобильнике).
Personal Information и Experience не друг под другом, а рядом должны быть?
Геймдев на вебассембле. Пока тухляк, но скоро начнет набирать обороты.
https://www.webgamedev.com/games-demos#webassembly
ска как я ненавижу эти инпуты, лучше уж на сво
>это ебаный стиль всех говнокодеров-новичков
Для лейаут блоков не стоит так делать, для контент блоков наоборот
Бля реально, завтра устрою рефакторинг стилей в пет-проекте.
Раст можно и не писать.
Там чисто оболочку дает на васм.
Сам бек можно и на ноде, пайтоне, просто потом билдить в одно, кажется сайдкар называется.
Мимо посидел пописал пет пару часов на таури, прикольно, круто, но пока ничего не понятно.
>Сам бек можно и на ноде
Звучит как ещё больше пердолинга. Проще электрон взять сразу.
Сам взял таури под под пет относительно недавно, сидел тут охуевал после релиза 2.0.
У меня подписка на гопоту и курсор редактор.
Пользуюсь от силы раз в неделю-две.
Так что если ты там генеришь центрирование дива, то да, это для тебя.
Все что сложнее - мимо.
Ее максимум - помочь с версткой. Начиная со связанного с ней же жс-кода, она безбожно лажает
Как сча с трудойстройством? На хихи.ру 4к вакансий, года два назад, когда я был в теме было столько же вакансий. Но хуй влезешь по 1000 откликов на вакансия, сейчас аналогичная тенденция?
Вкат закрыт.
Зависит от твоего уровня. Для джунов очень плохо, для мидлов изи, для сенек супер изи
Почему именно его? Tabnine пробовал и остальные подобные проекты?
Да ты просто капитан очевидность
Там прям в ссылке порт из юнити в вебассембли/webgl
https://beta.unity3d.com/jonas/AngryBots/
Иди возьми конфетку с полки.
А если серьезно, просто обратите внимание насколько порт васм меньше жрет железо, у меня ноут завывает от жопоскрипт 2D игр, а там графоний с отражением и норм, вообще срать.
>Наконец-то SCSS/Sass отправлены в помойку.
Ага блин, конкатенация запрещена. Пока жив БЭМ, от Sass никуда не деться.
>Пока жив БЭМ
Чел, тебя даже шторм не разбудил? Он мёртв уже лет 5, с тех пор как появились css/scss модули он перестал быть нужным.
https://codepen.io/fjiumqtd-the-decoder/pen/oNKLOGW
https://codepen.io/fjiumqtd-the-decoder/pen/BaXLQoE
Нет, я не про это. Я буквально про то, что
> с тех пор как появились css/scss модули БЭМ перестал быть нужным
То есть он вообще больше не нужен нигде в принципе, и это уже много лет так, ты всё проспал.
импортировать стили в js-файлы?
создавать html-элементы в js-файлах?
нет уж увольте, с тем же успехом можно css-стили писать в json и импортировать его куда надо.
О да, передать styles.element в className это так сложно и неудобно, лучше буду писать огромные нечитаемые БЭМ-портянки, которые дают отрицательный developer experience и моментально превращают стилизацию проекта в говнокод, легаси и технический долг. Короче, назло маме отморожу уши!
Смотря какой стаж
Ну типа имеется ввиду что ты проебал контекст. Скажем ты вызвал функцию (обычную, не стрелочную) внутри другой функции (например внутри метода класса) и обращаешься к зыс, думаешь ебаный рот зыс щит, а там уже совершенно другой буллщит, и ты такой типа сак май дик.
Пишу на JS с 2011-го года, и моментально путаюсь в любых современных туториалах. "Функции высшего порядка" - што? Какой насос выдумал такое название для функций, которые просто получают другую функцию аргументом. И такое сплошь и рядом. "Оператор нулевой коалесценции", блядь. Реально, сложнее все эти названия в уме удержать, чем писать хороший код на JS.
Если доебываться и душнить, то да, ты прав. Но как еще ты бы это назвал? Вызовнестемконтекстомкоторыйтыподразумевалкогдаписал?
Функции высшего порядка это не новый термин и не термин ЖС, это общий термин используемый уже тыщу лет. То что ты как жс программист нихуя кроме жс в жизни не видел - твоя проблема
>Операр нулевой коалесценции
Это новый оператор, для него новое слово и его придется выучить, да. В чем твоя проблема? Про спред с рестом тоже бомбишь?
Никак. До того как функция вызвалась this нет. А появляется он при вызове, по определенным правилам в зависимости от того как и где вызвалась функция. Не надо там ничего "подразумевать", тебе вообще должно быть похуй че там в коде написано, пока туда не перешло управление.
Потеря контекста вызова - это типа если функция задумывалась для вызова с одним контекстом, а ты её вызываешь с другим. Обычно такое происходит, когда дурачки отцепляют функцию от объекта, например, для краткости (классическое log = console.log).
Когда пишешь метод класса - подразуметь что this будет указывать на инстанс - это норма, особенно когда внутри самого метода this туда и указывает. Это технически правильное, конечно, поведение, но про него забываешь, особенно когда на других языках пишешь
>классическое log = console.log
кстати говоря, а есть ли вообще смысл биндить лог к консоли? вроде и без этого работает щас
Консоли в спеке нет, а значит полагаться на то что она всегда прибинжена - тупо. Метод и есть метод, работай с ним как с методом, а не полагайся на то что хромиум за тебя сопли подтер
То цсс модулям поебать что у тебя на стороне хтмл, на уровне файлов они заскопятся и зауникалятся. Ты бэм пишешь по компоненту в каждом файле один хуй же, и без каскада, так что какая разница? Модули тебе будут генерить класснеймы, а сами классы называй как хочешь, даже лучше
Если деструктурировать объект то можно не думать о подобных проблемах.
const { log } = console;
Работает во всех окружениях
Абсолютно никакого влияния на this не оказывает и никакой разницы с const log = console.log нет.
Покажите мне пальцем спеку в которой написано что лог всегда прибинжен к консоли. Если такой спеки нет - советы хуйня.
Пиздец я ахуел. Тебя самого не напрягло копипастить обработку полей 20 раз?
>const { log } = console;
это просто сахар для const log = console.log, никакой разницы в поведении
>>292467
https://stackblitz.com/edit/vitejs-vite-dgr5cq?file=main.js,index.html&terminal=dev
Хотя бы как-то так в плане направления.
Ну так и создавай промис вокруг имаджа, зачем он нужен в первом бранче?
Какой у тебя тип у this.ready?
Внутренний метод createElement включает в себя createImageBitmap, это асинхронная фигня из браузерного API. И надо, чтобы всё было доделано, когда ready (промис) наконец разрешится инстансом.
Использование такое:
sprite = await new Sprite({ source: "..." }).ready
Что за хуйню я читаю вообще, как будто джавистом написано
const loadImage = src => {
const {resolve, reject, promise} = Promise.withResolvers()
const img = new Image();
img.onload = resolve;
img.onerror = reject;
img.src = src;
return promise;
}
class {
constructor(){
init();
}
async init(){
await loadImage(url)
this.ready = true;
}
}
import {loadImage} from '../lib/image/'
class {
constructor(){
this.ready = loadImage('url')
}
}
Кто давно с ним, поясните:
Если функциональный компонент в useEffect вызывает асинхронный код и делает в then апдейт состояния компонента, есть нормальный способ подождать пока все что этот компонент хотел сделать выполнится и компонент отрендерится окончательно? В интернете ответа не нашел. Есть ощущение что это невозможно. Ну по крайней мере средствами Jest. Есть какие то устоявшиеся практики по этому поводу?
Если ты даже не осилил нагуглить нормально, может, не стоит этим заниматься?
https://legacy.reactjs.org/docs/testing-recipes.html#data-fetching
>Promise.withResolvers()
О, прикольный шорткат, не знал.
Только если я правильно понял, твой класс таким же как у меня функционалом не обладает. У тебя нельзя ждать, когда картинка у инстанса будет готова, и получить в результате созданный инстанс.
Нормально, пусть продолжает для реакта умений и мозгов уже хватит
this.ready = loadImage().then(()=>this)
return new Promise(resolve => resolve(5))
return (async () => 5)()
Да, и то же самое что return Promise.resolve(5)
заебало. Да и выглядит убого.
Поэтому сюда и закинул, чтобы дали пизды, сказав как надо правильно
Учти, что в любой нормальной конторе тебе за пикрил двушку в петилово пропишут. Этот высер стандарта хуже with, хуже void 0.
Хех, я вижу это впервые за последние лет 10, и до того я видел это на стековерфлоу. Уж лучше писать if (true) { }, иначе любой джаваскриптер полезет вверх искать do, while, лабел, объявление функции или что-нибудь ещё. Отделяй пустыми строками, каментами.
Ну хоть удивил кого-то этим.
>Этот высер стандарта хуже with, хуже void 0
Заранее интересно, почему так нельзя писать?
> почему так нельзя писать?
Например потому, что какая-то хрень в скобочках без кейворда впереди автоматически воспринимается как создание объекта. Сравни:
// Создание объекта { kek: { } }
let myObj =
{
kek: { }
}
// Ничего не значащий блок с лабелом
{
kek: { }
}
p.s. Справедливости ради, вот тут есть пример использования такого "голого" блока: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let
Но лично я бы для целей ограничения скоупа скорее использовал вызываемую на месте функцию (IIFE):
(() => {
// изолированный код тут
})()
Это по крайней мере ни с чем не спутаешь.
В условии не оговорены ограничения. Вопрос уебанский. Значит return 5.
Заебали однословные каличи из /b
Если писать нормально структурированый код то ничего "визуально отделять" подобным методом будет не нужно. Я уж молчу что подобную хуйню любой линтер просто удалит и не поперхнется
Только спроецировал зачем-то себя.
Эта хуйня что ты запостил, я ее видел, но она держится довольно таки на соплях.
Простой контрпример:
x = () => {
Promise.resolve().then(() => {
console.log("Promise");
Promise.resolve().then(() => {
console.log("Nested Promise")
})
});
}
x();
await console.log("Out of the promise 1");
console.log("Out of the promise 2");
Nested Promise будет выведено последним. То ест в случае чуть сложнее все может сломаться и подождать пока все просрется посредством одного лишь эвэйта может и не выйти.
Tanstack Query + Suspense
Плохому танцору яйца мешают
Можно ещё поставить таймаут на 50 миллисекунд, например. Юзер хуй заметит разницу, а всякая хуета явно успеет просраться, если там нет фетчей. Делали так на проде крупного портала, работало.
Мы разные аноны.
Только как замена ошибкам компиляции в нормальных языках, не более.
Советую купить железную клавишу чистки кэша браузера, а то сотрется
ну я имел ввиду для конкретного проекта, например для реакта там свой конфиг с их сайта тянется
буду очень благодарен если кто откликнется !
Он депрекейтед давно
.this это хуйня которая получает контекст в зависимости от среды в которой она написана.
Так вроде в 10 тысяч раз понятнее.
нихуя не шарю в кодинге а только пытаюсь вкатиться хотябы в основы
Всё ровно наоборот: this внутри функции зависит только от способа вызова этой функции. Ты можешь вызывать любую функцию с любым this. Исключение - стрелочные функции, у которых своего контекста нет, прямо как у каких-нибудь условных блоков.
ну под написана я имел ввиду вызвана. Потому что когда ее вызываешь по сути пишеш ее же.
>.this это хуйня которая получает контекст в зависимости от среды в которой она вызвана.
По сути эта залупа заменяет аргумент в функции, чтоб вместо:
function dergat (kraynyayaPlot){
return kraynyayaPlot.zalupa ;
}
Можно была написать:
function dergat (kraynyayaPlot){
return this.zalupa ;
А еслиб мы вызывали хуйню из dergat в другой функции, то .this нельзя было бы использовать потому что она бы брала контекст из аргумента той функции и нада было бы крайнюю плоть пихать.
Или я совсем хуйню несу?
eslint
Зачем уволится ? Ты в курсах как сложно ща фронту стажировку найти )?
А ведь вторую функцию сейчас даже редкий сенька написать смог бы. Отошли от корней.
Честно говоря, я топил за самопис пока не понадобилось прикручивать платежные системы к сайту.
У каждой своё апи и как правило свои модули для популярных кмс или плагинов к ним типа вуукомерс, сижу и думаю сколько времени можно было бы сэкономить.
а можно и не сэкономить, когда их модули кривое говно и реализовать самому два апи-вызова куда проще
скрин с пенсией по шизе еще приложи, здесь не /b/
Я чёто не заметил, что мою либу последнее время клонируют, вношу туда breaking changes не глядя. Надо бы где-то описать изменения.
Бывает, что люди путают гит и гитхаб, это ладно, по неопытности.
Но когда люди, которые якобы грамотные, библиотеки, блять, выпускают, но думают, что гитхаб диктует какие-то правила ведения чего либо. Гитхаб - это просто твоя расшаренная папка с кодом, дебил, он не в силах тебе что-то диктовать.
На гитхабе куча правил как оформлять и публиковать, иначе алгоритмы тебя закопают.
Ты серьезно думаешь, что кто-то выбирает библиотеки из trending гитхаба, ебанат?
Да это даже ни при чём. Если ты не напишешь нормально тот же readme.md, твоя страница будет выглядеть как говно. Лицензию тоже надо не абы как разместить, чтобы гитхаб её распознал и это отразилось на интерфейсе.
Че такой агрессивный?
Все е2е тесты держутся на соплях, не переживай
>>293065
Не обращай внимания, есть такая тонкая прослойка кодеров которые на полном серьезе считают что кодстайл нужно контролировать руками на этапе ревью. У них либо шизофрения либо они никогда не работали в командах, либо работали в шизокомандах уровня умирающего НИИ
>>293082
Рассказываю, пикрилейтед. Не очень понимаю о чем тут вообще можно спорить
>>293194
This это ссылка на контекст исполнения. Контекст исполнения или определяется в момент вызова или может быть прибинжен к функции намертво через bind. Так же его можно принудительно передать при вызове функции через call или apply. Исключая вышеназваные варианты, контекст определяется в момент вызова по простым правилам, про которые можно почитать на лернжиэс
А вот стрелочные функции замыкают this из места объявления, да. То есть, стрелочная функция это все равно что (function(){}).bind(this)
Он ведется в releases
Коммитишь по conventional commits, релизишься через release-please например и чейнджлог подбивается самостоятельно.
>иначе алгоритмы тебя закопают
Надо в readme.md добавлять хэштеги: #хочувреки, #тренд, #втоп
Чтобы гитхаб продвигал твой репозиторий и у тебя было больше подписчиков.
Начинающим гитхаберам рекомендуется публиковать не меньше трёх реп в неделю, иначе про тебя там все забудут.
Если не вывозишь сам писать столько кода, подключи аи.
Вот пример многообещающего гитхаб канала: https://github.com/yyx990803 , на таком можно зарабатывать от $10 в день с монетизации.
Changelog - это список изменений, понятный конечному пользователю. Автогенерируемая из коммит-мессаджей хуйня абсолютна нечитаемая даже для анальника, которые эти коммиты делал.
На пике веб-интерфейс stable diffusion, конкретно расширение depth library.
Что мне нужно: чтобы картинки рук добавлялись в черный квадрат и я мог их двигать по экрану как в паинте/фотошопе. Собственно, это должен быть нормальный режим работы.
Но конкретно в моей версии не срабатывает кнопка ADD. Все остальные кнопки работают исправно.
Еще отмечу, что на более новой версии есть вкладка с текстом, и его добавление работает уже как надо - могу крутить вертеть, двигать по экрану. Так что думаю что проблема где-то в путях/скриптах.
Что делал: ставил новую версию, полностью переустанавливал, разрешал браузеру все на этом сайте, пробовал в двух браузерах (файрфокс и яндекс), пытался разобраться в скриптах, но потерпел поражение.
Пишу сюда, так как вся начинка там, как я понял, на JS. Собственно, если у кого есть идеи как помочь - скину всю инфу
Оставлю ссылку на ту версию, что у меня в данный момент установлена.
https://github.com/jexom/sd-webui-depth-lib
В инете не нашел вообще людей с такой же проблемой.
5к и я открою этот твой гитхаб.
>Бляяя как вообще в гитхабе ченджлог ведут?
1. Ставишь commitizen, semantic release, semver, commitlint, husky.
2. Коммитишь через commitizen https://commitizen-tools.github.io/commitizen/
3. Ищешь на гитхабе "commitizen action", добавляешь этот экшн на master
4. Мержишь изменения в мастер
...
5. PROFIT!!! Ченжлог генерируется автоматически гитхабом.
Ты с премией считаешь или как? Если чистыми без премий, то сеньор 350-450, при этом ближе к 400 и выше тебе будут очень часто предлагать оформление через ИП кроме крупных компаний, ну и регулярно спрашивают алгоритмы и систем дизайн. Если найти 400, то учитывая премию 3 оклада в год, в месяц будет ровно 500. У тимлида будет не сильно больше доход, но часто сильно больше ответственности. Откликайся в компании, которые платят выше рынка, например Авито, Райффайзен, Точка. А ещё лучше оформил бы ИП в Грузии и нашел валютную удалёнку за 6-8к в месяц с налогами в 1%.
>А вот стрелочные функции замыкают this из места объявления, да. То есть, стрелочная функция это все равно что (function(){}).bind(this)
Стрелочные же берут контекст на один уровень выше, не?
>This это ссылка на контекст исполнения.
Ты бредишь. this - это всегда ссылка на объект.
>Контекст исполнения или определяется в момент вызова или может быть прибинжен к функции намертво через bind.
Не пиши в интернет ничего по JS больше, не путай новичков. Контекст исполнения возникает ТОЛЬКО и ИСКЛЮЧИТЕЛЬНО в момент передачи управления исполняемому коду JS программы.
>Так же его можно принудительно передать при вызове функции через call или apply.
Нельзя его никак передать при вызове, это объект движка. Ты его не контролируешь никак.
>А вот стрелочные функции замыкают this из места объявления, да.
Они не замыкают ничего ниоткуда. У них лексический this.
Лучше думай о стрелочных функциях как о простом блоке. Будто у тебя не (() => { ... })(), а if (true) { ... }
Вот какое this было бы в простом блоке, такое же и в стрелочной функции. То есть она "this-прозрачная", никакого своего влияния на this не оказывает.
Хотя если подумать, то по-другому и никак. Ладно, всё равно живём в эпоху мощных компов.
Делай хорошо, плохо не делай.
>Блин, а чё, функция замыкает вообще всё своё окружение
По стандарту да, по факту реализации пытаются это оптимизировать эвристикой, захватывая только используемые переменные. Но когда мудаки суют eval() в замыкание, тут наша эвристика все.
Чтобы что? Если мне надо почитать описание КАЖДОГО коммита, я просто пойду читать историю коммитов, нахуй ченджлог, дублирующий историю коммитов? Это именно что саботаж ведения человекочитаемого ченджлога.
Спасибо, солнышко
Удаленку через Грузию реально искать через местные рекрутинговые агентства, или надо самому все через хедхантеры тамошние?
>Все е2е тесты держутся на соплях, не переживай
1. У меня в жабе такой хуйни не было
2. Это е2е тесты которые маскируются под юнит тесты и они все держатся на сраных соплях вплоть до того что "истекший" по таймауту тест может подсирать другим тестам - потому что асинхронное выполнение можно перестать ждать, но нельзя остановить... Так нельзя жить. Здесь act() тут await и делаем довольное ебало что все работает и протестировано. Замечательно!
Ни то, ни другое, я имею в виду не удалёнку на грузинские компании, а удалёнку на компании из Европы, США, Канады, Дубая, Сингапура и т.д., они не будут работать с физлицом из РФ, а с грузинским юрилицом будут. Искать на линкедине и сайтах типа:
https://wellfound.com
https://web3.career
Создателя CSS покусал создатель Lua.
Есть
Только в мире Си и ему подобном, где массив это указатель на первый элемент. (даже тут я употребляю слово "первый", в общем это тупой атавизм, который уже не победить)
Я же написал - conventional commits, что тебе не понятно?
>>293782
Что такое "уровень выше". Он у них такой же как в том месте где она была объявлена
>Ты бредишь. this - это всегда ссылка на объект.
Во-первых, я нигде не писал что контекст не является объектом, во-вторых, он может быть undefined и этот факт равен обоссыванию тебя. В третьих, ты всем своим постом решил просто доебаться до формулировок на ровном месте, хотя прекрасно понимаешь о чем я писал.
>Нельзя его никак передать при вызове, это объект движка. Ты его не контролируешь никак.
Ясно, а что тогда передается в первый агрумент call?
>Не пиши в интернет ничего по JS больше
Ясно, а что делает бинд, расскажи нам?
>>294000
Есть способ создать style и въебать его на сраницу
> Не обращай внимания, есть такая тонкая прослойка кодеров которые на полном серьезе считают что кодстайл нужно контролировать руками на этапе ревью. У них либо шизофрения либо они никогда не работали в командах, либо работали в шизокомандах уровня умирающего НИИ
Мамин энтерпрайзник в компании-единороге (с капитализацией в один миллион рублей) завыл.
https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAUQG4FMB2MEmDGKpwBmUEIcA5CqhgM7kBQ9MAnmCnAPJgzARo1wAvHADe9OBKIQIAfgBccGjCjA0Ac3GSARgEMo8uGgCuILfk0TdALwNKV6+gF9GAYwA2OmgIDCHr3BQADzw0ABMBZHRMbFx8UQs4KBQdUL43ZilZBTtVDUlE5NS0dLhdfQVjU3N8pJS0jOts5VzGfJc+OyMXGGg4AAoIbl5+BS4eDoBKePz8miM2KD6JhPyOLQArFG6AOk8aYDU0PpgAC2AaABo4QfH+ZZnJU-Pt6zgAHzfhcgBHI0CGfLOBI0FAwAAKJDAAB4ACoBYLocJwADWKGYEEInCGHQAfP1UcwFDCrkgdG4jCgFAAlFC-YBJUJQsbDGg4gDaMIAuu9DEY3G4JgokBBgKFpg84MBMX1SeT2IIFbz+fcJflTiQAO6GFBahBQEiLcgwjgAEQ4CjAkIKIJg5GWK0kAHpHXBvEYlKQ4AsALSWwZwWWinS3OBuCBqYAuB0SGganAuE74tFTMSqtqedjkQjSchyaNpqX9WUU7ZudBqU5wPEAZgATCq02n1RAtWgdYh9dA+lnpJKBD0IKG+GoAIR2-OqrS1ZETyQuDMUMq52cPQsyskUqtwACsDcbEubrfbeoN3bKfbgA9KBzHe-3pWn+aBqqeNG2KBifQABja5AASEQCUcL8rhEOANU8BRXzZAlOSuNAWyFDd2EcO9JDWTYdj2A4jlfUC4BgtFOSQuU4FQhJnGcIA
Можно как-то сделать, чтобы value красненьким не горело, не ломая при этом типизацию а-ля value: any в сигнатуре и не дописывая на каждом шагу говно типа <Options['foo']>value? Просто переписать всё по-другому нельзя, надо именно в рамках функции setProp решить вопросик.
Вы видите копию треда, сохраненную вчера в 18:13.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.