tailwindcss 는 스타일을 태그에서 모두 볼수있게 하고 일관성과 간결함을 갖는데 있습니다. 모든 스타일이 보이는데 간결함이라고 하여 의문을 가질수도 있지만 기존에는 프로젝트가 커질수록 제어불가능한 css와 클래스가 커지지만 tailwindcss는 style 속성을 이용하는것처럼 태그에서 직관적으로 관리 가능하죠 style 속성과 차이점은 미디어 태그를 사용 가능하고 지정된 크기 (*4 비율의 크기) 를 사용하고 조건식을 사용 가능하고 더 간결하다는 점이 다릅니디. 또한 tailwind도 지정된 스타일이름만 사용하고 오타는 감지하는 플러그인이 있지요. 또한 사용하는 클래스만 컴파일되서 css파일을 최소화 해줍니다 저는 StyleX를 왜 tailwindcss와 비교하는지 모르겠어요. 접근방식 자체가 아에 다릅니다. 기존에 css in js 를 사용할때 타입안정성의 이점을 가진지는 예전부터 가지고 있었고 해결하려는 문제 자체와 방식이 다르다고 생각합니다 오히려 css in js 라이브러이들 예를 들어 styled components 와 비교 하는게 어땟을까요. 이 영상은 단순히 css in js 와 tailwindcss 의 비교 내용밖에 없어보입니다
접근방식이 완전히 다르다는 점에 공감합니다. 테일윈드랑 비교하려면 적어도 HTML과 CSS를 여기저기 스위칭하면서 보기보다 한 눈에 나타낼 수 있는 것들이 나와야한다고 봅니다. 어느 부분을 특징으로 삼았느냐에 따라 비교할 수 있을지 없을진 다르겠지만, 저 역시도 아쉽군요 😂 하지만 니꼬쌤은 늘 유익한 정보를 주기땜에 재밌게봤습니다.
접근방식이 다르다는거지 두 라이브러리 중 택일 해야하는 점에서 비교하는데 전혀 무리가 없어보이네요 그리고 테일윈드가 간결하다고 보기는 어렵습니다 테일윈드가 생산성이 좋기 때문에 주목을 받은거지 초창기부터 좋은 패턴이 아니다라는 지적은 계속 있어왔습니다 커스텀 스타일이나 조건에 따라 스타일을 합칠때(twMerge) 가독성이 떨어지는 긴 문자열이 생기는 경우가 많습니다 물론 세심한 설계와 코딩으로 테일윈드도 간결히게 작성이 가능합니다만 그만큼 생산성은 떨어지고 테일윈드를 사용할 이유가 없는거죠
@@artrix2222 tailwindcss 의 간결성에 대해서는 수긍합니다. tailwindcss 를 작은 프로젝트에서 사용했을때 기존 방식들보다 심플하게 느껴져서 좋았던 경험때문에 그렇게 생각했지만, 상황에 따라 다르고 간결하지 않다라는 의견에 어느정도 수긍합니다. 다만 twMerge 는 되도록 사용하지 않는것이 좋다고 생각하고 공식문서에서도 그렇게 나와있던걸로 기억합니다. 다른 의미로는 결국 스타일을 합쳐야하고 재사용 해야하고 더 큰 규모로 관리해야 하는 경우에는 적합하지 않다는 것 같습니다. --- 다만.. 접근방식이 다른 두 라이브러리 (tailwindcss, styleX) 인데 'styleX'는 처음 들어본 입장으로서.. 영상 제목인 '테일윈드를 대체했다고?' 라는 제목은 '대체' 라는 단어가 접근방식과 해결하려는 내용이 같거나 비슷한 라이브러리를 이야기 하면서 서로 비교하는 영상이다. 라고 오해할만한 소지가 있는 제목이라고 생각합니다. 또한 영상 내용도 그런 오해를 풀어주는 내용은 없죠. 제목과 영상 내용은 의도적으로 테일윈드와 비교하면서 css in js 의 새로운 방법이다! 라는 의도가 곳곳에 있다고 느껴졌습니다. 그런 느낌을 받은 이유는.. 아마 시간들여서 찾아보면 그런 의도를 집을수 있겠지요. 때문에 저는 이런 어그로성이 있는 제목과 내용에서 오해할수 있는 내용이 전달될수 있다는 부정적인 인식이 있습니다. 개인적으로, 다양한 관점은 좋고 최근 FE 트랜드를 알수 있는 영상이라 그 부분은 좋지만 마케팅적인 의도에 의해 착각할수 있는 내용이 전달될수 있다는 점은 안좋다고 생각합니다.
Tailwind의 장점은 프론트엔드에서 스타일은 완전히 문자열로 독립시킴으로써 더이상 기능 구현과 관련이 없는 것처럼 분리시킨다는 데 있음. 이 단순함이 주는 마음의 평화야말로 최대 장점임. 코드 가독성만 해도 스타일은 항상 오렌지색 긴 문자열에 들어가 있으므로 항상 이건 스타일이구나 직관적으로 파악됨. 스타일에 관련된 부분 보면서도 자꾸 객체나 함수를 보는 것 같은 느낌을 받는다는 자체가 스트레스 요소임
@@위즈WisdomIT 모종의 이유(next의 동작 원리 때문이라고는 하는데 자세히는 모르겠어요)로 인해 서버 컴포넌트에서는 styled-components 라이브러리를 직접 import하여 사용하는게 불가능합니다. 다른 파일에서 클라이언트 컴포넌트로 작성한 후 필요한 서버 컴포넌트로 불러오는 식으로 쓸 수는 있는데, 불필요하게 파일이 쪼개지는 것과 S.Component 방식의 네이밍이 지원이 되지 않는게 참 불편했습니다.
뭘까 싶어서 헐레벌떡 들어왔지만,, 테일윈드랑 styled-components 같은 것들은 패러다임부터 완전 다르다고 봅니다. 테일윈드로 넘어온 제 취향으로선 HTML과 CSS가 두 개 이상의 파일을 옮겨가며 볼 필요 없이 한 눈에 어떤 모양새인지 볼 수 있다는 점 때문인데, 결국 HTML와 CSS를 분리해야하는 StyleX는 TailwindCss를 대체하기엔 저에겐 불만족스럽군요 😢
이것도 결국 프로젝트 커지고 노후화되면 중복된 변수들 쌓이고 다음 사람오면 전 사람이 급해서 tsx 밑에 구석탱이에 짱박아놓은 거 발견 못하고 새로 만들고 하다보면 한 10년 후에는 꼴도보기 싫은 프로젝트로 될 거 같아서.... tailwind가 더 좋아보여요.... 퍼블리셔랑 협업해야 할 때도 tailwindcss가 좋고.... 혹시 테일윈드 망하더라도 convert해서 css로 만들면 다른걸로 바꾸기도 용이함...
웹프론트개발자 되어야지 했다가.. 금전적인 문제로 다시.. 원래 업종 복귀하고.. 회사 전산(웹)보며.. IE모드 필수이고.. 예쁘게 만들필요없어.. 백엔드 분들이 만든 코드들이 잘 작동되면 장떙인걸..보고 괜히 프론트 공부했나 생각 들곤 있긴합니다. 개발자 하기전 나갈때도 사내 친한 개발자분이 백엔드 재미있다고하셨는데.. 그말 무시한게 이렇게 된건지 ㅠㅠ 요즘 짜투리 시간으로 일일 보고서 작성할 부분 자바스크립트 기반으로 메크로처럼 만드는데 GPT센세에게 물어보는거 보면 개발자 될려면 몇년 걸릴것 같다 생각이 드네요. 접근성이 옳바르게 되어 잘 작동되는지 먼저 보고 있어서 CSS에 대해서는 아직 모르겠어요...
IE 모드가 필수인 환경이라면 너무 안좋은 환경이군요. 이미 잘 아시겠지만 사업방향에 따라 백엔드분이 만든 코드가 잘 작동되면 장땡인게 맞을때도 있고 FE 개발자가 전문적으로 있어서 유지보수하며 기능을 추가해 나가는게 정답일때도 있다고 생각합니다. 저 또한 개발하면서 최근에는 GPT 센세에게 많이 물어보네요. 뭐 이리저리 이야기해보았자 뭐하겠어요. 우리 모두 겸손한 자세와 마음가짐을 가지고 공부해야죠.
🔥 다가오는 2024년....
찐한 개발자 스터디와 열공하고 갓생살고 싶다면? 😉
👉🏻 bit.ly/3trPM3i
.
📌 직접 만들면서 코딩 배우기 (*무료*)
👉🏻 bit.ly/46W9XVC
tailwindcss 는 스타일을 태그에서 모두 볼수있게 하고 일관성과 간결함을 갖는데 있습니다.
모든 스타일이 보이는데 간결함이라고 하여 의문을 가질수도 있지만
기존에는 프로젝트가 커질수록 제어불가능한 css와 클래스가 커지지만
tailwindcss는 style 속성을 이용하는것처럼 태그에서 직관적으로 관리 가능하죠
style 속성과 차이점은 미디어 태그를 사용 가능하고 지정된 크기 (*4 비율의 크기) 를 사용하고 조건식을 사용 가능하고 더 간결하다는 점이 다릅니디.
또한 tailwind도 지정된 스타일이름만 사용하고 오타는 감지하는 플러그인이 있지요.
또한 사용하는 클래스만 컴파일되서 css파일을 최소화 해줍니다
저는 StyleX를 왜 tailwindcss와 비교하는지 모르겠어요. 접근방식 자체가 아에 다릅니다. 기존에 css in js 를 사용할때 타입안정성의 이점을 가진지는 예전부터 가지고 있었고
해결하려는 문제 자체와 방식이 다르다고 생각합니다
오히려 css in js 라이브러이들 예를 들어 styled components 와 비교 하는게 어땟을까요.
이 영상은 단순히 css in js 와 tailwindcss 의 비교 내용밖에 없어보입니다
완전 공감이요 그냥 제목에 테일윈드넣고 어그로 끈거같습니다
@@zzz-ej5fy 답답함에 막 적은 글이라 가독성이 떨어지는데 읽고 공감해주셔서 감사합니다.
4년전쯤에 노마더 코더를 페이스북에서 처음 보고 이후 안보다가 이 영상을 다시 접했는데 역시 음..
마케팅을 잘하는 유튜버네요.
접근방식이 완전히 다르다는 점에 공감합니다. 테일윈드랑 비교하려면 적어도 HTML과 CSS를 여기저기 스위칭하면서 보기보다 한 눈에 나타낼 수 있는 것들이 나와야한다고 봅니다.
어느 부분을 특징으로 삼았느냐에 따라 비교할 수 있을지 없을진 다르겠지만, 저 역시도 아쉽군요 😂
하지만 니꼬쌤은 늘 유익한 정보를 주기땜에 재밌게봤습니다.
접근방식이 다르다는거지 두 라이브러리 중 택일 해야하는 점에서 비교하는데 전혀 무리가 없어보이네요 그리고 테일윈드가 간결하다고 보기는 어렵습니다 테일윈드가 생산성이 좋기 때문에 주목을 받은거지 초창기부터 좋은 패턴이 아니다라는 지적은 계속 있어왔습니다 커스텀 스타일이나 조건에 따라 스타일을 합칠때(twMerge) 가독성이 떨어지는 긴 문자열이 생기는 경우가 많습니다 물론 세심한 설계와 코딩으로 테일윈드도 간결히게 작성이 가능합니다만 그만큼 생산성은 떨어지고 테일윈드를 사용할 이유가 없는거죠
@@artrix2222
tailwindcss 의 간결성에 대해서는 수긍합니다.
tailwindcss 를 작은 프로젝트에서 사용했을때 기존 방식들보다 심플하게 느껴져서 좋았던 경험때문에 그렇게 생각했지만, 상황에 따라 다르고 간결하지 않다라는 의견에 어느정도 수긍합니다.
다만 twMerge 는 되도록 사용하지 않는것이 좋다고 생각하고 공식문서에서도 그렇게 나와있던걸로 기억합니다.
다른 의미로는 결국 스타일을 합쳐야하고 재사용 해야하고 더 큰 규모로 관리해야 하는 경우에는 적합하지 않다는 것 같습니다.
---
다만..
접근방식이 다른 두 라이브러리 (tailwindcss, styleX) 인데 'styleX'는 처음 들어본 입장으로서..
영상 제목인 '테일윈드를 대체했다고?' 라는 제목은 '대체' 라는 단어가 접근방식과 해결하려는 내용이 같거나 비슷한 라이브러리를 이야기 하면서 서로 비교하는 영상이다. 라고 오해할만한 소지가 있는 제목이라고 생각합니다. 또한 영상 내용도 그런 오해를 풀어주는 내용은 없죠.
제목과 영상 내용은 의도적으로 테일윈드와 비교하면서 css in js 의 새로운 방법이다! 라는 의도가 곳곳에 있다고 느껴졌습니다. 그런 느낌을 받은 이유는.. 아마 시간들여서 찾아보면 그런 의도를 집을수 있겠지요.
때문에 저는 이런 어그로성이 있는 제목과 내용에서 오해할수 있는 내용이 전달될수 있다는 부정적인 인식이 있습니다.
개인적으로,
다양한 관점은 좋고 최근 FE 트랜드를 알수 있는 영상이라 그 부분은 좋지만 마케팅적인 의도에 의해 착각할수 있는 내용이 전달될수 있다는 점은 안좋다고 생각합니다.
Tailwind의 장점은 프론트엔드에서 스타일은 완전히 문자열로 독립시킴으로써 더이상 기능 구현과 관련이 없는 것처럼 분리시킨다는 데 있음. 이 단순함이 주는 마음의 평화야말로 최대 장점임. 코드 가독성만 해도 스타일은 항상 오렌지색 긴 문자열에 들어가 있으므로 항상 이건 스타일이구나 직관적으로 파악됨. 스타일에 관련된 부분 보면서도 자꾸 객체나 함수를 보는 것 같은 느낌을 받는다는 자체가 스트레스 요소임
큰 프로젝트에서는 tailwindCSS보다 좋은 점이 있어 보이는군요!
작은 프로젝트에서는 여전히 tailwindCSS가 빠르고 편하기 때문에 좋아보이긴 하지만요, 좋은 목적으로 쓸 수 있는 옵션이 있는 느낌이라 좋습니다
타입 관리 해주는건 정말 좋네요
Latex 코딩 강의 잘 아시면 알려주세요!! 노마드님한테 배우고 싶어요!
공부 할게 또 하나 생겼네요.
감사합니다! 바로 하나 예제 하나 만들어 봐야겠네요 ❤
무려 리액트 네이티브를 만든곳인데 긍정적으로 봅시다 ㅎㅎ
Thanks for information!
근데 형 nextjs 강의 언제 나오나요...?
커밍 쑨....!
타입 세이프를 지원하는 점에서는 stitches 랑 비슷해보이네요!
This is a great content. Thank you.
CSS 작동 방식을 잘 몰라서 그런데, Tailwind보다 빠르게 작동되나요?
보다 JS스러운 스타일이 필요했었는데,원하던걸 찾았습니다!!
man I love your videos.
아니 뭐 이거 그냥 스벨트 아님?
리엑트로 데이터베이스 접근을 하더니, CSS 도 완존 장악하기... 그냥 자바스크립트로 전부 다 하고 싶어하는 듯 하네요.
what?? 다들 설명 고맙습니다.
Tailwind와 마찬가지로 Next.js 서버 컴포넌트에 사용 가능할지가 궁금한데 써보신분 있나요? Styled-components는 이래저래 에로사항이 있었어서..
저도 궁금하네요 111
저도 궁금하네요 222
저도 이 질문 남기려고했는데..333
서버 컴포에 적용되면 tailwind 대신 사용하기 좋아보이긴해요 취향에 따라..
근데 자바스크립트와는 독립적으로 컴파일해서 클래스를 만들어준다는거보면 될거같기도하고..
저는 next.js에 styled-components 적용해서 사용하고 있는데 어떤 부분이 문제이신건가요?
@@위즈WisdomIT
모종의 이유(next의 동작 원리 때문이라고는 하는데 자세히는 모르겠어요)로 인해 서버 컴포넌트에서는 styled-components 라이브러리를 직접 import하여 사용하는게 불가능합니다. 다른 파일에서 클라이언트 컴포넌트로 작성한 후 필요한 서버 컴포넌트로 불러오는 식으로 쓸 수는 있는데, 불필요하게 파일이 쪼개지는 것과 S.Component 방식의 네이밍이 지원이 되지 않는게 참 불편했습니다.
근데 진짜 tailwind가 가독성이나 관리차원에서 이점이 있나요 ?
왤케 모르겠지 나는
소규모 프로잭트면 당연히 잇지만... 규모가 커지면 ㄹㅇ... 코드 읽는 가독성부터 조져놧는데.
ㄹㅇ 진짜 규모커지면 코드쓰레기장이 따로없음
CSS 까지 타입 세이프티가 필요한가..
이제 그만 놔둘렵니다. 스벨트랑 tailwindcss 둘다 현업에서 잘쓰고 있습니다
vanilla extract 같은 느낌이 나네요
뭘까 싶어서 헐레벌떡 들어왔지만,, 테일윈드랑 styled-components 같은 것들은 패러다임부터 완전 다르다고 봅니다.
테일윈드로 넘어온 제 취향으로선 HTML과 CSS가 두 개 이상의 파일을 옮겨가며 볼 필요 없이 한 눈에 어떤 모양새인지 볼 수 있다는 점 때문인데, 결국 HTML와 CSS를 분리해야하는 StyleX는 TailwindCss를 대체하기엔 저에겐 불만족스럽군요 😢
이것도 결국 프로젝트 커지고 노후화되면 중복된 변수들 쌓이고 다음 사람오면 전 사람이 급해서 tsx 밑에 구석탱이에 짱박아놓은 거 발견 못하고 새로 만들고 하다보면 한 10년 후에는 꼴도보기 싫은 프로젝트로 될 거 같아서.... tailwind가 더 좋아보여요.... 퍼블리셔랑 협업해야 할 때도 tailwindcss가 좋고.... 혹시 테일윈드 망하더라도 convert해서 css로 만들면 다른걸로 바꾸기도 용이함...
글쎄요 css 에 과연 타잎 안정성이 그렇게 필요한 것인가...라는 의문이.. 스타일을 저런식으로 쓰면 가장 큰 단점이 코드 재사용성이 매우 떨어진다는 점에 있어 테일윈드의 가장 큰 장점이 사라지는것.
호우!!!
예전부터 봐 왔지만 FE는 참.. ㅋㅋ 결국 껍데기와 코딩 스타일만 바꾸면서 유행을 너무 많이 탐. 새로운 기술을 배워서 이전에 구현할 수 없던 무언가 가능해지거나 체감되는 퍼포먼스가 대단히 증가하느냐 하면 딱히 그것도 아닌...
❤
웹프론트개발자 되어야지 했다가.. 금전적인 문제로 다시.. 원래 업종 복귀하고.. 회사 전산(웹)보며.. IE모드 필수이고.. 예쁘게 만들필요없어.. 백엔드 분들이 만든 코드들이 잘 작동되면 장떙인걸..보고 괜히 프론트 공부했나 생각 들곤 있긴합니다.
개발자 하기전 나갈때도 사내 친한 개발자분이 백엔드 재미있다고하셨는데.. 그말 무시한게 이렇게 된건지 ㅠㅠ
요즘 짜투리 시간으로 일일 보고서 작성할 부분 자바스크립트 기반으로 메크로처럼 만드는데 GPT센세에게 물어보는거 보면 개발자 될려면 몇년 걸릴것 같다 생각이 드네요.
접근성이 옳바르게 되어 잘 작동되는지 먼저 보고 있어서 CSS에 대해서는 아직 모르겠어요...
IE 모드가 필수인 환경이라면 너무 안좋은 환경이군요.
이미 잘 아시겠지만
사업방향에 따라 백엔드분이 만든 코드가 잘 작동되면 장땡인게 맞을때도 있고 FE 개발자가 전문적으로 있어서 유지보수하며 기능을 추가해 나가는게 정답일때도 있다고 생각합니다.
저 또한 개발하면서 최근에는 GPT 센세에게 많이 물어보네요.
뭐 이리저리 이야기해보았자 뭐하겠어요. 우리 모두 겸손한 자세와 마음가짐을 가지고 공부해야죠.
???: 튜닝의 끝은 순정이다
Ssr 지원해준다더니 막상 next에 깔아보려니까 babel config 커스텀하라 그래서 바로 지움.
native css 가 최고다!!
형 요즘엔 현업들 안쓰는것만 골라서 갖고오네
넘 공부할게 많아 ㅜㅜ
음 그냥 피그마 신(god) 쓰면 신경 안써도 되는? ㅋㅋㅋ
메타는 jest 빼고는 믿고 거르는 1인...
ㅇㅈ RN부터 Recoil까지 참 뭐시기함
@@user-ql2ko9fm7t Recoil은 익히 들어 알고있었는데 RN도 유기당했나요😢
@@user-ql2ko9fm7t rn은 한국에서 유니콘들 안 쓰는 곳이 없는데 ㅋㅋ
@@simsim--RN보다 플러터가 더 우세하지 않나요?
@@limeojin363 문제가 산더미인데 개선할 생각을 안함.. 특히 퍼포먼스 부분은 아예그냥 손놓고 아몰랑 이러고있음
아니이 몆게를 해먹는거야 진짜 그만좀 해
별론데
StyleX is just another piece of crap, just like React, that tries to shove meta at you. The very idea of StyleX is nonsense.
The level of overengineering in modern frontend development is already off the charts.
1