Кроваво-черное ничто пустилось вить систему клеток, связанных внутри, клеток, связанных внутри, клеток в едином стебле и явственно, до жути на фоне тьмы ввысь белым бил фонтан
Даже если сеньор согласится - результат зависит от качества постановки задач. Если джунам дают тщательно разжёванные описания - то норм, я даже уже видел такие скиллы и команды типа “в джире прочитай описание тикета, в гите сделай ветку, закодь, заведи пулл-реквест с описанием изменений, сделай код-ревью”.
Иначе у сеньора не хватит интеллектуального ресурса (мыслетоплива) разбираться не с одним, а с целым ворохом плохо сформулированных тикетов " хорошо делойте а плохо не делойте".
У Станислава Лема в “Сумме технологии” был раздел на эту тему. Перечитываю, многое всё ещё выглядит лучше и актуальнее свежесгенерированного нейрослопа.
В мире frontend есть проблема: многие разработчики плохо ориентируются в структурах данных и не умеют их грамотно применять, чтобы получать эффективные и производительные решения своих задач
И авторы статьи - не исключение
Списки
связный список позволяет легко перемещаться между треками
Не любой список, а только двусвязный - в односвязном перемещаться назад стоит O(N). И не между любыми треками, а только между соседями - переместиться на случайный элемент тоже O(N). А массив позволяет легко перемещаться между вообще любыми элементами.
Если использовать двусвязный кольцевой список, то появляется проблема автоматической очистки сборщиком мусора
Сами проверяли или из интернета списали? Современные сборщики мусора в V8 (Chromium), JavaScriptCode (Safari), SpiderMonkey (Firefox) умеют собирать циклические структуры. Это было проблемой только в древних IE, который использовал reference counting GC.
Очередь
Сами же написали
в массиве для удаления элемента необходимо не только удалить сам элемент, но и сдвинуть все последующие элементы
и сами же сделали реализацию очереди через массив. Каждое извлечение элемента очереди - это удаление начального элемента массива со сдвигом всех последующих.
Очереди могут стать узким местом в производительности, если элементы добавляются быстрее, чем обрабатываются. Если не управлять размером очереди должным образом, это может привести к переполнению памяти.
Это проблема не очереди, а скорости обработки элементов. Если не успеваем обрабатывать входной поток данных - захлебнёмся в любом случае, если не делать backpressure или не выбрасывать/объединять часть входных данных.
Дерево
Производительность: одной из основных проблем деревьев является их балансировка. Несбалансированные деревья могут привести к значительному снижению производительности при выполнении операций поиска, вставки и удаления.
Показали бы на своём же примере (дерево комментариев или файловая система), как можно дерево балансировать (нет). И как одна длинная ветка комментариев или жирная папка со множеством файлов может привести к значительному снижению производительности.
Сначала с сервера приходит плоский список комментариев. На стороне клиента мы преобразуем этот список в дерево
А нельзя прислать с сервера сразу дерево? Или прислать плоский список с уровнем вложенности каждого элемента, чтобы его так плоским списком и рендерить на клиенте? Почему преобразование в дерево на клиенте, а не на сервере? И нужно ли здесь дерево вообще, или хватило бы плоского списка с уровнем вложенности и ссылкой на родителя ветки?
Компонент комментария вызывает сам себя для отображения вложенных ответов, что создает рекурсивную структуру. Это позволяет нам легко и эффективно отображать комментарии любой глубины вложенности.
Глубина рекурсии ограничена объёмом памяти, объёмом передаваемых параметров и объёмом локальных переменных. Так что “любой глубины вложенности” - преувеличение. Неудачная реализация может падать на бюджетном телефоне с минимумом памяти в очень глубоко вложенном поддереве.
Массив
Когда использовать? Когда нужно хранить список элементов, где важен порядок.
Список, Set, Map и простой JS-объект с полями тоже сохраняют порядок элементов. Так что этот пункт можно исключить (ну или добавить в описание соответствующих структур).
сколько создателям Фаервокса платит Гугл например. Там как раз миллиарды
С удовольствием посмотрю на официальные числа, если скинете ссылку. Но всё равно "организация гугл платит организации мозилла" != "у пятерых авторов первого mozilla firefox в кармане миллиард баксов", чувствуете разницу?
Линккс Фондейшен тоже намного богаче чем вы говорите
Платиновое членство (самое крутое) в Linux Foundation стоит от $500000 в год https://opensource.stackexchange.com/q/4744. Всё ещё не вижу миллиарды. Да, корпораций-спонсоров несколько, но всё равно порядок величин не тот.
В любом случае не вижу толпы примеров. Как и писал выше, на подсчёт хватит пальцев одной руки.
Эти опенсорсники с миллиардами баксов сейчас с нами в одной комнате? Zloirock из core-js прямо при установке либы писал, что ищет работу. Tailwind сократил 3 из 4 программистов. Curl, left-pad, xz, faker.js. Это что пришло в голову за десять минут.
Да, на Linux Foundation корпорации скидываются по несколько сотен тысяч долларов в год. Сотен тысяч, не миллиардов. Но на подсчёт таких примеров хватит пальцев одной руки токаря, плохо соблюдающего технику безопасности. И суммы там далеко не миллиардные.
Охотиться разучились, когда начали заниматься сельским хозяйством. Ковать оружие 99% и так никогда не умели. Но охотники, строители, фермеры, спецы по работе с металлом остались и никуда не деградируют.
Это если ты начальник. А если они "блатные", или из соседних отделов и тебе/твоему начальнику никак не подчиняются, или выше тебя/твоего начальника по иерархии - то люлей могут навставлять тебе.
Почему "изображать работу"? Посты в корпоративном трекере появляются? Появляются. Если ничего сиюминутно-срочного нет, и результаты работы появились сегодня в 22 вечера или завтра в 8 утра - в чём проблема?
Если она на удалёнке не перформит, а от перевода в офис продуктивность статистически значимо вырастет - это другой вопрос, но вы про это ни слова не сказали.
Хотел использовать content-visibility на одном проекте - а там много айфонов с Safari 15-16 и телевизоров с Chrome 84.
Хотел использовать на другом проекте - а там вёрстка завязана на отрицательный margin (или padding - не помню уже) - дизайнеры наизвращались. Такое не дружит с intrinsic size - все выступающие за габариты кусочки разметки просто не рисуются.
Хотел на третьем - а там у элементов разная высота, в зависимости от того, сколько строк текста получилось.
Так что начинать надо с дизайна продукта и аудитории, иначе приходится делать на JS.
отсекать невидимые элементы по сравнению боундингов
Тут прикол в том, что ты говоришь браузеру, что у каждого невидимого элемента высота 300px, и это сильно упрощает расчёты - ему не надо лезть внутрь каждого невидимого элемента, чтобы подсчитать его размеры.
Бесконечный список с подгрузкой и оптимизация/виртуализация списка - это ортогональные штуки. Можно использовать IntersectionObserver для первого и content-visibility для второго.
Кроваво-черное ничто пустилось вить систему клеток, связанных внутри, клеток, связанных внутри, клеток в едином стебле и явственно, до жути на фоне тьмы ввысь белым бил фонтан
© Набоков, использовано в “Бегущем по лезвию 2049”
Даже если сеньор согласится - результат зависит от качества постановки задач. Если джунам дают тщательно разжёванные описания - то норм, я даже уже видел такие скиллы и команды типа “в джире прочитай описание тикета, в гите сделай ветку, закодь, заведи пулл-реквест с описанием изменений, сделай код-ревью”.
Иначе у сеньора не хватит интеллектуального ресурса (мыслетоплива) разбираться не с одним, а с целым ворохом плохо сформулированных тикетов " хорошо делойте а плохо не делойте".
Это Республика Беларусь. Какое глушение? Какое подавление GPS?
У меня минимум одно банковское приложение уже не хочет работать, если просто включен режим разработчика.
У Станислава Лема в “Сумме технологии” был раздел на эту тему. Перечитываю, многое всё ещё выглядит лучше и актуальнее свежесгенерированного нейрослопа.
И авторы статьи - не исключение
Списки
Не любой список, а только двусвязный - в односвязном перемещаться назад стоит O(N). И не между любыми треками, а только между соседями - переместиться на случайный элемент тоже O(N). А массив позволяет легко перемещаться между вообще любыми элементами.
Сами проверяли или из интернета списали? Современные сборщики мусора в V8 (Chromium), JavaScriptCode (Safari), SpiderMonkey (Firefox) умеют собирать циклические структуры. Это было проблемой только в древних IE, который использовал reference counting GC.
Очередь
Сами же написали
и сами же сделали реализацию очереди через массив. Каждое извлечение элемента очереди - это удаление начального элемента массива со сдвигом всех последующих.
Это проблема не очереди, а скорости обработки элементов. Если не успеваем обрабатывать входной поток данных - захлебнёмся в любом случае, если не делать backpressure или не выбрасывать/объединять часть входных данных.
Дерево
Показали бы на своём же примере (дерево комментариев или файловая система), как можно дерево балансировать (нет). И как одна длинная ветка комментариев или жирная папка со множеством файлов может привести к значительному снижению производительности.
А нельзя прислать с сервера сразу дерево? Или прислать плоский список с уровнем вложенности каждого элемента, чтобы его так плоским списком и рендерить на клиенте? Почему преобразование в дерево на клиенте, а не на сервере? И нужно ли здесь дерево вообще, или хватило бы плоского списка с уровнем вложенности и ссылкой на родителя ветки?
Глубина рекурсии ограничена объёмом памяти, объёмом передаваемых параметров и объёмом локальных переменных. Так что “любой глубины вложенности” - преувеличение. Неудачная реализация может падать на бюджетном телефоне с минимумом памяти в очень глубоко вложенном поддереве.
Массив
Список, Set, Map и простой JS-объект с полями тоже сохраняют порядок элементов. Так что этот пункт можно исключить (ну или добавить в описание соответствующих структур).
Шёл 2026 год. Проверку правописания в редакторах текста используют не только лишь все.
С удовольствием посмотрю на официальные числа, если скинете ссылку. Но всё равно "организация гугл платит организации мозилла" != "у пятерых авторов первого mozilla firefox в кармане миллиард баксов", чувствуете разницу?
Платиновое членство (самое крутое) в Linux Foundation стоит от $500000 в год https://opensource.stackexchange.com/q/4744. Всё ещё не вижу миллиарды. Да, корпораций-спонсоров несколько, но всё равно порядок величин не тот.
В любом случае не вижу толпы примеров. Как и писал выше, на подсчёт хватит пальцев одной руки.
Эти опенсорсники с миллиардами баксов сейчас с нами в одной комнате? Zloirock из core-js прямо при установке либы писал, что ищет работу. Tailwind сократил 3 из 4 программистов. Curl, left-pad, xz, faker.js. Это что пришло в голову за десять минут.
Да, на Linux Foundation корпорации скидываются по несколько сотен тысяч долларов в год. Сотен тысяч, не миллиардов. Но на подсчёт таких примеров хватит пальцев одной руки токаря, плохо соблюдающего технику безопасности. И суммы там далеко не миллиардные.
Охотиться разучились, когда начали заниматься сельским хозяйством. Ковать оружие 99% и так никогда не умели. Но охотники, строители, фермеры, спецы по работе с металлом остались и никуда не деградируют.
Война... Война никогда не меняется.
Это если ты начальник. А если они "блатные", или из соседних отделов и тебе/твоему начальнику никак не подчиняются, или выше тебя/твоего начальника по иерархии - то люлей могут навставлять тебе.
Почему "изображать работу"? Посты в корпоративном трекере появляются? Появляются. Если ничего сиюминутно-срочного нет, и результаты работы появились сегодня в 22 вечера или завтра в 8 утра - в чём проблема?
Если она на удалёнке не перформит, а от перевода в офис продуктивность статистически значимо вырастет - это другой вопрос, но вы про это ни слова не сказали.
И ни единой ссылки на репозиторий или открытый issue
Корпоративная память и обратная контрабанда
https://coollib.cc/b/215983/read
Такой близкий к Земле объект, как Земля, всё ещё не отфотографировали в хорошем разрешении
Хотел использовать content-visibility на одном проекте - а там много айфонов с Safari 15-16 и телевизоров с Chrome 84.
Хотел использовать на другом проекте - а там вёрстка завязана на отрицательный margin (или padding - не помню уже) - дизайнеры наизвращались. Такое не дружит с intrinsic size - все выступающие за габариты кусочки разметки просто не рисуются.
Хотел на третьем - а там у элементов разная высота, в зависимости от того, сколько строк текста получилось.
Так что начинать надо с дизайна продукта и аудитории, иначе приходится делать на JS.
Тут прикол в том, что ты говоришь браузеру, что у каждого невидимого элемента высота 300px, и это сильно упрощает расчёты - ему не надо лезть внутрь каждого невидимого элемента, чтобы подсчитать его размеры.
Бесконечный список с подгрузкой и оптимизация/виртуализация списка - это ортогональные штуки. Можно использовать IntersectionObserver для первого и content-visibility для второго.
10 коммитов "Initial commit with task details" и 10 коммитов "Revert "Initial commit with task details"" особо доставляют.
Он историю коммитов перед созданием пулл-реквеста хоть причесал бы.