Как стать автором
Обновить

Комментарии 40

Надо бы было в опросе добавить пункт "Не использую ИИ", было бы интересно увидеть процент пуристов ;)

Причины не использования могут быть связанны с юридической стороны проекта.

В крупных компаниях давно подняли свои локальные модели, а к ним также можно подключиться через плагины.

RTK Query ни разу не стал стандартом - он даже не поддерживает такие базовые вещи как бесконечная пагинация и нормализация, а апи сильно переусложнено на пустом месте, если сравнивать с тем же tanstack query.

Советую посмотреть в сторону react-redux-cache.

Постараюсь объяснить:

  • подавляющее большинство проектов использует Redux и переход на RTK Query будет сильно плавнее, чем на tanstack;

  • в RTK Query есть из коробки механизм useLazyQuery, чтобы подобное накостылить на tanstack, нужно изгаляться с enabled и refetch;

  • возможностей у него конечно меньше, поэтому разумеется нужно подбирать инструмент под каждый конкретный кейс.

useLazyQuery все объяснило спасибо. Сэкономлю одну строчку с `enabled: false`.

Нет конечно, смешно даже читать такое - это все что "руководителю отдела frontend разработки" пришло в голову сравнивая две эти библиотеки?

Про плавный переход - а вы вообще дочитали мой комментарий до конца перед тем как объяснять? Я не предлагаю использовать tanstack query с redux.

Еееее срач.

Просто объяснил почему мой коллега написал про стандарт. Сравнению этих двух библиотек можно посвятить отдельную статью/доклад/воркшоп, да что угодно.

Что касается реакта: его плюсом и минусом как раз является то, что там кучи вариантов использования всего со всем.

Всем добра ☺️

>Vue 3 имеет лучшую поддержку TypeScript

По сравнению с чем?

По сравнению с Vue 2, конечно. =)

Функциональный подход к DI и управлению потоком

В Angular 19 значительно изменился подход к внедрению зависимостей (DI) и управлению потоком данных. Новая функция inject() заменяет традиционный конструктор, делая код более лаконичным и гибким:

Так написано, как будто до Angular 19 не было функции inject() ...

Да ну его, но да: таки анонсировали Deno 2.0!

Странно, никто не упомянул про мол, который ещё на этапе проектирования был идеальным и не нуждается в улучшениях. /sarcasm

Давайте соберём конференцию и большим коллегиальным решением уже примем раз и навсегда взвешенное окончательное: мол или смоль?

Я может сейчас фронтенд-скуфом буду выглядеть, но что такое мол?

Фреймворк $mol, за авторством Дмитрия Карловского.

Сам глубоко в $mol не погружался - отталкивает гонор автора и язвительная модель рекламы $mol, что в совокупности множит на ноль возможно хорошие идеи фреймворка.

Понял, про Карловыча слышал только мемы, мы больше на всемирное комьюнити ориентировались пока писали, локальные штуки не так интересны.

Пока всемирное комьюнити жуёт сопли, мы уже и 3d движок на $mol запилили, и децентрализованную базу данных. Я уж молчу про те фичи, которые у нас уже 10 лет как есть, а вы даже не в курсе, что так можно было.

Это, безусловно, прекрасно. Но я все ещё мыслю в перспективе нескольких лет: что будет с поддержкой, будет ли заменяемость специалистов и прочие штуки. Где и как быстро мне нанять людей под это дело и как сильно нужно удерживать уже существующих. Ничего личного, просто бизнес.

Ответы на все эти вопросы есть на видео.

Не нашел внятных готовых примеров. У вас есть хоть один пример полноценного приложения которое можно посмотреть, в идеале боевой? на сайте не нашел даже примера банальной тудушки. на том же vue/nuxt далеко ходить не надо, открыть один из русскоязычных маркетплейсов, оценить производительность и т.д.

Я неоднократно видел ваши комментарии с рекламой фреймворка, но должны же быть публичные проекты, которое могут продемонстрировать возможности в бою?

С мобилы ничего непонятно :<

слежу много лет за этим проектом и его кодом, очень нравится движ вокруг этого фрейма, сам не рискну юзать...

в качестве работника я не смогу работу найти по такой специальности ((

в качестве директоре я не смогу найти грамотных специалистов по этой специальности ((

ну тема мне интересна очень, так как не каждый рискнет мутить чет свое крупное и на столько отличающееся от обычных практик

Всего там задач, помимо этой, ещё минимум на пол года, поэтому ищется middle+ фронтендер на полную занятость в данном проекте с дальнейшим переходом в другие.

В другие нормальные фреймворки, кода наиграются настрадаются. Ну и вакансия... вами писанная? Достойна мола скажем так - никакой конкретики, только водичка про мол.

А вот статистика

Человек спросил про статистику о моле - а в ответ ему рейтинг с целым JS?) А что уже мол всех похоронил? Ой как непрофессионально жирно

Вакансия, разумеется, для интеллектуального меньшинства. Вам она, к сожалению, не подойдёт.

Слава богу я традиционный специалист, инженер, а не представитель этих нетрадиционных ваших меньшинств.

Примечательно, что умные стесняются быть не такими как все, зато дураки гордятся тем, что ума им недостаёт.

Братва, жизнь все расставит по местам. И по вакансиям, и по фреймворкам.

Всем успехов найти ту работу и тот инструмент, который вам подойдет. =)

Ещё полезная информация от разработчиков будет? Ну по теме хотя бы?

Чем не угодил THREE.js, в котором и функционал шире, и поддержка устройств лучше, и примеров больше? Или, например, движок babylon, в котором и 3д графика, и физика?

Постарайтесь ответить без гонора ("Вакансия, разумеется, для интеллектуального меньшинства. Вам она, к сожалению, не подойдёт."), и сарказма ("У нас не только разработчиков нет, но и документации: https://mol.hyoo.ru/#!section=docs"), а по пунктам: у THREE.js / babylon нет, а у $mol есть, или в THREE js / babylon это не настраивается, а у $mol - настраивается, и так далее.

Three:

  • Много весит (170кб в ужатопережатом виде).

    • Поставляется со своей кривой UI либой, открывающейся во фрейме.

  • Не поддерживает реактивность.

    • Не умеет грузить ресурсы лениво.

    • Не умеет автоматически освобождать ресурсы.

  • Шейдеры пишутся в строковых литералах, а не в отдельных файлах.

    • Нет модульной системы для шейдеров.

    • Копипаст кода через препроцессор а-ля C++ замедляет их компиляцию.

    • Нет стандартной библиотеки шейдеров.

  • Не удобный API.

    • Нет автоматической группировки всех инстансов с одинаковым шейпом.

    • Рендеринг либо треугольниками, либо всё руками на шейдерах.

Babylon:

  • Очень много весит (1300кб в ужатопережатом виде).

    • Дальше можно уже не смотреть, но проблемы всё те же.

Много весит (170кб) / (1300кб)

Ужели в 2024 170 кб или 1.3 мб так иного для 3d рендера и игрового движка? Нет смысла уменьшать размер js, если модели, текстуры, звуки будут весить 10+ мб.

Поставляется со своей UI либой

Это плюс - не нужно шаманить дебаг меню, а модно взять готовое

Не поддерживает реактивность

Ленивая загрузка ресурсов 3д сцены не тривиальная тема, так что в любом случае придётся загружать вручную. В каких-то случаях, окэй, принимаю как минус THREE.js

Шейдеры пишутся в строковых литерах, а не в отдельных файлах

На мой взгляд это плюс, так как можно сделать shaders.json и грузить все разом, а не делать 10 запросов на сервер за каждым файлом.

Копипаст кода через препроцессор а-ля С++ замедляет компиляцию

Шейдеры в любом случае будут компилиться, если вы не кладёте их в кэш, а чтобы положить - нужно их скомпилить хотя бы раз.

Нет стандартной библиотеки шейдеров

Зато есть стандартные материалы, например https://threejs.org/docs/#api/en/materials/MeshStandardMaterial

Нет автоматической группировки инстансов с одинаковым шейпом

Думаю, это действительно лучше делать ручками, так как инстансинг в принципе возможен только если одинаковый шейдер и одинаковые текстуры (окей, можно взять textureArray, но он не везде может быть и минимальный гарантированный размер - 256 слоёв одинаковых по формату и размеру текстур).

Рендеринг либо треугольниками, либо всё руками на шейдерах

Как бы да, все GPU рендерят либо треугольники, либо линии.

А теперь по плюсам THREE js:

  1. Есть куча стандартных материалов

  2. Есть скелетная и морфовая анимация, блендинг, инверсная кинематика

  3. Поддержка множества форматов 3д моделей, ибо gltf не панацея

  4. Подробная документация

  5. Множество статей, вопросов и ответов, решений проблем новичков

  6. Рендер текста

С Вавилоном вы получаете полноценный движок игры, и нужно делать только игру, а не возиться с рендером, загрузкой/выгрузкой ресурсов и так далее.

3D не только в играх нужен. Впрочем, быстро запускающие игры - это прекрасно.

Скрипты являются критическим ресурсом. Модели и звуки могут грузиться и после начала показа сцены.

В $mol ленивая загрузка не просто тривиальная, а автоматизированная.

В MAM все использованные шейдеры собираются в один бандл без дублирования кода.

Нет смысла руками делать то, что прекрасно автоматизируется.

Я там прокомментировал эти "тесты".

Зарегистрируйтесь на Хабре, чтобы оставить комментарий