ชุมชนนักพัฒนาเว็บกำลังมีการถกเถียงกันอย่างเข้มข้นเกี่ยวกับว่าการไล่ตามความบริสุทธิ์ของ functional programming ได้นำการพัฒนา frontend สมัยใหม่ไปในทางที่ผิดจากความสามารถดั้งเดิมของแพลตฟอร์มเว็บหรือไม่ การถกเถียงมุ่งเน้นไปที่ว่าเครื่องมือต่างๆ เช่น React, CSS-in-JS และ JavaScript framework ที่ซับซ้อนได้ทำให้การพัฒนาเว็บซับซ้อนโดยไม่จำเป็นด้วยการต่อสู้กับฟีเจอร์ที่มีอยู่แล้วในเบราว์เซอร์
การถกเถียงใหญ่เรื่อง CSS: Global vs Scoped Styling
หนึ่งในประเด็นที่ถกเถียงกันมากที่สุดในการอภิปรายนี้หมุนรอบการจัดการ CSS นักพัฒนาจำนวนมากโต้แย้งว่าการเปลี่ยนแปลงของอุตสาหกรรมจาก CSS แบบดั้งเดิมไปสู่โซลูชัน CSS-in-JS และ utility framework เช่น Tailwind ได้สร้างปัญหามากกว่าที่จะแก้ไข ชุมชนชี้ให้เห็นว่า CSS ได้รับการออกแบบมาให้ cascade แบบ global ทำให้ stylesheet ขนาดเล็กสามารถควบคุมเอกสารขนาดใหญ่ได้อย่างมีประสิทธิภาพ อย่างไรก็ตาม ผู้สนับสนุน functional programming ผลักดันให้มีการแยก component ออกจากกัน ส่งผลให้เกิดการสร้างสไตล์ขณะรันไทม์และเครื่องมือที่ซับซ้อน
นักพัฒนาที่มีประสบการณ์บางคนสังเกตว่าปัญหาที่แท้จริงไม่ใช่เรื่องเทคนิคแต่เป็นเรื่ององค์กร ทีมต่างๆ ต่อสู้กับการบังคับใช้แนวทาง CSS ในหมู่นักพัฒนาหลายคน ทำให้พวกเขาใช้ utility framework ที่รับประกันความสอดคล้องแม้จะต้องแลกกับ markup ที่ยาวเยื่อและ HTML payload ที่ใหญ่ขึ้น สิ่งนี้เน้นย้ำถึงความตึงเครียดพื้นฐานระหว่างการรักษาคุณภาพโค้ดในระดับใหญ่และการใช้ประโยชน์จากความสามารถดั้งเดิมของแพลตฟอร์ม
Native Web APIs vs การสร้างใหม่ด้วย JavaScript
ส่วนสำคัญของการถกเถียงมุ่งเน้นไปที่วิธีที่ framework สมัยใหม่มักจะสร้างฟีเจอร์ของเบราว์เซอร์ใหม่ใน JavaScript แทนที่จะใช้ native API การอภิปรายเน้นย้ำถึงความขัดแย้งเรื่อง element <dialog> โดยเฉพาะ ที่นักพัฒนายังคงสร้าง modal component แบบกำหนดเองด้วย element <div> แทนที่จะใช้ฟังก์ชัน dialog ดั้งเดิมที่ให้การจัดการ focus, การจัดการคีย์บอร์ด และฟีเจอร์ accessibility ที่มีอยู่แล้ว
อย่างไรก็ตาม ชุมชนให้บริบทสำคัญเกี่ยวกับเวลาและความเข้ากันได้ Element <dialog> เพิ่งได้รับการสนับสนุนเต็มรูปแบบจากเบราว์เซอร์ในเดือนมีนาคม 2022 โดย Firefox เพิ่มการสนับสนุนเมื่อสองเดือนที่ผ่านมา สิ่งนี้อธิบายได้ว่าทำไม component library ที่มีอยู่และสื่อการเรียนรู้ยังคงพึ่งพาการใช้งาน JavaScript - พวกเขาถูกสร้างขึ้นก่อนที่ทางเลือกดั้งเดิมจะใช้งานได้
Native Web APIs เทียบกับการพัฒนาแบบ Framework
| คุณสมบัติ | โซลูชันแบบ Native | แนวทาง Framework | การแลกเปลี่ยน |
|---|---|---|---|
| Modal Dialogs | element <dialog> |
คอมโพเนนต์ <div> แบบกำหนดเอง |
Native: มี a11y ในตัว, การจัดการ focus; Framework: ควบคุมได้มากกว่า, รองรับเบราว์เซอร์เก่า |
| Form Validation | HTML5 validation attributes | JavaScript validation libraries | Native: ทันที, ไม่ต้องใช้ JS; Framework: โลจิกแบบกำหนดเอง, UX ที่สม่ำเสมอ |
| Routing | แท็ก <a>, History API |
Client-side routers | Native: ทำงานได้โดยไม่ต้องใช้ JS, เข้าถึงได้; Framework: ไม่ต้องโหลดหน้าใหม่, รักษาสถานะ |
| Styling | CSS cascade, stylesheets | CSS-in-JS, utility classes | Native: การแยกวิเคราะห์แบบขนาน, payload ที่เล็กกว่า; Framework: การแยกคอมโพเนนต์, ไม่มีความขัดแย้งในการตั้งชื่อ |
ปัญหาเส้นโค้งการเรียนรู้
สมาชิกชุมชนแสดงความกังวลเกี่ยวกับวิธีการสอนและประยุกต์ใช้แนวคิด functional programming ในการพัฒนา frontend หลายคนสังเกตเห็นนักพัฒนาเขียนโค้ดที่ซับซ้อนเกินไปโดยใช้ array method เช่น reduce() และการ chain method มากเกินไป ในขณะที่ for-loop แบบธรรมดาจะอ่านและดูแลรักษาได้ง่ายกว่า
ผมเห็นโค้ดที่วุ่นวายมากมายด้วย arr.reduce() หรือ arr.map().filter().filter().map() ที่ chain กันหลายตัว ซึ่งจะง่ายและอ่านง่ายกว่ามากถ้าเป็น for-loop แบบคลาสสิก
การอภิปรายเผยให้เห็นความแตกต่างระหว่างรุ่นในแนวทางการเขียนโปรแกรม นักพัฒนาที่ได้รับการฝึกฝนใน functional programming พบว่า imperative loop ยากที่จะเข้าใจ ในขณะที่ผู้ที่มีพื้นฐาน procedural ต่อสู้กับ functional chain สิ่งนี้บ่งบอกว่าปัญหาไม่ได้อยู่ที่แนวทางหนึ่งจะเหนือกว่าโดยธรรมชาติ แต่เกี่ยวกับการจับคู่เครื่องมือที่เหมาะสมกับปัญหาเฉพาะและบริบทของทีม
วิวัฒนาการของแพลตฟอร์ม vs ข้อจำกัดของ Framework
แง่มุมที่น่าสนใจของการถกเถียงเกี่ยวข้องกับความเร็วในการพัฒนามาตรฐานเว็บเปรียบเทียบกับการยอมรับ framework ชุมชนสังเกตว่าเบราว์เซอร์ตอนนี้สนับสนุนฟีเจอร์มากมายที่นักพัฒนาสร้างใหม่ใน JavaScript มาหลายปี เช่น element <select> ที่ปรับแต่งได้, date picker ดั้งเดิม และความสามารถในการจัดแต่ง CSS ขั้นสูง
อย่างไรก็ตาม ข้อจำกัดของ framework บางครั้งป้องกันไม่ให้นักพัฒนาใช้ฟีเจอร์ใหม่เหล่านี้ ฟีเจอร์ทดลองของเบราว์เซอร์บางอย่างทำให้เกิด hydration failure ใน framework ยอดนิยม สร้างสถานการณ์ที่แพลตฟอร์มได้พัฒนาไปเกินกว่าที่เครื่องมือพัฒนาหลักจะจัดการได้ สิ่งนี้สร้างช่วงหน่วงระหว่างสิ่งที่เป็นไปได้ในแบบดั้งเดิมและสิ่งที่ใช้งานได้จริงในการพัฒนาที่ใช้ framework
ไทม์ไลน์การรองรับของเบราว์เซอร์สำหรับฟีเจอร์สำคัญ
- องค์ประกอบ
<dialog>: ได้รับการรองรับอย่างเต็มรูปแบบในเดือนมีนาคม 2022, Firefox เพิ่มการรองรับในเดือนตุลาคม 2024 <select>ที่ปรับแต่งได้: ยังคงอยู่ในระยะทดลองในเบราว์เซอร์ส่วนใหญ่ ณ ปี 2024- ตัวเลือก CSS
::part()และ::pseudo(): การรองรับอย่างกว้างขวางสำหรับการจัดแต่งขั้นสูง <input type="date">: ได้รับการรองรับเป็นอย่างดีในเบราว์เซอร์สมัยใหม่- Popover API: การรองรับที่กำลังเกิดขึ้นสำหรับฟังก์ชัน tooltip และ overlay
ความแตกต่างระหว่างองค์กร vs เทคนิค
การอภิปรายกลับมาที่แนวคิดที่ว่าการตัดสินใจทางเทคนิคมากมายในการพัฒนา frontend จริงๆ แล้วแก้ปัญหาองค์กรมากกว่าปัญหาทางเทคนิค ทีมพัฒนาขนาดใหญ่ต้องการความสอดคล้องและความสามารถในการดูแลรักษา ซึ่งบางครั้งขัดแย้งกับการใช้ฟีเจอร์แพลตฟอร์มอย่างเหมาะสม สิ่งนี้อธิบายได้ว่าทำไมทีมเลือกเครื่องมือที่บังคับใช้รูปแบบและป้องกันข้อผิดพลาดบางประเภท แม้ว่าเครื่องมือเหล่านั้นจะเพิ่มความซับซ้อนหรือภาระด้านประสิทธิภาพ
ชุมชนยอมรับว่า React และ framework ที่คล้ายกันแก้ปัญหาจริงด้วยการพัฒนาแบบ jQuery โดยเฉพาะเรื่องการจัดการ state และการจัดระเบียบ component คำถามไม่ใช่ว่าเครื่องมือเหล่านี้มีค่าหรือไม่ แต่ว่าพวกเขาได้กลายเป็นตัวเลือกเริ่มต้นสำหรับปัญหาที่ไม่ต้องการความซับซ้อนของพวกเขาหรือไม่
มองไปข้างหน้า
การสนทนาบ่งบอกว่าอุตสาหกรรมเริ่มตระหนักถึงความตึงเครียดเหล่านี้ Framework ใหม่ๆ เช่น HTMX, Qwik และ Astro ได้รับการออกแบบมาอย่างชัดเจนเพื่อทำงานร่วมกับความสามารถของแพลตฟอร์มเว็บมากกว่าการต่อสู้กับมัน เครื่องมือเหล่านี้มีเป้าหมายที่จะให้ประสบการณ์การพัฒนาสมัยใหม่ในขณะที่ใช้ประโยชน์จากฟีเจอร์ดั้งเดิมของเบราว์เซอร์เพื่อประสิทธิภาพและความเรียบง่าย
การถกเถียงในท้ายที่สุดสะท้อนให้เห็นระบบนิเวศที่กำลังเติบโตซึ่งต่อสู้กับความสมดุลระหว่างประสบการณ์นักพัฒนา ประสิทธิภาพ และการปรับตัวให้เข้ากับแพลตฟอร์ม เมื่อมาตรฐานเว็บยังคงพัฒนาและให้โซลูชันดั้งเดิมมากขึ้น ชุมชนจะยังคงประเมินใหม่ว่าเมื่อไหร่ที่ framework ซับซ้อนจำเป็น เทียบกับเมื่อไหร่ที่แนวทางที่เรียบง่ายและสอดคล้องกับแพลตฟอร์มอาจเหมาะสมกว่า
อ้างอิง: How Functional Programming Shaped (and Twisted) Frontend Development