สงคราม JavaScript Framework จบลงแล้ว

และมีผู้ชนะเพียงหนึ่งเดียว

ผู้เข้าแข่งขัน: สงครามระหว่างเฟรมเวิร์กเป็นหัวข้อร้อนแรงของชุมชน JS มาโดยตลอด Backbone, Sencha และรายอื่น ๆ หายไปแล้ว ส่วน jQuery นั้นน่าประหลาดใจที่ยังคงมีชุมชนขนาดใหญ่อยู่ และก็มีบางรายอย่าง Angular ที่ไปไม่ค่อยสวย

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

AngularJS: อยู่ในโหมด LTS และปลดระวางไปแล้ว มันเป็นก้าวกระโดดครั้งใหญ่ของระบบนิเวศเฟรมเวิร์ก และยังมีหลายคนคิดถึงมัน เนื่องจากไม่มีการดูแลต่อแล้ว จึงไม่ใช่ผู้เข้าแข่งขันอีกต่อไป

Angular:

• เกิดขึ้นมาเพื่อแข่งขันกับ React จากปัญหาด้านประสิทธิภาพและความแข็งแรงของ AngularJS ทำให้โปรแกรมเมอร์จำนวนมากอิจฉา React Angular พยายามทำ AngularJS ให้ทันสมัยขึ้นและใช้ประโยชน์จากการปรับปรุงของ ES6 เพื่อแข่งขันกับ React
• ความยากที่ใหญ่ที่สุดคือช่วงการเรียนรู้ที่ชันมาก ต้องเข้าใจหลายแนวคิด สืบทอดความชันในการเรียนรู้จาก AngularJS มา แถมยังมีความยากใหม่อย่าง RxJS หรือการฉีด dependency แบบลำดับชั้น (DI)
• อีกความกังวลหนึ่งคือการผิดสัญญาหลายครั้ง ตัวอย่างเช่น V2 เคยทำให้การสร้างหน้า server-side rendering (SSR) ดูง่าย แต่ ณ วันที่ 2022/2/24 กลับยังทำงานไม่ได้หากไม่มี JS
• ปัญหาใหญ่ที่สุดคือความแตกย่อยและการอัปเกรดเวอร์ชัน การอัปเกรดเวอร์ชันยากเกินไปจนผู้ใช้ไม่ยอมเสี่ยง ซึ่งเห็นได้จากสถิติบนเว็บ npm

VueJS:

• เป็นคำตอบสำหรับนักพัฒนาที่ต้องการสิ่งที่เร็วกว่า AngularJS เสถียรกว่า Angular และใช้งานง่ายกว่า ในระบบเทมเพลต Vue มีความใกล้เคียงกับ AngularJS มาก จึงคงความเรียบง่ายของ AngularJS ไว้ พร้อมรับพลังจาก React
• แต่ VueJS มีปัญหาร้ายแรงในเวอร์ชัน 1 และ 2 จัดการกับ array ได้ไม่ดี และผู้เขียนยังโทษ JavaScript สำหรับการเลือกอัลกอริทึมการอัปเดตที่ผิดพลาด อีกทั้งยังพึ่งพาไลบรารีอย่าง Vuex หรือ Redux
• ปัญหานี้ได้รับการแก้ไขในเวอร์ชัน 3 อย่างไรก็ตาม การโทษคนอื่นในความผิดพลาดของตัวเองไม่ใช่สิ่งที่เหมาะกับชุมชน

SvelteJS:

• คู่แข่งที่กำลังเติบโต และกำลังให้คำสัญญาครั้งใหญ่ โดยอ้างว่าจุดเด่นสำคัญคือการแปลองค์ประกอบเป็นภาษาเชิงคำสั่ง ตามคำกล่าวของพวกเขา สิ่งนี้ดีกว่าแนวทางเชิงประกาศของ React
• การใช้งานนั้นง่าย แต่คอมโพเนนต์ที่เกิดจากการแปลแบบคำสั่งกลับไม่ได้คาดเดาได้ง่ายอย่างที่เห็น และในบางกรณีก็ไม่สามารถตรวจจับการเปลี่ยนแปลงได้อย่างถูกต้อง ในกรณีนี้ state อาจเสียหายและทำให้ view ไม่อัปเดตอย่างถูกต้อง ปัญหานี้ก่อให้เกิดความกังวลมากมาย จนทำให้ยากจะหาเหตุผลรองรับโครงการใด ๆ ของ SvelteJS เช่นเดียวกับ VueJS ในอดีต

StencilJS:

• พูดอย่างเคร่งครัดแล้วมันไม่ใช่เฟรมเวิร์ก เป็นเครื่องมือสำหรับเขียนคอมโพเนนต์และแปลงไปเป็นเฟรมเวิร์กอื่นได้ ปัจจุบันสามารถแปลงเป็น Angular, React, Vue และ Web Components ได้
• ตั้งคำถามว่า โค้ดที่ได้มีลักษณะเหมือนโค้ดของเฟรมเวิร์กอื่นหรือไม่? (ดูต้นฉบับ)

Mitosis:

• คุณอาจไม่เคยได้ยินชื่อมาก่อน แต่นี่คือเหตุผลที่ทำให้ผู้เขียนบทความนี้ขึ้นมา มันคือเฟรมเวิร์กล่าสุดที่สร้างโดย Misko Hevery ผู้สร้าง Angular
• มีเป้าหมายแบบเดียวกับ StencilJS คือแปลคอมโพเนนต์ไปเป็นเฟรมเวิร์กจำนวนมาก
• เช่นเดียวกัน มันตั้งคำถามว่า โค้ดที่ได้มีลักษณะเหมือนโค้ดของเฟรมเวิร์กอื่นหรือไม่? (ดูต้นฉบับ)

React:

• เป็นหนึ่งในเฟรมเวิร์กที่เก่าแก่ที่สุดซึ่งอยู่ในคลัง npm มานานกว่า 10 ปี มันเปลี่ยนไปมาก แต่ส่วนใหญ่ยังเข้ากันได้กับเวอร์ชันเก่า การเปลี่ยนแปลงทั้งหมดทำให้มันดีขึ้น บางคนถึงกับบอกว่า hooks ทำให้ React กลายเป็นเฟรมเวิร์กที่ดีกว่ามาก
• คุณภาพที่ดีที่สุดไม่ได้อยู่ที่ hooks หรือความสามารถที่มองเห็นได้ แต่อยู่ในสิ่งตรงกันข้าม React นำมาตรฐาน JS สมัยใหม่และ JSX มาใช้ จนมันไม่ใช่เฟรมเวิร์กอีกต่อไป หรืออาจไม่เคยเป็นเลย React พยายามอย่างหนักกับมาตรฐานจนลบตัวเองออกจากโค้ดของผู้ใช้

ดังนั้นผู้ชนะคือ...

• JSX มันคือ React ด้วย แต่ก็เป็นปรัชญาที่อยู่เบื้องหลัง React ตัว React เองเป็นไลบรารี และยังแทนที่ได้ด้วยไลบรารีอื่นมากมาย เช่น Preact หรือ React Native หากมองให้ดี StencilJS หรือ Mitosis ก็คล้ายกับ React มาก และนี่ไม่ใช่เรื่องบังเอิญ
• "เฟรมเวิร์กที่ดีที่สุดคือเฟรมเวิร์กที่ลบตัวเองออกจากโค้ดของผู้ใช้"
• React ใช้ JS และ JSX อย่างมาก โค้ดของผู้ใช้จึงไม่ผูกกับ React และโค้ดเดียวกันก็สามารถทำงานกับเฟรมเวิร์กอื่นได้โดยแทบไม่ต้องแก้ไขมาก
• ดังนั้น React คือผู้ชนะของสงครามเฟรมเวิร์กอย่างไม่ต้องสงสัย
• เพราะมันไม่ใช่เฟรมเวิร์กภายในโค้ดของผู้ใช้นั่นเอง

[piriri11]

สิ่งสำคัญคือถ้าเราเขียนโค้ดโดยพยายามทำตามคำพูดของลุงบ๊อบที่ว่า "อย่าแต่งงานกับเฟรมเวิร์ก" ให้มากที่สุด ไม่ว่าจะเป็น React, Vue หรือ Angular ก็น่าจะพัฒนาได้อย่างสนุกไม่ใช่หรือครับ

[polygon]

มุมมองต่ออนาคตของ marko js เป็นอย่างไรบ้าง?
พอดีเห็นว่า eBay เป็นผู้สนับสนุน เลยเริ่มสนใจขึ้นมาช่วงนี้ แต่ในต้นฉบับกลับไม่มีการพูดถึงเลยแม้แต่น้อย...

[minhoryang]

React ที่ว่า "เปลี่ยนไปมาก แต่ส่วนใหญ่ยังเข้ากันได้กับเวอร์ชันเก่า" - ผมแทบไม่ได้สัมผัสประสบการณ์ความเข้ากันได้นี้เลย
Angular ที่ว่า "การแตกย่อยและการอัปเกรดเวอร์ชัน" - แต่ในส่วนนี้ผมกลับมีประสบการณ์ที่ราบรื่นอยู่บ่อย ๆ

[roxie]

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

[xguru]

ขอบคุณสำหรับสรุปและคอมเมนต์ดี ๆ นะครับ~! คิดว่าเรื่องพวกนี้น่าจะช่วยคนอื่น ๆ ได้มากเลย ;)

[plastic041]

โดยรวมแล้วผมรู้สึกว่าเป็นบทความที่แปลก ๆ

ก่อนอื่นคือส่วนของ Svelte
พอไปดูต้นฉบับ เขาเขียนไว้ว่าตอนอัปเดตอาร์เรย์ ถ้าเขียนแบบ array[0] += 1 แล้วมันจะไม่อัปเดต เลยเป็นปัญหา แต่ในเอกสารทางการของ Svelte ก็เขียนอยู่ว่าอาร์เรย์ต้องถูกกำหนดค่าใหม่ถึงจะอัปเดตได้ และแต่เดิมใน React เองก็อัปเดตอาร์เรย์ด้วยวิธีแบบนี้ไม่ได้อยู่แล้วไม่ใช่เหรอ?

ส่วนของ VueJS ก็เหมือนกัน
กำลังพูดถึงข้อเสียของ Vue โดยเทียบกับ Angular แต่กลับเอาโค้ด Angular ที่ทำงานได้มาเทียบกับโค้ด Vue ที่ทำงานไม่ได้ แล้วก็บอกว่า Vue ไม่ค่อยดี แบบนั้นมันมีความหมายอะไรผมไม่เข้าใจครับ

[pppqqq]

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

โดยเฉพาะ vue ใช้วิธีอัปเดตสถานะเมื่อมีการ set ผ่าน proxy ซึ่งดูเผิน ๆ เหมือนจะเข้าใจง่าย แต่ก็มีช่องให้พลาดได้เยอะมาก ผมเองก็เห็นด้วยอย่างยิ่งกับการวิจารณ์ในจุดนั้น

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

[tequila]

ขอเสริมประเด็นนิดหน่อยนะครับ ใน Vue 3 รองรับการอัปเดตอาร์เรย์ในลักษณะแบบนั้นแบบ reactive อยู่แล้ว แต่ผมรู้สึกว่าบทความนี้กลับไปโจมตีแค่ Vue เวอร์ชันเก่าแบบหนัก ๆ แล้วก็ผ่านไปอย่างคร่าว ๆ ...^^;; ทั้งที่ใน React เองการอัปเดตแบบนี้ทำไม่ได้ก็ไม่ใช่ข้อเสียเล็ก ๆ เลย แต่กลับเหมือนว่าไม่ได้ชี้ให้เห็นคุณสมบัตินั้นอย่างเหมาะสมเท่าไรนะครับ ฮ่าๆ

[tenshi]

ต้นฉบับก็มีคอมเมนต์จำนวนมากเช่นกัน และดูเหมือนว่าจะมีคอมเมนต์จำนวนมากที่ชี้ให้เห็นปัญหาหลายอย่าง

[riddler]

ฉันสับสนกับส่วน โค้ดนี้คล้ายกับโค้ดของเฟรมเวิร์กอื่นหรือเปล่า? ที่มีคำอธิบายกำกับไว้สำหรับ StencilJS กับ Mitosis เลยไปดูต้นฉบับมา ดูเหมือนว่าผู้เขียนกำลังถามว่าโค้ดที่ใช้ในสองเฟรมเวิร์กนั้น ดูเหมือนโค้ดที่เคยเห็นในเฟรมเวิร์กอื่นบ้างไหมใช่ไหมครับ

น่าจะเขียนขึ้นมาในความหมายว่ามีรูปแบบการเขียนโค้ดคล้ายกับ React ครับ

[jjpark78]

ดูจะประเมิน VueJS แบบเข้มงวดเกินไปหน่อยนะ..

เรื่องการพึ่งพา redux นั้น react เองก็คงไม่ได้เป็นอิสระจากมันอย่างสิ้นเชิงหรอก..

ถ้าวัดกันที่ขนาดฐานผู้ใช้ react ครองอันดับ 1 แบบทิ้งห่างก็จริง

แต่ในแง่เทคนิค จะเรียกว่าเป็นโปรเจกต์ที่ด้อยกว่า react ก็คงไม่ได้หรอก

[cckn1985]

ประเด็นที่พูดถึง VueJs เป็นหลักตรงนี้ ไม่ใช่เรื่องการพึ่งพาไลบรารีภายนอกมากกว่า แต่เป็นเรื่อง "ท่าทีที่โยนความรับผิดชอบให้ JS ต่อปัญหาที่ตัวเองก่อขึ้น" ไม่ใช่หรือ?

ผมคิดว่าเป็นความจริงที่กระแสความเห็นต่อ vueJS ไม่ค่อยดีนัก

ถ้าเข้าไปอ่านในเนื้อหาหลัก จะเห็นว่าส่วนที่กล่าวถึงการพึ่งพา Vuex, Redux ก็เป็นประเด็นที่ว่า เพื่อแก้ปัญหาที่เกิดขึ้นใน VueJS 2 นั้น ไลบรารีอย่าง Vuex, Redux ถือเป็นสิ่ง 'จำเป็น' น่ะครับ

[jjpark78]

เหมือนจะเป็นสิ่งที่มีคอมเมนต์ไว้หลายอันแล้วในต้นฉบับเหมือนกัน

ถ้าความซับซ้อนเพิ่มขึ้น ไม่ว่าจะเป็น Vue หรือ React ไลบรารีเก็บสถานะ/แคชอย่าง redux ก็จะกลายเป็นสิ่งที่ "จำเป็น" ทั้งหมด

จริงด้วย ต้นฉบับชี้ว่านี่เป็นข้อเสียของ VueJS แต่กลับ "จงใจ" ไม่พูดถึง React เลยนะ

สำหรับผม พฤติกรรมของคอมมูนิตี้ไม่ได้สำคัญอะไรนัก..

[road4one]

ใน React นั้น redux ไม่ได้เป็นสิ่งจำเป็น เพราะสามารถใช้ contextAPI หรือ useReducer เพื่อจัดการสถานะได้ ผมก็ไม่ได้คิดว่านี่เป็นเหตุผลที่ใช้บอกได้ว่า React ดีกว่า Vue แต่อย่างใด

[cckn1985]

ใช่ครับ ฮ่าๆ โดยรวมแล้วดูเหมือนจะไม่ใช่บทความที่ดีนัก

ผู้เขียนเหมือนตั้งข้อสรุปเอาไว้ก่อน แล้วก็พยายามกดเฟรมเวิร์กอื่น ๆ เพื่อให้ไปถึงข้อสรุปนั้น