-
reset
- ใช้ preflight styles ของ Tailwind โดยคัดลอกมาจาก
tailwind.css ช่วงแรกประมาณ 200 บรรทัด
- ผู้เขียนคุ้นกับ Tailwind reset มานาน และกฎที่ใส่
box-sizing: border-box ให้ทุก element ก็ทำให้ความกว้างของ element รวม padding อยู่ด้วย
* { box-sizing: border-box; }
- อาจมีการพึ่งพากฎ reset อื่น ๆ แบบไม่รู้ตัว เช่น
html {line-height: 1.5;} และถ้าจะเขียน CSS โดยไม่มีกฎพวกนี้ ก็ดูเหมือนต้องใช้เวลาปรับตัวมาก
-
components
- CSS ส่วนใหญ่ถูกจัดเก็บเป็น ไฟล์ตามคอมโพเนนต์ คล้ายกับคอมโพเนนต์ใน Vue หรือ React
- แต่ละคอมโพเนนต์มีคลาสเฉพาะของตัวเอง และจัดให้ CSS ของคอมโพเนนต์หนึ่งไม่ไปเขียนทับ CSS ของอีกคอมโพเนนต์
- ในทางปฏิบัติ CSS ที่อยากแก้จริง ๆ ราว 80% อยู่ในไฟล์คอมโพเนนต์ ดังนั้นเวลาแก้คอมโพเนนต์ 100 บรรทัด ก็คิดแค่ 100 บรรทัดนั้นพอ
- ตัวอย่างเช่น คอมโพเนนต์
.zine อาจมี HTML แบบนี้
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
- ฝั่ง CSS จะใช้ nested selectors เพื่อรวมสถานะอย่าง
.horizontal, .vertical และ :hover ไว้ภายในคอมโพเนนต์
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
- แม้จะยังไม่ได้ใช้วิธีแบบ Web Components หรือ
@scope เพื่อกันการรบกวนกันระหว่างคอมโพเนนต์ในเชิงโปรแกรม แต่แค่ตั้งธรรมเนียมและยึดตามนั้นก็ช่วยได้มากแล้ว
-
colours
- ใน
colours.css จะรวม CSS variables ที่หยิบมาใช้ได้เมื่อจำเป็น
- สีเป็นเรื่องยาก และในการรีแฟกเตอร์ครั้งนี้ผู้เขียนไม่อยากกลับไปทบทวนการใช้สีใหม่ จึงยังคงแนวทางเดิมไว้
- กฎเดียวคือให้ระบุสีทั้งหมดที่ใช้ในเว็บไซต์ไว้ในไฟล์นี้
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
-
font sizes
- ใน Tailwind แค่เลือกขั้นขนาดอย่าง
text-lg, xl, 2xl ก็พอ จึงไม่ต้องจำว่าจะใช้ em, px หรือ rem
- เพื่อคงประสบการณ์แบบนั้นใน vanilla CSS ผู้เขียนจึงนิยามตัวแปรขนาดที่นำมาจาก Tailwind
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
- ขนาดฟอนต์ถูกกำหนดผ่านตัวแปร ซึ่งแม้จะยืดยาวกว่า Tailwind เล็กน้อย แต่ตอนนี้ก็ยังเป็นวิธีที่น่าพอใจ
h3 {
font-size: var(--size-lg);
line-weight: var(--line-weight-lg);
}
-
utilities
- องค์ประกอบที่ซ้ำข้ามหลายคอมโพเนนต์ เช่น ปุ่ม จะถูกจัดไว้ในหมวด utilities
- utility classes บางตัว เช่น
.sr-only สำหรับ element ที่ควรให้ผู้ใช้ screen reader เห็นเท่านั้น ถูกคัดลอกมาจาก Tailwind
- ผู้เขียนพยายามคงส่วนนี้ให้เล็ก และระมัดระวังเวลาแก้ไข
-
base
- สไตล์ “base” คือสไตล์ที่ใช้กับทั้งเว็บไซต์โดยตรง
- เพราะยังไม่มั่นใจพอจะบังคับสไตล์จำนวนมากทั้งไซต์ จึงตั้งใจให้ส่วนนี้เล็กมาก
- ตอนนี้มีกฎที่รู้สึกว่าโอเคอยู่ 2 อย่างสำหรับ
<section> และ a โดยกฎของ <section> อาจเปลี่ยนในภายหลัง
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
- สำหรับ base styles วิธีที่ดูง่ายที่สุดคือเริ่มจากเกือบว่างไว้ก่อน แล้วค่อยย้ายสิ่งที่พบว่าอยากใช้ร่วมกันจากคอมโพเนนต์ขึ้นมาไว้ใน base แบบ bottom-up
-
spacing
- วิธีจัดการ padding และ margin ยังไม่ได้ถูกกำหนดลงตัวทั้งหมด
- ตอนใช้ Tailwind ผู้เขียนมักใส่ padding กับ margin แบบเฉพาะหน้าไปเรื่อย ๆ จนกว่าจะได้หน้าตาที่ต้องการ และตอนนี้กำลังมองหาวิธีที่มีหลักการกว่านั้น
- ตอนนี้พยายามให้คอมโพเนนต์ layout ชั้นนอกเป็นผู้รับผิดชอบเรื่องระยะห่างให้มากที่สุด
- ถ้าอยากเว้นระยะเท่ากันระหว่างลูกใน
<section> ที่มีลูกหลายตัว ก็อาจใช้กฎแบบนี้
section > *+* {
margin-top: 1rem;
}
-
responsive design
- ใน Tailwind ผู้เขียนใช้ ไวยากรณ์แบบ media query เยอะ เช่น
md:text-xl ที่จะใช้สไตล์ text-xl เมื่อเกินขนาดที่กำหนด
- ตอนนี้พยายามสร้าง layout ด้วย CSS grid ที่ยืดหยุ่นกว่าและไม่ต้องพึ่ง breakpoint มากนัก
- การใช้
auto-fit ช่วยให้บนหน้าจอใหญ่เป็น 2 คอลัมน์ และบนหน้าจอเล็กเป็น 1 คอลัมน์โดยอัตโนมัติ
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
-
build system
- ระหว่างพัฒนาไม่จำเป็นต้องมี build system แยก
- CSS มี
@import ในตัวอยู่แล้ว จึงสามารถแยกไฟล์แล้วนำเข้ามาใช้ได้
@import "reset.css";
@import "typography.css";
@import "colors.css";
- CSS ยังมี nested selectors ในตัวด้วย
.page {
h2 { ...}
}
- ถ้าอยาก bundle ไฟล์ CSS สำหรับ production ก็สามารถใช้
esbuild ได้
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
- โดยทั่วไปผู้เขียนพยายามเลี่ยงการใช้ระบบ build สำหรับ CSS และ JS แต่สำหรับ
esbuild มองว่าโอเค เพราะอิงเว็บมาตรฐานและเป็น static Go binary
- ผู้เขียนเคยเขียน บทความเกี่ยวกับ esbuild และ Vue ไว้เมื่อปี 2021
3 ความคิดเห็น
พอเปลี่ยนเป็น zero-config แล้ว มันดูดีขึ้นหน่อยไม่ใช่เหรอ?
ความคิดเห็นจาก Hacker News
ฉันสอนเรื่อง HTML เชิงความหมาย และมาร์กอัปที่เข้าถึงได้มานาน และก็เคยทำทั้งเว็บและแอปสำหรับ screen reader มาเยอะ ปัญหาใหญ่ที่สุดของ Tailwind คือมันกลับลำดับการคิดระหว่าง HTML กับ CSS
HTML มีไว้แสดงความหมายของเอกสาร จึงควรเริ่มจากตรงนั้น แล้วค่อยใช้ CSS จัดสไตล์ต่อ หากจำเป็นต้องมีองค์ประกอบเพิ่มเพราะเหตุผลด้านสไตล์ จะใช้ div หรือ span ก็ได้ แต่ก่อนอื่นควรถามก่อนว่ามีองค์ประกอบที่เหมาะสมกว่านั้นหรือไม่
Tailwind ผลักให้นักพัฒนาเข้าหาแนวคิดแบบ CSS มาก่อน จนต้องคิดก่อนว่าอยากได้คลาส Tailwind อะไร แล้วค่อยเพิ่ม div อีกตัวใน DOM เพื่อเอาคลาสนั้นไปใส่
ความสามารถของนักพัฒนาเว็บควรรวมถึงการสร้าง HTML และ CSS ที่อ่านง่ายในอนาคต ใช้งานได้กับผู้ใช้ทุกคน และโดยรวมสอดคล้องกับสเปก HTML/CSS แต่ Tailwind ทำให้ทักษะด้านนั้นถดถอย ตัวอย่างแรกบนเว็บไซต์ Tailwind ก็มีแต่ div กับ span และถือเป็นการสอนที่ไม่ดีสำหรับนักพัฒนาใหม่ อีกทั้งยังมีส่วนทำให้ LLM ชอบพ่น div soup ออกมา ถ้าไม่ได้สั่งเป็นพิเศษ
เครื่องมืออะไรก็ใช้ผิดได้ และ Tailwind ก็ไม่ใช่ข้อยกเว้น ฉันใช้ CSS มาราว 20 ปี และเคยใช้ Less, SASS/SCSS, Stylus, PostCSS มาแล้ว แต่ที่ลงเอยกับ Tailwind ในช่วงไม่กี่ปีมานี้ กลับเป็นเพราะมันช่วยให้จัดสไตล์แอปได้แข็งแรงขึ้น
ไม่ต้องสร้างชั้น abstraction ของ style/class มากเกินไป พอวางสไตล์ไว้ตรงกับมาร์กอัปที่ได้รับผลกระทบ ภาระในการทำความเข้าใจก็ลดลง ตัวเลือกแบบหลวม ๆ ที่ไปเปลี่ยนสไตล์โดยไม่ตั้งใจก็น้อยลง และดีบักก็ง่ายขึ้น เมื่อเทียบกับโค้ดเบสที่มี CSS framework แบบทำเองแล้ว โค้ดเบสที่ใช้ Tailwind มักซับซ้อนน้อยกว่าและเปราะบางน้อยกว่า ยกเว้นแค่เว็บ/แอปที่เรียบง่ายมาก
เมื่อคำนึงถึงสเกลฟอนต์ สี และขนาดที่สม่ำเสมอ, bundle ที่เล็กกว่า, ความสม่ำเสมอระหว่างนักพัฒนาที่รู้จัก Tailwind, ระบบนิเวศที่แข็งแรง และความเป็นมิตรกับ LLM ด้วย มันจึงเป็นตัวเลือกที่ยอดเยี่ยมสำหรับหลายทีม สุดท้ายแล้วก็เหมือนเครื่องมือส่วนใหญ่ คือขึ้นอยู่กับว่าใครใช้
ความยุ่งเหยิงของ HTML/CSS/JS สำหรับฉันคือความชั่วร้ายที่จำเป็นเมื่อต้องทำงานกับเบราว์เซอร์ และสำหรับฉันมันก็เป็นแค่ชั้นการแสดงผลเท่านั้น ในงานจริงฉันให้ความสำคัญกับความถูกต้องของสคีมาฐานข้อมูลหรือ business logic ฝั่ง backend มากกว่าเยอะ
ถ้าชั้นการแสดงผลจะรกหน่อย แต่ใช้ให้น้อยที่สุดและยังพอดูแลรักษาได้ ก็ถือว่าเพียงพอแล้ว และ Tailwind ก็เหมาะกับเป้าหมายนั้นมาก LLM เขียนได้ดี นักพัฒนาใหม่ก็เข้าใจได้เร็ว และกลับมาอ่านหรือแก้ทีหลังก็ค่อนข้างง่าย
ฉันเห็นด้วยเต็มที่ว่าโปรเจกต์ Tailwind ไม่ใช่วิธีที่ดีที่สุดสำหรับให้นักพัฒนาใหม่เรียน HTML/CSS แต่ฉันกลับอยากให้นักพัฒนาใหม่ไปโฟกัสกับสคีมาฐานข้อมูลที่ดี, API ที่เข้าใจง่าย, business logic ที่ทดสอบได้ มากกว่า
ตัว Tailwind เองไม่ได้มีอะไรที่บังคับให้ใช้ div กับ span แทนแท็ก HTML ที่เหมาะสม
เอกสารกับอินเทอร์เฟซไม่เหมือนกัน และ Tailwind สมเหตุสมผลกว่ามากกับ อินเทอร์เฟซ คุณใช้ Tailwind กับอินเทอร์เฟซ และใช้ตัวเลือก HTML แบบจำกัดขอบเขตกับคอนเทนต์ประเภทอื่นได้
ความจริงที่ว่า Tailwind เร็วกว่าการเขียนโค้ดเบส CSS ที่ซับซ้อนราว 4 เท่า และแทบไม่มี overhead ก็ยังเป็นข้อดีไม่ว่าจะประเมินจากมุมไหนก็ตาม
สรุปคือมันเป็นวิธีเขียน CSS ตามลำดับของความเฉพาะเจาะจง:
/scss/
├── 1-settings. <- การตั้งค่าระดับ global
├── 2-design-tokens <- ฟอนต์, สี, ระยะห่าง ฯลฯ
├── 3-tools <- Sass mixin, CSS function ฯลฯ
├── 4-generic <- reset, box sizing, normalize ฯลฯ
├── 5-elements <- สไตล์พื้นฐานของ heading, button, link
├── 6-skeleton <- layout grid ฯลฯ
├── 7-components <- card, carousel ฯลฯ
├── 8-utilities <- utility และ helper class
├── _shame.scss <- แฮ็กที่ไว้แก้ทีหลัง
└── main.scss
ITCSS แทบจะกำจัดสงครามเรื่อง specificity ในโค้ดเบส CSS ได้เลย โดยปกติที่เดียวที่มักมี
!importantก็คือชั้น utility[1]: https://matthiasott.com/notes/how-i-structure-my-css
ถ้าดู component library ก็จะเห็นว่ามี
ariaattributes รวมมาให้ด้วย: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...เว้นแต่จะเป็นอะไรแนว landing page ที่ใกล้เคียงโบรชัวร์ดิจิทัล ฉันก็เริ่มจากมาร์กอัปก่อนเสมอแล้วค่อยเติม CSS class ลงไป
ข้อดีสองอย่างของ Tailwind คือมีข้อมูลคลาสอยู่ใน ชุดข้อมูลฝึก AI เยอะมากอยู่แล้ว และไม่มีปัญหาสไตล์ชนกัน
เพราะอย่างนั้นเวลา AI จะสร้างสไตล์ใหม่ มันไม่ต้องอ้างอิง stylesheet เดิม จึงดีต่อการจัดการ context
แต่ถ้าเป็น CSS แบบทำเอง AI ต้องอ่าน stylesheet เดิมเพื่อลดการชนกันหรือการเขียนซ้ำ ซึ่ง stylesheet ขนาดใหญ่ก็อาจกินพื้นที่หน่วยความจำของ AI มากจนเป็นปัญหาได้
ฉันชอบงานเขียนของ Julia Evans มากจริง ๆ
เธอเขียนจากจุดที่มีทั้งความเปราะบางและความซื่อตรง หลายคนเขียนเพื่อให้ตัวเองดูฉลาด แต่ Julia เขียนด้วยท่าทีแบบ “ฉันเองก็ไม่ได้รู้ทุกอย่างหรอก แต่มีบางอย่างที่ค้นพบแล้วอยากแบ่งปัน” มันให้ความรู้สึกเหมือนกำลังแบ่งอะไรบางอย่างให้คนที่รัก แม้จะไม่ได้รู้จักเธอเป็นการส่วนตัวก็ตาม
ใน Strange Loop ครั้งล่าสุด เธอขึ้นพูดร่วมกับ Randall Munroe หลังจบมีคนต่อคิวรอคุยกับเขา แต่ฉันรอคุยกับ Julia ฉันรู้สึกเสียใจจริง ๆ ที่เหมือนเธอจะไม่เข้าใจมุกที่ฉันพูดเรื่องให้เขียน bash script ใหม่เป็น Perl
ฉันไม่ใช่ Julia แต่ก็มีปรัชญาเรื่องการพูดในที่สาธารณะและการพรีเซนต์แทบจะเหมือนกัน และพยายามปลูกฝังสิ่งนี้ให้เพื่อนร่วมงานที่ลำบากใจกับการนำเสนอด้วย การได้ถ่ายทอดความรู้ที่เราคุ้นเคยกว่าเล็กน้อย และอาจเป็นประโยชน์ต่อเพื่อนร่วมงานหรือคนที่เรารัก ถือเป็นสิทธิพิเศษอย่างมาก
CSS Modules เป็นคำตอบที่ง่ายกว่าสำหรับปัญหาเรื่อง cascade มันสร้างชื่อคลาสที่ไม่ซ้ำเพื่อป้องกันการชนกันของคลาส [1]
และไม่มีข้อเสียใหญ่สองอย่างของ Tailwind คือเรื่องความอ่านง่าย [2] และการรองรับจากเครื่องมือ โดยเฉพาะฉันคิดว่าการดีบักและการทดลองแบบโต้ตอบใน Chrome และ FireFox DevTools ทำได้ดีกว่า
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
สิ่งที่ทำให้ฉันประทับใจเกี่ยวกับ Tailwind มาโดยตลอดคือ แทบทุกเหตุผลของฝั่งผู้สนับสนุนสุดท้ายแล้วจะวนกลับไปที่ “ไม่เคยเรียน CSS ให้เกินระดับจูเนียร์จริง ๆ”
เรามักได้ยินคำพูดอย่าง “ถ้าไม่มี Tailwind ก็จะมีไฟล์ CSS ก้อนโตที่ไม่เป็นระเบียบ โตจนควบคุมไม่ได้ เต็มไปด้วยโค้ดเก่าและ
!important” แต่ CSS ก็เป็นทักษะอย่างหนึ่งเหมือนทักษะทางเทคนิคอื่น ๆถ้าคุณเรียนแค่พอให้มันออกมาดูถูกใจ แล้วคอยปะผุไปเรื่อย ๆ ความทะเยอทะยานก็จะวิ่งแซงความสามารถในการจัดระเบียบโค้ดอย่างรวดเร็ว
เวลาคุยกับใครเรื่อง Tailwind และ CSS แล้วถึงจุดที่ตระหนักว่าอีกฝ่ายไม่เพียงไม่รู้ว่า “cascading” หมายถึงอะไร แต่ไม่เคยแม้แต่จะคิดว่ามันอาจเป็นแนวคิดที่มีประโยชน์ในบริบทของ stylesheet ด้วยซ้ำ นั่นชวนหงุดหงิดมาก
ฉันใช้ CSS มาเยอะตั้งแต่ยุค 90 แล้วพอมาดู Tailwind ก็รู้สึกว่าเข้าใจมัน และหลังจากเข้าใจแล้ว ฉันก็หลีกเลี่ยง CSS ล้วนเกือบทั้งหมด ในแง่หนึ่งมันคือการเอาความยุ่งเหยิงแบบหนึ่งไปแทนอีกแบบหนึ่ง แต่ส่วนตัวฉันยังชอบรับมือกับ ซุปของคลาสที่ถูกทำให้เป็นเฉพาะจุด มากกว่ารับมือกับ cascade ที่ทับซ้อนและขัดแย้งกันข้ามหลายไฟล์
ทั้งสองแบบทำให้สะอาดได้ แต่ถ้าต้องเก็บกวาด ฉันว่าความยุ่งเหยิงของ Tailwind ดีกว่าความยุ่งเหยิงของ CSS มาก และกระบวนการพัฒนาโดยรวมก็สนุกกว่าด้วย
ฉันเองก็เขียนโปรแกรมมาเกิน 20 ปี และทำเว็บมาเกือบ 15 ปีแล้ว แต่ก็ยังหาแรงจูงใจที่จะเรียน CSS แบบจริงจังได้ยาก เพราะมีทักษะทางเทคนิคอีกมากที่ต้องตามให้ทัน และ CSS ก็อยู่ค่อนข้างล่างในลำดับความสำคัญของฉัน
ฉันอยากปล่อยให้ผู้เชี่ยวชาญดูแล แต่บริษัทต่าง ๆ ก็ไม่ค่อยอยากจ้างนักพัฒนา frontend โดยเฉพาะ
ฉันกำลังเขียน คู่มือพัฒนาเว็บแบบสะอาด ที่เน้นการเขียน HTML และ CSS ที่ขยายต่อได้ดี: https://webdev.bryanhogan.com/
อาจมีประโยชน์กับคนที่นี่ก็ได้ สำหรับการจัดสไตล์ ฉันไม่ใช้พวกอย่าง Tailwind แต่ใช้ modern framework อย่าง Astro หรือ Svelte ร่วมกับ CSS
ทุกโปรเจกต์ของฉันจะมี
reset.css,var.css,global.css,util.cssและสไตล์ที่เหลือก็จะจำกัดขอบเขตไว้กับ component หรือ layout นั้น ๆเป็นบทความที่ดี
ฉันชอบตัด dependency จากไลบรารีภายนอกออกแล้วสร้างทางแก้เองตั้งแต่ต้น แต่กับ Tailwind มีเหตุผลชัดเจนที่ฉันไม่ทำแบบนั้น นั่นคือมันมีการ optimize สำหรับ production ที่ช่วยให้มั่นใจว่าจะส่งออกเฉพาะ CSS ขั้นต่ำที่จำเป็นจริง ๆ เท่านั้น
ต่อให้คุณไปไล่ประกาศตัวเลือกเรื่องสี ระยะห่าง ฯลฯ ไว้ทั้งหมดใน
globals.cssหรือที่อื่น คุณก็ไม่ต้องกังวลเลยว่าจะใช้ variation ทั้งหมดนั้นใน production หรือไม่ และถ้าทำงานใน framework อย่าง Next.js ขั้นตอนย่อส่วนนี้ยังเกิดขึ้นให้อัตโนมัติตอน build อีกด้วย แค่นี้ก็เป็นเหตุผลเพียงพอแล้วที่ฉันจะไม่ย้ายออกจาก Tailwindฉันไม่เคยรู้สึกว่าการใช้ inline CSS ใน Tailwind มีข้อจำกัดที่รับมือยาก และก็ไม่เคยมีปัญหาใหญ่กับการใช้เครื่องมือ grid ของ Tailwind เพื่อทำกริดที่ตอบสนองตามความกว้างหน้าจอ สถานการณ์ต่าง ๆ ในบทความนั้น ฉันเคยแก้ได้หมดแล้วด้วย Tailwind หรือด้วย Tailwind ผสม CSS และถึง
grid-column-areasจะไม่มีมาให้โดยตรงจริง แต่จนถึงตอนนี้ฉันก็ยังไม่รู้สึกว่ามันเป็นข้อจำกัดใหญ่ใน responsive grid layoutปัญหาใหญ่ที่สุดของ Tailwind คือมันต้องใช้เวลานานพอสมควรกว่าจะอ่านคล่อง เราถูกสอนมาแบบว่า inline CSS ไม่ดี ส่วน CSS แบบ global scope นั้นดี และก็คุ้นกับ HTML ที่สะอาดเรียบร้อย พอเห็นโค้ด Tailwind จริง โดยเฉพาะบรรทัดยาว ๆ ตอนแรกมันเลยดูอ่านยากมาก พอใช้ไปนาน ๆ ฉันก็ชินกับหน้าตาของมันเต็มที่ และสุดท้ายก็มาสรุปว่า Tailwind สำหรับฉันมีประสิทธิภาพกว่า ดูแลรักษาง่ายกว่า และอ่านง่ายกว่าด้วย แต่ก็ต้องใช้เวลาไม่น้อย
ช่วงนี้แนวทางที่ฉันชอบมากคือใช้ Tailwind ร่วมกับ style แบบจำกัดขอบเขต (ใน Svelte และ Vue)
แบบนี้จะยังได้ความสะดวกของ Tailwind โดยทำให้ template เลอะน้อยที่สุด:
+
{{ count }}
สำหรับฉัน Svelte กับ LLM ทำให้ไม่จำเป็นต้องใช้ Tailwind อีกต่อไปโดยสิ้นเชิง
พอมาคิดดู เหตุผลหลักที่ฉันใช้ Tailwind ไม่ใช่ข้อจำกัดที่ตั้งขึ้นเอง แต่เป็นการหลีกเลี่ยง CSS ชนกัน และไวยากรณ์ที่สำหรับฉันรู้สึกมีเหตุผลมากกว่า
สิ่งที่ดีที่สุดใน Tailwind คือไม่ต้องคอยคิดชื่อคลาสชั่วคราวอีกต่อไป ไม่ต้องใช้ BEM แล้ว
ความเห็นจาก Lobste.rs
สำหรับโปรเจกต์ส่วนตัว เดี๋ยวนี้แทบไม่ใช้ เฟรมเวิร์ก CSS/JavaScript แล้ว
เพราะถ้าไม่มี dependency ก็จะไม่มีช่องโหว่ในซัพพลายเชนเกิดขึ้นได้ แน่นอนว่าช่องโหว่ไม่ได้มีแค่นั้น แต่ก็ช่วยได้
เป็นผลรวมของความล้าจากเฟรมเวิร์ก, ภาระจาก
npm auditและการที่มี LLM ทำให้ไม่ต้องสนใจคำตัดสินของคนอื่นเรื่องวิธี implement มากเท่าเดิม เช่นคำถามประมาณว่า “ทำไมไม่ใช้ React กับ Tailwind”นี่ก็เป็นแค่ วิธีการทำงานของ CSS เอง
เวลาเห็นคนไม่รู้เรื่องนี้แล้วใช้ Tailwind แบบไม่ลืมหูลืมตา ก็อยากออกไปตะโกนใส่ก้อนเมฆเลย สำหรับฉัน Tailwind 90% ก็คือ inline style ที่เปลี่ยนแค่ไวยากรณ์ และอาจมองได้ว่าแค่ดีกว่าแท็ก
<FONT>ขึ้นมาขั้นหนึ่งบล็อกโพสต์นี้อธิบายในสิ่งที่ฉันจำเป็นต้องรู้จริงๆ
Tailwind ทำงานต่างจาก inline style มาก และจริงๆ แล้วคล้าย CSS มากกว่ามาก อย่างที่บทความชี้ไว้ นิสัยที่ดีหลายอย่างซึ่งทำให้ใช้ Tailwind ได้เก่ง ก็เป็นนิสัยเดียวกับที่จำเป็นต่อการเขียน CSS อย่างมีประสิทธิภาพ Tailwind ใกล้เคียงกับการแนบ บล็อก CSS ที่มีสโคปโดยนัย ให้ทุกองค์ประกอบ โดยใช้ DSL ที่มีลักษณะเฉพาะมากกว่า
ฉันเข้าใจการทำงานของ CSS ดี แต่ CSS แบบเพียวๆ ยังรู้สึกหนักมือ และฉันก็ไม่ค่อยเก่งด้านกราฟิกดีไซน์ เลยยังใช้ Tailwind อยู่ บทความนี้ให้ไอเดียในการจัดโครงสร้าง CSS โดยอิงจาก Tailwind
สำหรับคนที่ตามกระแสล่าสุดไม่ค่อยทัน บทความนี้ดูเหมือนจะแสดงให้เห็น แนวปฏิบัติ CSS สมัยใหม่ ได้ค่อนข้างดี
ชอบตรงที่มีลิงก์ต่อไปยังบทความที่เป็นแรงบันดาลใจหลายชิ้นด้วย เหมาะจะเก็บไว้อ่าน ตอนนี้ฉันเพิ่งอ่านแค่ "no outer margin"
แต่ก็ยังแอบสงสัยเล็กน้อยกับแนวทางตั้ง default style แบบ “จากล่างขึ้นบน” ไม่รู้ว่าควรทำอย่างอื่นแทนไหม และมันก็ดูน่าลองอยู่ แต่ default style โดยธรรมชาติก็เป็นเรื่องที่จัดการยากอยู่แล้ว
บทความนี้ดีมากจริงๆ
ฉันเองก็ค่อยๆ เรียน CSS ไปพร้อมกับทำเว็บเล็กๆ หลายแบบ และคิดว่าถ้าเริ่มต้นมาพร้อม วิธีคิดเชิงระบบ แบบนี้ก็น่าจะช่วยได้มาก แม้จะค่อนข้างไม่ชอบเฟรมเวิร์ก แต่พอไม่ได้ใช้ ก็ถึงจะทำสิ่งที่ต้องการได้ก็จริง ทว่ามักรู้สึกเหมือนลอยอยู่กลางอากาศแบบไร้โครงสร้าง
ชอบตรงที่ไม่ได้พูดว่า “Tailwind ไม่ดี ก็ไปใช้ CSS เถอะ” แต่เป็นแนวว่า “Tailwind ยอดเยี่ยม แต่ตอนนี้อาจไม่จำเป็นแล้วก็ได้”
ฉันมีปัญหากับการจัดโครงสร้าง CSS ด้วยมือตลอด และบทความนี้ทำให้เริ่มคิดมันในมุมที่ต่างออกไปมาก
ตอนจัดระเบียบ CSS ฉันพบว่า เทคนิคการจัดโครงสร้าง นี้มีประโยชน์มาก: https://rstacruz.github.io/rscss/
โดยรวมแล้วมันเข้ากันได้ดีกับสิ่งที่ jvns อธิบายในบทความต้นทาง และช่วยเติมเรื่องโครงสร้างกับความเป็นระเบียบเข้าไปอีกหน่อย