Какие принципы нужно соблюдать при разработке фреймворков по типу Bootstrap/Tabler, UIKit и прочих?

Question

[NedoKoder]

Привет народ. Иногда пишу какие-то проекты для автоматизации всякой всячины. Я больше по бекенду, потому чтоб не возиться с фронтом — юзаю всякие бутстрапы, UIKit и прочие. Хотел на Tailwind перейти, но количество классов в HTML — это жесть, поэтому нет.

В чем собственно проблема

Проблема в том, что у этих готовых решений есть "недостатки", из-за которых я не могу на одном остановиться.

У кого-то лучше модальные окна, у кого-то компоненты красивее, но при этом что-то другое хуже, чем у конкурента.

У одного меню на ПК норм, на мобилке ужасное, у другого наоборот.

В итоге — каждый раз в зависимости от проекта приходится искать компромиссы.

Так вот, так как нынче бушуют всевозможные ИИ, решил создать свой CSS/JS фреймворк для личного пользования (может потом и в паблик закину, если чё путное получится).

Понимаю, что создание фреймворка — дело время-затратное, поэтому решил сначала сделать базу, каркас.

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

Вопрос такой:
Какие принципы должны лечь в основу создания CSS-кода, чтобы потом не пришлось ничего ломать и переделывать в будущем?

Спрашивал у разных ИИ — советы у разных моделей иногда противоположные:

• кто-то советует адаптив писать в конце каждого файла
  
• кто-то — выносить в отдельный файл типа adaptive.css
  
• кто-то — делать отдельный файл для каждого компонента: container.css + container.adaptive.css
  
• кто-то — за mobile-first
  
• другие — за подход, где базовые стили под ПК, а адаптив под мобилки
  

и прочие пункты в таком духе.

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

Для себя накидал пока такие. Может какие то плохи и нужно менять?

+Базово только 2 брейкпоинта, до 768 и после.
+ Всё оформление в отдельный файл аля theme.css потом переопределяя другим файлом по необходимости, в т.ч это касается и темных тем.
+ модульность. Один файл, одна логика. Удаление любого css файла кроме файла темы и файла с переменными, не должно влиять на другие файлы
+ один класс у всякого элемента базовый, остальные влияют лишь модифицируют внешний вид

Пока только такие

Буду благодарен за любой опыт и советы!

Comments

[Ankhena]

Все ИИ обосновывают и всё звучит логично, причём разные по сути решения, но хочется услышать мнение от живых людей

А по-вашему, ИИ на основе чего вам всё это насоветовал?

Спрашивал у разных ИИ — советы у разных моделей иногда противоположные:

Да, люди ответят вам тоже самое.
Только в вашем перечне ещё перепутались исходники и конечный код - это раз.
Сейчас появился нативный нестинг в CSS - это два.

mobile-first vs desktop-first

Ну логично, целевые аудитории разные, задачи разные. Откуда возьмется один ответ "делай только так"?
В большинстве случаев сейчас будет mibile-first.

чтобы потом не пришлось ничего ломать и переделывать в будущем?

Вроде называете себя разработчиком, а мечтаете о какой-то утопии.

+Базово только 2 брейкпоинта, до 768 и после.

Вообще страшно, но возможно, под ваши проекты подходит. Мы их не видим.

Всё оформление в отдельный файл аля theme.css потом переопределяя другим файлом по необходимости, в т.ч это касается и темных тем.

Не понятно зачем в отдельный файл. А при наличии кастомок, так совсем.
При разработке чаще всего удобно, когда стили одного блока в одном месте и не надо скакать по файлам (речь про файлы исходников, а не в билде).

модульность

В целом логично.

[its2easyy]

если

у этих готовых решений есть "недостатки", из-за которых я не могу на одном остановиться

то почему бы просто не сделать форк и менять в нём то, что не нравится? в придачу получить готовую архитектуру, которая точно будет лучше чем у самописа

Answer 1

[Алексей Уколов]

Вашим фреймворком (тем более написанным с помощью генераторов текста) никто пользоваться не будет, так что ориентируйтесь на собственные задачи и предпочтения.
А базу можете подсмотреть во всяких бутстрапах, UIKit и прочих - там уже набиты все возможные шишки, лучше вы не придумаете. Можете только что-то упростить для себя, понимая и принимая ограничения, которые это удаление создаст.

Comments

[NedoKoder]

Ну я же написал что пишу для себя. В чем проблема заюзать ИИ для своих нужд? А то что он потом может быть в паблик выложен, и что? Будет не 100 фреймворков, а 101. Что это изменит? Я не любитель фронта чтобы изучать историю бутстрапа и u uikit, чтобы их базу выписывать

[VoidVolker]

NedoKoder, потому что настоящего ИИ в публичном доступе нет.

[Алексей Уколов]

NedoKoder, да я вам не запрещаю же ни фреймворк писать, ни ИИ при этом использовать. Но ценность результат будет иметь только для вас - вам и определять критерии.

Answer 2

[VoidVolker]

Те же самые, как и при разработке любого другого ПО: планирование, декомпозиция, модульность, документация, а так же фокусировка на достижении приоритетных целей. Определитесь сначала с проблемами, которые вы хотите решить с помощью данного фреймворка и уже от этого отталкивайтесь. Описываете проблему, ограничения, требования - далее ищите возможные решения, выбираете оптимальное и проектируете уже более конкретно. Постановка задачи -> техническое задание -> частное техническое задание -> проект -> декомпозированный и проработанный проект -> реализация. Примерно так.

Answer 3

[Алексей Голягин]

Сделайте так:
1. Файл с тем что используется везде, нормалайзер, сетка, еще что то - в принципе как у бутстрап
2. Компоненты по очереди (с комментариями), чтобы можно было выкинуть эти куски, если они не нужны
Ну и соответственно mobile-first стили, от мобилы к ПК
Я бы делал так)