Вы не поняли суть статьи или суть проекта? Эта информация просто о том, зачем нам понадобился этот воркер
Сервис показывает самолеты в виртуальной сети полетов VATSIM. В ней реальные люди собираются и летают, их обслуживают диспетчера, которые также люди, и это всё симулирует реальные процессы, принятые в мире.
Низкая задержка нужна в том числе для того, чтобы, если диспетчера онлайн нет, смотреть самолеты в округе и быть в курсе происходящего - но и с диспетчерами пользы много от низкой задержки.
Тут, возможно, излишний драматизм, но я правда в некотором отчаянии сидел, глядя на растущую память, жалобы пользователей, и очень странные, непонятные симптомы проблемы
Условный реакт и вью это уже нынче стандарт. Без них разрабатывать бывает больно, мы не думаем, подключать их или нет
От аксиоса мы ушли на ofetch, и даже без него писали бы свою обертку под фетч. Изначально сидели на аксиосе из-за его превосходства над XHR, доказанного временем, но ушли с переходом на Nuxt 3 из-за того, что $фетч в нем встроен
Day.js мы не подключали, но если бы у нас не было ресурса писать обертки под Intl - подключили бы
UI библиотеки мы не используем, потому что написали собственные. Их полезно использовать, если на проекте нет и не будет дизайнера
Наговнокодить можно и на нативном js, не нужно ругать из-за этого каждый инструмент, который делает рутинные, сложные вещи проще для понимания
Нет, я ругаю именно лодаш. Однако, я видел множество проектов, созданных умными людьми, на которых столько библиотек, что черт ногу сломит - и как минимум половину можно выкинуть. Так что да, я сторонник того, что что-то легко заменить, лучше это сделать - а если не легко, посмотреть на популярность, актуальность библиотеки и другие факторы.
Но мы тоже не сумасшедшие, чтобы писать свои костыли на каждый чих - например, на основном проекте подключена относительно легкая set-cookie-parser, а также еще ряд библиотек, замена которых того явно не стоит - плюс всё, что у нас подключено, хорошо или хотя бы средне поддерживается, чего не скажешь о лодаше.
Нет, просто это наше решение из-за большого числа проектов - своя библиотечка, которую я назвал ui kit'ом, но там еще и утилитки есть.
Если лодаш и подобные подключатся во имя каких-то утилит, от которых нельзя отказаться или заменить на что-то, а также нет ресурсов/не хочется заниматься ревью и выносить дублирующиеся участки в набор утилит (локальный или нет - неважно) - то хотя бы правильно использовать, о чем я писал в статье - правильно подключать и использовать только то, что нужно.
Ну и варианты как мой, так и условного лида, который подключил лодаш, не идеальны и несут свои издержки. А проблема ревью и дубликатов мелких утилит никуда не уходит - дубликаты, по идее, будут происходить и без всяких лодашей (как с компонентами, так и с методами). Лодаш и подобные не покрывают всё, поэтому отсекать дубликаты и выносить их куда-то надо в любом случае (особенно на больших проектах).
Мы написали UI Kit, потому что у нас не пет проекты, а десятки проектов.
Недавно делал пет проект, и, внезапно, не использовал лодаш. И не писал кучу кастомных утилит. Когда писал vue-yandex-maps понадобился метод сравнения - ну поставил либу для этого. И все равно справился без лодаша.
Было также еще несколько пет проектов в течение последних лет - и опять без лодаша, без jquery, что же это такое! И без велосипедов в виде утилит заменителей.
А, и кстати
Ну то есть мне на любой свой пет-проект писать юай-кит
Ну если там кастомный дизайн, и вдруг еще есть грамотный дизайнер, то для компонентов уж точно полезно было бы. Сколько раз за свою жизнь написал компонент попапа и кнопки - сбиваюсь уже со счета. И это все еще и без таилвинда и бутстрапа! Страх и ужас, одним словом.
В правильный код я не верю. Скорее всего, код без лодаша будет работать быстрее - как минимум после замены на натив. Использование нативных методов также улучшит понимание того, что можно делать в чистом JS. Ну и код, скорее всего, правда будет чище - меньше импортов, меньше неймспейсов с методами.
можно и писать, но они заведомо будут хуже того, что было протестированно на таком количестве тест кейсов
Зависит от метода. Условный дебаунс тяжело написать плохо
можно и писать, но они заведомо будут хуже того, что было протестированно на таком количестве тест кейсов
Опять же - зависит от сложности и огромности проекта. В большинстве случаев, на больших проектах уже и так куча утилит, а тут просто +5 на замену лодаша, а на мелких часто вам многие методы и не нужны
Не нравится теущий инструмент - поменял на другой
Когда весь код покрыт лодашем - так не получится. Мы его относительно долго выпиливали с одного проекта, где он также использовался совершенно бысмысленно
И такие библиотеки, как lodash, ramda, etc. являются прекрасным обучающим материалом
Вот совершенно не соглашусь. Их часто используют, не вникая в то, как это работает - методы простые и решают задачу, зачем вникать, пока с ними нет проблем или непоняток?
В отличие от того же UnJS, которые местами написали сложные штуки, на которые хочется взглянуть - да и то не делают.
Я очень ленивый разработчик, поэтому написали свой набор утилит, и локально в проектах переиспользуем composable (я вьюшник) в отдельных папках. И это не велосипеды, а небольшие методы. Велосипеды есть, но их минимум - если совсем выхода нет, подключаем библиотеку. Но ни разу за все время в АВ на куче проектов никто не сказал "это нельзя сделать без лодаша".
А писать PR и переписывать лодаш - вот опять же, смысл? Ради тех пяти методов? Им всем уже есть современные легковесные альтернативы (если уж нет в нативе), может за редкими исключениями.
В целом что угодно современное. Мы используем Intl и натив, но если не подходит, сейчас date-fns очень популярен слышал. А так Moment просто официально умер, поэтому лучше бы слезать
Про методы: дебаунс совсем уж легко заменить, sortBy... Не знаю с ходу отличий от обычного сорта, но как будто мы не так часто сортируем, а когда да, прописывание логики по типу (a,b) => a - b даже помогает в понимании (имхо)
Вы не поняли суть статьи или суть проекта? Эта информация просто о том, зачем нам понадобился этот воркер
Сервис показывает самолеты в виртуальной сети полетов VATSIM. В ней реальные люди собираются и летают, их обслуживают диспетчера, которые также люди, и это всё симулирует реальные процессы, принятые в мире.
Низкая задержка нужна в том числе для того, чтобы, если диспетчера онлайн нет, смотреть самолеты в округе и быть в курсе происходящего - но и с диспетчерами пользы много от низкой задержки.
Манит попробовать уже пару месяцев...
Это другая история :D
Тут, возможно, излишний драматизм, но я правда в некотором отчаянии сидел, глядя на растущую память, жалобы пользователей, и очень странные, непонятные симптомы проблемы
Вы о чем? Чем хабр не лучше?
В данный момент мы не используем внешних скриптов, вообще - не считая антибота Cloudflare
Там как минимум урезанное апи, но не подошло не поэтому. Я смог завести свои сокеты, но дешевое не стало(
Мне нужно выполнять ровно один скриптик, эта штука кажется немного про другое
Пропустил комментарий!
Условный реакт и вью это уже нынче стандарт. Без них разрабатывать бывает больно, мы не думаем, подключать их или нет
От аксиоса мы ушли на ofetch, и даже без него писали бы свою обертку под фетч. Изначально сидели на аксиосе из-за его превосходства над XHR, доказанного временем, но ушли с переходом на Nuxt 3 из-за того, что $фетч в нем встроен
Day.js мы не подключали, но если бы у нас не было ресурса писать обертки под Intl - подключили бы
UI библиотеки мы не используем, потому что написали собственные. Их полезно использовать, если на проекте нет и не будет дизайнера
Нет, я ругаю именно лодаш. Однако, я видел множество проектов, созданных умными людьми, на которых столько библиотек, что черт ногу сломит - и как минимум половину можно выкинуть. Так что да, я сторонник того, что что-то легко заменить, лучше это сделать - а если не легко, посмотреть на популярность, актуальность библиотеки и другие факторы.
Но мы тоже не сумасшедшие, чтобы писать свои костыли на каждый чих - например, на основном проекте подключена относительно легкая set-cookie-parser, а также еще ряд библиотек, замена которых того явно не стоит - плюс всё, что у нас подключено, хорошо или хотя бы средне поддерживается, чего не скажешь о лодаше.
Нет, просто это наше решение из-за большого числа проектов - своя библиотечка, которую я назвал ui kit'ом, но там еще и утилитки есть.
Если лодаш и подобные подключатся во имя каких-то утилит, от которых нельзя отказаться или заменить на что-то, а также нет ресурсов/не хочется заниматься ревью и выносить дублирующиеся участки в набор утилит (локальный или нет - неважно) - то хотя бы правильно использовать, о чем я писал в статье - правильно подключать и использовать только то, что нужно.
Ну и варианты как мой, так и условного лида, который подключил лодаш, не идеальны и несут свои издержки. А проблема ревью и дубликатов мелких утилит никуда не уходит - дубликаты, по идее, будут происходить и без всяких лодашей (как с компонентами, так и с методами). Лодаш и подобные не покрывают всё, поэтому отсекать дубликаты и выносить их куда-то надо в любом случае (особенно на больших проектах).
Мы написали UI Kit, потому что у нас не пет проекты, а десятки проектов.
Недавно делал пет проект, и, внезапно, не использовал лодаш. И не писал кучу кастомных утилит. Когда писал vue-yandex-maps понадобился метод сравнения - ну поставил либу для этого. И все равно справился без лодаша.
Было также еще несколько пет проектов в течение последних лет - и опять без лодаша, без jquery, что же это такое! И без велосипедов в виде утилит заменителей.
А, и кстати
Ну если там кастомный дизайн, и вдруг еще есть грамотный дизайнер, то для компонентов уж точно полезно было бы. Сколько раз за свою жизнь написал компонент попапа и кнопки - сбиваюсь уже со счета. И это все еще и без таилвинда и бутстрапа! Страх и ужас, одним словом.
Вы простите, конечно, но я процитирую себя:
В правильный код я не верю. Скорее всего, код без лодаша будет работать быстрее - как минимум после замены на натив. Использование нативных методов также улучшит понимание того, что можно делать в чистом JS. Ну и код, скорее всего, правда будет чище - меньше импортов, меньше неймспейсов с методами.
Поддержка низкаяНе низкая, её нет
Не нужна, потому что он официально устарел) Там нет особо дискуссии
Зависит от метода. Условный дебаунс тяжело написать плохо
Опять же - зависит от сложности и огромности проекта. В большинстве случаев, на больших проектах уже и так куча утилит, а тут просто +5 на замену лодаша, а на мелких часто вам многие методы и не нужны
Когда весь код покрыт лодашем - так не получится. Мы его относительно долго выпиливали с одного проекта, где он также использовался совершенно бысмысленно
Вот совершенно не соглашусь. Их часто используют, не вникая в то, как это работает - методы простые и решают задачу, зачем вникать, пока с ними нет проблем или непоняток?
В отличие от того же UnJS, которые местами написали сложные штуки, на которые хочется взглянуть - да и то не делают.
Верно, но на моей практике такие объекты нужно копировать весьма редко
Обыватель - вряд ли. Даже если он доберется для доки - она такая, что проще забить и не использовать (https://github.com/lodash/lodash/wiki/FP-Guide)
Я очень ленивый разработчик, поэтому написали свой набор утилит, и локально в проектах переиспользуем composable (я вьюшник) в отдельных папках. И это не велосипеды, а небольшие методы. Велосипеды есть, но их минимум - если совсем выхода нет, подключаем библиотеку. Но ни разу за все время в АВ на куче проектов никто не сказал "это нельзя сделать без лодаша".
А писать PR и переписывать лодаш - вот опять же, смысл? Ради тех пяти методов? Им всем уже есть современные легковесные альтернативы (если уж нет в нативе), может за редкими исключениями.
Самый надежный метод из придуманных, конечно) Но да, structuredClone - наш выход
В целом что угодно современное. Мы используем Intl и натив, но если не подходит, сейчас date-fns очень популярен слышал. А так Moment просто официально умер, поэтому лучше бы слезать
Скажу как тимлид, ударивший кулаком: написали свой UI Kit c утилитами и юзаем. Полет - прекрасный)
Тут соглашусь, звучит не так легко. Просто сам никогда этим не пользовался, но фишка удобная
Спасибо!
Про методы: дебаунс совсем уж легко заменить, sortBy... Не знаю с ходу отличий от обычного сорта, но как будто мы не так часто сортируем, а когда да, прописывание логики по типу (a,b) => a - b даже помогает в понимании (имхо)