프레임워크들의 단점 - tailwind, mui

tailwind

기본적인 특징은 여러 정의된 클래스 네임을 다이렉트로 박으면서 사용하는것인데...

1. 의미없는 클래스명 (시멘틱하지 않다)

column_1 같은 숫자를 붙이는 것이나
largeText 같은 단순히 ui를 보여주는 용도의 클래스명으론 이 선언된 클래스의 ui의 이름을 파악하기 어렵습니다.

description, wrap 등 ui가 아닌 의미가 있는 단어를 사용해야 합니다.

wrap이나 inner 같은 의미없는 클래스를 선언하는 것이 시멘틱하지 않다는 의견이 있지만 모든 클래스가 시멘틱 할 필요는 없습니다.

시멘틱하지 않기에 시멘틱 하지 않는 것으로 보여집니다.

다시말해 의미가 없는 단순히 감싸는 용도의 스타일이라는 거죠. 그렇기에 시멘틱한 클래스보다는 신경을 덜 쓰게됩니다.

이럴때는 부분적으로 tailwind를 쓰는것도 괜찮으나, 이 와중에 반복되는 부분이 있다면 묶음 처리로 해야 아래에서 나열되는 단점들에 포함되지 않습니다.

2. 길어지게 되는 클래스명

inline-flex items-center rounded-full border border-transparent bg-indigo-600 px-6 py-3 text-base font-medium text-white shadow-sm hover:bg-indigo-700 focus:outline-none focus:ring-2 focus:ring-indigo-500 focus:ring-offset-2 mb-6

이 클래스 묶음은

이 버튼 ui를 보여주기 위해 사용됩니다.

mb-6같은것은 필요가 없긴한데 그럼에도 여전히 깁니다.

인라인 또는 css 파일에서 작성시 한줄로 작성하는 것은 가독이 안좋으며 가독이 안좋으니 수정하기도 불편합니다.

그 특성대로 수정할시에 한눈에 들어오지 않고 처음부터 일일이 찾아보면서 수정해야 합니다.

결국 인라인으로 스타일을 작성하는 것과 같은 효과입니다.

저 부분을 묶어서 class="btn" 이런식으로 압축해서 사용할수 있지만 관리포인트가 단 한개의 파일 입니다. 그 안에서 .btn 에 대한 위의 속성들을 정의하고 사용합니다.

이때, 길어진 inline 속성들을 공통 파일에서 정의해서 다시 활용하느냐, 아니면 이대로 놔드느냐 에 대한 판단이 애매합니다. 만약 매번 정의를 한다면 관리하는 파일은 하나이기 때문에 꼬일위험도 높습니다.

코드에서 btn으로 작성해도 실제 개발자모드에서는 btn으로 보이는지 아니면 위처럼 모든 클래스들이 보이는지는 개인적으로 확인되진 않았습니다.

이런 클래스 네이밍은 최소 6년전에 위의 설명했던 내용들처럼 시멘틱하지 않다. 가독이 안좋다. 수정이 불편하다등의 내용으로 이미 마크업쪽에서는 시장된 방법론입니다.

그래서 퍼블을 하지 않고 바로 개발을 하게된 케이스에서는 편하다고 생각할 수 있으나 장기적으로 보면 좋지 않습니다.

3. 모든 것을 지원해 주지 않는다.

[https://codepen.io/rudwnok/pen/abgdvVX] scss의 삼각함수를 이용한 행성 배치 ui
위 코드는 tailwind 에서 지원이 되지 않습니다.

결국

<div id="circle-container" class="relative w-[260px] h-[260px] border border-gray-300 rounded-full">
    <div class="dot absolute w-[10px] h-[10px] bg-red-500 rounded-full"></div>
    <div class="dot absolute w-[10px] h-[10px] bg-red-500 rounded-full"></div>
    <div class="dot absolute w-[10px] h-[10px] bg-red-500 rounded-full"></div>
  ...
</div>

그 외로 input 의 css인 valid 나 placeholder-shown은 없음.

 

html은 더러워지고 js로 밖에 해결이 되지 않습니다.

4. 유지보수 불편

화면에 보이는 특정 ui의 css를 수정하고 싶다. 라고 할때

1. 화면에서 보이는 ui의 개발자모드의 css를 확인한다.
   그 다음엔? class명은 너무 길어서 class명으로 찾으려면 다 긁어서 전체검색으로 찾아야 함.
   page를 먼저 추적? 특정 행동을 해야 볼수있는 화면이라면? (로그인이나 특정 단계 이후 볼수있는 화면)

5. 추가 적인 설정이나 사용이 강요됨.

기본 단위가 rem이기 때문에 px로 변환하는 작업을 tailwind.config.js에서 해줘야 하고,

 

class명이 길어지기 때문에 @layer components 로 묶어야 하며, 이 @layer 를 관리하는 css파일은 한개가 디폴트인데. @layer 가 추가될수록 여러사람이 작업할수록 공통파일을 계속 수정하는 꼴.
만약, 관리하는 css파일을 더 추가한다면 다른것과 다른것이 없게됨.

 

물론 모든것에 @layer components를 사용하지 않아도 되는데 길어지게 되는것이 보기 싫으니 확장프로그램 fold를 써야함.

 

길어진 class명에 순서도 맞춰야 하니 headwind도 써야함.

 

위에서도 언급했던 css override를 위해서 tailwind-merge 를 썰치해야함.

 

tailwind 하나 쓰는데

• tailwind.config.js 설정
• headwind
• fold
• tailwind-merge

벌서 4개가 필수적인 작업이 들어가네?

6. 관리포인트의 분할화

css에서 애니메이션이 들어간다면?

애니메이션 이름, 키프레임, 백그라운드 같은 요소를 죄다 tailwind.config.js에서 정의를 해야되는데 이거 여기에서 관리하는거 맞음?

단 한번만 사용할 코드인데 공통코드에 작성을 강요하는게 맞음?

좀만 복잡해도 배보다 배꼽이 더 크거나 구현이 불가능해져 버림.

 

 

※ 다른사람의 tailwind 단점 글

https://miriya.net/blog/clk0ml8qi0009h2m3amur1y0v

[나는 참 Tailwind CSS가 싫어요

나는 테일윈드 CSS를 정말 싫어한다. 나는 코드를 짤 때 한 파일당 줄 수가 150~200줄이 넘어가게 짜지 않고 채썰어서 관심사 분리를 확실하게 하는 편이다. 하지만 테일윈드는 예전에 부트스트랩

miriya.net](https://miriya.net/blog/clk0ml8qi0009h2m3amur1y0v)

 

 

※ atomic css에 대하여

part1

https://tech.kakao.com/2022/05/20/on-demand-atomic-css-library/

part2

https://tech.kakao.com/2022/05/24/on-demand-atomic-css-library-2/

[내가 하면 더 잘 만들 것 같아서 만들어 본 세상 귀여운 on-demand Atomic CSS Library. -Part.1

- 내가 하면 더 잘 만들 것 같아서 만들어 본 세상 귀여운 on-demand Atomic CSS Library.최근에 CSS 계에서 주목받고 있는 TailwindCSS를 써보셨거나 들어보신 적이 있나요? 혹은 Utility-first CSS, Atomic CSS, Func

tech.kakao.com](https://tech.kakao.com/2022/05/20/on-demand-atomic-css-library/)

mui

1, 2, 3 코드 : https://codesandbox.io/s/mui-theme-customization-and-overrides-w51hw?file=/src/App.js
4 코드 : https://codesandbox.io/s/uqt9m?file=/pages/index.js

1. 일치하지 않은 작성한 속성 순서와 실제 렌더링의 속성 순서

실제 선언된 순서는 margin-left, backgorund, diplay, color 순이지만

적용된 순서는 color, display, background, margin-left

게다가 적용된 순서는 일반적인 css 작성 순서에 어긋납니다.

이로 인해 다른 협업자가 스타일을 수정할일이 생길때 '추적'이 굉장히 힘듭니다.

2. 코드 작성 방식

기준 코드 : https://codesandbox.io/s/uqt9m?file=/pages/index.js

독자적인 스타일링 문법을 가지고 있어 커스텀 자체가 쉽지 않습니다.

css in js 의 공통적인 작성 방식은

export const ItemStyle = styled.div`
  position: relative;
  display: flex;
`;

각각의 속성들에 ''가 붙지 않습니다. css in js에서 스타일 속성들을 자동완성 하려면 특정 확장프로그램이 필요한데 mui만의 자동완성 확장프로그램이 또 필요합니다.

3. 과도한 클래스명

버튼 하나에도 ~root , ~root, ~contained, ~button 처럼 기본적으로 4개가 붙고, 커스텀 클래스 부여가 불편합니다.

커스텀 클래스 부여가 불편하기 때문에 클래스로도 '추적'이 불편합니다.

4. 고유한 상태값

focus같은 순수 css 처리해도 되는것들이 자체적인 props 속성으로 정의되어있습니다.

focus일때 스타일을 수정하고 싶으면 css를 수정하면되는것이 아닌 정의된 이벤트에 속성을 줘야합니다.

마찬가지로 '추적' 시에 css를 찾고 싶은데 이벤트를 먼저 찾아야되는 불편함이 있습니다.

일반적인 css in js 나 css도 '관리'가 불편한부분이 있는데
mui는 '협업', '사용', '추적' 면에서 단점이 나와 css프레임워크의 기본 단점을 벗어난 단점들을 추가로 갖고 있습니다.

도입을 하려고 한다면 제발 멈춰주세요.

총정리

css 라이브러리나 프레임워크는 어드민같은 수정이 거의없고, 유저가 직접사용하지 않는 부분에서나 고려는 해볼수있으나

실제 유저가 사용하는 서비스에서 사용하게되면 위의 단점들이 너무나 크게 작용합니다.