Обновить

Комментарии 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) } . Я бы рекомендовал вариант с поддоменами - поисковики с этим лучше работают, да и код не нужно подстраивать.

да согласен меня не в ту степь занесло про метафреймворки.
metadata тоже не нужно, можно через ssrContext пробросить. (или provide/inject). Просто привык к meta, layouts, file routing, префиксам и тд.
Здесь просто этого нету, ладно надо просто поиграться.

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

Публикации