Front-end Frameworks: แนวทางแก้ไขหรือปัญหาป่อง?

เฟรมเวิร์กส่วนหน้าสมัยใหม่ต้องการให้คุณดาวน์โหลดสภาพแวดล้อมการพัฒนา พร้อมด้วยการพึ่งพา และคอมไพล์โค้ดของคุณก่อนที่จะพยายามดูบนเบราว์เซอร์ของคุณ นี้เป็นสิ่งที่ดี? ปัญหาที่เรากำลังสร้างไซต์ที่ซับซ้อนมากขึ้นหรือเป็นเพราะเฟรมเวิร์กนั้นซับซ้อนในสิทธิของตนเอง ทำให้เกิดระดับความซับซ้อนที่ไม่จำเป็นหรือไม่

การพัฒนาเว็บในปัจจุบันมีวิวัฒนาการไปมากตั้งแต่ยุค 90; เราสามารถสร้างประสบการณ์ทั้งหมดที่ใกล้เคียงกับสิ่งที่แอปพลิเคชันดั้งเดิมสามารถทำได้ และกระบวนการพัฒนาก็เปลี่ยนไปเช่นกัน ผ่านไปแล้ว การเป็นนักพัฒนาเว็บส่วนหน้าเป็นเรื่องของการเปิด Notepad การพิมพ์โค้ดสองสามบรรทัด ตรวจสอบบนเบราว์เซอร์ และอัปโหลดไปยังโฟลเดอร์ FTP หมดไป

การพัฒนาเว็บส่วนหน้าของอดีต

ฉันต้องเริ่มต้นด้วยการระบุให้ชัดเจน: โลกไม่เหมือนกับเมื่อ 10 ปีที่แล้ว (ฉันรู้น่าตกใจ) สิ่งเดียวที่คงอยู่คือการเปลี่ยนแปลง เมื่อก่อน เรามีเบราว์เซอร์น้อยมาก แต่มีปัญหาความเข้ากันได้มากมาย วันนี้ คุณไม่เห็นสิ่งต่างๆ เช่น “ดูดีที่สุดบน Chrome 43.4.1” มากนัก แต่ในตอนนั้น เป็นเรื่องปกติธรรมดา ขณะนี้มีเบราว์เซอร์เพิ่มขึ้น แต่มีปัญหาความเข้ากันได้น้อยลง ทำไม? เนื่องจาก jQuery jQuery ตอบสนองความต้องการที่จะมีไลบรารี่มาตรฐานทั่วไปที่อนุญาตให้คุณเขียนโค้ด JavaScript ที่จัดการ DOM โดยไม่ต้องกังวลว่ามันจะทำงานอย่างไรในแต่ละเบราว์เซอร์และในแต่ละเวอร์ชันของแต่ละเบราว์เซอร์ ซึ่งเป็นฝันร้ายที่แท้จริงในยุค 2000 .

เบราว์เซอร์สมัยใหม่สามารถจัดการ DOM เป็นมาตรฐานได้ ดังนั้นความต้องการไลบรารีดังกล่าวจึงลดลงอย่างมากในช่วงไม่กี่ปีที่ผ่านมา ไม่ จำเป็นต้อง ใช้ jQuery อีกต่อไป แต่เรายังคงพบปลั๊กอินที่มีประโยชน์อย่างมากจำนวนหนึ่งซึ่งขึ้นอยู่กับปลั๊กอินดังกล่าว กล่าวอีกนัยหนึ่ง เว็บเฟรมเวิร์กอาจไม่จำเป็น แต่ก็ยังมีประโยชน์เพียงพอที่จะเป็นที่นิยมและใช้กันอย่างแพร่หลาย นี่เป็นลักษณะทั่วไปของเว็บเฟรมเวิร์กยอดนิยมส่วนใหญ่ ตั้งแต่ React, Angular, Vue และ Ember ไปจนถึงรูปแบบและการจัดรูปแบบโมเดล เช่น Bootstrap

ทำไมผู้คนถึงใช้กรอบงาน

ในการพัฒนาเว็บเช่นเดียวกับในชีวิต การแก้ปัญหาอย่างรวดเร็วนั้นมีประโยชน์เสมอ คุณเคยทำเราเตอร์มาก่อนใน JavaScript หรือไม่? ทำไมต้องผ่านกระบวนการเรียนรู้ที่เจ็บปวดในเมื่อคุณสามารถ npm-ติดตั้ง front-end framework เพื่อเอาชนะปัญหาได้ เวลาเป็นสิ่งฟุ่มเฟือยเมื่อลูกค้าต้องการทำสิ่งต่างๆ ให้เสร็จสิ้น เมื่อวานนี้ หรือคุณได้รับโค้ดจากนักพัฒนาซอฟต์แวร์รายอื่นที่ออกแบบมาสำหรับเฟรมเวิร์กเฉพาะ หรือหากคุณกำลังผสานรวมกับทีมที่ใช้เฟรมเวิร์กที่กำหนดอยู่แล้ว มาเผชิญหน้ากัน—เฟรมเวิร์กมีอยู่ด้วยเหตุผล หากไม่มีผลประโยชน์ใดๆ กับพวกเขา ก็คงไม่มีใครใช้พวกมัน

ประโยชน์และคุณสมบัติเฉพาะของการใช้เฟรมเวิร์กการพัฒนาเว็บมีอะไรบ้าง?

เวลาคือเงิน. เมื่อคุณกำลังพัฒนาโปรเจ็กต์และลูกค้าไม่สนใจว่าเฟรมเวิร์กใดที่คุณใช้—ที่จริงแล้ว อาจไม่รู้ด้วยซ้ำว่าคุณใช้อะไร— พวกเขาสนใจแค่การได้ผลลัพธ์เท่านั้น และยิ่งเร็วยิ่งดี กรอบงานที่สร้างขึ้นช่วยให้คุณสร้างความรู้สึกก้าวหน้าได้ทันทีตั้งแต่เริ่มต้น ซึ่งลูกค้าต้องการตั้งแต่วันแรก นอกจากนี้ ยิ่งคุณพัฒนาได้เร็วเท่าไหร่ คุณก็ยิ่งทำเงินได้มากขึ้นเท่านั้น เนื่องจากเวลาที่กรอบงานว่างสามารถเปลี่ยนเส้นทางไปสู่การรับมากขึ้น โครงการต่างๆ

มันคือทั้งหมดที่เกี่ยวกับชุมชน เมื่อเลือกกรอบงาน นี่เป็นจุดสำคัญมาก—ใครจะช่วยคุณได้บ้างเมื่อคุณติดอยู่กับปัญหา คุณและฉันต่างก็รู้ว่ามันจะเกิดขึ้นในบางจุด คุณจะไปถึงจุดที่คุณต้องทำบางสิ่งที่เฟรมเวิร์กไม่ได้ตั้งใจจะทำ หรือเฟรมเวิร์กไม่เคยได้รับการออกแบบมาเพื่อให้คุณเข้าถึงได้ ดังนั้นการมีชุมชนที่สนับสนุนคุณจึงเป็นสิ่งจำเป็น การพัฒนา—โดยเฉพาะอย่างยิ่ง ฟรีแลนซ์—อาจเป็นเรื่องยาก เนื่องจากคุณดำดิ่งสู่โลกเสมือนจริง และหากคุณเป็นนักพัฒนาเว็บส่วนหน้าเพียงคนเดียวในทีม แสดงว่าคุณคือคนเดียวที่มีประสบการณ์และความเชี่ยวชาญในการค้นหา สารละลาย. แต่ถ้า front-end framework ที่คุณใช้มีการสนับสนุนที่มั่นคง ก็จะมีคนที่อยู่อีกฟากหนึ่งของโลกที่ประสบปัญหาเดียวกันและอาจช่วยคุณได้

มีมาตรฐานสวยงาม คุณเคยสังเกตไหมว่าเมื่อคุณดูโค้ดเก่า ๆ ของคุณเอง คุณสามารถไปยังส่วนต่างๆ ของโค้ดได้อย่างง่ายดาย หรืออย่างน้อยก็ง่ายกว่าโค้ดที่เขียนโดยคนอื่น? คุณคิดในทางใดทางหนึ่ง และคุณมีวิธีการตั้งชื่อและจัดระเบียบโค้ดในแบบของคุณเอง นั่นเป็นมาตรฐาน เราทุกคนติดตามพวกเขา แม้ว่าพวกเขาจะทำเพื่อตัวเราเองเท่านั้น เรามักจะกินของที่คล้ายกันเป็นอาหารเช้า ตื่นนอนเวลาใดเวลาหนึ่ง และวางกุญแจไว้ที่เดิมทุกวัน และแน่นอน หากเราเปลี่ยนกิจวัตรประจำวัน ชีวิตจะยากขึ้นมาก เพียงแค่คิดหาวิธีทำสิ่งต่างๆ เคยทำกุญแจหายเพราะคุณวางไว้ในที่ที่ต่างไปจากปกติหรือไม่? มาตรฐานทำให้ชีวิตง่ายขึ้น เมื่อทำงานเป็นส่วนหนึ่งของทีมหรือชุมชนนักพัฒนา พวกเขาจะกลายเป็นสิ่งที่ขาดไม่ได้อย่างแน่นอน

กรอบงานให้มาตรฐานตั้งแต่วินาทีที่คุณติดตั้ง ซึ่งจะแนะนำคุณในการคิดและเขียนโค้ดในลักษณะเฉพาะ คุณไม่จำเป็นต้องใช้เวลาสร้างมาตรฐานร่วมกับทีมของคุณ คุณสามารถทำตามวิธีการทำสิ่งต่างๆ ในกรอบงานได้ ทำให้ง่ายต่อการทำงานร่วมกัน การค้นหาฟังก์ชันจะง่ายกว่าเมื่อคุณรู้ว่าฟังก์ชันนั้นต้องอยู่ในไฟล์บางไฟล์ เพราะมันถูกสร้างขึ้นเพื่อเพิ่มเส้นทางใน SPA และในกรอบงานของคุณ เส้นทางทั้งหมดจะอยู่ในไฟล์ที่มีชื่อนั้น ผู้ที่มีระดับทักษะต่างกันสามารถทำงานร่วมกันได้ถ้าคุณมีมาตรฐานในระดับนี้ เพราะในขณะที่ผู้เขียนโค้ดขั้นสูงรู้ ว่าเหตุใดจึง เป็นเช่นนั้น แม้แต่นักพัฒนารุ่นเยาว์ก็สามารถปฏิบัติตามมาตรฐานได้

เมื่อกรอบงานล้มเหลว

เมื่อสองสามปีก่อน การพูดบางอย่างเช่น “ฉันไม่ได้ใช้เฟรมเวิร์ก—ฉันไม่เห็นประโยชน์ที่แท้จริงจากมัน” จะนำผู้คนที่มีคบไฟและโกยมาที่ประตูของคุณ แต่ทุกวันนี้ มีคนถามตัวเองมากขึ้นเรื่อยๆ ว่า “ทำไมฉันถึงต้องใช้ Framework เลย? ฉันต้องการพวกเขาจริงๆเหรอ? มัน ยากไหมถ้าไม่มีรหัสเหล่านี้”

ฉันเป็นหนึ่งในนั้นอย่างแน่นอน ฉันไม่เคยเป็นแฟนของเฟรมเวิร์กใดเลย และฉันเขียนโค้ดโดยไม่มีมันมาตลอดชีวิตการทำงาน ถ้าฉันมีทางเลือกในเรื่องนี้ ฉันเลือกเสมอว่า "ไม่ ขอบคุณ" ฉันพัฒนา JavaScript มาหลายปีแล้วและใน ActionScript ก่อนหน้านั้น ฉันกำลังเขียนโค้ดใน Flash เมื่อคนส่วนใหญ่คิดว่ามันตายแล้ว (ฉันรู้ ฉันรู้… แต่ฉันกำลังทำแอนิเมชั่นมากมาย และแอนิเมชั่นใน HTML ธรรมดานั้นยาก) ดังนั้น หากคุณเป็นหนึ่งในหลายๆ คนที่ไม่เคยคิดเกี่ยวกับการเขียนโค้ด โดยไม่มี เฟรมเวิร์ก ให้ฉันแสดงเหตุผลบางประการให้คุณดู จะต้องดิ้นรน

“หนึ่งขนาดเหมาะกับทุกคน” เป็นเรื่องโกหก คุณลองนึกภาพการเขียนซอฟต์แวร์ชิ้นเดียวที่สามารถทำทุกอย่างที่คุณทำได้สำเร็จในอาชีพการงานของคุณหรือไม่? นั่นเป็นหนึ่งในปัญหาหลักเกี่ยวกับเฟรมเวิร์กการพัฒนาเว็บ โครงการของคุณมีความต้องการที่เฉพาะเจาะจงมาก ซึ่งเรามักจะแก้ไขโดยการเพิ่มไลบรารี ปลั๊กอิน หรือส่วนเสริมเพื่อขยายขอบเขตของกรอบงาน ไม่มีเฟรมเวิร์กใดที่เสนอสิ่งที่คุณต้องการได้ 100% และไม่มีเฟรมเวิร์กใดที่ประกอบด้วยสิ่งที่คุณจะพบว่ามีประโยชน์ 100%

การมีโค้ดมากเกินไปซึ่งคุณไม่ได้ใช้อาจส่งผลให้เวลาโหลดล่าช้าสำหรับไซต์ของคุณ ซึ่งจะมีความสำคัญมากขึ้นสำหรับผู้ใช้แต่ละรายเพิ่มเติม อีกปัญหาหนึ่งคือความคิด "หนึ่งขนาดเหมาะกับทุกคน" ส่งผลให้โค้ดไม่มีประสิทธิภาพ ยกตัวอย่างเช่น $('sku-product').html('SKU 909090'); ซึ่งเป็นโค้ด jQuery ที่ท้ายที่สุดแล้ว เราทุกคนรู้ว่าจะถูกแปลเป็นบางอย่าง เช่น document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

ความแตกต่างดังกล่าวในบรรทัดเดียวอาจดูเหมือนไม่สำคัญ แต่การเปลี่ยนเนื้อหาขององค์ประกอบเฉพาะของหน้านั้นเป็นคุณธรรมของ React อย่างแม่นยำ ตอนนี้ React จะเข้าสู่กระบวนการสร้างการแสดงแทน DOM และวิเคราะห์ความแตกต่างในสิ่งที่คุณพยายามแสดงผล ง่ายกว่าไหมที่จะกำหนดเป้าหมายเนื้อหาที่คุณต้องการเปลี่ยนตั้งแต่เริ่มต้น

วัชพืชที่พันกันที่คุณกำลังเดินอยู่นั้นกำลังเติบโตหนาม คุณเคยอยู่ในสถานการณ์ที่คุณกำลังใช้เฟรมเวิร์กและพยายามเพิ่มไลบรารี่เข้าไป เพียงเพื่อให้ตระหนักว่าเวอร์ชันไลบรารีที่คุณต้องการใช้งานไม่ได้กับเวอร์ชันเฟรมเวิร์กที่คุณใช้อยู่หรือไม่ บางครั้งต้องใช้ความพยายามมากขึ้นในการทำให้โค้ดสองชิ้นทำงานร่วมกันได้ มากกว่าการเขียนโค้ดด้วยตัวเอง และเนื่องจากเฟรมเวิร์กและไลบรารีที่คุณใช้มักจะสร้างขึ้นบนเฟรมเวิร์กและไลบรารี อื่นๆ ที่อาจมีความเข้ากันไม่ได้ที่ซ่อนอยู่ซึ่งคุณคาดไม่ถึง ปัญหาดังกล่าวอาจซับซ้อนมากขึ้นแบบทวีคูณ จนถึงจุดที่จัดการไม่ได้หากคุณ ต้องการให้โครงการเติบโตต่อไป

การรักษาให้ทันกับโจนส์เป็นสิ่งที่ เคยทำงานในโครงการใน AngularJS เพียงเพื่อจะพบว่าคุณต้องการบางสิ่งที่ไม่ปรากฏจนกว่า Angular 4 จะเปิดตัวใช่หรือไม่ คุณรู้หรือไม่ว่า Angular 5 ได้รับการเผยแพร่แล้ว? นี่เป็นอีกปัญหาใหญ่ แม้ว่าคุณจะยึดติดกับเฟรมเวิร์กส่วนหน้าเพียงอันเดียว เมื่อรีลีสหลักใหม่เกิดขึ้น สิ่งต่าง ๆ สามารถเปลี่ยนแปลงได้มากจนโค้ดที่คุณทำงานอย่างหนักเพื่อสร้างจะไม่ทำงานในเวอร์ชันใหม่ ซึ่งอาจส่งผลให้เกิดการเปลี่ยนแปลงเล็กๆ น้อยๆ ที่น่ารำคาญซึ่งจำเป็นต้องทำกับไฟล์จำนวนมาก ไปจนถึงการเขียนโค้ดของคุณใหม่ทั้งหมด

การติดตามโครงสร้างล่าสุดของเฟรมเวิร์กเป็นสิ่งที่ท้าทาย แต่ในบันทึกเดียวกัน เฟรมเวิร์กอื่นๆ จะประสบปัญหาเมื่อการอัปเดตหยุดลงโดยสมบูรณ์ และพวกเขาไม่สามารถติดตามเทคโนโลยีที่เหลือได้ ในปี 2010 ทั้ง AngularJS และ Backbone ได้เปิดตัวเป็นครั้งแรก วันนี้ Angular อยู่ในเวอร์ชันหลักที่ห้าและ Backbone นั้นไม่ได้รับความสนใจอย่างสมบูรณ์ เจ็ดปีดูเหมือนนาน หากคุณสร้างเว็บไซต์ เว็บไซต์อาจมีการเปลี่ยนแปลงโดยสิ้นเชิงในด้านความสวยงามและการใช้งาน หากคุณกำลังสร้างแอป การเดิมพันบนเฟรมเวิร์กที่ไม่ถูกต้องอาจทำให้บริษัทตกอยู่ในสถานการณ์ที่ยากลำบาก—และมีราคาแพง—ในภายหลัง เมื่อสิ่งต่างๆ จำเป็นต้องเขียนใหม่

เมื่อคุณมีค้อน ทุกอย่างก็ดูเหมือนตะปู หากคุณเคยใช้เฟรมเวิร์กการพัฒนาเว็บบ่อยครั้ง สิ่งนี้อาจเกิดขึ้นกับคุณ โดยที่ฐานโค้ดเดียวกำหนดรูปร่างของโค้ดที่คุณใช้ในอนาคต แม้ว่าจะเกี่ยวข้องกับอุปกรณ์ต่อพ่วงเท่านั้น สมมติว่าคุณกำลังจะสร้างแพลตฟอร์มเช่น YouTube และคุณต้องการใช้ Framework X อาจมีจุดที่แม้จะฟังดูไร้สาระในยุคนี้ คุณตัดสินใจใช้ Flash สำหรับวิดีโอเพราะนั่นคือสิ่งที่มา สร้างขึ้นด้วยกรอบ

กรอบงานมีความคิดเห็นและมีความเข้มแข็ง ตัวอย่างเช่น React บังคับให้คุณใช้ JSX ในลักษณะเฉพาะ คุณสามารถเห็นการใช้รหัสในลักษณะนั้นได้ทุกที่ มีทางเลือกอื่นหรือไม่? ใช่. แต่ใครใช้ล่ะ? นี่ไม่ใช่สิ่งที่แย่เสมอไป แต่ถ้าคุณต้องการทำแอนิเมชั่นที่ซับซ้อน คุณอาจต้องการเฟรมเวิร์กสำหรับการสร้างแอนิเมชันเท่านั้น ไม่ใช่ทั้ง React ฉันเคยเห็นคนทำสิ่งที่บ้าๆ บอๆ เช่น เพิ่ม jQuery ในหน้าเพียงเพื่อผนวกโหนดเข้ากับองค์ประกอบ บางอย่างที่สามารถทำได้ใน vanilla JS ด้วย document.getElementById('id_of_node').appendChild(node); .

Eval Is Evil แต่ .innerHTML Is Machiavellian

ฉันต้องการใช้เวลาสำรวจประเด็นนี้แยกกัน เพราะฉันคิดว่านี่เป็นหนึ่งในเหตุผลที่ผู้คนจำนวนมากขึ้นไม่เขียนโค้ดโดยไม่มีเฟรมเวิร์ก เมื่อคุณเห็นว่าโค้ดส่วนใหญ่ทำงานอย่างไรเมื่อพยายามเพิ่มบางอย่างใน DOM คุณจะพบ HTML จำนวนมากที่ถูกแทรกโดยคุณสมบัติ .innerHTML ดูเหมือนเราทุกคนเห็นด้วยว่า eval นั้นไม่ดีสำหรับการรันโค้ด JavaScript แต่ฉันต้องการทำให้ .innerHTML เป็นจุดสนใจที่นี่ เมื่อคุณใส่โค้ด HTML เป็นสตริงธรรมดา คุณจะสูญเสียข้อมูลอ้างอิงใดๆ ที่คุณอาจมีกับโหนดใดๆ ที่คุณสร้างขึ้น เป็นความจริงที่คุณอาจนำมันกลับมาโดยใช้ getElementsByClassName หรือกำหนด id ให้พวกเขา แต่สิ่งนี้ไม่มีประโยชน์จริง เมื่อพยายามเปลี่ยนค่าของโหนดใดโหนดหนึ่ง คุณจะพบว่าตัวเองแสดง HTML ทั้งหมดกลับมาอีกครั้ง

นี่เป็นสิ่งที่ดีเมื่อคุณเริ่มเขียนโค้ด คุณสามารถสร้างสิ่งง่าย ๆ มากมายได้อย่างง่ายดายโดยไม่ต้องมีประสบการณ์มากนัก ปัญหาเกิดขึ้นกับความซับซ้อนของเว็บไซต์สมัยใหม่ ซึ่งมีแนวโน้มว่าจะคล้ายกับแอปมากกว่า ซึ่งหมายความว่าเราต้องเปลี่ยนค่าของโหนดของเราอย่างต่อเนื่อง ซึ่งเป็นการดำเนินการที่มีค่าใช้จ่ายสูง หากคุณทำโดยการติดตั้งโครงสร้างใหม่ทั้งหมด ผ่าน .innerHTML React แก้ปัญหานี้ได้อย่างมีประสิทธิภาพผ่าน Shadow DOM และ Angular จัดการกับปัญหาโดยใช้การเชื่อมโยงเป็นวิธีที่ง่ายในการปรับเปลี่ยนค่าที่แสดงบนหน้า อย่างไรก็ตาม ยังสามารถแก้ไขได้ค่อนข้างง่ายโดยการติดตามโหนดที่คุณสร้างและบันทึกโหนดที่จะใช้ซ้ำหรืออัปเดตในตัวแปร นอกจากนี้ยังมีสาเหตุอื่นๆ ที่ควรหลีกเลี่ยง .innerHTML โดยทั่วไป

ตำนานที่ใหญ่ที่สุดเกี่ยวกับการเข้ารหัสโดยไม่มีกรอบ

เวลาคือเงิน. ใช่ ฉันกำลังนำแนวคิดนี้กลับมาจากก่อนหน้านี้ หลายคนรู้สึกว่าถ้าพวกเขาหยุดใช้เว็บเฟรมเวิร์กยอดนิยม เราจะเปลี่ยนไปเป็นอินเทอร์เน็ตในยุค 90 ทันที เมื่อ <marquee> เป็นแท็กโปรดของทุกคน การหมุน GIF บนเว็บไซต์ Geocities นั้นดูทันสมัยและล้ำสมัย Alta Vista คือคำตอบ สำหรับการค้นหาเว็บ และตัวนับจำนวนการกดมีอยู่ทุกหนทุกแห่ง

ด้วยกรอบงานเว็บ โค้ดบรรทัดแรกของคุณดูเหมือนจะช่วยประหยัดเวลาได้มาก แต่เมื่อถึงจุดหนึ่ง กำไรกลับกลายเป็นขาดทุน คุณใช้เวลาอ่านเกี่ยวกับวิธีสร้างเฟรมเวิร์กเพื่อทำในสิ่งที่ไม่ได้สร้างมา วิธีผสานรวมไลบรารีและทำให้ใช้งานได้ดีกับเฟรมเวิร์ก และพบว่าโค้ดที่คุณสร้างในขณะที่ปฏิบัติตามมาตรฐานของเฟรมเวิร์กนั้นไม่เกิดขึ้น ใช้งานได้เลย และตอนนี้คุณต้องเขียนใหม่ เมื่อคุณทำสิ่งต่าง ๆ โดยไม่มีกรอบงาน คุณจะเริ่มช้าลง แต่คุณจะก้าวหน้าอย่างมั่นคง ในท้ายที่สุด ทั้งหมดอยู่ที่ว่าคุณต้องการส่วนไหนที่ง่ายที่สุด เวลาทั้งหมดจะไม่แตกต่างกันมากนัก

รหัสของฉันจะยาวกว่ากำแพงเมืองจีน การเขียนโดยไม่มีกรอบก็เหมือนการซื้อภาพยนตร์แทนที่จะสมัครใช้บริการสตรีมมิง คุณไม่สามารถเข้าถึงภาพยนตร์หลายร้อยเรื่องที่คุณต้องการดูได้ทันที แต่คุณไม่ต้องเสียเงินซื้อภาพยนตร์อีกหลายพันเรื่องที่คุณไม่เคยคิดแม้แต่จะดาวน์โหลดจากร้านค้า คุณสามารถเขียนสิ่งที่คุณต้องการ

พ่อค้าคนกลางมีประโยชน์หรือไม่? แน่นอน. แต่ปกติก็ไม่ จำเป็น โค้ดทุกบรรทัดที่คุณเขียนมีความหมายมากกว่า เนื่องจากคุณไม่จำเป็นต้องปรับให้เข้ากับข้อกำหนดของเฟรมเวิร์ก รู้สึกเหมือนกำลังเขียนโค้ดมากขึ้นด้วย JavaScript ล้วนๆ เนื่องจากวิธีการสร้างองค์ประกอบ DOM ต้องใช้เส้นเพื่อสร้างองค์ประกอบ แนบไปกับ DOM และอาจเพิ่มคลาสสำหรับการจัดสไตล์ แทนที่จะเรียกใช้บรรทัดเดียวของ รหัสใน JSX แต่ถ้าคุณเปรียบเทียบโค้ดโดยใช้ไลบรารี่เช่น jQuery หรือ React วานิลลา JS อาจมีความยาวใกล้เคียงกัน บางครั้งก็ยาว แต่บางครั้งก็สั้นด้วย

ไม่จำเป็นต้องคิดค้นล้อใหม่ มนต์ของอาจารย์วิทยาการคอมพิวเตอร์ทุกที่ และเป็นความจริง—ไม่จำเป็นต้องหมายถึงเฟรมเวิร์กโดยเฉพาะ การส่งคำขอ Ajax เพื่อโหลดหรือบันทึกข้อมูลเป็นข้อกำหนดในเกือบทุกเว็บแอป ตัวอย่างเช่น การไม่มีเฟรมเวิร์กไม่ได้หมายความว่าคุณต้องเขียนโค้ดใหม่ทุกครั้ง คุณสามารถสร้างห้องสมุดหรือฐานรหัสของคุณเอง หรือแยกรหัสจากผู้อื่นได้ ยิ่งมีขนาดเล็กเท่าไหร่ ก็ยิ่งปรับเปลี่ยนหรือปรับเปลี่ยนตามต้องการได้ง่ายขึ้นเท่านั้น ดังนั้นจึงสะดวกเมื่อคุณต้องการบางอย่างเฉพาะสำหรับโครงการ การแก้ไขโค้ด 100-200 บรรทัดทำได้ง่ายกว่าการไปยังไฟล์ต่างๆ ที่ไลบรารีหรือเฟรมเวิร์กของบริษัทอื่นอาจมีอยู่

มันจะใช้ได้กับโครงการขนาดเล็กเท่านั้น นี่เป็นตำนานทั่วไป แต่ไม่เป็นความจริงเลย ขณะนี้ ฉันกำลังทำงานกับระบบทั้งหมดเพื่อจัดการทุกแง่มุมของบริษัททางออนไลน์ในที่เดียว รวมถึงโมดูลที่คล้ายกับ Google ไดรฟ์ ไม่ว่าจะมีเฟรมเวิร์กหรือไม่มีเฟรมเวิร์ก ฉันก็ทำตามขั้นตอนที่คล้ายคลึงกันและพบปัญหาที่คล้ายกันมาก ความแตกต่างเล็กน้อย อย่างไรก็ตาม หากไม่มีเฟรมเวิร์ก โค้ดทั้งหมดของฉันจะเล็กลงและจัดการได้ง่ายขึ้น

ฉันต้องการหลักฐาน

ตกลง. หยุดพูดถึงทฤษฎีและข้ามไปยังตัวอย่างในโลกแห่งความเป็นจริง เมื่อหลายวันก่อน ฉันต้องแสดงรายการแบรนด์ที่มีโลโก้สำหรับร้านค้า โค้ดเริ่มต้นใช้ jQuery แต่มีปัญหาเมื่อโหลดใน Mozilla แสดงไอคอนรูปภาพที่เสียหายสำหรับแบรนด์ที่ยังไม่ได้อัปโหลดโลโก้ เราไม่สามารถทำให้ร้านดูไม่เสร็จได้เพียงเพราะว่าบริษัท X ยังไม่เสร็จงานของพวกเขา แต่ฟีเจอร์จำเป็นต้องเผยแพร่

รหัสต่อไปนี้ใช้ jQuery ที่เทียบเท่ากับ .innerHTML :

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

หากไม่เจาะลึกถึงข้อดีและข้อเสียของ jQuery ปัญหาคือเราไม่มีการอ้างอิงถึงรูปภาพที่เราสร้างขึ้น แม้ว่าจะมีวิธีแก้ไขที่ไม่เกี่ยวข้องกับการเปลี่ยนรหัส ลองใช้โอกาสนี้เพื่อดูว่าสามารถทำได้โดยไม่ต้องใช้ไลบรารี่เลย:

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

รหัส jQuery ดั้งเดิมมีความยาวหกบรรทัด ในขณะที่โซลูชัน vanilla JS ใช้เวลาสิบสองบรรทัด ในการแก้ปัญหา การซ่อนแต่ละภาพจนกว่าจะโหลดเสร็จ ใช้เวลาในการเขียนโค้ดนานเป็นสองเท่า ลองดูทางเลือกอื่น สามารถแก้ไขได้ใน jQuery ด้วยหรือไม่? ลองดูสิ:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

ด้วยโค้ดเพิ่มเติมสองสามบรรทัด ตอนนี้มีความแตกต่างเพียงสามบรรทัดระหว่าง jQuery และ vanilla แต่ใน jQuery คุณจะเห็นว่าบรรทัด img_out นั้นซับซ้อนมากอย่างรวดเร็ว จนถึงจุดที่คุณต้องหยุด และคิดให้รอบคอบเกี่ยวกับสิ่งที่คุณทำ การเข้ารหัส DOM โดยตรงโดยใช้ฟังก์ชันโหนดเพื่อเพิ่มแอตทริบิวต์ ฟังก์ชัน และอื่นๆ ที่คล้ายกันอาจมีความยาวมากขึ้น แต่แต่ละบรรทัดมีความหมายที่ชัดเจนและแม่นยำยิ่งขึ้น ทำให้อ่านและบำรุงรักษาได้ง่ายขึ้นในอนาคต

มาดู React กัน:

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

เวอร์ชันนี้มีความเหมาะสมรองลงมาอย่างชัดเจน โค้ดไม่สั้นไปกว่าวานิลลา และเรายังไม่ถึงจุดแก้ปัญหาและซ่อนลิงก์จนกว่ารูปภาพในนั้นจะถูกโหลด

ทุกตัวอย่าง ผลลัพธ์จะแตกต่างกัน บางครั้ง jQuery จะสั้นลง บางครั้ง React จะชนะ มีบางครั้งที่ vanilla JS อาจสั้นกว่าทั้งคู่ ไม่ว่าในกรณีใด เป้าหมายในที่นี้ไม่ได้เพื่อพิสูจน์ว่าเป้าหมายหนึ่งเหนือกว่าอีกฝ่ายโดยเนื้อแท้ แต่เพื่อแสดงให้เห็นว่าไม่มีความแตกต่างอย่างมีนัยสำคัญระหว่างการใช้ vanilla JS กับการใช้เฟรมเวิร์กเมื่อพูดถึงความยาวของโค้ด

บทสรุป

เช่นเดียวกับปัญหาในชีวิตจริง ไม่มีอะไรที่เป็นสีดำหรือสีขาว การเข้ารหัสโดยไม่มีกรอบการพัฒนาเว็บอาจเป็นทางออกที่ดีที่สุดสำหรับบางโครงการของคุณและฝันร้ายสำหรับโครงการอื่นๆ เช่นเดียวกับทุกเครื่องมือ กุญแจสำคัญอยู่ที่การเรียนรู้ไม่ใช่แค่วิธีใช้งาน แต่เมื่อใด และข้อดีและข้อเสียของการใช้งานจะเป็นอย่างไร การเขียนโค้ดใน JavaScript ล้วนๆ ก็เหมือนกับเฟรมเวิร์กใดๆ ก็ตาม การควบคุมให้เชี่ยวชาญนั้นต้องใช้เวลาก่อนที่คุณจะรู้สึกสบายใจที่จะใช้มัน

แต่ข้อแตกต่างที่สำคัญ อย่างน้อยสำหรับฉันก็คือ เฟรมเวิร์กนั้นมาและไป และแม้ว่าเฟรมเวิร์กจะได้รับความนิยมมาเป็นเวลานาน แต่ก็สามารถเปลี่ยนจากเวอร์ชันหนึ่งไปอีกเวอร์ชันหนึ่งได้อย่างมาก Pure JavaScript จะเป็นตัวเลือกที่ยาวนานกว่านั้นมาก จนกระทั่งหยุดความเกี่ยวข้องโดยสิ้นเชิงและบางภาษาก็ปรากฏขึ้น ถึงกระนั้นก็จะมีแนวคิดและกลยุทธ์มากมายที่คุณสามารถโยกย้ายจากภาษาหนึ่งไปอีกภาษาหนึ่งได้โดยตรงมากกว่าที่คุณจะทำได้ด้วยกรอบงานที่กำหนดไปยังอีกภาษาหนึ่ง เวลาและความพยายามจะเทียบเท่าโดยประมาณกับโครงการเดียว การลดค่าเสื่อมราคาของความรู้ และบทเรียนที่คุณสามารถนำไปพร้อมกับความท้าทายครั้งต่อไปเป็นปัจจัยที่สำคัญมากที่ต้องพิจารณา