ลู่วิ่งของฟรอนต์เอนด์
(polotek.net)- ยิ่งผลิตภัณฑ์มีอายุการใช้งานยาวนาน เวลาและพลังงานที่ใช้ไปกับการถกเถียงเรื่องการเขียนใหม่จะกลายเป็นต้นทุนที่มากกว่า การเลือกเฟรมเวิร์กฟรอนต์เอนด์
- หากผลิตภัณฑ์ยังอยู่ได้ในอีก 5 ปีข้างหน้า ก็ถือว่าประสบความสำเร็จ แต่ในระหว่างนั้น เฟรมเวิร์กที่เลือกไว้อาจกลายเป็น ของล้าสมัย หรือเปลี่ยนไปอย่างมากในเวอร์ชันใหม่ที่ใช้ชื่อเดิม
- ทีมผลิตภัณฑ์ที่ดีกว่าจะไม่เปลี่ยนไปใช้เครื่องมือใหม่ แต่จะทำความเข้าใจเฟรมเวิร์กปัจจุบันอย่างลึกซึ้ง และเพิ่ม ความชำนาญ ให้มากพอที่เครื่องมือจะไม่ขัดขวางความคืบหน้าของงาน
- เพื่อลดต้นทุนระยะยาว การเลือกที่อยู่ใกล้ เว็บแพลตฟอร์ม และเทคโนโลยีเว็บแกนหลัก มากกว่าการใช้ abstraction ที่ซับซ้อน อาจเป็นการประนีประนอมทางธุรกิจที่สมเหตุสมผล
- ความซับซ้อนของระบบนิเวศฟรอนต์เอนด์ทำให้ทั้งนักพัฒนามือใหม่และทีมสรรหาบุคลากรลำบาก และนักพัฒนาที่ พื้นฐานเว็บ อ่อนจะเปราะบางมากขึ้นต่อการเปลี่ยนแปลงสแต็กครั้งต่อไป
การเขียนใหม่ทำให้หลุดจากลู่วิ่งได้ยาก
- ทีมฟรอนต์เอนด์จำนวนมากเชื่อว่าการเขียนใหม่จะนำไปสู่สภาพที่ดีกว่า แต่สำหรับผลิตภัณฑ์ที่จะอยู่ยาว การเลือกเฟรมเวิร์ก เองไม่ใช่การตัดสินใจทางเทคนิคที่สำคัญที่สุด
- หากผลิตภัณฑ์ดำเนินต่อไปได้นานกว่า 5 ปี ก็ถือได้ว่าประสบความสำเร็จ แต่ในช่วงเวลานั้น เฟรมเวิร์กที่เลือกไว้อาจล้าสมัยได้
- คอมมูนิตี้ฟรอนต์เอนด์ขับเคลื่อนโดยมีการเปลี่ยนแปลงเป็นศูนย์กลางมาโดยตลอด และมีโอกาสน้อยที่จะเปลี่ยนไปในอนาคตอันใกล้
- แม้แต่เฟรมเวิร์กยอดนิยมที่ยังอยู่รอด ภายในก็อาจเปลี่ยนไปทั้งหมด และอาจถูกเขียนใหม่โดยพฤตินัยภายใต้หมายเลขเวอร์ชันใหม่
- สิ่งที่ทีมควรมุ่งเน้นไม่ใช่การไล่ตามเครื่องมือใหม่ที่ดูแวววาว แต่คือการเรียนรู้เฟรมเวิร์กที่ใช้อยู่ตอนนี้ให้เพียงพอ
- จำเป็นต้องมีความเข้าใจและความชำนาญในระดับที่เครื่องมือไม่กลายเป็นอุปสรรคต่อความคืบหน้าของงาน
- ความคาดหวังว่าปัญหาจะได้รับการแก้ไขด้วยการเปลี่ยนไปใช้เครื่องมือทางเลือกนั้นใกล้เคียงกับ กับดัก
ยิ่งอยู่ใกล้เว็บแพลตฟอร์ม ต้นทุนระยะยาวยิ่งลดลง
- หากบริษัทต้องการลดต้นทุนจากการที่เทคโนโลยีฟรอนต์เอนด์ล้าสมัยบ่อยครั้ง ก็อาจพิจารณาทิศทางที่อยู่ใกล้ เว็บแพลตฟอร์ม มากขึ้น
- ต้องลด abstraction ที่ซับซ้อน และกลับมาเรียนรู้อีกครั้งว่าเว็บทำอะไรได้จริงบ้าง
- ไม่ได้หมายความว่านี่คือคำตอบของทุกปัญหา หรือดีกว่าเสมอไปโดยไม่มีเงื่อนไข
- ในระยะยาว นี่อาจเป็น การประนีประนอมทางธุรกิจ ที่ให้คุณค่าได้มากขึ้นและลดต้นทุนได้
- หากอยู่ใกล้เทคโนโลยีเว็บแกนหลัก ก็จะถูกโน้มน้าวน้อยลงจากคำกล่าวอ้างว่าเมื่อต้องจ้างวิศวกรที่มีความสามารถในอนาคต จะต้องเขียนโค้ดหลายล้านบรรทัดใหม่ก่อนจึงจะทำงานได้
- สำหรับวิศวกรรายบุคคล การทำความเข้าใจ เทคโนโลยีเว็บแกนหลัก อย่างลึกซึ้งจะช่วยเพิ่มมูลค่าในตลาดระยะยาวได้มากกว่าการคอยตามเฟรมเวิร์กใดเฟรมเวิร์กหนึ่งอยู่เรื่อย ๆ
- อาจต้องยอมสละความน่าสนใจในตลาดจ้างงานระยะสั้นบางส่วน
- เป็นผลดีต่อความยั่งยืนของอาชีพมากกว่าวิธีที่พยายามเรียนรู้เทคโนโลยียอดนิยมทั้งหมด
- การรู้เทคโนโลยีเฉพาะอย่างไม่ได้หมายความว่าจะได้รับการปกป้องจากความเป็นจริงอย่างภาวะตลาดแย่ลง
ความชอบเฟรมเวิร์กและต้นทุนของทีม
- วิศวกรที่มีความชอบเฟรมเวิร์กอย่างแรงกล้าควรสะท้อนเกณฑ์นั้นไว้ในเงื่อนไขการหางาน
- หากเข้าร่วมทีมที่ใช้เฟรมเวิร์กใดเฟรมเวิร์กหนึ่งอยู่แล้ว แล้วพยายามเปลี่ยนให้เป็นเฟรมเวิร์กที่ตนชอบ จะทำให้ทีมสั่นคลอนและเพิ่มต้นทุนอย่างมาก
- ความซับซ้อนของระบบนิเวศฟรอนต์เอนด์ในปัจจุบันเป็นภาระต่อทั้งนักพัฒนามือใหม่และบริษัท
- นักพัฒนามือใหม่รู้สึกว่ายากที่จะเรียนรู้ทักษะให้เพียงพอต่อการได้งาน และถูกเครื่องมือที่ซับซ้อนกดดันจนล้นมือ
- บริษัทเองก็รู้สึกว่าการจ้างนักพัฒนาทั่วไปยังยากขึ้น และเกณฑ์เข้าสู่งานนักพัฒนาประจำก็สูงขึ้นด้วย
- หากผู้ที่เรียนรู้ระบบนิเวศเทคโนโลยีปัจจุบันไม่ได้เรียนรู้ พื้นฐานเว็บ เมื่อสแต็กเปลี่ยนอีกครั้ง ก็อาจเสียเปรียบอย่างรุนแรง
- เว็บเป็นแพลตฟอร์มที่มีความสามารถและมีเอกลักษณ์ในการส่งมอบซอฟต์แวร์ ดีขึ้นตามกาลเวลา และคง ความเข้ากันได้ย้อนหลัง ในระดับสูงมาโดยตลอด
- เครื่องมือพื้นฐานในปัจจุบันดีพอมากแล้ว แต่ชั้นเฟรมเวิร์กกลับทำงานสวนทางกับแพลตฟอร์ม แทนที่จะยอมรับมัน
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เมื่อไม่นานมานี้ได้ทำงานเปลี่ยนระบบ build ของโค้ด frontend จาก yarn ไปเป็น pnpm ปกติเป็นวิศวกร backend แต่ก็เคยผ่านงานฝั่ง JS มาพอสมควร
สิ่งที่น่าหงุดหงิดที่สุดเวลาเข้าไปยุ่งกับ frontend คือมันดูเหมือนว่า ทุกอย่างถูก deprecated ไปหมดจริง ๆ ถ้าเคยใช้ apollo CLI ในปี 2022 มันก็ถูก deprecated ทันที แล้วต้องไปเรียนรู้เครื่องมือคนละแบบอย่าง graphql-client ที่มีการตั้งค่าและออปชันต่างกันสิ้นเชิง สุดท้ายก็ต้องคงของเก่าไว้ แล้วแค่ปิดการตรวจ Node engine ของ pnpm เพื่อไม่ให้มันบ่น พอพยายาม patch upgrade dependency บางตัว type signature ก็อาจพัง เลยต้อง pin ไว้อีก แล้วทิ้ง TODO ใน codebase หวังว่าสักวันจะมีใครมาแก้
พอทำให้มันรันได้อย่างยากเย็น ระหว่างติดตั้งก็มีคำเตือน deprecated หลายร้อยรายการไหลผ่าน และทันทีที่ build เสร็จก็อยากหนีออกมา
รู้สึกแปลกมากที่การพัฒนา frontend โดยรวมยอมรับ breaking changes และ deprecated กันถึงระดับนี้ ผมทำโปรเจกต์ Rust ขนาดใหญ่มาเกือบ 4 ปี ในช่วงนั้นมี breaking change เล็ก ๆ จากไลบรารี third-party อยู่บ้างไม่กี่ครั้ง แต่ major change ที่ทำให้ต้องแก้แอปพลิเคชันครั้งใหญ่มีแค่ครั้งเดียว ในทางกลับกัน JS ดูเหมือนยังไม่ทันครบ 6 เดือนก็ต้องเขียนอะไรใหม่อีกแล้ว
โลก frontend เปิดรับโซเชียลมีเดีย, YouTube และแม้แต่ Twitch อย่างจริงจังกว่าสาขาอื่นมาก influencer เหล่านี้ต้องมีวัตถุดิบใหม่อยู่เรื่อย ๆ เพื่อรักษา relevance จึงผลักดันสิ่งใหม่ ๆ ที่เอาไปทำเป็นคอนเทนต์ได้อย่างต่อเนื่อง
ยังมีวัฒนธรรม conference ที่คึกคักเข้ามาเสริมด้วย conference ด้าน frontend และ JS ให้ความรู้สึกเหมือนเป็นการแข่งขันครั้งใหญ่เพื่อประกาศหัวข้อใหม่ที่กำลังมาแรง
ตลาดขายคอร์ส frontend ก็ใหญ่เช่นกัน ผู้ทำคอร์สต้องทำให้หัวหน้าอนุมัติ คอร์สวิดีโอราคาพิเศษแบบจำกัดเวลา $700 สำหรับเรียนกระแสใหม่ให้ได้ ซึ่งจะทำอย่างนั้นได้ก็ต้องทำให้อุตสาหกรรมถอยห่างจากของเก่าที่ทุกคนรู้อยู่แล้ว ดังนั้นจึงผลักของใหม่อย่างหนัก และทำให้ของเก่ากลายเป็น deprecated
เว็บแอป pure JS ขนาดเล็กประมาณ 5KLOC ที่เขียนไว้เมื่อ 15 ปีก่อน ยังมีคนราว 10 คนใช้อยู่ทุกวันโดยไม่ต้องแก้แม้แต่บรรทัดเดียวด้วยซ้ำ ทนทานกว่ายิ่งกว่าแอปพลิเคชัน Win32
ผมมองว่า churn ส่วนใหญ่ของ frontend แทบจะเป็นความล้มเหลวเชิงการเมืองและองค์กรล้วน ๆ
ตอนเริ่มในยุค pure JS/jQuery การจัดการ dependency แทบจะเป็นการคัดลอกไฟล์
.jsไปใส่ในไดเรกทอรีvendor/ต่อมา nodejs/npm ก็ออกมา และฝั่ง frontend ก็เคยใช้ bower ก่อน npm แล้วจู่ ๆ คำแนะนำมาตรฐานก็กลายเป็นว่าอย่าสร้างเอง ให้ดาวน์โหลด module มาใช้แต่แม้ในตอนนั้นก็มีหลายคนที่สงสัยว่า มันถูกต้องหรือไม่ที่จะไม่ถือครองโค้ดที่ซ่อนอยู่นับพันบรรทัดเอง แล้วฝากมันไว้กับอาสาสมัครที่ทำโอเพนซอร์สเป็นงานอดิเรก
แม้ตอนนี้ ถ้าอยากดูแลโปรเจกต์ให้ยืนยาว ก็สามารถไม่ทำให้ส่วนที่มองไม่เห็นบวมเกินไปได้ ปัญหาเล็ก ๆ จัดการได้ด้วยแนวทางแบบ “เราต้องการแค่ฟังก์ชันเดียวจากไลบรารีนี้ อย่าพึ่งพาทั้งไลบรารีเลย คัดลอกเฉพาะฟังก์ชันนั้นเข้ามาใน codebase แล้วใส่ test ให้มัน”
ดังนั้นผมมองว่านี่ไม่ใช่ปัญหาของ JavaScript เอง แต่เป็น ปัญหาของคนและกระบวนการ มีนักพัฒนา JS จำนวนมากที่ไม่เจอปัญหาแบบนี้ แต่ส่วนใหญ่ของ ecosystem ยังเป็นแบบนั้น
ทุกวันมีคนใช้เวลาหลายพันชั่วโมง-คนไปกับการแก้ผลลัพธ์ของ breaking change ที่ ‘สำคัญมาก’™ อย่าง “ถ้าเปลี่ยน MultiselectDropdown เป็น MultiSelectButtonDropdown ล่ะ? เปลี่ยน API ให้ใหม่หมดด้วยเลย!”
แทบไม่มีวัฒนธรรมที่เข้าใจต้นทุนมหาศาลของ API ที่พัง backward compatibility หลังจากทำ Go มา 10 ปี เลยยิ่งหงุดหงิดเป็นพิเศษ Go มีคำมั่นเรื่อง backward compatibility และดูเหมือนว่าสิ่งนี้ส่งผลต่อทัศนคติของนักพัฒนาไลบรารี Go ต่อ compatibility และ breaking changes ด้วย ประสบการณ์ที่โค้ดที่เขียนไว้เมื่อ 10 ปีก่อนยัง compile และทำงานได้ตามเดิมบน Go เวอร์ชันล่าสุดนั้นดีมากจริง ๆ
ผมเคยย้ายไป Flutter เพื่อหนีจากนรก JS/web นี้ด้วย ซึ่งค่อนข้างเข้าทาง และทำให้ลืม accidental complexity ของ web stack ไปได้มาก แต่ก็น่าหงุดหงิดมากที่วัฒนธรรม “ทำแพ็กเกจพังก็ไม่เป็นไร” เริ่มซึมเข้าไปใน ecosystem ของ Dart แล้วเหมือนกัน
พูดตรง ๆ ผมว่ามันหนักกว่า frontend มาก Frontend อย่างน้อยก็ยังมี TypeScript และคุณสมบัติของภาษาที่ช่วยจำกัดขอบเขตความเสียหายให้อยู่ในระดับที่ค่อนข้าง sane ใน Python คุณทำได้ ทุกอย่างตามตัวอักษรจริง ๆ และเพราะแบบนั้น ผู้เขียนไลบรารีก็ทำทุกอย่างได้ตามตัวอักษรเหมือนกัน ถ้าอยากเปลี่ยนวิธี import module ก็เปลี่ยนได้ ถ้าอยากใช้ metaclass ทำลายสมมติฐานทุกอย่างเกี่ยวกับพฤติกรรมของ class ก็ทำได้ ต่อให้คิดว่า static type จะช่วยได้ เรื่องเล็ก ๆ อย่าง
Partialก็ยังทำไม่ได้ และการ assert แบบ static ว่าวัตถุสองตัวเป็น type เดียวกันก็ทำไม่ได้เวลาเห็นคนบ่นว่าไลบรารีเปลี่ยนแล้วก็อดขำไม่ได้ การเปลี่ยนจาก Python 2 ไป 3 เลวร้ายมาก ถึงขนาดที่ที่ทำงานเก่าของผมมี Python monolith ขนาด 100 ล้านบรรทัด ที่ไม่มีแผนจะ upgrade เป็น Python 3 เลย การย้ายจาก SqlAlchemy 1 ไป 2 เป็น migration 8 ขั้นและแทบจะเป็นการเขียนใหม่ทั้งหมด ถ้าอะไรพังแม้แต่อย่างเดียว เว็บไซต์ก็ล่ม แต่กลับบ่นกันว่า React เพิ่ม hooks แบบเลือกใช้ได้
ที่แปลกคือบนอินเทอร์เน็ตมีบทความ “frontend treadmill” เต็มไปหมด แต่กลับแทบไม่เห็นบทความบ่นเรื่องฝั่งตรงข้ามเลย
เกี่ยวกับคำกล่าวที่ว่า “ถ้าเป็นวิศวกร ยิ่งเข้าใจเทคโนโลยีเว็บหลักอย่างลึกซึ้ง ก็จะยิ่งรักษามูลค่าในตลาดไว้ได้สูงกว่ามากเมื่อเวลาผ่านไป” ผมทำฟรอนต์เอนด์มาเกือบ 20 ปี และผ่านการเปลี่ยนแปลงพาราไดม์ครั้งใหญ่มาหลายครั้ง เลยคิดว่าพอมีสิทธิ์ออกความเห็นได้
ถ้ารู้เทคโนโลยีเว็บหลักทั้งหมด ก็เป็นความจริงแน่นอนว่าจะเป็นวิศวกรที่สมดุลมากขึ้น แต่ผมยังสงสัยว่ามันทำให้ดูน่าสนใจขึ้นในตลาดงานจริงหรือไม่ ไม่ใช่เพราะความรู้นี้ไม่สำคัญ แต่เพราะคนที่มีอำนาจตัดสินใจจ้างงานโดยทั่วไปมักทำ pattern matching
ถ้าอยากเพิ่ม “มูลค่าในตลาด” ให้สูงสุด ก็ยังต้อง เก่ง React มากๆ อยู่ดี นี่ใกล้เคียงกับบัตรผ่านประตูขั้นพื้นฐาน ส่วนอย่างอื่นยอดเยี่ยมก็จริง แต่ถ้าไม่มีฐานนี้ ตัวเลือกจะลดลง บางทีผู้เขียนอาจหมายถึงแบบนั้นอยู่แล้ว แต่ผมอ่านผิดไปก็ได้
อย่างไรก็ตาม ในบทบาทอย่างงานคอนซัลต์หรืองานสัญญาจ้าง ผมเห็นด้วยกับคอมเมนต์ต้นทาง ถ้าเคยทำงานร่วมกับคนในบริษัทคอนซัลต์ใหญ่ๆ ที่เป็นผู้ตัดสินใจว่าจะจ้างหรือจะเรียกสัมภาษณ์ใคร จะเห็นว่าคนที่ยังไม่รู้สแต็กที่พวกเขาชอบหรือสแต็กที่ลูกค้าปัจจุบันใช้อยู่แทบจะถูกคัดออกโดยอัตโนมัติ แม้แต่ technical architect ก็เป็นแบบนี้ จึงไม่ใช่ปัญหาเฉพาะ recruiter ที่ไม่ใช่สายเทคนิคเท่านั้น พวกเขาไม่ต้องการเวลาปรับตัวกับตัวเทคโนโลยี ไม่ว่าความชำนาญจะเป็นอย่างไร
ในบทบาทแบบนี้ การตามให้ทันของใหม่อยู่เสมอสำคัญมาก ไม่อย่างนั้น hiring manager จะโยนเรซูเม่ทิ้งเพราะไม่มี buzzword ตั้งแต่ก่อนที่วิศวกรจะได้ประเมินฝีมือด้วยซ้ำ
อาจเป็นกรณีพิเศษก็ได้ แต่การไม่รู้ React ไม่เคยเป็นปัญหาเลย คำว่า “บัตรผ่านประตูขั้นพื้นฐาน” แรงเกินไป
ฟรอนต์เอนด์มีเพดานค่าตอบแทนที่ค่อนข้างแข็ง พอขึ้นไปเกินระดับหนึ่ง ก็ไม่จำเป็นต้องสร้าง UI อีกต่อไป
บริษัทส่วนใหญ่ แม้แต่บริษัทใหญ่ๆ ก็ไม่ได้สนใจ ตรวจสอบ หรือจ้างคนตามพื้นฐานแกนหลักมากนัก แต่จ้างตามเกณฑ์อย่าง “เก่ง React” หรือ “มีประสบการณ์ Next.js เยอะ”
พื้นฐานดีมากเมื่อจะสร้างอะไรตั้งแต่ศูนย์ แต่บริษัทจริงๆ แทบไม่ทำแบบนั้น ส่วนใหญ่จะเอาของสำเร็จรูปที่มี ecosystem ใหญ่และเอกสารดีมาใช้ ถ้าทำของพวกนั้นได้ดี ก็หางานได้ง่ายกว่ามาก และพื้นฐานก็เรียนระหว่างทางได้
คำพูดที่ว่า “ไม่ว่าจะเลือกเฟรมเวิร์กไหน อีก 5 ปีมันก็จะ obsolete” ดูเป็นตรรกะที่ค่อนข้างเก่าไปหน่อย
ผมไม่ได้เป็นนักพัฒนาฟรอนต์เอนด์เป็นหลัก แต่เวลาต้องทำฟรอนต์เอนด์ก็ไม่ได้หลีกเลี่ยง และใช้ React มาประมาณ 10 ปีแล้ว กระแสส่วนหนึ่งกำลังย้ายไปทาง Svelte แต่กว่าจะถึงเวลาที่ Svelte แซง React ได้ Svelte ก็คงถูกใช้ในโปรดักชันมานานพอๆ กันแล้ว Angular ก็อาจหมดแรงลงในสักวัน แต่ถ้านับยุค Angular1 กับ Angular2+ รวมกัน มันก็เก่ากว่า React ด้วยซ้ำ
การพัฒนาฟรอนต์เอนด์เคลื่อนไหวเร็วก็จริง แต่ไม่ได้แย่ถึงขนาดนั้น ถ้าเลือกทางที่น่าเบื่อ ผลลัพธ์ก็จะน่าเบื่อ
Angular1 กับ 2 ต่างกันจนแทบเทียบกันไม่ได้ ยกเว้นชื่อ และนักพัฒนาจำนวนมากก็โดนตรงนี้เล่นงาน Angular เองก็กำลังเปลี่ยนไปค่อนข้างมาก แม้จะไม่หนักเท่าตอนย้ายจาก v1 ไป Angular2 แต่ก็ยังมากพอให้ต้องปรับตัวใหม่ไม่น้อย ทุกอย่างกำลังย้ายไปเป็น standalone component, syntax เทมเพลตใหม่, signals ฯลฯ
React ก็คล้ายกัน การมาถึงของ functional component และ hooks ทำให้เกิด การเปลี่ยนพาราไดม์ครั้งใหญ่ แม้จะเข้ากันได้ย้อนหลัง แต่ทั้งสองแบบแตกต่างกันมาก
ในพาราไดม์ที่กว้างกว่านั้นก็เช่นกัน ตอนแรกทุกอย่างเป็น server-side rendering จากนั้นก็วิ่งเต็มแรงไปสู่ single-page app แล้วกลับมาที่ server-side rendering อีกครั้ง แต่คราวนี้เป็น server-side rendering แบบบางส่วนที่มี hydration
ต่างกันจนเรียกว่าเป็นเฟรมเวิร์กคนละตัวก็ได้ ดังนั้นแม้จะมี nuance แต่ตรรกะนั้นก็ยังไม่ได้ตายสนิท
ทำงานด้วยง่ายมาก ผมสร้างแอปจัดสรรพอร์ตหุ้นแบบง่ายๆ สิ่งที่ตกใจที่สุดคือขนาด bundle อยู่ที่ 9KB เมื่อ gzip แล้ว และเล็กกว่าเฟรมเวิร์กไหนๆ ที่ผมรู้จัก เล็กกว่า htmx ที่ค่อนข้าง “ต่อต้าน JS” ในระดับหนึ่งด้วยซ้ำ
เฟรมเวิร์กเก่าๆ ก็ยังรันต่อไปได้นานมาก ถ้ายังมีคนที่รู้สแต็กนั้นอยู่ และเมื่อจำเป็นก็จ้างมาทำงานได้ สแต็กนั้นก็ยังไม่ obsolete อาจเรียกว่า “เก่า” หรือ “legacy” ได้ แต่จนกว่าจะถึงวันที่ไม่มีใครเหลือที่จะดูแลมันได้ มันก็ยังไม่ obsolete
ที่เรียกสิ่งนี้ว่าปัญหาฟรอนต์เอนด์เป็นเรื่องน่าสนใจ มันไม่ใช่ปัญหาฟรอนต์เอนด์ แต่เป็น ปัญหาที่ผู้เข้าร่วมรายใหม่ยังคงเข้ามาในระบบนิเวศขนาดใหญ่อย่างต่อเนื่อง
ตอน Java อยู่แนวหน้าของนวัตกรรมเมื่อ 15 ปีก่อน ก็เห็นแบบเดียวกัน ภายในไม่กี่ปีก็มีเฟรมเวิร์กหลายสิบตัวและระบบบิลด์หลายแบบออกมา การเปลี่ยนจาก React 17 เป็น 18 เป็นการเปลี่ยนแปลงที่เล็กกว่าการไปจาก Perl 5 เป็น 6 หรือ Python 2 เป็น 3 มาก
ในแบ็กเอนด์ แทนที่จะพูดว่า “มาใช้เฟรมเวิร์กใหม่กัน” มักจะกลายเป็น “มาใช้ภาษาใหม่กัน” กระแสล่าสุดคือการเขียนอะไรสักอย่างใหม่ด้วย Rust และก่อนหน้านั้นก็มี Go, Haskell, Scala, F#
ถ้าคิดว่าการย้ายโค้ดฟรอนต์เอนด์จาก React ไปเป็นอย่าง Svelte นั้นน่ารำคาญ ลองเขียนแอป VB 6 ใหม่ดูสิ ยังไม่ต้องพูดถึงอะไรอย่าง RPC ที่มีข้อมูลฝังอยู่ในโค้ด
ไม่ได้หมายความว่าความไม่เสถียรของแนวปฏิบัติทางวิศวกรรมไม่ใช่ปัญหา มันเป็นปัญหาใหญ่ เพียงแต่ไม่ใช่ปัญหาเฉพาะของฟรอนต์เอนด์เท่านั้น
webpack ก็มีอายุ 13 ปีแล้ว แต่แม้ในช่วงไม่กี่ปีที่ผ่านมา วิธีตั้งค่าก็เปลี่ยนไปอย่างมาก
ถ้าการตั้งค่า Apache เปลี่ยนบ่อยเท่าระบบเหล่านี้ ก็คงไม่มีใครใช้ Apache
ที่ทำงานก่อนหน้า ในช่วง 2 ปีมีการย้ายฐานข้อมูล 2 ครั้ง ใช้เวลาวิศวกรรมรวม 1 ปี ไม่ใช่แค่ตารางที่ไม่สำคัญบางส่วน แต่เป็นทุกตาราง พอมีอะไรพัง หรือผู้บริหารถามว่าทำไมช้าขนาดนี้ ก็โทษวิศวกรที่กำลังเรียนฟรอนต์เอนด์ว่าเพราะขาดประสบการณ์
ผมทำงานเป็นนักพัฒนา Java มานานกว่า 25 ปี และช่วง 10 กว่าปีแรกทำฟูลสแตก ซึ่งเป็นรูปแบบทั่วไปของบริษัทในตอนนั้น ตอนนี้โดยทั่วไปจะมีทีมฟรอนต์เอนด์แยกต่างหาก และหลายที่ก็มีถึงสามทีมคือเว็บ, iOS, Android สำหรับผม การเปลี่ยนแปลงนั้นเกิดขึ้นราว ๆ ช่วงที่ย้ายจาก AngularJS ไป Angular
Java ก็เปลี่ยนเร็วในช่วงราว 10 ปีแรก โดยเฉพาะ 3 ปีแรกที่เร็วมาก แต่ช่วงนั้นจบไปแล้ว Java 5 เป็นการเปลี่ยนแปลงครั้งใหญ่ และ Java 8 ก็มีฟีเจอร์สำคัญ แต่ Java 8 คือปี 2014 ทีมของเราเพิ่งย้ายไป Java 11 เมื่อไม่นานมานี้ และตอนนี้ Java 24 ออกมาแล้ว ผมยังไม่เคยใช้ฟีเจอร์ของ Java 11 เลย และไม่รู้ด้วยว่ามีอะไรบ้าง ตลอด 10 ปีไม่ได้เรียนฟีเจอร์ภาษาใหม่เลยสักอย่าง
เครื่องมือบิลด์เหมือนเดิมตลอด 15 ปีที่ผ่านมา IDE ก็เหมือนเดิมตลอด 20 ปีที่ผ่านมา เฟรมเวิร์กหลักที่ใช้ก็เหมือนเดิมมา 10 ปี ตอนย้ายมางานล่าสุด โครงสร้าง codebase เหมือนกับทีมก่อนหน้าทุกประการ
การสร้างเว็บเซอร์วิสด้วย Java เป็น ปัญหาที่แก้จบแล้ว น่าเบื่ออย่างสมบูรณ์ในความหมายที่ดี และเหมือน COBOL
ฟรอนต์เอนด์เปลี่ยนเร็วในช่วงปลายยุค 90 และต้นยุค 2000 แต่หลังจากนั้นก็ยังเปลี่ยนเร็วต่อเนื่อง โปรเจกต์ UI ส่วนตัวที่ทำไว้เมื่อไม่กี่ปีก่อนล้าสมัยไปหมดแล้ว
ถ้าเป็นโปรเจกต์ Java ที่ผมเคยทำในยุคหลัง EJB ทุกวันนี้หานักพัฒนา Java มาลงงานก็น่าจะทำงานได้อย่างมีผลิตภาพทันที ต่อให้นักพัฒนาคนนั้นเกิดหลังโปรเจกต์ถูกสร้างขึ้นมาก็ตาม แค่มีไลบรารีเก่า ๆ ไม่กี่ตัวที่ต้องเรียนรู้
วิธีลงจากลู่วิ่งคือไม่ใช้เฟรมเวิร์กฟรอนต์เอนด์เลย ไม่ใช่เลือกเฟรมเวิร์กอื่นแบบสุ่มแล้วค่อยมาเขียนใหม่ภายหลัง
ต้องใช้ server-side rendering, ใช้ JavaScript เฉพาะเวลาที่จำเป็น และไม่แยกบุคลากรแบ็กเอนด์กับฟรอนต์เอนด์ภายในบริษัท
ถ้าวิศวกรคนหนึ่งสามารถเขียน SQL ให้ดึงเฉพาะคอลัมน์ที่จำเป็นต่อเว็บวิว SSR ได้พอดี และรับผิดชอบเว็บวิวนั้นได้ด้วย ก็ไม่ต้องเสียเวลาคิดเรื่อง API หรือ ORM แม้แต่วินาทีเดียว แค่รู้ SQL กับ HTML/CSS/JS แบบล้วนที่ทันสมัยก็พอ งานส่วนใหญ่ที่ทำจะกลายเป็นการแปลงวิวของธุรกิจ (SQL) ให้เป็น DOM (HTML) ขณะที่ระบบนิเวศการเขียนโปรแกรมฝั่งเซิร์ฟเวอร์ถอยไปอยู่เบื้องหลัง
ผมมองว่ารูปแบบสุดท้ายคือการ SSR คอนเทนต์เว็บจากภายใน RDBMS แบบเดียวกับ Oracle APEX แต่เอ็นจิเนียร์ส่วนใหญ่ยังไม่พร้อมจะคุยเรื่องนั้น ผมเองก็ตอนเห็นครั้งแรกในงานจริงก็เป็นแบบนั้น เราผูกพันกับวิธีที่ทำให้ตัวเองเจ็บปวดมากเกินไป
มันทำให้ปัญหาฟรอนต์เอนด์ซับซ้อนเกินจำเป็นหนักขึ้น เพราะมีคนอยู่ในทีมฟรอนต์เอนด์ พวกเขาจึงสร้างงานและเพิ่มความซับซ้อนต่อไป อีกปัญหาคือมีคนที่รู้แต่การพัฒนาเว็บและไม่รู้อย่างอื่นมากเกินไป
ในไซด์โปรเจกต์ ผมตั้งข้อจำกัดตั้งแต่แรกข้อหนึ่งว่า แม้จะปิด JavaScript ทั้งไซต์ก็ต้องลดความสามารถลงอย่างสง่างามและยังใช้งานได้ พอเป็นแบบนั้น ทุกครั้งที่พยายามเพิ่มฟีเจอร์ที่ปกติจะทำด้วย JavaScript ก็จะถามว่า “ทำสิ่งนี้โดยไม่ใช้ JavaScript ได้ไหม?” และจนถึงตอนนี้ คำตอบกลับเป็น yes อย่างน่าประหลาดใจเสมอ
แค่ CSS selectors สำหรับคอนโทรล HTML พื้นฐาน ก็ทำอะไรได้มากจริง ๆ ในปัจจุบัน codebase นั้นยังไม่มี JS แม้แต่บรรทัดเดียว
ทีมผลิตภัณฑ์/ดีไซน์อาจผลักดันให้ใส่ลูกเล่น JavaScript ให้มากที่สุดเท่าที่ทำได้ โดยไม่คำนึงถึง usability, performance, accessibility หรือวิศวกรรมที่ดีเลย
ผมไม่ถนัดฟรอนต์เอนด์ และก็ไม่มีดีไซเนอร์ แบ็กเอนด์ผมทำได้ดีกว่ามาก แต่คนอื่น ๆ ในทีมมีพรสวรรค์ด้านการออกแบบฟรอนต์เอนด์มากกว่าผม
ตอนสร้างเว็บไซต์แรก ผมอ่านบทความทำนองว่า “Svelte ดีกว่า React”, “solid-js จะเป็นกระแสใหญ่ถัดไป” แล้วคิดว่านั่นคือส่วนสำคัญของการพัฒนาเว็บ
มือใหม่ควรอ่าน MDN แล้วไม่ต้องสนใจอย่างอื่น
ผู้คนต้องการบทเรียนและ walkthrough และต้องค่อย ๆ สร้างความเข้าใจภายในว่าสิ่งทั้งหมดนี้ทำงานอย่างไร
framework ช่วย abstract ส่วนเหล่านั้นได้
แต่กระแสล่าสุดอย่าง Next.js และความหมกมุ่นกับ SSR อาจไม่ใช่แบบนั้น ส่วนตัวคิดว่าสิ่งนี้อาจกลายเป็นปัจจัยที่ทำให้ฝั่ง React เสื่อมถอยได้
ถ้าคิดถึงพัฒนาการของ JS ล้วนและ CSS ในช่วงไม่กี่ปีที่ผ่านมา รวมถึงฟีเจอร์ที่น่าสนใจอย่างแอนิเมชันของ
display: noneที่ใกล้จะถูกนำมาใช้จริงแล้ว แนวทางสร้าง HTML template บนเซิร์ฟเวอร์แล้วใช้ JS เฉพาะจุดที่จำเป็นก็ดูสมเหตุสมผลกว่าที่เคยพูดในฐานะคนที่ทำมาหากินหลัก ๆ กับ React
เหมือนผู้เขียน ผมก็ทำ frontend มา 20 ปีในรูปแบบต่าง ๆ ระบบนิเวศ, churn, และกายกรรมในการซิงก์สถานะระหว่าง frontend กับ backend นี่บ้าคลั่งจริง ๆ
ช่วงหลังผมเริ่มโปรเจกต์ proof of concept ด้วย Go templates และ HTMX และพยายามเลียนแบบความรู้สึกในการสร้าง UI เป็น “component” แบบ React ยังมีส่วนที่หยาบอยู่มาก แต่ก็มีศักยภาพ พูดตรง ๆ ยังไม่แน่ใจด้วยซ้ำว่าจำเป็นต้องใช้ HTMX ไหม ผมเริ่มจัดการ event listener เองแล้ว และดูเหมือนจะชอบทางนั้นมากกว่า
ที่น่าสนใจคือ การจัดการสถานะ UI ที่ซับซ้อนตามบทบาทและสิทธิ์ของผู้ใช้นั้นทำบนเซิร์ฟเวอร์ง่ายกว่ามาก แค่ส่ง HTML เท่าที่ผู้ใช้มองเห็นได้ก็พอ
อย่างไรก็ตาม React, Vue ฯลฯ มี แรงขับเคลื่อนมหาศาล ผมไม่รู้ว่าการเปลี่ยนกรอบคิดร่วมกันจะเริ่มขึ้นได้อย่างไร โดยเฉพาะเมื่อพิจารณาว่ามีนักพัฒนาจำนวนมากที่รู้จักเพียง frontend framework ในฐานะวิธีสร้าง UI เท่านั้น
ผมไม่ค่อยแน่ใจกับคำพูดที่ว่า “ไม่ว่าจะเลือก framework ไหน อีก 5 ปีก็ obsolete”
ผมใช้ React อย่างมืออาชีพมากว่า 10 ปีแล้ว
package.jsonประกาศ dependency ไว้กี่ตัว? ทีมใช้ node/npm เวอร์ชันไหน?ถ้าใช้เวอร์ชันที่ค่อนข้างใหม่และใช้ไลบรารียอดนิยม ก็น่าจะเคยเห็นแจ้งเตือน deprecated ของ dependency ชั้นล่าง ๆ กองขึ้นมาระหว่าง
npm installถ้าพูดอย่างเป็นธรรม ผมคิดว่าโค้ด React เองรักษา backward compatibility ได้ค่อนข้างดี ไม่ใช่ความผิดของ React แต่ build system ที่ใช้เมื่อ 5 ปีก่อนล้วนเปลี่ยนไปหมดและทำให้ backward compatibility พัง ผมยังลืมเรื่อง component lifecycle methods ไปด้วย
แม้แต่โปรเจกต์ที่ดูแลดีอย่าง React ก็หนีความเละเทะของ ecosystem มันไม่พ้น
แม้จะไม่ได้มีทางเลือกเสมอไป แต่ทุกวันนี้ผมมักเลือก import JS ล้วน โดยไม่มี build system ทำเท่าที่เป็นไปได้ใน backend Python/Django และออกจาก ecosystem ของ JavaScript ให้หมด ไม่เคยเสียใจเลย
ยังปล่อยให้แอปอยู่บน React 15 อยู่หรือเปล่า?
WYSIWYG editor ทั้งหมดที่ทำงานบน React 16 ไม่ได้รับการสนับสนุนอีกแล้ว ถ้าพบปัญหาความปลอดภัยก็อยู่ในสถานการณ์ที่ต้อง “ฝากไว้กับโชค” หรือไม่ก็ไม่ควรใช้
React 16 ยังได้รับการสนับสนุนอยู่ แต่แน่นอนว่า obsolete แล้ว
ข้อโต้แย้งคือ ถ้าไม่ adopt framework สุดท้ายก็จะสร้าง framework ภายในเอง ที่คนนอกทีมไม่เข้าใจ เอกสารก็มักแย่ และต้องทำงานต่อเนื่องเพื่อเพิ่มฟีเจอร์ที่ framework ที่มีอยู่แล้วก็มี
frontend มีฟีเจอร์ที่ต้องใช้ร่วมกันและปัญหาร่วมที่ต้องแก้ ไม่ดีกว่าหรือที่จะเริ่มด้วยการวางอะไรสักอย่างไว้ แทนที่จะเริ่มจากศูนย์?
เป็นไปไม่ได้ที่จะหาคนที่ทำงานได้ทันที เพราะไม่เคยเห็น framework ภายในมาก่อน ต่อให้เอกสารดีมาก ก็ต้องใช้เวลาเรียนรู้และซึมซับ ถ้าเป็นการจ้างระยะยาวก็ไม่เลวร้ายที่สุด แต่ถ้าจู่ ๆ ต้องการนักพัฒนาเพิ่มชั่วคราวก็หมดทาง
เคยเขียนไว้ที่อื่นด้วยว่าแทบทุกคนอยากได้ web app หรือคิดว่าตัวเองมี web app แต่จริง ๆ แล้วส่วนใหญ่เป็นแค่เว็บไซต์แบบ dynamic เท่านั้น ไม่จำเป็นต้องสุม framework ขึ้นมาเพื่อสร้างเว็บไซต์แบบ dynamic
นี่ไม่ใช่ปัญหา frontend แต่เป็น ปัญหาของ ecosystem JS เกิดขึ้นใน backend ด้วย
สภาพแวดล้อม JS เป็นความโกลาหลเต็มรูปแบบที่ dependency มี dependency อื่น ๆ อีกนับสิบหรือนับร้อย ตัวอย่างเช่น dependency graph ของ Platformatic ซึ่งเป็น Node framework บน Fastify เป็นแบบนี้
https://npmgraph.js.org/?q=platformatic#zoom=h
dependency เหล่านี้อาจถูกทิ้งได้ทุกเมื่อ แม้แต่ dependency ขนาดยักษ์อย่าง Axios หรือ Express ก็เคยดูเหมือนถูกปล่อยทิ้งช่วงหนึ่ง
และ dependency แต่ละตัวถูกครอบงำโดยวิธีที่ maintainer คิดว่าถูกต้อง ไม่กี่วันก่อน dependency ตัวหนึ่งที่ใช้ใน production มีดาวน์โหลดราว 25 ล้านครั้งต่อสัปดาห์ เทียบกับ React ราว 26 ล้าน และถูกใช้ใน GitHub repository 10 ล้านแห่ง แต่กลับตัดสินใจว่าสามารถเลิกรองรับ Safari เวอร์ชันเมื่อประมาณ 3 ปีก่อนได้แล้ว เมื่อคิดว่า Safari มีส่วนแบ่งตลาดมือถือในสหรัฐฯ มากกว่า 50% นี่เป็นเรื่องบ้าจริง ๆ