Да, согласен, это можно было бы добавить. Но я специально держу статью на уровне "для новичков и всё", чтобы сначала было понятно, как работает сам WebSocket и SSE, так как им наваливают всего и сразу и они путаются
Очень большая ошибка так думать, WS это не (прокачанный SSE), это просто другой инструмент. Если ты, например, делаешь ленту новостей, зачем тебе вообще WS? SSE спокойно закроет задачу: он проще, легче и работает из коробки без лишней боли
А с WS ты сразу тащишь за собой кучу усложнений, нужно думать про переподключения, ping-pong, ловить ситуации когда соединение тихо умерло и т.д.
Я использую термин «паттерны» скорее в прикладном, учебном контексте, как типовые подходы к решению задач (two pointers, hashmap и т.д.), которые помогают быстрее распознавать решения на практике. Но и не назвать их Паттернами не могу.
При этом в вашем комментарии есть небольшое противоречие: сначала вы пишете, что паттерны - это типичные наборы приемов, алгоритмов и структур данных, а затем отмечаете, что я описываю как раз алгоритмы и структуры данных.
Для начинающих это удобный способ структурировать мышление перед переходом к более сложным алгоритмам и концепциям.
Да, согласен, сейчас требования выросли. Но базовые паттерны и структуры данных - это фундамент, который многие как раз пропускают на старте, именно поэтому стоит Простая сложность
Да, в целом ты прав, но ты немного радикально обобщаешь. Проблема не столько в самих веб-компонентах, сколько в том, как их используют. Если просто наивно рендерить тысячи элементов через DOM -любой подход упрётся в лимиты, не только WC.
Да, согласен, это можно было бы добавить. Но я специально держу статью на уровне "для новичков и всё", чтобы сначала было понятно, как работает сам WebSocket и SSE, так как им наваливают всего и сразу и они путаются
Очень большая ошибка так думать, WS это не (прокачанный SSE), это просто другой инструмент. Если ты, например, делаешь ленту новостей, зачем тебе вообще WS? SSE спокойно закроет задачу: он проще, легче и работает из коробки без лишней боли
А с WS ты сразу тащишь за собой кучу усложнений, нужно думать про переподключения, ping-pong, ловить ситуации когда соединение тихо умерло и т.д.
POV: тут был ответ на коммент выше
Круто, что тебе понравилось )
В табличке было перепутано, но я уже все поправил. Странно, что у тебя не обновилось.
Стоп, правильно ли понял, что ты предлагаешь переделывать резюме для каждого отклика?
Прикольно, а еще не тратьте время и деньги на проверку ATS, бесполезная ерунда, всегда показывает одинаковый результат
Круто! но я бы добавлял кодстайл больше похожий на React, мб дело вкуса
Я использую термин «паттерны» скорее в прикладном, учебном контексте, как типовые подходы к решению задач (two pointers, hashmap и т.д.), которые помогают быстрее распознавать решения на практике. Но и не назвать их Паттернами не могу.
При этом в вашем комментарии есть небольшое противоречие: сначала вы пишете, что паттерны - это типичные наборы приемов, алгоритмов и структур данных, а затем отмечаете, что я описываю как раз алгоритмы и структуры данных.
Для начинающих это удобный способ структурировать мышление перед переходом к более сложным алгоритмам и концепциям.
Да, согласен, сейчас требования выросли. Но базовые паттерны и структуры данных - это фундамент, который многие как раз пропускают на старте, именно поэтому стоит Простая сложность
Да, в целом ты прав, но ты немного радикально обобщаешь. Проблема не столько в самих веб-компонентах, сколько в том, как их используют. Если просто наивно рендерить тысячи элементов через DOM -любой подход упрётся в лимиты, не только WC.
зашло, как ты разложил разницу между «комиссии есть» и «итоговая доходность есть» — многие на этом вообще не фокусируются