Комментарии 17
Спасибо, что делитесь своими разработками:)
опять одна библиотека с одним маленьким решением
Это путь в никуда, нужна полноценная система где у разработчика не будет возможности сделать "плохой" или "неправильный" выбор
Желательно вообще не делать выбор, что бы в фреймворки это было уже настолько продумано, что бы внешнее решение не требовалось
Это путь в никуда
Нет. Это может быть путь в никуда именно для вас, а для настоящих разработчиков это путь вперед и вверх!
нужна полноценная система где у разработчика не будет возможности сделать "плохой" или "неправильный" выбор
Получается вы не можете(и не хотите) сделать шаг влево шаг вправо без указки начальника/хозяина/и т.п. Ну как бы к такой жизненной философии не надо людей привлекать, человечество не так давно от нее освободилось) Кто-то предпочитает свободу, а кто-то рабство. Я например отношусь к тем, кто принципиально предпочитает свободу.
Желательно вообще не делать выбор, что бы в фреймворки это было уже настолько продумано, что бы внешнее решение не требовалось
Мда, это конечно очень удручающе) Боюсь вы не ту профессию выбрали)
опять одна библиотека с одним маленьким решением
Так это прекрасно, одно маленькое, но качественное решение, чем большой уродливый монстр.
Все берут эти "хорошие маленькие решёния" а получают глючное приложение на реакте
странно от Go разработчика слышать хейт в сторону небольших библиотек
Все берут эти "хорошие маленькие решёния" а получают глючное приложение на реакте
Кто всё? 100% разработчиков? Или под "все" вы имеете ввиду только плохих разработчиков? Почему то у меня все прекрасно получается когда я беру хорошие маленькие решения и много у кого все прекрасно получается.
Большинство
На самом деле конечно чаще берут то что уже знают, это самая верная эвристика
Здорово что у вас получается, правда
Я аппелирую только не совсем к этому. Да из маленьких либ можно собрать хорошее приложение, но это сложнее как при постройке так и в поддержке, лучше когда флоу продуманы, cookbookи написаны
Но ещё лучше когда остаётся написать только бизнес логику, а всё остальное берёт на себя фрейморк, при этом никак не ограничивая закопаться вглубь
Чем "настоящий" разработчик отличается от "ненастоящего" ? Я вот код пишу, даже зачастую руками, я разработчик , по вашему ?
Незнаю что вы там навыдумывали про свободу какие то бредни
Хз реально чем вы кичетесь, не понимаю. Лучше конечно инструмент решает много задач, а не приходится под каждую задачу подбирать отдельный инструмент, особенно во фронтенде, так как это полностью формализованная область знаний
Чем "настоящий" разработчик отличается от "ненастоящего" ? Я вот код пишу, даже зачастую руками, я разработчик , по вашему ?
Настоящий - не тот, кто пишет код руками, а тот кто любит это делать, любит разбираться досконально всё устроено, как всё работает и т.п. И т.к. априори настоящий разработчик уже знает что и как устроено и что и как работает, то понятное дело он хочет делать все максимально удобно для себя, без ограничений и т.п. Потому что он знает, как сделать лучше. И если его не устраивает монструозный фреймворк all-in-one, то это не потому что разработчик плохой, а потому что фреймворк плохой.
Незнаю что вы там навыдумывали про свободу какие то бредни
Это не выдумки, вы прямо говорите что свобода плохо, надо зажимать в тиски разработчика что нельзя было ступить шаг влево шаг вправо.
под каждую задачу подбирать отдельный инструмент
У меня основа Typescript + React + MobX, все остальные задачи я решаю сам, и не подбираю под каждую задачу библиотеку, более того за много лет у меня давно есть решения почти на все случаи жизни) У меня и свой роутер которому уже лет 8 и инструменты для работы с формами/валидации, всякие хэлперы для асинхронного кода, плагины для Vite и т.д. и т.п.
если его не устраивает монструозный фреймворк all-in-one, то это не потому что разработчик плохой, а потому что фреймворк плохой.
Логически неверный аргумент
Про свободу. Где свободнее, в строго типизированных языках или динамических ? Где свободнее, в языках с прямым доступом к памяти или в языках где есть GC ?
Вся история программирования - про искусственные ограничения. Но при этом должна оставаться гибкость в использовании, как раз для решений разработчика.
За mobx like, хороший инструмент
Для себя я выбрал $mol, по скорости как mobx, только не нужно следить за состояниями, реактивностью, он сам под капотом всё делает хорошо
Для себя я выбрал $mol
Это всё объясняет))))
Вся история программирования - про искусственные ограничения. Но при этом должна оставаться гибкость в использовании, как раз для решений разработчика.
Да?)) Понятно) Нужно чтобы машина не разгонялась больше 20км/ч, но при этом нужно чтобы она разгонялась до 300км/ч)
Это, конечно, решает частную боль автора этой либы, но их всегда будут писать, как минимум по той причине, что что-то большое иногда происходить от чего-то маленького, так что в этом нет ничего плохого
"ведь к более качественному закрытому коду доступа нет"
Объясните пожалуйста, а чего это он более качественный?
Статистики именно по "качеству" нигде нет, исхожу только из личного опыта и открытой статистики. Например, в прошлом году на Гитхабе 81% коммитов были именно в приватных рабочих репо, и процессы там как правило строже - с ревью, тестами, постоянной production-доработкой и адаптацией к новым технологиям.
А в публичных репо большая часть - пет-проекты или библиотеки даже без базовых тестов / эксперименты, которые в проде никто и не использовал. Да и из оставшихся репо многие устарели или заброшены с много лет висящими issues, потому что OSS очень непросто монетизировать, а на энтузиазме далеко не уедешь. Поэтому мысль "ИИ в основном обучается на менее качественном коде, не готовом к продакшену и стабильной предсказательной генерации", думаю, валидна.
Конечно, есть OSS авторы с шикарными библиотеками, но как правило они их писали как раз для продакшена и после нескольких лет доработок и обкатки выложили в публичные репо. Есть и компании, у которых бизнес-модель построена на OSS и они могут нанимать большие команды, чтобы делать качественно. Но это капля в море
я только ближайший аналог знаю Nano Stores Router (да знаю подход другой, но там проще). В теории это намного лучше чем vue-router. Но поддерживать это будет больно из-за обилия адаптеров. Тут ведь не только на чистом vite делают, тут есть метафреймворки вроде nuxt/next/remix/astro. И под каждого нужен свой адаптер. Хорошо если подхватит комьюнити, но я не думаю. Кстати я не нашел как использовать metadata и локализацию
Метафреймворки на то и есть, чтобы под них не писали адаптеры, а вся экосистема была "из коробки" - туда независимым разработчикам очень сложно интегрироваться, да и не нужно.
По поводу metadata (title, description, social теги) - это хотя и можно сделать через роутер (внутри beforeEnter), лучше все-таки использовать компоненты страниц. То есть проставлять их при рендере на onMount или другими способами конкретной UI-библиотеки, так сохранится поддержка SSR и MPA.
Под локализацией не понял, что имеется в виду, так как есть разные схемы. Например, заводят поддомены вида lang.mydomain , тогда в конфигурации роутера никаких изменений делать не нужно. Либо если через params - можно к каждому path добавлять параметр /:lang/home , либо через query: { lang: (v) => ['en', 'ru'].includes(v) } . Я бы рекомендовал вариант с поддоменами - поисковики с этим лучше работают, да и код не нужно подстраивать.

Reactive Route — новый роутер для разных фреймворков и реактивных систем в 2 КБ