ผลลัพธ์เกณฑ์มาตรฐานสำหรับ Next.js 12 นั้นน่าเชื่อถือ แต่มันคุ้มค่าที่จะเปลี่ยนหรือไม่?

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

พื้นหลัง

แนวโน้มทั่วไปในซอฟต์แวร์คือการเขียนเครื่องมือที่เราในฐานะนักพัฒนาใช้เพื่อสร้างแอปพลิเคชันของเราในภาษาเดียวกับที่เราใช้สร้างแอปพลิเคชัน ตัวอย่างเช่น pip เขียนด้วย Python, Composer เขียนด้วย PHP, Maven เขียนด้วย Java เป็นต้น สิ่งนี้สมเหตุสมผลเพราะโดยส่วนใหญ่แล้วคนที่สร้างเครื่องมือก็เป็นคนที่ใช้มันด้วย ดังนั้นจึงง่ายกว่าที่จะทำงานในภาษาที่พวกเขาเลือก

JavaScript ก็ไม่มีข้อยกเว้น ตั้งแต่ Gulp และ Bower ไปจนถึง Babel และ Webpack เราเขียนทั้งหมดนี้ด้วย JavaScript สิ่งนี้ใช้ได้ดีสำหรับเรา แต่มีปัญหาเล็กน้อย

ปัญหาเกี่ยวกับจาวาสคริปต์

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

เป็นภาษาตีความที่สามารถรวบรวมได้ทันเวลาและเป็นเธรดเดียว ใช่ ใช่ ฉันรู้เกี่ยวกับการสร้างอินสแตนซ์หลายรายการและการสื่อสารกับพนักงานเว็บ... แต่ในความคิดของฉัน นั่นไม่ใช่มัลติเธรด นั่นเป็นวิธีการแก้ปัญหาแบบวูดูแปลกๆ ที่พยายามเบี่ยงเบนความสนใจของเราจากความจริงที่ว่าเราไม่มีมัลติเธรดแบบเนทีฟ

ปัญหาที่ใหญ่กว่าคือมันค่อนข้างช้าบนคอนโซล เมื่อเทียบกับภาษาอื่นๆ

ในขณะที่ JavaScript นั้นยอดเยี่ยมในหน้าหนึ่ง ๆ มันค่อนข้างแย่ในคอนโซล

วันหนึ่งนักพัฒนา JavaScript กลุ่มหนึ่งจึงมารวมตัวกันในห้องมืด และหลังจากดื่มมากเกินไปแล้วมีคนพูดว่า:

“เฮ้ พวก ถ้า… ฟังฉันหน่อย… จะเกิดอะไรขึ้นถ้าเราไม่เขียนเครื่องมือที่สร้าง JavaScript ของเราใน JavaScript”

มีเสียงหายใจเฮือกใหญ่ เก้าอี้ถูกโยน การต่อสู้ปะทุขึ้น และหลังจากฝุ่นสงบลง ทุกคนตกลงที่จะลองดู

ตกลง ฉันอาจสร้างสิ่งนั้นขึ้นมา แต่ผลลัพธ์ก็ยังเหมือนเดิม ขณะนี้เรากำลังสร้างเครื่องมือสร้าง JavaScript ในภาษาอื่นที่ไม่ใช่ JavaScript

แต่ทำไมสนิม?

พูดได้คำเดียวว่า… ความเร็วและบัฟเฟอร์ล้น

Rust เป็นภาษาโปรแกรมเอนกประสงค์หลายกระบวนทัศน์ที่ออกแบบมาเพื่อประสิทธิภาพและความปลอดภัย มันเหมือนกับ C ++ แต่สำหรับคนรุ่นมิลเลนเนียลและซูมเมอร์ เป็นภาษาของระบบที่บังคับใช้ความปลอดภัยของหน่วยความจำและมีการทำงานพร้อมกันที่ "ปลอดภัย" มันคล้ายกับ C++ แบบวากยสัมพันธ์ และที่สำคัญกว่านั้น มันเกือบจะเร็วพอๆ กับ C++ เลย

การเรียกร้องที่มีแนวโน้ม

มีหลายโครงการที่พยายามแทนที่เครื่องมือ JavaScript ด้วยเครื่องมือที่ใช้สนิม ตัวอย่างบางส่วน ได้แก่ ParcelJS, Deno, ESBuild และ Speedy Web Compiler (SWC) พวกเขาทั้งหมดอ้างว่าทำงานได้เร็วกว่าสิ่งที่พวกเขาพยายามเปลี่ยนและหากคุณต้องการหัวเราะเบา ๆ ลองดูการเปรียบเทียบesbuild

สำหรับโพสต์นี้ ฉันจะไม่ตรวจสอบทั้งหมด แต่ฉันจะดู SWC อย่างใกล้ชิดผ่าน Next.js

Speedy Web Compiler (SWC)

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

Next.js เครื่องมือสนิมล่าสุด

Next.js แนะนำคอมไพเลอร์ Rust ในเวอร์ชัน 12 ที่ใช้ SWC ในเว็บไซต์ Next.js พวกเขาอ้างว่ารีเฟรชเร็วขึ้น ~3 เท่าในเครื่อง และผลิตเร็วขึ้น ~5 เท่า

ฟังดูเหมือนเป็นข้อเรียกร้องที่สามารถทดสอบได้สำหรับฉัน ดังนั้นฉันจึงทดสอบมัน

ฉันสร้างโปรเจ็กต์เดียวกันในเวอร์ชัน 11 และ 12 และเพิ่มคอมโพเนนต์ที่สร้างขึ้น 400 รายการเหมือนกัน ฉันใช้React Benchmark Generatorสำหรับสิ่งนี้ ข้อแตกต่างเพียงอย่างเดียวระหว่างโปรเจ็กต์คือเวอร์ชันของ Next.js ส่วนอื่นๆ เหมือนกันทุกประการ

ผลลัพธ์ค่อนข้างน่าเชื่อ นี่คือ Next.js 11:

และสำหรับ Next.js 12 ไปที่:

Next.js 12 ใช้เวลา 12 วินาทีในการทำสิ่งที่ Next.js 11 ทำใน 1 นาที 40 วินาที ซึ่งเร็วกว่าประมาณ 8 เท่า เห็นได้ชัดว่าพวกเขาไม่ได้พูดเกินจริง

ฉันไม่ได้คาดหวังว่า Next.js 12 จะใช้เวลา 12 วินาที เดาว่าเป็นความบังเอิญที่มีความสุข

มันคุ้มค่ากับการโฆษณาหรือไม่?

ตอนนี้คำถามที่ชัดเจนคือ: มันคุ้มค่ากับความเร่งรีบหรือไม่?

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

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

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

หาก CI ของคุณให้บิลด์พร้อมกันไม่จำกัดจำนวน แต่คิดค่าบริการตามนาทีบิลด์หรือวินาทีของเวลาประมวลผล ดังนั้น Next.js จะทำให้คุณเสียค่าใช้จ่ายมากกว่า Next.js 12 ถึง 8 เท่า

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

ไม่ว่าจะด้วยวิธีใด การสร้างช้าจะทำให้คุณเสียเวลาหรือเงินมากขึ้น หรือทั้งสองอย่าง

บทสรุป

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