Videos → A Journey into Next-Gen CSS-in-JS Innovations
Description
ปัญหาและทางออกของ CSS-in-JS ในยุคใหม่ พบกับคุณจุ้น UI engineer จากทีม MUI ผู้พัฒนา Material UI library ยอดนิยมบน React เขาจะมาเล่าถึงปัญหาที่พบเจอจากการใช้งาน CSS-in-JS ในโปรเจคขนาดใหญ่ รวมถึงข้อจำกัดในการใช้งานร่วมกับเทคโนโลยีใหม่ๆ อย่าง React Server Components พร้อมเจาะลึกแนวโน้มการใช้งาน CSS-in-JS ที่กำลังลดลง และทางเลือกใหม่ๆ ที่น่าสนใจอย่าง Next Generation CSS-in-JS เช่น Vanilla Extract, Compiled, Panda CSS, Linaria, Stylex และ Griffel โดยเฉพาะ Linaria ที่ทางทีม MUI เลือกใช้เป็นพื้นฐานในการพัฒนา Zero Runtime engine ใหม่ มาร่วมสำรวจอนาคตของการจัดการสไตล์ใน JavaScript และเรียนรู้วิธีการสร้างเว็บแอปพลิเคชันที่รวดเร็วและมีประสิทธิภาพยิ่งขึ้น
Chapters
- แนะนำหัวข้อและวิทยากร 0:00
- ปัญหาของ CSS-in-JS และการค้นหาโซลูชัน 0:30
- แนะนำ Material UI และสถิติการใช้งาน 1:30
- ความท้าทายในการพัฒนา open source ขนาดใหญ่ 3:26
- อธิบาย CSS-in-JS และข้อดีของมัน 4:28
- การลดลงของความนิยมใน CSS-in-JS 6:54
- ปัญหาความเข้ากันไม่ได้กับ React Server Components 8:05
- การค้นหาโซลูชันใหม่สำหรับ CSS-in-JS 10:17
- แนะนำ Zero Runtime CSS-in-JS 12:20
- การ migrate จาก Emotion ไปสู่ Zero Runtime 14:20
- กระบวนการทำงานของ Zero Runtime ในช่วง build time 17:20
- การจัดการ dynamic styles ใน Zero Runtime 20:10
- ผลลัพธ์และประโยชน์ของ Zero Runtime 21:54
- การทดสอบประสิทธิภาพของ Zero Runtime 23:06
- แผนการเปิดตัว Zero Runtime ใน Material UI v6 24:12
- สรุปและเปิดโอกาสสำหรับคำถาม 24:50
Transcript
คำบรรยายต่อไปนี้อาจไม่ถูกต้องทั้งหมด หากคุณพบข้อผิดพลาดใดๆ คุณสามารถช่วยแก้ไขข้อผิดพลาดได้บน GitHub
แนะนำหัวข้อและวิทยากร0:00
จะเป็นหัวข้อ Next Generation CSS in JavaScript นะครับ เดี๋ยวขอเสียงปรบมือให้กับพี่จุ้นหน่อยนะครับ เวทีอลังการมาก คนเยอะด้วยนะครับ โอเค ก็
ทุกคนมีใครเคยใช้ CSS-in-JS บ้าง มีไหมฮะ น่าจะเคยผ่านๆ มาอยู่เนอะ โอเค อันนี้ก็จะเป็นเรื่องเกี่ยวกับ step ต่อไปของ CSS-in-JS นะครับ เดี๋ยวผมจะเล่าให้ฟังว่า มันมีปัญหาอะไรบ้าง
ปัญหาของ CSS-in-JS และการค้นหาโซลูชัน0:30
และก็ solution ที่ทางทีมเรา พยายามมองหานะครับว่า มันจะ ทำให้เว็บเราเร็วขึ้นยังไงได้บ้างนะครับ อย่างแรกเนี่ย เดี๋ยวแนะนำตัวสักเล็กน้อยนะ ผมชื่อ ศิริวัฒน์นะครับ เรียกสั ้นๆ ว่า เรียกจุ้นก็ได้ ตอนนี้ก็เป็น UI engineer นะครับ อยู่ที่ทีม MUI บริษัทชื่อ MUI นะครับ ทางเราก็เป็นบริษัทที่เชี่ยวชาญเรื่อง user interface นะครับ แล้วก็เขียน React มาพอสมควร แล้วก็โปรเจคที่เรียกว่าเป็นโปรเจคทำให้ทุกคนรู้จัก บริษัทเรานี้ ก็คือโปรเจคที่ชื่อว่า Material UI นะครับ ก็เป็นโปรเจคที่ได้รับทั้งคำชม และคำด่านะครับ โอเค ซึ่งตอนนี้เป็น open source
React component library ก็เดี๋ยวจะอธิบายให้ฟังถึงตัว
โปรเจคนิดนึงนะว่า scale มันอยู่ที่ตรงไหนนะครับ ทำไมสาเหตุที่มีทั้งคนชมแล้วก็มีทั้งคนด่า เรื่องความช้าหรือเรื่อง style อะไรพวกนี้ เดี๋ยวเรามาว่ากัน
แนะนำ Material UI และสถิติการใช้งาน1:30
stat เล็กๆ น้อยๆ นะครับ เพื่อให้เราเห็นว่า โปรเจคมันอยู่ที่ level ตรงไหน อย่างคนที่เข้ามาใช้งานตัวเว็บ MUI ตอนนี้ก็ประมาณ 1 ล้านคน 1 ล้านคนเลยนะต่อเดือน ตรงนี้ก็จะเป็น programmer, developer หรือ designer ที่เข้ามาดู doc มา research component ดู demo อะไรต่างๆ ประมาณ 1 ล้านคน ก็ถือว่าเป็นตัวเลขที่เยอะพอสมควรนะครับ ส่วนยอดดาวน์โหลด ณ ปัจจุบัน สำหรับตัวแพ็กเกจ Material UI ก็อยู่ที่ประมาณ 3 ล้าน ครั้งนะครับต่อสัปดาห์ ซึ่งสามล้านครั้งเนี่ย เยอะหรือไม่เยอะนะ เราลองเทียบกับ
ตัว React DOM ecosystem ดูนะ ประมาณ 16% ของยอดดาวน์โหลดทั้งหมดของ React DOM ซึ่ง React DOM เนี่ยก็คือ React ของ web platform ถูกไหมครับ เพราะฉะนั้น 16% นะ ก็ลองนึกภาพดูว่ามันเป็นตัวเลขที่ ค่อนข้างเยอะพอสมควร ก็ยั งเป็น อยู่ใน library ที่มียอด download อันดับ 1 อยู่ ในโลกของ React แล้วเมื่อกี้เห็นได้ยินว่า React ก็ยังชนะอยู่ใช่ไหม โอเคเพราะนั้น ก็ยังต้องใช้ React อยู่ เพราะถ้าเราก็ชนะ
ตรงนี้ผมจะแบ่งย่อยลงมาให้ดูว่า ในมุมของคนที่ใช้งาน ในเชิงที่เป็นบริษัท หรือว่าอุตสาหกรรมต่างๆ อยู่ในตรงไหนกันบ้าง ก็ลูกค้าของเราเนี่ยจริงๆ ก็ หลากหลาย อุตสาหกรรมมากๆ นะ อุตสาหกรรมเทค เกม รีเทลต่างๆ อวกาศก็มีนะครับ
ไม่ว่าจะเป็น streaming หนังนะครับ เทค โทรศัพท์ เกม รีเทล e-commerce ก็เป็นลูกค้าของเราทั้งสิ้นเลย อันนี้ก็เป็นแค่ส่วนหนึ่งนะครับ จริงๆ มีอีกเยอะมากๆ ที่ผมก็ไม่สามารถจะใส่มาในสไลด์ได้หมด
ความท้าทายในการพัฒนา open source ขนาดใหญ่3:26
ถ้าอยากให้เห็นว่าโปรเจ Material UI เนี่ย มันมีทั้งคนชอบและคนไม่ชอบ แต่ว่าโดย scale ของมันเป็น scale ที่ค่อนข้างใหญ่นะครับ เพราะฉะนั้นเวลาที่เราต้องการเขียนนำเสนอ feature ใหม่ๆ หรือการปรับปรุงโครงสร้างของโปรเจค คือเราไม่สามารถทำได้แบบ นึกอยากจะทำก็ปุ๊บ commit โค้ด push ขึ้นไปอะไรอย่างนี้นะครับ เพราะว่ามันมีคนอีกเป็น เรียกว่าเป็นล้านๆ โปรเจคที่ใช้โปรเจคเราอยู่นะครับ มันจะ affect วงกว้างมากๆ อย่างที่ทุกคนรู้นะว่าตัว Material UI ข้างหลังมันก็คือ ถ้าเรื่องของสไตล์มันใช้ CSS-in-JS ซึ่งตอนนี้หลักๆ ก็คือจะเป็น library ที่ชื่อว่า Emotion นะครับ ก็คือเรา เรียกว่าข้างหลังเป็น Emotion ในการเขียนสไตล์ขึ้ นมา แล้วก็
เราก็เอา design guidelines ของทาง Google มาใช้ แล้วก็ต้องขอย้ำว่า เราไม่ได้เกี่ยวอะไรกับทาง Google นะ ไม่ใช่แบบ บริษัทลูก Google อะไรอย่างนั้น ไม่เกี่ยวกันเลยนะครับ เราแค่ทำ component library ได้ดีกว่า Google แค่นั้นเอง ก็เลยมีคนเอาไปใช้
อธิบาย CSS-in-JS และข้อดีของมัน4:28
โอเคนะครับ ต่อมาเดี๋ยวเรามาเข้าเรื่อง CSS-in-JS กันนิดนึงนะครับ เมื่อกี้เห็นมีบางคนที่ อาจจะไม่ได้ยกมือนะ อาจจะยังไม่เก็ต หรือว่าไม่เคยได้ยินเลยนะครับ เดี๋ยวจะปู พื้นฐานให้ฟังเล็กน้อยนะครับ โดยสรุปว่ามันคืออะไร โดยชื่อมันก็ตรงตัวอยู่แล้วว่ามันคือการที่เราเขียน CSS ในรูปของในไฟล์ JavaScript ได้ หน้าตาเนี่ยส่วนใหญ่ๆ นะครับ คือ library ทุกอันเนี่ย มันจะมีฟังก์ชันให้เรา ที่ส่วนใหญ่ชื่อ CSS เลยนะครับ คือฟังก์ชันเนี้ยเวลาที่เรา
เรียกนะครับ เราจะสามารถใส่สไตล์ลงไปได้ สไตล์เนี่ยอาจจะเป็นตัว template literal string นะครับ หรือจะเป็น object ก็ได้ พอเราใส่เข้าไปปุ๊บนะครับ สิ่งที่มันจะ return มาให้เราเนี่ย ก็จะมันจะ generate class name ขึ้นมาให้ ก็คือ random ขึ้นมา เสร็จแล้วพวก random string พวกนี้ก็เอาไปใส่ใน class name ทีนี้พอเราเลือกใช้ปุ๊บเนี่ย library มันจะมีการสร้าง cache ขึ้นมาเป็น object ก็ object เปล่าๆ เลย ใส่ cache เข้าไป แล้วก็สุดท้ายมันจะเอา style พวกนั้นนะครับ ที่มันเก็บไว้ไปพ่นออกมานะครับ พ่นออกมาเป็น style tag อันนี้คือการทำงานคร่าวๆ อย่างโดยสรุปของตัว CSS-in-JS ส่วนใหญ่ก็จะเป็นประมาณนี้ ซึ่งข้อดีของมันก็คือหนึ่งคือเรื่องของ colocation จริงๆ มันจะมี มันจะมีเส้นด้วยนะแต่สงสัยมันมองไม่เห็น เรื่องของ colocation เนี่ย ก็คือเราทำทุกอย่าง ในไฟล์ JavaScript ไฟล์เดียว เพราะฉะนั้นมันจะ เรียกว่าเหมาะมาก ถ้าเราจะเอามาสร้างเป็น component ใช้ในโปรเจค แล้วก็จะมีเรื่องของ runtime JavaScript ที่ เนื่องจากว่ามันอยู่ใน JavaScript นะ เวลาเราจะเขียนพวก conditions ต่างๆ อะไรพวกนี้ มันก็ทำได้ง่ายถูกไหมครับ ทำได้สะดวกเลย ถ้าเป็นใน CSS เนี่ย เราจะเขียนสไตล์ที่เป็น condition ยังไง เราก็ต้องไปสลับ class name เอา อะไรพวกนี้มันก็จะมีความลำบากดูอ้อมๆ นิดหนึ่ง สิ่งที่สำคัญก็คือเรื่องของ scope นะครับ คืออย่างที่บอกว่า มันเหมาะกับการสร้าง component มากๆ เลย เพราะว่า component เนี่ ย คือเราต้องการให้มัน reusable ใช่ไหมครับ แต่ว่าถ้าเราสร้างด้วยอย่าง CSS อะไรอย่างเนี้ย class name มันอาจจะ conflict กับคนอื่นได้ ถูกไหม เพราะ class name ถ้ามันเหมือนกัน style มันก็จะ override ทับกัน ขึ้นอยู่กับ order ของ CSS ตรงนั้นนะครับ
การลดลงของความนิยมใน CSS-in-JS6:54
อันนี้คือข้อดีโดยคร่าวๆ นะ อันนี้จะเป็นกราฟของ ของ CSS-in-JS ก็คือตัว Emotion กับ styled-components นะ ก็คือเป็นยอดดาวน์โหลด ผมเอามาให้ดูว่าประมาณช่วงประมาณ 3-4 ปีที่ผ่านมา เราจะเห็นว่ายอดดาวน์โหลดมันก็พุ่งขึ้นเรื่อยๆ นะครับ มันก็แสดงให้เห็นว่ามีคนเริ่มจะเข้ามาใช้งานเยอะขึ้นๆ ก็ในช่วงประมาณ 4-5 ปีที่ผ่านมามันก็ค่อยๆ โตขึ้นนะครับ แน่นอนว่าสาเหตุน่าจะเป็นเพราะว่า 4-5 ปีที่แล้ว JavaScript มันก็เริ่มบูมขึ้นนะฮะ ทำทุกอย่างด้วย JavaScript นะ ก็เลยต้องมี CSS-in-JS ด้วย แล้วก็ไม่ว่าจะเป็นเรื่องของ design system ที่มันเป็นเทรนด์ที่เข้ามา ทุกบริษัทก็ต้องมี design system ของตัวเอง แล้วก็เรื่องของการสร้าง component ก็เป็นเทรนด์ที่แบบมาแรงมากๆ เพราะฉะนั้นคิดว่า ตัว CSS-in-JS ก็ได้รับความนิยมสูงขึ้นนะครับ แน่นอนพอมันมีคนใช้งานเยอะขึ้นสูงขึ้นเรื่อยๆ นะครับ มันก็จะเริ่มเห็น edge case มากขึ้น จนมาถึงประมาณกลางปีที่แล้วที่
มันเริ่มจะเป็นจุดเปลี่ยนนิดนึง ให้คนก็เริ่มตั้งคำถาม มากขึ้นนะว่า
ปัญหาความเข้ากันไม่ได้กับ React Server Components8:05
ควรจะใช้ต่อไหม หรือเราควรจะย้ายไปใช้อย่างอื่น ดี ถามว่าจุดไหน เป็นจุดที่ Next.js เขาออกตัว stable version ของ React Server Components มานะครับ ก็ทางทีม React เขาก็ออกมาบอกเหมือนเป็น note บอกว่า เอ้ย ถ้าเกิด เป็นโน้ตฝากถึง maintainer ของ CSS-in-JS library ว่า
React Server Component โดยสรุปคือ มันยังไม่ compatible กับ CSS-in-JS นะครับ เพราะฉะนั้นตอนนั้นทุกคนก็เลยเปิด issue เปิดทุกที่เลย เปิดว่า ช่วยทำให้มันเวิร์กหน่อย เปิดที่ Material UI เปิดที่ Emotion เปิดที่ Next.js เปิดมาหมดเป็น issue เดียวกัน ซึ่งสุดท้ายมันลิงก์มาอยู่ที่เดียวนะครับ ซึ่งตอนนี้ก็ยังแก้ไม่ได้นะครับ มันคงเป็นปัญหาเรื่องของ architecture ของตัว React Server Component ด้วยที่มัน ไม่ค่อยเหมาะสมกับตัว CSS-in-JS สักเท่าไหร่ ก็เรื่องนี้ก็ไม่ได้มีใครผิดนะ โอเค ทีนี้มันก็จะมีอ ันหนึ่งก็คือ ตัวของ State of CSS ที่มันเป็นเรียกว่า
ข้อมูลอีกอันหนึ่งนะ- อ่า อินเทอร์เน็ตไม่มี เยี่ยมเลย แล้วคีย์โน้ตหายไปไหน
ไม่เป็นไรนะครับ เดี๋ยวทุกคนลองไปเสิร์ช Google ดูกันนะ State of CSS 2023 ล่าสุดเลยนะครับ เราจะสังเกตมันจะมีแท็บหนึ่งที่เป็นแท็บ CSS-in-JS เลย เราจะเห็นว่า ในกราฟเนี่ย ค่าของ retention มันจะดร็อปลงทุกๆ ปีนะครับ หมายถึงว่าในทุกๆ ปีเนี่ย มีคนใช้ CSS-in-JS น้อยลงเรื่อยๆ แล้วทุกคนย้ายไปไหน คิดว่าตอนนี้ทุกคนก็น่าจะได้ยิน เรื่องของ Tailwind อะไรพวกนี้ใช่ไหม อะไรที่มันเป็นเหมือนกับ static CSS มากขึ้นนะครับ อย่าไปยุ่งกับฝั่ง JavaScript อะไรประมาณนี้นะครับ ซึ่งผมคิดว่าปีนี้ ปีนี้มันน่าจะคงที่ละ น่าจะไม่ค่อยมีคนใช้ CSS-in-JS เพิ่มขึ้นแล้ว แล้วมันก็จะค่อยๆ ดร็อปลงเรื่อยๆ นะครับ ถ้าเรายังหา solution ใหม่ๆ ไม่เจอนะครับ คนก็จะย้ายไป เรียกว่าเขียน pure CSS หรือว่าเขียน CSS Module อะไรพวกนี้น่าจะเหมาะสมกว่า
การค้นหาโซลูชันใหม่สำหรับ CSS-in-JS10:17
โอเค นี่แหละอย่างทีม MUI เนี่ย เราก็ได้รับรีพอร์ต issue เรื่องนี้มาพอสมควรนะครับ แล้วเราก็ เรียกว่าทราบดีมากๆ ถึงปัญหาที่เรามีอยู่ แต่อย่างที่บอก นะครับเราไม่สามารถที่จะแบบ นึกจะแก้อะไรก็ push commit อะไรอย่างนี้ไม่ได้นะครับ เราต้องมีการ research ก่อนนะครับ ซึ่ง เราก็ไม่อยากที่จะเหมือนกับเปลี่ยน
engine ทั้ง engine เลยนะครับ เพราะว่าถ้าเราเปลี่ยน การ migrate โค้ดของคนที่ใช ้โปรเจคเราอยู่ เรียกว่ามันจะต้องใช้เวลานาน ลองเล่นภาพดูว่า มีหนึ่งล้านโปรเจคที่ใช้ Material UI
แล้วเขาต้องการเวลาหนึ่งวันในการ migrate เพื่อไป engine ใหม่ แน่นอนว่ามันจะเร็วขึ้นแหละอะไรพวกนี้นะ แต่ 1 วันเลยนะ 1 ล้าน project ก็คือ หนึ่งล้านวัน ของเวลาที่ developer ต้องเสียไปกับการ migrate โค้ด อันนี้เป็นส่วนหนึ่งที่ทางทีมเราเรียนรู้ว่า การที่จะทำ open source ให้มัน สำเร็จนะครับ เรื่องนี้เป็นเรื่องที่สำคัญมาก ที่เราจะต้องคิดให้ดีว่าจะทำยังไง เพราะฉะนั้นเนี่ย เรามีเป้าหมาย ในการที่จะแก้ปัญหานี้อยู่ อย่างแรกคือโอเค มันต้องเร็วขึ้นแน่นอน ต้อง compatible กับตัว React Server Component แล้วก็มันจะต้องมี runtime JavaScript ที่น้อยที่สุด อย่างเมื่อกี้ที่เราเห็นแล้วว่า ตัว CSS-in-JS คือทุกอย่างเนี่ยมันเป็น JavaScript ที่มันต้อง run บน client นะครับ ตรงนั้นมันจะมี bottleneck อยู่นะ ถ้าเกิดว่าเราเขียน style เยอะๆ อะไรพวกนี้ ก็จะอาจทำให้เว็บช้าได้ ตอนนั้นสิ่งที่เราต้องการก็คือ เราต้องการให้ runtime มันน้อยที่สุด แล้วก็อย่างที่บอก สิ่งที่สำคัญมากๆ เลยก็คือ เรื่องของการ migrate โค้ด สำหรับฝั่งโปรแกรมเมอร์นะครับ เราจะพยายามหา API ที่มันใกล้เคียงกับสิ่งที่เขาใช้อยู่ แล้วก็ให้เขาได้ประโยชน์ของ static CSS ไปด้วยเลย โดยที่เขาแทบจะไม่ต้อง migrate อะไรก็ตาม
แนะนำ Zero Runtime CSS-in-JS12:20
ซึ่งจริงๆ แล้วเราก็ลอง research แล้วเราก็พบว่า มันมีคนที่ทำพวกนี้ให้อยู่แล้วนะครับ เรียกว่า กลุ่มนี้เป็น Next Generation ของ CSS-in-JS ทั้งหมดเลยนะครับ ก็คือเป็น library ที่จะ build- อย่างเขียน
CSS ในรูปแบบของ JavaScript ได้ แต่ว่ามันจะเป็นการ build static file CSS ออกมาทั้งหมดเลยนะครับ ยกตัวอย่างเช่น Vanilla Extract นะครับ อันนี้ก็มี ค่อนข้างมีชื่อเสียงเหมือนกัน แล้วก็ Compiled นี่เป็นของ Atlassian แล้วก็มี Panda CSS เคยได้ยินไหม Panda CSS ของทีม- มีใครเคยใช้ Chakra UI ไหมครับ Chakra UI อันนี้ก็คือทีมเดียวกันเลย ที่เขาพัฒนาตัวนี้ขึ้นมา อันนี้เป็น Atomic CSS นะครับ แล้วก็มี Linaria อันนี้ของทีมที่ชื่อว่า Callstack นะครับ Stylex ของ Meta นะครับ ซึ่งออกมาไม่นาน แล้วก็มี Griffel ของ Microsoft
Griffel อันนี้ก็พอดีทางทีมเราก็มีโอกาสได้คุยกับคน ที่เขาสร้าง Griffel เหมือนกัน ก็ได้ข้ อมูลมาค่อนข้างเยอะนะครับเกี่ยวกับการพัฒนา library อะไรพวกนี้ ทีนี้เราพบมาตัวหนึ่งว่าตัวนี้แหละเป็นตัวที่เราน่าจะใช้มา extend ต่อได้ แล้วก็ ทำให้ API มันใกล้เคียงกับของเดิมมากที่สุด ก็คือตัวที่ชื่อว่า Linaria มาจากทีม Callstack นะครับ เราเอาตัวนี้มา ณ ตอนนี้นะครับ เราเอาตัวนี้มา แล้วเราก็เอามา extend API build on top มันขึ้นไปเพิ่ม feature ต่างๆ ให้มันเหมาะสมกับโปรเจค Material UI นะครับ แล้วเราก็ตั้งชื่อมันว่า Zero Runtime นะครับ ซึ่งชื่อนี้ก็ยังเป็น- เรียกว่าอะไร ชื่อยังไม่ final นะ แต่ว่าในวันนี้เนี่ย เรียกว่าเราทำความรู้จักมันด้วยชื่อนี้กันก่อนนะครับ ตัว Zero Runtime ตัวนี้ เดี๋ยวเราจะมาดูนะครับว่า มันจะต่างจากเดิมยังไง
การ migrate จาก Emotion ไปสู่ Zero Runtime14:20
โดยเราจะใช้ Next.js project เป็นตัวอย่าง
อันนี้เดี๋ยวจะเป็น Next.js project ที่มีการใช้ Emotion สร้างเป็นปุ่มขึ้นมา และเดี๋ยวเราจะมาลอง migrate ดู ว่าเราจะ migrate นี้ไปเป็น Zero Runtime ได้ยังไง โอเค มีคนแย่งซีนแล้วหนึ่ง โอเคครับ อย่างแรกเลย เราจะต้องมาแก้ config file ก่อน Next.js เขาจะมีตัว config file ให้เราก็ชื่อว่า next.config.js นะครับ สิ่งที่เราจะต้องทำก็คือ เราจะต้องไป import plugin ที่ทางทีมเราเนี่ย ทางทีมผมเนี่ยจะ สร้างออกมาให้นะครับ ทีนี้เราก็ import แล้วก็เราก็ใช้ ตัวนี้ไปแปะตรงตัว config file แน่นอนตอนนี้เราไม่ต้องสนใจเลยว่ามันทำอะไร ขอแค่ว่านี่คือสิ่งที่เราจะต้องเพิ่มเข้าไปนะครับ เพิ่มตัว config file เข้าไป เรียกว่าให้ Zero Runtime มันรู้จักโปรเจคนะครับ ต่อมาเราจะกลับมาดูที่โค้ดที่เราเขียนตอนแรกนะครับ อันนี้คือโค้ดที่ เราสร้างตัวปุ่มขึ้นมานะครับ ด้วย Emotion style API ตรงนี้ก็ค่อนข้างจะ ตรงตัวนะครับ คือเราสร้างปุ่มจากตัว style API แล้วก็ใส่ ฟังก์ชัน คือฟังก์ชันมันจะให้ theme เรากลับมา ถ้าเรามีการสร้าง theme แล้วเราก็- ตัว background เราสามารถที่จะ รับค่าจาก property ได้ด้วย ก็คือเป็น dynamic style นะ ตัวปุ่มเนี้ย สีปุ่มก็จะเปลี่ยนตาม prop ที่ชื่อว่า bg นะครับ โอเค แล้วอันอื่นเนี่ยก็ตรงตัวนะครับ มันก็จะใช้ค่าจาก theme ซึ่งตอนนี้เราไม่จำเป็นต้องรู้ว่า theme คืออะไรบ้าง เอาเป็นว่าเดี๋ยว theme มันจะส่งค่าที่เป็นพิกเซล หรือเป็นค่าตัวเลขอะไรกลับมาให้เราเอง เสร็จแล้วเราก็ render ตัวปุ่มนี้นะครับ แล้วก็ใส่ bg เข้าไป อย่างตอนแรกสุดเลยเนี่ย bg เราเป็นสีแดงใช่ไหม เพราะฉะนั้นเราก็จะเห็นปุ่มเรา render ออกมาเป็นสีแดงก่อน แล้วพอเราคลิกนะครับ พอคลิกตัวปุ่ม ปุ๊บ ตัวฟังก์ชัน random เนี่ย มันคิดว่ามันจะ return สีใหม่ออกมาให้เรา พอเราคลิกปุ๊บ สีปุ่มก็จะเปลี่ยนไปเรื่อยๆ ตอนที่เราคลิกๆ อันนี้คือ คร่าวๆ ของสิ่งที่
มันเกิดขึ้นอยู่อย่างนี้นะครับ ทีนี้พอเราจะขยับไปใช้ Zero Runtime อย่างแรกคือเราแก้ config file แล้ว อย่างที่สองเนี่ย นี่คือสิ่งที่ทางทีมเราดีไซน์ไว้ คือเราดีไซน์ให้ทุกคน แค่แก้ import path แค่นั้นพอ ก็คือแก้ import จากการใช้ Emotion นะ ย้ายมาใช้แพ็กเกจที่ชื่อว่า Zero Runtime ทุกคน อาจจะสงสัย เอ๊ แล้วมันจะต่างยังไง มันก็ดูเหมือนเดิมเลยนะครับ เขียนเหมือนเดิมทุกอย่าง มันจะต่างจากเดิมตอนนี้ครับ ตอนนี้ทุกคนรัน yarn build อย่างตอนแรกที่เราแก้ config file ใช่ไหม ตอนนี้ Zero Runtime มันจะเข้าไปอยู่ใน build process ของ Next.js นะครับ
กระบวนการทำงานของ Zero Runtime ในช่วง build time17:20
ตัว Next.js เวลามัน build มันก็จะ process ไฟล์ต่างๆ ที่เรามีการเขียนนะ import ใช่ไหม แต่ละ route อะไรพวกนี้ครับ มันก็จะดึงไฟล์เข้ามา ตัว Zero Runtime เนี่ย จะเข้าไปอยู่ ไปแทรกอยู่ใน build process ตัว Zero Runtime อย่างแรกที่มันจะทำคือ มันจะ evaluate ไฟล์ว่ามีการ import Zero Runtime อยู่หรือเปล่า อย่าง case นี้ โอเค เจอแล้ว มีการ import มันจะไล่ดูต่อไปที่ style call นะครับ พอเจอป ุ๊บ อ๋อ ไฟล์นี้มีการใช้ Zero Runtime ในการสร้าง component ขึ้นมา มันจะทำการอ่านตัว style นะครับ แล้วก็ extract ออกมา
อยู่ในไฟล์ CSS ตรงนี้เกิดขึ้นที่ build time นะครับ ตอนที่เรารัน yarn build มันจะทำงานประมาณนี้นะครับ เสร็จ อย่างแรกมันจะสร้าง class ก็คือ generate class ขึ้นมา อันนี้ก็ยังอยู่ใน CSS-in-JS อยู่นะครับ generate class ขึ้นมา แล้วก็อะไรก็ตาม ค่าอะไรก็ตามที่เป็นฟังก์ชันนะครับ เราจะแทนค่าตรงนั้นด้วย CSS Variable อย่างที่ทุกคนเห็นอยู่ ซึ่งมัน hash ตัวแปรขึ้นมา ตรงนี้คือ CSS Variable นะครับ อยู่ใน CSS โอเค แต่ว่าเราจะ generate ค่าตัวแปรขึ้นมา แล้วก็แปะลงไปเพื่อให้มันสามารถที่จะ run บน CSS ได้ แล้วก็ whatever ที่เป็น theme การใช้งานอะไรพวกนี้ เราจะ resolve ออกมาเพื่อให้ มันเป็น valid CSS
โอเค สุดท้ายนะครับ เราจะมีการ modify ตัว JavaScript ไฟล์นี้ด้วย สิ่งที่ทุกคนเขียน เนื่องจากว่าเรามีการ generate ตัว CSS ขึ้นมาแล้ว เรามี class name อะไรโผล่ขึ้นมาแล้ว เราจะเอา class name พวกนั้นแปะกลับเข้าไป แล้วเราก็จะแก้ไฟล์นี้ให้ ซึ่งข้างหลังเนี่ย ฟังดูอาจจะง่ายนะ แต่ข้างหลังมันจะมี เรื่องแบบ AST อะไรที่เราต้องแปลง แล้วก็แปลงกลับ ก็จะมีความสนุกอยู่เหมือนกันนะครับ เราต้องการที่จะ reference ตัว class กับตัว variable พวกนี้ในไฟล์ CSS กับไฟล์ JavaScript เพราะฉะนั้นเราก็เลยต้องมีการแก้ code นิดหนึ่ง แปะกลับเข้าไป อันนี้คือ build time เสร็จแล้ว build เสร็จแล้ว เสร็จแล้วพอมันไปอยู่ใน runtime นะครับ พอตัวแอปเรา render บน หน้าเว็บไซต์ปุ๊บ อ่า ตัวข้างล่างนี้คือ HTML ที่เราจะเห็น เราจะสังเกตว่าเราก็จะเห็น class ใช่ไหม ที่มันมาจาก ข้างนู้นนะครับ และ class นี้ก็จะได้ style ที่มาจากไฟล์ CSS
มันก็จะไม่มี runtime JavaScript เลย ถ้าเราไม่นับ React นะครับ
การจัดการ dynamic styles ใน Zero Runtime20:10
โอเค ทีนี้มีอันหนึ่งที่อยากจะเน้นคือ ตัวที่เป็น inline style นะครับ ที่เป็น dynamic style ตัว style พวกนี้มันเกิดจาก ค่า state ใช่ไหมครับ ทีนี้ถ้า state เปลี่ยน background ก็จะเปลี่ยน แล้ว Zero Runtime มันทำงานได้ยังไง เวลาที่เราคลิกปุ๊บ เราจะได้ background ใหม่ขึ้นมาใช่ไหม แล้ว state ก็จะถูก set component ก็จะถูก re-render ใช่ไหม สมมุติว่าเรากดคลิกนะครับ เราได้ background เป็น yellow เข้าไป ตัว React ก็จะทำการอัปเดต inline style นึกตามดีๆ นะ อัปเดต inline style นะ ไม่ได้อัปเดต CSS อ่า นี่คือเทคนิคในการใช้งาน เพื่อให้ไฟล์ CSS ของเราเนี่ย ไม่มีการถูกแก้อีก เพราะฉะนั้นมันจะเร็วมาก ก็คือเหมือนเราเขียนไฟล์ CSS เลย แต่ว่าเราเขียนในรูปแบบของ JavaScript เราให้ ตัว bundler อะไรพวกนี้มันทำการ แปลงโค้ดออกมาให้นะครับ อันนี้ก็คือวิธีการทำงาน เพราะฉะนั้นถ้าเกิดว่าเราย้อนกลับไปประมาณสัก 3-4-5 ปีที่แล้ว เราจะไม่มีทางทำอะไรแบบนี้ได้ เพราะว่า ยุคนั้น CSS Variable ยังไม่ได้ fully support เบราว์เซอร์ทั้งหมด มันก็เลยเรียกว่าอาจจะยังเป็นแค่ช่วง research แต่ ณ ปัจจุบันเนี่ย เราสามารถทำแบบนี้ได้ เพราะว่า CSS variable มัน fully support ทุกเบราว์เซอร์แล้ว แล้วก็ค่อนข้างที่จะเป็น เปอร์เซ็นต์ที่เยอะมากด้วย น่าจะเกิน 96% เพราะฉะนั้นเนี่ย เราเลยพร้อมแล้วที่จะไปทาง build time รัวๆ นะครับ
ผลลัพธ์และประโยชน์ของ Zero Runtime21:54
โอเค result ที่เกิดขึ้นมี 2 อันนะที่เห็นได้ชัดเลย หนึ่งก็คือ เราไม่มี library CSS-in-JS แปะไปหา user แล้ว
ถูกไหมครับ เพราะว่าทุกอย่างเนี่ย มันเกิดขึ้นตอน build time ตอน build time เราได้ไฟล์ CSS ออกมา แล้วก็ตัว JavaScript เนี่ย แทบจะเรียกได้ว่า React ทั้งยวงเลย แทบจะไม่เกี่ยวอะไรกับตัว CSS-in-JS เลยนะครับ อ่า เพราะงั้นเนี่ย ถ้าเราใช้ Emotion อย่างน้อยลดได้อย่างต่ำ ก็คือ 20 กิโลไบต์แน่นอนที่ส ่งไปหา user ส่วน runtime ก็ไม่มี runtime เลยนะครับ runtime เรียกว่าก็คือ React อย่างเดียว เพราะว่า style ทั้งหมดมันไปอยู่ในไฟล์ CSS ใช่ไหม แล้วอะไรก็ตามที่ ถึงแม้ว่าจะเป็น dynamic style เนี่ย React จะทำหน้าที่อัปเดตตัว inline style แล้วค่าเนี่ยมันก็จะสลับกันตาม CSS Variable แทน
ซึ่งตรงนี้เบราว์เซอร์จัดการให้ทั้งหมดเลย ก็เป็นปกติตามการ parse style ของเบราว์เซอร์ ซึ่งเร็วมากๆ นะครับ
การทดสอบประสิทธิภาพของ Zero Runtime23:06
อันนี้เป็น เรียกว่า research ที่เราลองทำมาดูนะครับ ก็คือเราลอง test ตัว Total Blocking Time ดูว่าถ้าเกิดว่าเรา render 1,000 ปุ่ม Material UI 1,000 ปุ่มนะครับ เราได้ตัว TBT ทั้งหมดอยู่ที่ประมาณ 10 millisec ถ้าเราใช้ Emotion ที่เป็น style engine จริงๆ อะ แต่ว่าถ้าเกิดว่าเรา migrate ไปที่ Zero Runtime ปุ๊บเนี่ย มันก็คือจะกลายเป็นศูนย์เลย ซึ่งมันก็ค่อนข้างที่จะ make sense นะ อย่างตัว input เนี่ย 1,000 input อันนี้เริ่มมี style เยอะมากขึ้นแล้วก็มี logic มากขึ้นนะครับ ตัวนี้อยู่ที่ประมาณ 250 millisec ซึ่งก็ค่อนข้างเยอะนะครับ ถ้านับในเชิงของตัว Total Blocking Time แต่ว่าถ้าเป็น Zero Runtime ก็จะกลายเป็นศูนย์ performance ก็จะเขียวขจี 100% เต็ม
นะครับ โอเค ถึงตรงนี้เนี่ย ทุกคนน่าจะพอเห็นภาพแล้วว่า เอ๊ะ ตัว Next Generation ที่ ในปีนี้หรือปีหน้า เราน่าจะได้ลองกันมากขึ้นครับ
ก็จะเป็นยังไงนะครับ ทีนี้เราต้องมาดูว่า แล้ว timeline เราจะได้ใช้เมื่อไหร่
แผนการเปิดตัว Zero Runtime ใน Material UI v624:12
ตอนนี้ในทางทีมที่เราคุยกัน เราก็แพลนว่า ในช่วงประมาณ quarter 2 ของปีนี้นะครับ เราจะออก Material UI เวอร์ชันใหม่ ก็คือเป็นเวอร์ชัน 6 ซึ่งในเวอร์ชัน 6 เราจะ ship ตัว Zero Runtime เข้าไปใน library เลยนะครับ แปลว่า เวอร์ชัน 6 เนี่ย ถ้าเรา migrate ปุ๊บเนี่ย เราจะสามารถค่อยๆ extract style เป็น CSS เพียวๆ ได้ โดยที่เรา migrate ตามความเร็วของเรา ที่เราต้องการได้
โอเค อันนี้คือเรื่องราวทั้งหมดนะครับ ของ Next Generation CSS-in-JS
สรุปและเปิดโอกาสสำหรับคำถาม24:50
ถ้าเกิดว่าใครมีคำถามสงสัยตรงไหน หรืออยากถามเกี่ยวกับโปรเจคเกี่ยวกับบริษัท อะไรอย่างนี้ ก็เรามาคุยกันข้างนอกได้นะครับ ในช่ว ง network ใช่ไหม Please wrap it up, thank you, OK, thank you จบแล้วครับทุกคน ขอบคุณมากครับ