장점 : 1. 사이드 플젝할때 이것만큼 빠른 결과물 뽑는건 없었음 2. 눈에 익으면 컴포넌트 보는 순간 어떤 결과물일지 대충 보임 3. 아토믹 디자인할때 유틸리티css가 잘 어울림 단점 : 1. 협업할때 분명한 러닝커브가 있음 2. 반응형 css 할때 일반 css보다 더 빡셈. (nest가 안되서 답답함) 결론 찍먹해도 됨. 팀끼리 쓰자고 하면 써봐도 됨
Tailwind CSS 사랑하는 사람으로써 장점 더 적어보겠습니다. 1. 유틸리티 추가하기 쉽다. config 파일에 colors: { primary: '#8856FE' } 처럼 커스텀 색깔을 추가하면 text-primary, bg-primary, border-primary 등의 유틸이 자동으로 추가됩니다. 2. css 를 normalize 해준다. 웹브라우저 마다 서로 다른 디폴트 스타일들이 있는데 이걸 통일시켜서 일관된 UI 를 만들 수 있게 해주고, 쓸데없이 들어가 있는 기본 마진 등을 없애서 원하는 스타일을 주기 쉬운 상태로 만들어줍니다. 3. 영상에서 스타일 재사용이 어렵다고 하셨는데 사실 매우 쉽다. 2:47 에서 소개해주신 방법으로 component 클래스를 만들면 되는데, 여기서 좋은 점은 쉽게 오버라이드가 가능하다는 것입니다. 예를들어 영상에 나온 card-text 에서 폰트 사이즈만 text-lg 를 text-xl 로 바꾸고 싶으면 class="card-text text-xl" 처럼 원하는 부분만 덮어쓸 수 있습니다. props 를 추가하는 것보다 간편하고, 인라인 스타일을 주는 것보다 깔끔합니다. 4. 재사용이 필요하지 않는 부분을 빠르게 개발할 수 있다. 가장 중요하게 생각하는 부분인데 프론트 개발이나 퍼블리싱을 하다 보면 생각보다 재사용할 일이 없는 코드가 굉장히 많습니다. 순수 css 를 쓰거나 styled-components 같은 것을 쓴다면 굳이 재사용이 필요하지 않은 부분에도 product-section-sidebar-inner-container 따위의 바보 같은 이름을 짓느라 시간을 많이 낭비하게 됩니다. 따라서 이런 부분을 빠르게 개발하고 나중에 재사용할 필요가 생기면 그때 component 클래스로 빼면 됩니다. 이런 전략을 잘 활용하면 코드도 나름 깔끔하게 유지할 수 있습니다.
3번 재사용이 어렵다는 매우 맞는 말씀이지만 tailwind 자체가 기존에 css나 styledComponent 등으로 개발했을 때 그게 이 사람 저사람 왔다갔다하면서 css 설계하고 naming한 거까지 인수인계하지 않기때문에 새로 입사해서 이거 좀 해주세요하면 js 온보딩할 거도 많은데 css 구조까지 다 파악 안 하고 그냥 새로운 css 추가해서 급한대로 해주는 게 국룰입니다. 그래야 다른 css랑 충돌나서 입사하자마자 욕쳐먹는 일이 안 생기거든요. 그렇게 2년 3년 지나다보면 여러 개발자들의 영혼이 모아져서 괴물 같은 css파일 혹은 styledComponent가 만들어져있습니다. 걷어내야하는데 이건 마치 지뢰찾기를 하는 느낌이라 전체 검색으로 그걸 사용하지 않는다고 해도 혹시 다른 영향을 받아서 주말에 쉬어야하는데 화면 깨졌다고 연락올까봐 안 건드립니다. 절대 안 건드려요. 근데 tailwind는 row 레벨로 독립적인 className을 적는 것이라 다른 거랑 충돌이 나고 그럴 수가 없습니다. 그리고 재사용이 어렵다는 단점을 react 같은 거 쓰시면 컴포넌트 자체가 통으로 재사용이 되기 때문에 딱히 단점이라고 볼 수 없습니다. styling을 tailwind로 최대한 쉽게하고 그 시간에 그냥 TDD나 cypresss 같은 거 시도하시는 게 본인 몸값에도 더 도움되실겁니다. 그리고 styledComponent 쓰시는 분들... styledComponent 이름 좀 MuiDropdownMenu 이렇게 해놓으시면 mui 디자인 커스터마이징했다는건지 저게 mui 기본 배포하는 라이브러리 컴포넌트인지 다른 사람이 알 길이 없습니다.
"Why not just use inline styles?" 해당 기술문서에 core concept에 나온 헤드라인 입니다. 실제로 해당 기술을 만든 사람들이 가장 많이 받은 질문이고 본인들도 그렇다 생각했기에 문서에 기록이 되어 있는거죠. 이미 아래 댓글에서 비판한 내용을 개발자들도 고민을 이미 했다는 겁니다. 해당 기술을 만든 개발자가 무능한게 아니고요..-_- 결국 철학적 접근인거죠. 우수한 개발자는 함수형과 클래스 형태의 장단을 어떻게든 조합해서 해결하려고 하지만 멍청한 개발자들은 함수가 최고니 클래스가 최고니 하고 있는거죠.. 실제로 그냥 inline style이 아닌 이유로 반응형 그리고 상태지원 명칭에 대한 고민을 안 해도 된다고 기록하죠. 그러나 근본적인 문제는 남아 있습니다. '가독성' 문제가 남아 있습니다. 오히려 문서에는 classname을 결정하는데 고민을 하지 않아도 된다고 하였지만 사실 이것도 트레이드오프가 있는 겁니다. card도 해당 기술문서에 소개된 카드는 엄청 dump한 수준의 카드 디자인인데 현실은 그렇지가 않으니깐요. 개발에서 Trade off는 늘 생각해야 됩니다. 외주회사에서 퍼블리셔가 존재해서 빠르게 화면을 만든다면 저는 해당 기술이 좋다고 봅니다. 그런데 프론트엔드가 있고 React를 쓴다면 저는 좀 더 이름을 결정하는데 시간을 써도 된다는 입장입니다. 그러면 오히려 css in js 기술을 쓰는 것을 추천하고요. 어떤 기술을 쓰는 것이 맞는지는 개발자 역량이 결정합니다. 그러니 싸울 필요는 없죠. 오히려 이게 무조건 좋다 나쁘다 단정하는 개발자들은 상종하면 안되죠..
부트스트랩이나 테일윈드 쓸 때 디자인이 나와있는 경우 일일이 손봐줘야되는거죠? 디자인이 이쁘지도 않고 커스텀한다고 손이 더 가는 경우도 있고 어떤건 자기 멋대로 스타일이 들어가있어서 그걸 또 다시 손봐야되는 경우가 왕왕 있어서요. 쓰면 편하다는데 왜 하나도 안 편한지 ㅠㅠ... 쩝...
백앤드 개발자만 있는 곳에서는 부트스트랩이나 테일윈드 쓰는거 괜찮은거 같습니다. 근데 프런트 개발자나 퍼블리셔 직군이있는 곳에서는 테일윈드는 특정 폼 (input이나 button)등을 제외하고는 지양하는게 맞다고 생각합니다. 폼등은 만들기 귀찮어서 ㅇㅅㅇ 특정 폼값에 클래스 추가 방식을 써서 커스텀해서 쓰면 좋다고 생각 합니다. 추후에 유지보수때 mb-4 이런거 들어가있으면 진짜 수정하는데 피똥쌈 ㅠㅠ
긍까 부트스트랩이랑 비교하자면 테일윈드는 뷔페같은거여서 진짜 원하는 게 다 있는데 그 뷔페에 맛 없는 음식이 있을 수 있듯이, 쓸떼없이 좋은 기능이 너무 많음 부트스트랩은 걍 정해진거만 주는 식당? 이라고 하면 됨 비유하자면 맛은 보장됐지만 음식은 맛있지만 종류가 다양하진 않음 개인적으로 디자인 잘 못하는 사람들은 정해진 부트스트랩만 써도 꽤 예쁘고 디자인 잘한다 싶으면 테일윈드로 편하게 디자인 해보면 됨 (나도 함 써볼까)
디자인요소는 개발적으로 반복요소를 찾기가 일반적인 로직작성하고 보는 관점이 판이하기 때문에 인라인으로 보이는것만 고치는거를 선호할 수밖에 없는데 그걸 더 부추기는 매우 좋지않은 프레임워크라고 개인적으로 생각합니다. 개발자만 좋아하는 디자인 추상화가 도를 넘었다고 생각하고 있어서 사용이 꺼려지게 되는거 같습니다
좀 더 복잡해지면 inline style 방식이라 수정 하기 많이 어려워져요. 그리고 디자인이 taiilwind spec 대로 8px 기준/색감이 아니면 다 커스텀으로 해야 합니다. 아무리 react 방식이라 해도 재사용이 안되고 하려면 다 @apply 방식으로 해야 하고요...@apply를 할거면 왜 tailwind를 만들었나 싶네요. tailwind는 css도 파악 못하는 개발자가 어떻게 하면 바퀴를 재 발명 할수 있을가 하며 무언가를 "개발" 하기 위해 만든 개발자의 무능함의 결과라고 봅니다. tailwind가 3.0까지 간게 신기할정도 입니다. Rapid prototype 할거면 모르지만 그 부분에서도 차라리 component로 뺀 bootstrap이 나을겁니다. tailwind로 반응형 함 해보세요, 어캐 되는지 ㅎㅎㅎ
그리고 때와 상황에 맞게 바닐라 css랑 병행해서 사용하면 이거 하나로 얻는 생산성이 단점을 훨씬 상회한다고 생각함. 테일윈드을 부분적으로 내 생산성을 올려주는 도구 그 이상이하도 아니게 접근을 해야지, 모든 스타일링을 다 해줄 수 있는 실버불릿으로 css를 퇴출시키겠다, 이런 마인드로 접근을 해서 사용한게 아닌가 싶음.
@@lizerd 님 제 댓글에서도 보고 좀 생각해 봤는데, 복잡한 계층의 프로젝트를 경험해보지 못하신것 같다는 생각이 드네요. 단순한 구조이거나, 설계가 거의 완벽해서 변경이 거의 발생하지 않는 프로젝트에서는 님 말이 맞는데, 구조가 5단 6단 들어가는 복잡한 컴포넌트 구조를 가진, 예를들어 아토믹 디자인 같은 경우에서는 무한 커스텀의 악순환에 빠집니다. 특히 기획자/디자이너가 테일윈드&아토믹에 대한 이해도 없이 바닐라 css를 던져줄 경우 그걸 테일윈드화 시키는 css 설계라는 공정이 하나 더 중간에 끼기 때문에 엔지니어의 부담이 커집니다. 이걸 테일윈드 기본 속성으로 가능한가를 먼저 판단하고, 가능하지 못한 부분이 있으면 뭘 어디까지 테일윈드로 커스텀을 할것이며, 테일윈드로 커스텀을 하느냐 바닐라 css로 그대로 사용하느냐에 대한 설계 레벨의 판단이 매 아톰을 개발할 때마다 개발자들에게 던져집니다. 어렵게 커스텀 만들어놨는데 디자이너가 이걸 재사용 해주지 않으면 쓸대없는 시간 낭비가 되고요. 이게 삽질 하던걸 굴삭기 가져와서 개발하는 것 만큼 좋은건 저도 써봐서 아는데, 기획자/디자이너가 라이브러리에 대해 전혀 이해가 없을 경우 프로젝트 엎어집니다.
그거 정말 미세하게 효과 보이는거라 아마 gray color로 맞춘거면 정말 모니터 해상도 성능에 따라 반영된건 지 파악하기 힘들거에요 ㅋ blue, red 같이 단색이 뚜렷한 color에 한번 테스트 해보시구 만약 안된다면 부모 태그 구조 문제 or config 파일 옵션 커스텀 해놓은 게 있는지 확인해보세요!
장점 : 글쎄요...................타이핑 조금 덜해도 되는거...?;;; (과연 파워풀할만한 뭔가가 있을까...;;) 단점 : 일단 다른 사람에게 욕부터 먹고 시작함............ (인라인으로 스타일 때려박는거랑 다를거 없기 때문...) 결론 : 나 혼자 만들어서, 나 혼자 수정하고, 나 혼자 끝낼 프로젝트라면 써도 상관없음~~~!!!
아마 대부분 스타트업에선 소규모 팀 단위라 css 컨벤션을 구축할 시간이 많이 부족할 거에요. 그렇기에 tailwind 특유의 규칙성에 따라가다 보면 팀 단위의 css 컨벤션이 맞춰지는 관계로 선호하는 개발팀도 있습니다. 디자이너의 디자인 시스템 기반에 따른 재사용성 컴포넌트와 타이포그래피 옵션에만 크게 관심을 기울이면 일정이 빠듯한 프로젝트 팀들에겐 더욱 편한 라이브러리 입니다. 러닝커브라고 종종 언급하는 사람들 계시는데,, 좀 오버해서 말한다고 저는 생각해요.. tailwind document 몇 번 보다 사용하면 바로 습득이 올거에요.. 전역 상태 관리 Redux, 입력 form 상태 관리 formik 등등 이런 라이브러리들의 러닝커브에 비하면 tailwindCSS는 충분히 2시간 안에 감이 옵니다.
테일윈드 쓰는 현장 세곳 정도 경험했는데, 테일윈드의 진정한 단점은 디자이너가 테일윈드에 대한 이해도가 없을때임. 테일윈드에 없는 속성값을 디자인에다가 쳐 박아버리면 테일윈드 전역설정으로 그 새로운 속성값을 개발하던지, 그 속성값을 우회에서 css를 박던지 해야 됨. 우리 서비스 테일윈드 쓰는거 알면서 좆되보라고 하는건지 계속 픽셀값 디자인 테일윈드 디자인이랑 엇나가는 디자인 던져주는 디자이너가 있어서, 좀 테일윈드 대로 재사용 가능한 디자인을 만들어서 던져주면 안되냐고 하니깐, 내가 왜 그래야 하냐. 그거 구현하는게 개발자 일 아니냐. 그렇게 하면 디자인 안 이쁘다 이지럴 해서 회사에서 대판 싸움. 썅련이 디자인 부심이 하늘을 찔러서, 재사용성 때문에 테일윈드 도입한건데 재사용 할수 없는 오리지널리티 뿜뿜 하는 디자인을 쳐 던져주면 어쩌자는건지. 프론트 개발자들끼리 모여서 이럴거면 테일윈드 그냥 날려버리면 안되냐고, 그냥 css 개발하는게 빠르겠다고 담배 피면서 하소연함.
디자이너가 테일윈드를 알던지, class를 디자이너한테 수정시키면 굉장히 좋은 물건임. 테일윈드 현장 세곳 중에 마크업에 관련된 코드는 전부 디자이너가 알아서 수정하고, 개발자는 타입 스크립트만 만지는 그런 현장 들어간적 있는데, 좆같은 디자인을 하면 개 고생한다는 것을 디자이너들이 몸소 체험하고 알아서 테일윈드에 맞춘 기계화된 공산품 디자인을 스스로 디자인 하기 시작했음. 일 하기 매우 수월했고, 가끔 디자이너들이 빼먹은거 내가 수정해주면 오히려 감사하다고 커피 사줌. 그 현장 참 꿀이었는데.
@@Dudurami 발주 손님이 이쁜 디자인 바라는 거였으면 모르겠는데, 1rem 2rem 차이가 뭔지도 모르는 뭐 그런 일반적인 커스터머 들이었기 때문에 쓰는 사람들이 아무도 신경을 안 쓰는 상황인데, 오직 디자이너 한명만 디자인에 대해 장인정신을 추구하는 상황이었음. 테일윈드 쓰는거 쉽게 말해 빨리빨리 생산물 만들자는 의도로 쓰는건데, 재사용성을 무시해 버리면 1부터 css만들기 시작해야 하고, 한곳 붕괴하면 다른곳 디자인도 차례로 붕괴하는게 뷰나 리엑트 같은 재사용성 강한 물건이기 때문에 그것 때문에 완성된 페이지 반복문으로 만들었던 디자인 다 부셔버리고 한땀한땀 다시 만들기도 하고 그렇게 됨. 20페이지 정도 화면 설계가 붕괴홰서 처음부터 다시 만들면 디자이너 증오하기 시작할거임.
장점 :
1. 사이드 플젝할때 이것만큼 빠른 결과물 뽑는건 없었음
2. 눈에 익으면 컴포넌트 보는 순간 어떤 결과물일지 대충 보임
3. 아토믹 디자인할때 유틸리티css가 잘 어울림
단점 :
1. 협업할때 분명한 러닝커브가 있음
2. 반응형 css 할때 일반 css보다 더 빡셈. (nest가 안되서 답답함)
결론
찍먹해도 됨.
팀끼리 쓰자고 하면 써봐도 됨
4:14 핵심입니다. 나중에 관리하고 업데이트 까지 해야하는 프로젝트는 왠만하면 css 직접 쓰세요. 이 경우 Tailwind 같은 것 쓰면 나중에 더 고생합니다.
찐 실무담. 쏠플아니고서야 로우하게 해야겠지요?
scss가 저한텐 더 맞더라고요. nested 지원과 변수 지원이 꽤 편했습니다. 컴파일러가 안 쓰는 클래스들 빌드할 때 쳐내주는 것도 편했고요.
ㄹㅇ 특히 프론트 개발자 준비하는 분들은 이런게 있다는 정도만 알고, 절대 이걸로 스타일링 하지 마시길..
뭐든 외부라이브러리 가져오면 언젠가 문제가 생김.. 에러가 나도 내가 수정도 못하고
ㅇㅈ 이런건 그냥 사플이나 어드민에서만 써야됨
백엔드만 할 줄 아는 저같은 프론트 고자들에겐 너무 반가운 소식입니다.
Tailwind CSS 사랑하는 사람으로써 장점 더 적어보겠습니다.
1. 유틸리티 추가하기 쉽다.
config 파일에 colors: { primary: '#8856FE' } 처럼 커스텀 색깔을 추가하면 text-primary, bg-primary, border-primary 등의 유틸이 자동으로 추가됩니다.
2. css 를 normalize 해준다.
웹브라우저 마다 서로 다른 디폴트 스타일들이 있는데 이걸 통일시켜서 일관된 UI 를 만들 수 있게 해주고, 쓸데없이 들어가 있는 기본 마진 등을 없애서 원하는 스타일을 주기 쉬운 상태로 만들어줍니다.
3. 영상에서 스타일 재사용이 어렵다고 하셨는데 사실 매우 쉽다.
2:47 에서 소개해주신 방법으로 component 클래스를 만들면 되는데, 여기서 좋은 점은 쉽게 오버라이드가 가능하다는 것입니다. 예를들어 영상에 나온 card-text 에서 폰트 사이즈만 text-lg 를 text-xl 로 바꾸고 싶으면 class="card-text text-xl" 처럼 원하는 부분만 덮어쓸 수 있습니다. props 를 추가하는 것보다 간편하고, 인라인 스타일을 주는 것보다 깔끔합니다.
4. 재사용이 필요하지 않는 부분을 빠르게 개발할 수 있다.
가장 중요하게 생각하는 부분인데 프론트 개발이나 퍼블리싱을 하다 보면 생각보다 재사용할 일이 없는 코드가 굉장히 많습니다. 순수 css 를 쓰거나 styled-components 같은 것을 쓴다면 굳이 재사용이 필요하지 않은 부분에도 product-section-sidebar-inner-container 따위의 바보 같은 이름을 짓느라 시간을 많이 낭비하게 됩니다. 따라서 이런 부분을 빠르게 개발하고 나중에 재사용할 필요가 생기면 그때 component 클래스로 빼면 됩니다. 이런 전략을 잘 활용하면 코드도 나름 깔끔하게 유지할 수 있습니다.
오
2번 진짜 엄청 공감
개별 CSS로 작성하면 따로 고지해줘도 자기스타일대로 만들어서 써서 나중에 엄청 고생함
2번 같은 경우에는 리셋 css로 해결할 수 있는 부분이 아닌가요? 리셋 css의 단점이 너무 커서 일반적으론 잘 사용하지 않기에 이 부분에 Tailwind 에서 장점인걸까요?
1번은 특징이고
2번은 장점이아닌 노말라이즈 css가 이미있고
3번은 장점이 아닌 특징이고
4번은 필요하지 않는부분이면 그때만 클래스를 주고 .a.b이런식으로 클래스조건부만 주면 되서 저렇게 긴클래스명이 필요가없고..
결국 장점이 없네요?
@@rudwnok 장점 맞는데 특징 이러네
2:25 쓸데없는 조건문ㅋㅋㅋ
맨 마지막이 핵심입니다.
얼른 만들어주고 튀어야 한다.
현시점 tailwind: 그냥 goat 됨
빨리 만들어주고 도망갈때 유용하다. ㅋㅋㅋㅋㅋㅋㅋ
협업해야 하는 경우 컴포넌트화를 잘해놔야겠죠. 근데 그문제는 일반 css를 사용해도 똑같은 문제기 때문에....
3번 재사용이 어렵다는 매우 맞는 말씀이지만 tailwind 자체가 기존에 css나 styledComponent 등으로 개발했을 때 그게 이 사람 저사람 왔다갔다하면서 css 설계하고 naming한 거까지 인수인계하지 않기때문에 새로 입사해서 이거 좀 해주세요하면 js 온보딩할 거도 많은데 css 구조까지 다 파악 안 하고 그냥 새로운 css 추가해서 급한대로 해주는 게 국룰입니다. 그래야 다른 css랑 충돌나서 입사하자마자 욕쳐먹는 일이 안 생기거든요. 그렇게 2년 3년 지나다보면 여러 개발자들의 영혼이 모아져서 괴물 같은 css파일 혹은 styledComponent가 만들어져있습니다. 걷어내야하는데 이건 마치 지뢰찾기를 하는 느낌이라 전체 검색으로 그걸 사용하지 않는다고 해도 혹시 다른 영향을 받아서 주말에 쉬어야하는데 화면 깨졌다고 연락올까봐 안 건드립니다. 절대 안 건드려요. 근데 tailwind는 row 레벨로 독립적인 className을 적는 것이라 다른 거랑 충돌이 나고 그럴 수가 없습니다. 그리고 재사용이 어렵다는 단점을 react 같은 거 쓰시면 컴포넌트 자체가 통으로 재사용이 되기 때문에 딱히 단점이라고 볼 수 없습니다. styling을 tailwind로 최대한 쉽게하고 그 시간에 그냥 TDD나 cypresss 같은 거 시도하시는 게 본인 몸값에도 더 도움되실겁니다. 그리고 styledComponent 쓰시는 분들... styledComponent 이름 좀 MuiDropdownMenu 이렇게 해놓으시면 mui 디자인 커스터마이징했다는건지 저게 mui 기본 배포하는 라이브러리 컴포넌트인지 다른 사람이 알 길이 없습니다.
맞아요 정말 그게 tailwind의 장점을 발하는 부분인데 오히려 사람들이 반대로 말하니 이거야 원 ㅋㅋ
"Why not just use inline styles?"
해당 기술문서에 core concept에 나온 헤드라인 입니다.
실제로 해당 기술을 만든 사람들이 가장 많이 받은 질문이고 본인들도 그렇다 생각했기에 문서에 기록이 되어 있는거죠.
이미 아래 댓글에서 비판한 내용을 개발자들도 고민을 이미 했다는 겁니다. 해당 기술을 만든 개발자가 무능한게 아니고요..-_- 결국 철학적 접근인거죠.
우수한 개발자는 함수형과 클래스 형태의 장단을 어떻게든 조합해서 해결하려고 하지만 멍청한 개발자들은 함수가 최고니 클래스가 최고니 하고 있는거죠..
실제로 그냥 inline style이 아닌 이유로 반응형 그리고 상태지원 명칭에 대한 고민을 안 해도 된다고 기록하죠.
그러나 근본적인 문제는 남아 있습니다. '가독성' 문제가 남아 있습니다.
오히려 문서에는 classname을 결정하는데 고민을 하지 않아도 된다고 하였지만 사실 이것도 트레이드오프가 있는 겁니다.
card도 해당 기술문서에 소개된 카드는 엄청 dump한 수준의 카드 디자인인데 현실은 그렇지가 않으니깐요.
개발에서 Trade off는 늘 생각해야 됩니다. 외주회사에서 퍼블리셔가 존재해서 빠르게 화면을 만든다면 저는 해당 기술이 좋다고 봅니다.
그런데 프론트엔드가 있고 React를 쓴다면 저는 좀 더 이름을 결정하는데 시간을 써도 된다는 입장입니다. 그러면 오히려 css in js 기술을 쓰는 것을 추천하고요.
어떤 기술을 쓰는 것이 맞는지는 개발자 역량이 결정합니다. 그러니 싸울 필요는 없죠. 오히려 이게 무조건 좋다 나쁘다 단정하는 개발자들은 상종하면 안되죠..
저는 생각이 조금 다른데, 퍼블리셔가 없는 프론트가 리액트에서 쓸 때 더 가치가 높다고 생각합니다
상종 안하는 것도 무조건 좋다 나쁘다 단정하는 것 같은데 ㅋㅋ
마지막 5초가 핵심 ㅋㅋㅋㅋ
Vercel과 V0dev 가 tailwind를 채택해버렸다.....
ㅋㅋ 마지막이 핵심이네
마지막 맨트가 아주 맘에 듭니다 ㅎㅎㅎ
런하는 아기 사진까지 너무 적절해요 ㅋㅋㅋㅋㅋㅋㅋㅋ
유틸리티 클래스로 도배된 마크업을 보고 퍼블리셔들은 그저 웃습니다..
부트스트랩이나 테일윈드 쓸 때 디자인이 나와있는 경우 일일이 손봐줘야되는거죠? 디자인이 이쁘지도 않고 커스텀한다고 손이 더 가는 경우도 있고 어떤건 자기 멋대로 스타일이 들어가있어서 그걸 또 다시 손봐야되는 경우가 왕왕 있어서요. 쓰면 편하다는데 왜 하나도 안 편한지 ㅠㅠ... 쩝...
가끔 혼자 프론트엔드까지 작업해야할 때 너무 유용하겠네요 ㅠㅠㅠ
스타일링 안 중요한 사이드 플젝이나 영상 말미에 말씀 하셨던대로 외주처럼 빨리 쳐내는 거 아니면 테일윈드나 부트스트랩은 정말정말 비추입니다.
형 프론트엔드 개발자에게 엄청 편한 툴 개발되서 이것도 소개시켜줘!
react vivid 라는건데 react랑 tailwind 쓰면 적용가능
브라우저상에서 바로 눈으로 보면서 react 코드 바꿀 수 있음!
빨리 만들고 다신 유지보수 안할꺼면 tailwind 써보세요ㅋㅋㅋ
이거 썼다가 다시 되돌린다고 정말 고생했습니다.ㅋㅋㅋ
몇년전에 이 방법 모조리 안쓰게 되었습니다. 특히 모듈형으로 만드는 대규모 플랫폼 사이트에서는요. 반응형 웹에도 맞지않고 유지보수가 헬입니다. 요즘엔 js플레임 워크에서 변수나 쿼리등으로 귀찮은 CSS작성을 단순하게 만들수있으니 굳이 저렇게 할필요도 없고요.
맞음.. 튜닝이 끝은 순정이 되버리더군요..
헐, 내가 6년 전에 요소별로 css 다 만들어 놓고 멀티 클래스로 사용했었는데, 진짜 장단점이 영상이랑 똑같음. 지금은 SCSS 쓰는 게 유지보수가 빨라서 더 좋음.
1:32 '기능은 똑같습니드아~!'
튀는짤 개웃기네 ㅋㅋ
빠르게 기능검토용 프로토 타입정도 만들때 유용할수도 있겠군요^^
맞습니다.
차라리 어느정도 디자인적인 요소가 함께 있는 부트스트랩이 낫겠네요.
부트스트랩이랑 동일하나 개발자라면 직접 css 스타일링 하셔야되요 저건 개인용도나 어드민페이지수준. 직접 다구현해보셔야됨 해보면글케안어려움 프로덕션레벨에서 쓸일이있나싶네요
저도 잘 못해서 부트스트랩 사용하는데 무난무난하게 반응형 디자인을 할수 있어서 좋더라고요.. (본인은 백엔드)
마침 css 라이브러리 관련해서 보고있는데 웬걸.. 바로 좋아요와 함께 감상합니다.
백앤드 개발자만 있는 곳에서는 부트스트랩이나 테일윈드 쓰는거 괜찮은거 같습니다.
근데 프런트 개발자나 퍼블리셔 직군이있는 곳에서는 테일윈드는 특정 폼 (input이나 button)등을 제외하고는 지양하는게 맞다고 생각합니다.
폼등은 만들기 귀찮어서 ㅇㅅㅇ 특정 폼값에 클래스 추가 방식을 써서 커스텀해서 쓰면 좋다고 생각 합니다.
추후에 유지보수때 mb-4 이런거 들어가있으면 진짜 수정하는데 피똥쌈 ㅠㅠ
그걸 또 덮어쓸 수 있어요
프론트가 저걸 환상적으로 써주면 유지보수도 조아용
물론 컴포넌트로 잘잘 쪼갠 사이트 한정 ㅎㅎ
CSS 없이 만든다지만 내부적으론 CSS로 돌아가는 아이러니함 ㅋㅋ
개인적으론 이런건 너무 추상화 레벨이 높아서.. 별로인듯
Vuetify 쓸때는 pa-5 로 패딩주기 같은건 나름 유용해서 사용하고 있기는 함
TailwindCSS 쓰고 두통이 사라졌습니다. 강추.
스타일 재사용은 그 전에 컴포넌트로 만드는법을 소개하셨는데 그걸로 하면 재사용 가능하죠
긍까 부트스트랩이랑 비교하자면
테일윈드는 뷔페같은거여서 진짜 원하는 게 다 있는데 그 뷔페에 맛 없는 음식이 있을 수 있듯이, 쓸떼없이 좋은 기능이 너무 많음
부트스트랩은 걍 정해진거만 주는 식당? 이라고 하면 됨 비유하자면 맛은 보장됐지만 음식은 맛있지만 종류가 다양하진 않음
개인적으로 디자인 잘 못하는 사람들은 정해진 부트스트랩만 써도 꽤 예쁘고
디자인 잘한다 싶으면 테일윈드로 편하게 디자인 해보면 됨
(나도 함 써볼까)
단, 하나 확실한건 디자이너가 원리를 제대로 파악하고 있어야만 가능하다는 것
디자인 규칙이 없는데 사용한다? 애플님 말대로 한번 손대고 다신 내가 수정안할 것 같다 하면 사용해도 될 듯
너무 많은걸 제공하다보니 고치려면 진짜 답이 안나오는데 저는 그래서 그냥 부트스트랩 쓰고 커스텀 클레스 뭉텅이를 따로 만들어서 씁니다 부트스트랩을 프로잭트에 맞게 따로 보강을 해서 쓰면 그게 속편하더라구요
개웃기네요 ㅋㅋ 빨리 만들어주고 튄다라 ㅋㅋㅋㅋㅋㅋㅋㅋ
코딩애플 님은 tainwind css를 아직 사용하고 계신가요?
써봤는데 저하고는 잘 안맞더라고요. 테일윈드가 스타일을 초기에 구축할 때는 편한데 테마 일괄변경 같은 걸 해야 할 때는 일일이 고쳐야 해서 뒤가 고역이었던 걸로 기억합니다.
Tailwind에서 테마를 만들어내실수 있습니다.
next js 14버전으로 테일윈드 적용하는 강의 기다립니다ㅜㅜ
이것저것 다 써봤는데. 저한테 제일 맞는거는 styled component 더라구요
C++애드온 강의 생각은 없으신가요
디자인 시스템과 같은 모듈형 디자인을 채택하지 않은 곳, mpa, 문서화되지 않는 컴포넌트 개발, 반응형 잘 못만드는 작업자는 지나가도 됩니다.
부트스트랩 사용하고있었는데 부트스트랩보다 더 괜찮나요?
괜찮습니다. 할수 있는것도 많고, 재사용성 뛰어납니다.
React-Native에도 적용가능한가요?
디자인요소는 개발적으로 반복요소를 찾기가 일반적인 로직작성하고 보는 관점이 판이하기 때문에 인라인으로 보이는것만 고치는거를 선호할 수밖에 없는데 그걸 더 부추기는 매우 좋지않은 프레임워크라고 개인적으로 생각합니다. 개발자만 좋아하는 디자인 추상화가 도를 넘었다고 생각하고 있어서 사용이 꺼려지게 되는거 같습니다
결론적으로 비슷한 형태의 UI만 작성이 가능해지고 세부적인 수정을 하려고 하면 오히려 코드가 더 더러워지는 상황이 발생하게 되는 것 같습니다.
마지막이 핵심이네요 ㅋㅋ
옛날에 저렇게 css작성하면 혼나던 시절이 있었는데요 이젠 많이 바뀌는군요
@Salida 중소기업은 프론트 빌드시스템조차 없는경우가 허다합니다 😞
혹시 해피해킹키보드 쓰시나요?
뭐 그냥 내가 원하는데로 만들어 컨트롤하는게 시간은 조금 더 걸려도 좋다고 생각해왔습니다만
마지막 말에서 써보기로 결심했습니다
가독성때문에 못쓰겠음..
styled-components가 아직은 최애
어휴 개인적인 독단과 편견과 아집이긴 하지만 부트스트랩 이상으로 개 극혐하는 tailwind
부스트트랩도 얘에 비하면 양반이져 ㅋㅋ 저는 부트스트랩정도는 좋아하는 온건파(?) 입니다만
키보드 정보 알려주실수 있나요?
이형은 너무 솔직하다니까 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 외주개발ㅌㅌ ㅇㅈ
형 외주개발하고 빨리 튀기위한 강의 만들어주세요
긍데 뭐 pc만 만들면 진짜 편할거같은데? 반응형이다하면 걍 안쓰는게 좋을듯함? 반응형이면 굳이 이걸 써야할까싶음 걍 저의 개인적인 의견!! 잔소리하지마세요 분명히 반응형이면 별로임
저는 tailwind도 버리고 daisyui 씁니다 daisyui가 진짜 미친놈임
울회사같은 좋좋소에서 쓰면 큰일날거같다는 생각이 들어버렸따
외주 홈페이지 만들때 잘 썼습니다. 꺼억~
감사합니다 😊
좀 더 복잡해지면 inline style 방식이라 수정 하기 많이 어려워져요. 그리고 디자인이 taiilwind spec 대로 8px 기준/색감이 아니면 다 커스텀으로 해야 합니다. 아무리 react 방식이라 해도 재사용이 안되고 하려면 다 @apply 방식으로 해야 하고요...@apply를 할거면 왜 tailwind를 만들었나 싶네요. tailwind는 css도 파악 못하는 개발자가 어떻게 하면 바퀴를 재 발명 할수 있을가 하며 무언가를 "개발" 하기 위해 만든 개발자의 무능함의 결과라고 봅니다. tailwind가 3.0까지 간게 신기할정도 입니다. Rapid prototype 할거면 모르지만 그 부분에서도 차라리 component로 뺀 bootstrap이 나을겁니다. tailwind로 반응형 함 해보세요, 어캐 되는지 ㅎㅎㅎ
쩝.. 각자 사용처가 있는 건데 이 정도 쓰이는 라이브러리 만든 개발자한테 무능하다고 비하하는 건 웃기네요 ㅋㅋ 본인이 제일 잘낫고 내 생각과 다른 이들은 모두 머저리인 전형적인 개발자 말투..에휴
외주 작업이나 간단한 프로젝트에서는 아주 요긴하게 쓰입니다
@@fabianbiduu6127 지나가던 개발자입니다. 저런 어투를 쓰는 사람들은 전형적인 개발자 취급 안합니다 ㅠ
tailwind로 반응형 너무 편하게 만들고 있어서 여기 달린 좋아요 4개가 정말 써보고 공감하는 건지 아닌지 헷갈리네;
그리고 때와 상황에 맞게 바닐라 css랑 병행해서 사용하면 이거 하나로 얻는 생산성이 단점을 훨씬 상회한다고 생각함. 테일윈드을 부분적으로 내 생산성을 올려주는 도구 그 이상이하도 아니게 접근을 해야지, 모든 스타일링을 다 해줄 수 있는 실버불릿으로 css를 퇴출시키겠다, 이런 마인드로 접근을 해서 사용한게 아닌가 싶음.
@@lizerd 님 제 댓글에서도 보고 좀 생각해 봤는데, 복잡한 계층의 프로젝트를 경험해보지 못하신것 같다는 생각이 드네요. 단순한 구조이거나, 설계가 거의 완벽해서 변경이 거의 발생하지 않는 프로젝트에서는 님 말이 맞는데, 구조가 5단 6단 들어가는 복잡한 컴포넌트 구조를 가진, 예를들어 아토믹 디자인 같은 경우에서는 무한 커스텀의 악순환에 빠집니다. 특히 기획자/디자이너가 테일윈드&아토믹에 대한 이해도 없이 바닐라 css를 던져줄 경우 그걸 테일윈드화 시키는 css 설계라는 공정이 하나 더 중간에 끼기 때문에 엔지니어의 부담이 커집니다. 이걸 테일윈드 기본 속성으로 가능한가를 먼저 판단하고, 가능하지 못한 부분이 있으면 뭘 어디까지 테일윈드로 커스텀을 할것이며, 테일윈드로 커스텀을 하느냐 바닐라 css로 그대로 사용하느냐에 대한 설계 레벨의 판단이 매 아톰을 개발할 때마다 개발자들에게 던져집니다. 어렵게 커스텀 만들어놨는데 디자이너가 이걸 재사용 해주지 않으면 쓸대없는 시간 낭비가 되고요.
이게 삽질 하던걸 굴삭기 가져와서 개발하는 것 만큼 좋은건 저도 써봐서 아는데, 기획자/디자이너가 라이브러리에 대해 전혀 이해가 없을 경우 프로젝트 엎어집니다.
스켈레톤 기능이 있던데 어떻게 활용하는지 모르겠네요.
그거 정말 미세하게 효과 보이는거라 아마 gray color로 맞춘거면 정말 모니터 해상도 성능에 따라 반영된건 지 파악하기 힘들거에요 ㅋ
blue, red 같이 단색이 뚜렷한 color에 한번 테스트 해보시구 만약 안된다면 부모 태그 구조 문제 or config 파일 옵션 커스텀 해놓은 게 있는지 확인해보세요!
장점 : 글쎄요...................타이핑 조금 덜해도 되는거...?;;; (과연 파워풀할만한 뭔가가 있을까...;;)
단점 : 일단 다른 사람에게 욕부터 먹고 시작함............ (인라인으로 스타일 때려박는거랑 다를거 없기 때문...)
결론 : 나 혼자 만들어서, 나 혼자 수정하고, 나 혼자 끝낼 프로젝트라면 써도 상관없음~~~!!!
뭐 맨날 버리고 새로운거 가지고오면 제작은 언제합니까ㅠㅠ
3:01 멍청이라 죄송합니다 흑흑
? style 쓰면 안되나요?
style은 일일히 다 쳐주야 하니까 시간이 많이 걸립니다.
아하 유틸리티 클래스를 더 써봐야겠군여
마지막 외주사이트에서 빵터졌습니다 ^^;
대충 만들어 주고 튀어야 한데 ㅋㅋㅋㅋ
쌤이 테일윈드쓴다니까 반갑다너무
핵심 : 외주할때 남에사이트 빨리만들고 튀어야하잔아요
부트스트랩 유틸리티 클래스가 적어서 불편했는데 저런게 있었군요
인라인 스타일이랑 뭐가 다른거죠
어느 정도는 class가 모듈화되어 있다는 게 장점이라면 장점이죠. 시간이 없을 때 빨리 쳐내기에 쓸만합니다. 단점은 시간 지난 뒤 어떻게 코딩했는지 까먹었을 때 쯤 유지보수하기엔 헬이지만.
아무리봐도 단점 너무많아보이는데 뭐가 장점이라는건지 모르겠음
단점이 많이 보이면 뭐 바닐라 css가 더 좋다는거임? 뭔 말을 해도 라이브러리 갖다 쓰는게 최고인건 실력자들도 인정하는건데
아마 대부분 스타트업에선 소규모 팀 단위라 css 컨벤션을 구축할 시간이 많이 부족할 거에요.
그렇기에 tailwind 특유의 규칙성에 따라가다 보면 팀 단위의 css 컨벤션이 맞춰지는 관계로 선호하는 개발팀도 있습니다.
디자이너의 디자인 시스템 기반에 따른 재사용성 컴포넌트와 타이포그래피 옵션에만 크게 관심을 기울이면 일정이 빠듯한 프로젝트 팀들에겐 더욱 편한 라이브러리 입니다.
러닝커브라고 종종 언급하는 사람들 계시는데,, 좀 오버해서 말한다고 저는 생각해요.. tailwind document 몇 번 보다 사용하면 바로 습득이 올거에요..
전역 상태 관리 Redux, 입력 form 상태 관리 formik 등등 이런 라이브러리들의 러닝커브에 비하면 tailwindCSS는 충분히 2시간 안에 감이 옵니다.
웹템플릿 구매하고 원하는 구성으로 변경할때 저런방식 썼었는데 아예 저렇게 되어있는 라이브러리가 따로 있었군요 ㅋㅋ
어짜피 고자들이 나모웹 쓰고 튀는 수준
와 씨 .. 난 억울해서 내가 만든거 걍 쓸래 ㅠㅜ
그래서 핵심은 마지막인 거죠?
마지막 말이 와 닫는다..
튀!
오 뷰티파이에서 쓰던 거네
손이 좀 더가더라도 이모션이나 스컴 사용합시다. ㅎㅎ
핵심 맨ㅁ ㅏ지막 굿
왜 우리 학교는 메모장으로 강의 하는거임..? 젼나 이해 안 가네
기본기를 알아야 저런거 써도 활용할 수 있음. 기본문법을 익히기 위해 메모장로 하는듯.
이번에 리액트 프로젝트 할때 tailwind 쓸려고했는데 ㅋㅋㅋㅋ
04:05 아하
애플아 왜 아까 서버 터졌었엉 놀랐잖아 ㅠㅠ
돌아가기만 하면 되니까
그 외 전부..
ㅠㅠ 난 멍청이 인가...
그 외주개발이 빨리하고 난 결과물을 받은 1인…
눈빠지는 프론트에 인공눈물같은 느낌이다...
휠윈드 갓윈드
RN 에서도 이런 유틸레벨 스타일링 하는거 빨리좀 만들어줬으면 편법말고요 ㅠㅠㅠ 너어어어어무 편합니다!
알았어욧
사이트만들고 튈때 좋을듯
테일윈드 JIT 모드 개꿀!!!!
테일윈드 쓰는 현장 세곳 정도 경험했는데, 테일윈드의 진정한 단점은 디자이너가 테일윈드에 대한 이해도가 없을때임. 테일윈드에 없는 속성값을 디자인에다가 쳐 박아버리면 테일윈드 전역설정으로 그 새로운 속성값을 개발하던지, 그 속성값을 우회에서 css를 박던지 해야 됨. 우리 서비스 테일윈드 쓰는거 알면서 좆되보라고 하는건지 계속 픽셀값 디자인 테일윈드 디자인이랑 엇나가는 디자인 던져주는 디자이너가 있어서, 좀 테일윈드 대로 재사용 가능한 디자인을 만들어서 던져주면 안되냐고 하니깐, 내가 왜 그래야 하냐. 그거 구현하는게 개발자 일 아니냐. 그렇게 하면 디자인 안 이쁘다 이지럴 해서 회사에서 대판 싸움. 썅련이 디자인 부심이 하늘을 찔러서, 재사용성 때문에 테일윈드 도입한건데 재사용 할수 없는 오리지널리티 뿜뿜 하는 디자인을 쳐 던져주면 어쩌자는건지. 프론트 개발자들끼리 모여서 이럴거면 테일윈드 그냥 날려버리면 안되냐고, 그냥 css 개발하는게 빠르겠다고 담배 피면서 하소연함.
저는 개발자지만 디자이너 입장이 더 이해가네요 이 상황에서는 ㅎㅎ;;
디자이너가 테일윈드를 알던지, class를 디자이너한테 수정시키면 굉장히 좋은 물건임. 테일윈드 현장 세곳 중에 마크업에 관련된 코드는 전부 디자이너가 알아서 수정하고, 개발자는 타입 스크립트만 만지는 그런 현장 들어간적 있는데, 좆같은 디자인을 하면 개 고생한다는 것을 디자이너들이 몸소 체험하고 알아서 테일윈드에 맞춘 기계화된 공산품 디자인을 스스로 디자인 하기 시작했음. 일 하기 매우 수월했고, 가끔 디자이너들이 빼먹은거 내가 수정해주면 오히려 감사하다고 커피 사줌. 그 현장 참 꿀이었는데.
@@Dudurami 발주 손님이 이쁜 디자인 바라는 거였으면 모르겠는데, 1rem 2rem 차이가 뭔지도 모르는 뭐 그런 일반적인 커스터머 들이었기 때문에 쓰는 사람들이 아무도 신경을 안 쓰는 상황인데, 오직 디자이너 한명만 디자인에 대해 장인정신을 추구하는 상황이었음. 테일윈드 쓰는거 쉽게 말해 빨리빨리 생산물 만들자는 의도로 쓰는건데, 재사용성을 무시해 버리면 1부터 css만들기 시작해야 하고, 한곳 붕괴하면 다른곳 디자인도 차례로 붕괴하는게 뷰나 리엑트 같은 재사용성 강한 물건이기 때문에 그것 때문에 완성된 페이지 반복문으로 만들었던 디자인 다 부셔버리고 한땀한땀 다시 만들기도 하고 그렇게 됨. 20페이지 정도 화면 설계가 붕괴홰서 처음부터 다시 만들면 디자이너 증오하기 시작할거임.
@@Dudurami 우린 정형화된 공산품을 만드는 사람들인데 왜 웹페이지에다가 예술을 하겠다고 그러는건지 이해가 안됨.
테일윈드가 유틸리티 클래스인데 극한으로 커스터마이징 해서 쓰라고 나와서 커스텀 속성값 집어넣는게 메인기능인데 그거로 디자이너랑 싸울 수가 있나요? 물론 부트스트랩을 잘못 말하신거라면 이해가 갑니다.
이렇게 호불호 많이 갈리는 툴인지는 첨 알았네요..
호불호가 맣이 갈린다기보단 기획, 디자이너가 피그마 같은 디자인툴만 보고 라이브러리 공부를 안하면 모든 부담이 엔지니어에게 쏠려서 그게 문제임.
개 13남자특 클래스 그딴거 안쓰고 style으로 그냥 때려박음. ㄷㄷ
ㅋ빨리 텨야할때..인정