Node.js Framework ที่ได้รับความนิยมสูงสุดในปี 2022

Express.js นั้นเก่าพอๆ กับ Node.js และในขณะที่ Express ยังคงเป็นเฟรมเวิร์กแบ็คเอนด์ที่ยอดเยี่ยม เครื่องมือและชุดเครื่องมือรูปแบบใหม่ก็กำลังทิ้งร่องรอยไว้

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

ข้อมูลนี้มีที่มาอย่างไร

ข้อมูลทั้งหมดได้มาจากการสำรวจเช่น State of JavaScript, Stack Overflow Developer Survey และประสบการณ์ส่วนตัวในการทำงานกับโครงการต่างๆ นี่ไม่ใช่การตรวจสอบตามกรอบงาน Node.js ที่มีดาว GitHub มากที่สุด

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

 หากคุณต้องการลองใช้เฟรมเวิร์กเหล่านี้ในสภาพแวดล้อมแบบเรียลไทม์ โปรดอ่านบทความของฉันเกี่ยวกับแพลตฟอร์มโฮสติ้งสำหรับนักพัฒนา แต่ละแพลตฟอร์มมีแผนบริการฟรี และเกือบทั้งหมดให้คุณนำเข้า repo GitHub และโฮสต์ได้โดยตรง 

เช่น คุณสามารถใช้ repo ใดก็ได้และใช้งานได้ภายในไม่กี่นาที

เทรนด์ Node.js ในปัจจุบัน

คุณจะสังเกตได้ตลอดโพสต์นี้ว่าเฟรมเวิร์กจำนวนมากที่กล่าวถึงในบทความนี้มีพื้นฐานมาจากเฟรมเวิร์กส่วนหน้า สิ่งนี้เรียกว่า meta-framework แล้วมันเกี่ยวอะไรกับเรื่องนี้ และทำไมถึงใช้วิธีนี้?

หากเราดูบางอย่างเช่น React วิธีแสดงหน้าจะทำผ่าน CSR – การแสดงผลฝั่งไคลเอ็นต์ เมื่อมีการร้องขอ เบราว์เซอร์จะได้รับไฟล์ HTML แบบแบร์โบนโดยไม่มีเนื้อหาของหน้าจริง ดังนั้น เบราว์เซอร์จึงเดินทางรอบที่สองเพื่อรับเอกสาร JavaScript ที่มีเนื้อหาของหน้า จากนั้นจึงส่งและแสดงหน้าเว็บจริง

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

ซึ่งมักเรียกอีกอย่างว่า SPA หรือ Single Page Application

และนี่คือข้อเสียของแนวทางนี้ – CSR –

• การแคช – เนื่องจากเนื้อหาหน้าทั้งหมดแสดงผลผ่าน JavaScript จึงไม่มีเนื้อหา HTML จริงบนหน้าที่สามารถแคชได้
• SEO – ในขณะที่โปรแกรมรวบรวมข้อมูลกำลัง "ฉลาดขึ้น" มีปัญหาที่ชัดเจนเกี่ยวกับการมีเนื้อหาดัชนีของโรบ็อตขึ้นอยู่กับ JavaScript เพียงอย่างเดียว
• การแสดงผล – การเรนเดอร์เริ่มต้นมักจะช้าและไม่ตอบสนองจนกว่า JavaScript ทั้งหมดจะเสร็จสิ้นการโหลด

ดังนั้น ในบริบทนี้ แนวคิดเบื้องหลังเฟรมเวิร์กอย่าง Next และ Nuxt คือการใช้เฟรมเวิร์กส่วนหน้า แต่ให้ SSR (Server-Side Rendering) ผ่าน Node.js

การพูดของ SSR – Nick Johnstone เผยแพร่ส่วนสำคัญที่น่าสนใจในหัวข้อ “ความซับซ้อนที่ไร้สาระของการเรนเดอร์ฝั่งเซิร์ฟเวอร์” และยังมีหัวข้อ Hacker News ที่เกี่ยวข้องซึ่งมีการพูดคุยกันค่อนข้างมากในหัวข้อนี้ แม้ว่าจะไม่มีการเปลี่ยนแปลงมากนักในอนาคตอันใกล้นี้ แต่ฉันเชื่อว่าแนวคิดบางอย่างเหล่านี้จะขับเคลื่อนการเปลี่ยนแปลงที่สำคัญในการทำงานของกรอบงานบางรูปแบบ

#1 – Next.js

มากกว่าการเป็น React Framework – Next.js ได้รับความนิยมเพิ่มขึ้นอย่างต่อเนื่องด้วยการพัฒนาที่สูงอย่างไร้เหตุผล Next.js 10 ถึง Next.js 12 ใช้เวลาเพียงปีเดียว

แนวคิดหลักที่อยู่เบื้องหลัง Next.js คือใช้ React เป็นพื้นฐาน แต่ดำเนินการโครงสร้างการเรนเดอร์ฝั่งเซิร์ฟเวอร์ทั้งหมดผ่านข้อกำหนดเฉพาะของตัวเอง เนื่องจากการเรนเดอร์ทำได้ที่ฝั่งเซิร์ฟเวอร์ คุณไม่จำเป็นต้องเรนเดอร์เพจในฝั่งไคลเอ็นต์ ซึ่งให้ประโยชน์ด้านประสิทธิภาพมหาศาลและ SEO ในประเด็นที่เกี่ยวข้อง

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

#2 – เนสท์

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

ซึ่งเจาะจงกับแบ็คเอนด์แน่นอน

Nest มีส่วนประกอบหลัก 3 ส่วน (ได้รับแรงบันดาลใจจาก Angular) – Controllers , Providers และ Modules การใช้ โมดูล เป็นวิธีที่ Nest พยายามแก้ปัญหาลำดับชั้นของแอปพลิเคชันที่ซับซ้อน แต่ละองค์ประกอบสามารถจัดหมวดหมู่ในโมดูลที่แยกจากกัน โดยที่คุณกำหนดค่าตัวควบคุม การพึ่งพา และผู้ให้บริการเฉพาะของตัวเอง

#3 – สตราปิ

หัวขาดเป็นสิ่งที่เดือดดาลในการเล่าเรื่องส่วนหน้าปัจจุบัน และ Strapi ทำงานได้อย่างยอดเยี่ยมในการวางตำแหน่งตัวเองให้เป็นหนึ่งในเฟรมเวิร์ก CMS แบบ Headless ชั้นนำ

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

ซึ่งรวมถึงการจัดการเนื้อหาของคุณผ่าน UI ที่กำหนดเอง จุดปลายแบบ on-the-fly สำหรับ GraphQL & REST การจัดการผู้ใช้ (บทบาท ฯลฯ) และอินเทอร์เฟซปลั๊กอินแยกต่างหากที่คุณสามารถสร้างได้ Strapi เป็นเฟรมเวิร์กที่ไม่เชื่อเรื่องพระเจ้าโดยสมบูรณ์ และรวมเข้ากับภาษา เฟรมเวิร์ก หรือไลบรารีส่วนหน้าใดๆ ก็ตาม

#4 – รีมิกซ์

Remix เป็นเฟรมเวิร์กฟูลสแตกที่สร้างโดยผู้สร้าง React Router

ฉันเชื่อว่า Remix เป็นหนึ่งในเฟรมเวิร์กฟูลสแตกที่เติบโตเร็วที่สุดที่เราเคยเห็นในช่วงไม่กี่ปีที่ผ่านมา แล้วมาได้ยังไง? ประการหนึ่ง Remix พยายามผสานรวมกับ Web Standards ให้ได้มากที่สุดโดยให้ API ที่กระชับสำหรับรหัสสถานะทั่วไปและการโต้ตอบกับผู้ใช้

Remix ไม่ได้สร้างโครงสร้างตามน้ำตก (ส่วนประกอบ) ต่างจากเฟรมเวิร์กดั้งเดิม แต่ข้อมูลจะถูกโหลดแบบขนานบนฝั่งเซิร์ฟเวอร์และทำหน้าที่เป็นหน้า HTML นอกจากนี้ยังหมายความว่าคุณลักษณะที่ใช้ JavaScript (เช่น การส่งแบบฟอร์ม) จะไม่ทำให้ไซต์เสียหายหากผู้ใช้ปิดใช้งาน JavaScript

#5 – Nuxt

Nuxt 3 (สำหรับ Vue 3) อยู่ในโอเพ่นเบต้า: โปรดระวัง

Nuxt สร้างบน Vue เป็นเฟรมเวิร์กฟูลสแตกสำหรับการสร้างแอปพลิเคชันที่มีประสิทธิภาพ นอกจากนี้ยังเป็นกรอบเมตาที่สร้างขึ้นเพื่อปรับปรุงประสบการณ์ของการพัฒนา Vue แบบฟูลสแตกอย่างมาก Nuxt รองรับ SSR, SPA และเพจที่สร้างแบบคงที่

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

ในขณะที่ Vue มีช่องฝั่งไคลเอ็นต์แบบถาวร Nuxt ไม่มี ดังนั้น การโต้ตอบกับ DOM หลังจากที่ Nuxt แสดงผลหน้าเว็บแล้วอาจเป็นเรื่องยาก

#6 – SvelteKit

Svelte มีสถานะเด็กสุดเจ๋งในยุค front-end ปัจจุบัน และทีมกำลังทำงานบน SvelteKit ซึ่งเป็นเฟรมเวิร์กฟูลสแตกที่สร้างขึ้นบน Sapper (แทนที่) SvelteKit โดดเด่นด้วยระบบกำหนดเส้นทางตามไฟล์ที่ซับซ้อน

เป้าหมายหลักของ SvelteKit คือการเร่งการพัฒนาเว็บโดยขจัดปัญหาคอขวดทั่วไปบางส่วน การใช้ Snowpack, Vite และเครื่องมือภายนอกอื่นๆ – SvelteKit สามารถมอบประสบการณ์การพัฒนาที่มีคุณลักษณะหลากหลาย

สุดท้าย SvelteKit ใช้กระบวนการ Hydration ความสามารถในการคงสถานะแอ็คทีฟสำหรับองค์ประกอบ DOM ที่แสดงผลฝั่งเซิร์ฟเวอร์

#7 – Fastify

กรอบงาน Fastify นั้นเกี่ยวกับประสิทธิภาพการทำงาน และการวัดประสิทธิภาพแต่ละรายการได้แสดงให้เห็นว่าสามารถรองรับคำขอได้มากถึง 60,000 คำขอต่อวินาที คุณสามารถขยาย Fastify (นอกเหนือจากเครื่องมือที่ยอดเยี่ยมอยู่แล้ว) ผ่าน Hooks และ Plugins และแม้ว่าจะไม่ใช่เฟรมเวิร์กที่เน้น TypeScript เป็นหลัก แต่ Fastify ก็ รองรับ TypeScript

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

#8 – เรดวูด

คุณรัก API หรือไม่? คุณชอบ JAMStack ไหม? ถ้าคำตอบคือใช่ คุณจะรัก RedwoodJS เป็นเฟรมเวิร์กเว็บแอปแบบฟูลสแตกที่ใช้เทคโนโลยีที่ทันสมัยมากมาย และเทคโนโลยีเหล่านั้นรวมถึง GraphQL, Prisma, Storybook และ Jest ส่วนหน้าใน Redwood สร้างขึ้นจาก React และคุณยังได้รับการสนับสนุน TypeScript เต็มรูปแบบอีกด้วย

#9 – ด่วน

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

#10 – อโดนิส

Adonis เป็นเฟรมเวิร์ก MVC แบ็คเอนด์ที่ TypeScript แรกสร้างขึ้นสำหรับ Node.js พึงระลึกไว้เสมอว่าแม้ Adonis จะอธิบายว่าตัวเองเป็นเฟรมเวิร์กแบ็คเอนด์ ก็ยังดีที่จะพัฒนาแบบฟูลสแตกด้วย

เหตุผลสำคัญประการหนึ่งที่นักพัฒนาซอฟต์แวร์ชอบ Adonis ก็คือการรองรับ TypeScript แบบเนทีฟ

แต่ยังรองรับ ORM (Object Relational-Mapping) แนวทางปฏิบัติด้านความปลอดภัยที่แข็งแกร่ง และเอกสารประกอบที่ง่ายต่อการปฏิบัติตาม

สุดท้ายแต่ไม่ท้ายสุด Adonis ทำงานร่วมกับระบบนิเวศของ Node.js ในระดับพื้นฐาน ดังนั้นการมีประสบการณ์มาก่อนในการพัฒนาโหนดจึงเป็นสิ่งที่ต้องมี

#11 – คีย์สโตน

เฟรมเวิร์ก Node.js สุดท้ายในรายการนี้คือ Keystone และเหมือนกับ Express ที่มีมา เกือบ ตั้งแต่วันแรก สิ่งนี้ทำให้ Keystone เป็นเฟรมเวิร์กที่สมบูรณ์ โดยให้เครื่องมือและการผสานรวมที่เป็นรูปธรรมเพื่อสร้างประสบการณ์ที่เป็นมิตรกับนักพัฒนา

คุณลักษณะเด่นบางอย่าง (ซึ่งส่วนใหญ่ได้รับการปรับปรุงในช่วงหลายปีที่ผ่านมา) ใน Keystone รวมถึง CRUD อัตโนมัติผ่าน GraphQL API ซึ่งคุณสามารถขยายเพิ่มเติมได้ นอกจากนี้ คุณสามารถสร้างและใช้ส่วนประกอบ React.js ของคุณเองได้

Keystone ถูกใช้ในด้านการพัฒนาต่างๆ และทำงานได้ดีกับแอพมือถือ เว็บไซต์ที่ใช้งานได้จริง หน้าร้านอีคอมเมิร์ซ และอื่นๆ อีกมากมาย

Meta พื้นเมืองและหยิกของ Headless

เป็นเวลานานแล้วที่ฉันได้ทำภาพรวมเช่นนี้ สิ่งต่างๆ นั้นง่ายกว่า มากใน ตอนนั้น และในขณะที่รถจักรและรถจักรไม่มีที่ไหนที่จะพบได้ มันเป็นเรื่องดีที่ได้เห็น Keystone และ Express ก้าวผ่านบททดสอบแห่งกาลเวลา

ฉันสามารถพูดได้ว่ามีข่าวลืออยู่รอบๆ Node.js ฉันเชื่อว่าบางคนไม่มีความสุขและรู้สึก ติดอยู่ กับมัน และแนวคิดของตัวจัดการแพ็คเกจ (npm) ก็เริ่มที่จะเก่าขึ้นเช่นกัน เนื่องจากแพ็คเกจยังคงเพิ่มกองบนกองขนาดมัดที่ไม่จำเป็นลงในโปรเจ็กต์ขนาดเล็ก

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