- คำวิจารณ์ส่วนใหญ่ว่า "PHP แย่ (PHP Sucks)" เกิดจากการที่ไม่ได้มอง PHP หลังปี 2012
- หลัง PHP 5.4 มีการเปลี่ยนแปลงมากมาย และจำเป็นต้องมองดูความเปลี่ยนแปลงของภาษาหลังจากนั้น
การเปลี่ยนแปลงสำคัญตั้งแต่ PHP 5.4
- Traits (PHP 5.4)
- ช่วยให้ใช้ composition แทน inheritance ได้
- สามารถมี traits ที่ใส่ลงในทุกคลาสได้
- ไวยากรณ์อาร์เรย์แบบย่อ
- ใช้วงเล็บเหลี่ยมได้โดยไม่ต้องใช้
array()
- การแยกโครงสร้างอาร์เรย์
- กำหนดค่าให้ตัวแปรได้โดยตรงโดยไม่ต้องกำหนดอาร์เรย์ลงตัวแปรชั่วคราวก่อน
- ฟังก์ชัน varargs ชั้นหนึ่ง
- ใช้ไวยากรณ์
... เพื่อส่งอาร์กิวเมนต์ให้ฟังก์ชันได้ตามต้องการ
- Generators
- ทำงานที่ใช้หน่วยความจำหนักได้อย่างมีประสิทธิภาพด้านหน่วยความจำมากขึ้น
- Anonymous classes
- สร้างคลาสใหม่ได้โดยไม่ต้องสร้างไฟล์ใหม่
- สามารถ implement interface ได้เหมือนคลาสอื่น ๆ
การเปลี่ยนแปลงสำคัญตั้งแต่ PHP 7
- จุลภาคต่อท้าย
- ไม่จำเป็นต้องกังวลกับการเพิ่มจุลภาคต่อท้ายใน function call หรือ method call
- Arrow functions
- แม้จะต่างจาก JavaScript เล็กน้อย แต่ก็เป็นสิ่งที่เพิ่มเข้ามาได้ดี
- ตัวดำเนินการรวมค่า null
- ไม่ต้องเช็ก null ก่อนกำหนดค่า
- ตัวดำเนินการกำหนดค่าแบบรวมค่า null (PHP 7.4)
- มีตัวดำเนินการกำหนดค่าแบบย่อสำหรับตัวดำเนินการรวมค่า null ด้วย
- Weak maps (PHP 7.4)
- ใช้หน่วยความจำได้ดีกว่าอาร์เรย์มาก
- ใช้อ็อบเจ็กต์เป็นคีย์ได้
การเปลี่ยนแปลงหลัง PHP 8
- ตัวดำเนินการลูกโซ่ null
- ไม่ต้องเช็ก null ก่อนเรียกเมธอด
- Named arguments
- ไม่ต้องใช้ null เพื่อข้ามอาร์กิวเมนต์แบบเลือกได้
- Attributes (annotations)
- ใช้เพิ่ม annotation ให้กับคลาส เมธอด อาร์กิวเมนต์ หรือพร็อพเพอร์ตีได้
- การจัดการข้อผิดพลาดที่ดีขึ้น
- ไม่ต้องมีตัวแปรข้อยกเว้นเพื่อคืนค่า false
- คำสั่ง Match
- วิธีที่กระชับและอ่านง่ายกว่าสำหรับแทน switch ที่ยาว
- Enums (PHP 8.1)
- สร้างคลาส enum ที่มีทั้งค่าและเมธอดได้
- ใช้เป็น type hint ได้ด้วย
- ความปลอดภัยด้านชนิดข้อมูล
- มีอาร์กิวเมนต์แบบระบุชนิด, return type, union type, intersection type เป็นต้น
- ใช้ type hint กับ enum ได้เช่นกัน
- Constructor property promotion (PHP 8.0)
- ถึงเวลาบอกลาคอนสตรักเตอร์ที่ยืดยาว
- ช่วยลด boilerplate code
- Readonly properties (PHP 8.1)
- สามารถประกาศคีย์เวิร์ดเพื่อระบุให้พร็อพเพอร์ตีเป็นแบบอ่านอย่างเดียวได้
ประสิทธิภาพ
- ประสิทธิภาพดีขึ้น 400% เมื่อขยับจาก PHP 5.6 ไปเป็น 7
- ประสิทธิภาพดีขึ้น 20% เมื่อขยับจาก PHP 7 ไปเป็น 8
- ให้ประสิทธิภาพเพียงพอสำหรับงานพัฒนาเว็บส่วนใหญ่ และหากเป็นงานเฉพาะทางกว่านี้ก็ควรเลือกใช้ภาษาที่เหมาะทางกว่า
สรุป
- PHP ไม่ได้ตาย และไม่ได้แย่ที่สุดอีกต่อไป ภาษาเปลี่ยนไปมากหลังปี 2012 และถึงเวลาปรับมุมมองต่อมันได้แล้ว
- ด้วยการเพิ่มฟีเจอร์ต่าง ๆ เช่น traits, ไวยากรณ์อาร์เรย์แบบย่อ, การแยกโครงสร้างอาร์เรย์ ทำให้ PHP กลายเป็นภาษาที่มีประสิทธิภาพ อ่านง่าย และดูแลรักษาง่ายขึ้น
- เมื่อรวมกับการจัดการข้อผิดพลาดที่ดีขึ้น การมาของ attributes และ enums ที่รอกันมานาน ก็ยิ่งชัดเจนว่า PHP พัฒนาเป็นตัวเลือกที่แข็งแรงและเชื่อถือได้สำหรับการพัฒนาเว็บ
- ดังนั้นถ้าใครบอกว่า PHP แย่ที่สุด ก็พูดได้อย่างมั่นใจว่าพวกเขายังติดอยู่กับอดีตเท่านั้น
ความเห็นของ GN⁺
- เมื่อดูการเปลี่ยนแปลงของภาษา PHP จะเห็นได้ว่าไม่ใช่ PHP แบบในอดีตอีกต่อไป แต่ดูเหมือนนักพัฒนาจำนวนมากยังคงติดอยู่กับภาพจำเก่า ๆ
- มีการเพิ่มฟีเจอร์จำนวนมากที่ทำให้โค้ดกระชับและอ่านง่ายขึ้น เช่น trait, ไวยากรณ์ short array, และ destructuring assignment ซึ่งน่าจะช่วยให้การบำรุงรักษาดีขึ้นด้วย
- ฟีเจอร์อย่าง generator และ weak map ที่ช่วยเพิ่มประสิทธิภาพด้านหน่วยความจำก็น่าสนใจเช่นกัน น่าจะมีประโยชน์เมื่อต้องจัดการข้อมูลขนาดใหญ่
- ยังมีการเปลี่ยนแปลงที่ช่วยยกระดับความสมบูรณ์ของภาษา เช่น enum และการปรับปรุงความปลอดภัยด้านชนิดข้อมูล ซึ่งน่าจะทำให้การเขียนคลีนโค้ดทำได้ง่ายขึ้น
- ที่สำคัญที่สุดคือการปรับปรุงประสิทธิภาพใน PHP 8 ที่น่าประทับใจ โดยระบุว่าผล benchmark จริงแสดงประสิทธิภาพใกล้เคียงกับ NodeJS และ Go
- แต่การทำให้โปรเจกต์ PHP แบบ legacy ทันสมัยขึ้นก็ไม่ใช่งานง่าย การย้ายโค้ดอาจต้องใช้ทรัพยากรมาก
- PHP ยังคงเป็นภาษาฐานของโอเพนซอร์สจำนวนมาก เช่น WordPress จึงคงยากที่จะลดทอนคุณค่าของ PHP เพียงจากคุณลักษณะของภาษาอย่างเดียว
40 ความคิดเห็น
คอมเมนต์พวกนี้ทำให้เห็นได้ชัดเลยว่าทำไม php ถึงยังห่วยอยู่
ยินดีด้วยที่มันกลายเป็นอึที่ไม่เหม็นแล้ว
ถ้ามีโอกาสก็ลองกินอย่างอื่นแทนอึดูบ้างนะ : )
มีความคิดเห็นเข้ามาเยอะมากเลยนะครับ ผมไม่ใช่นักพัฒนา PHP ครับ ดูเหมือนว่ากระแสเกลียดชัง PHP ที่ถูกปลุกปั่นในชุมชนจะทำให้นักพัฒนารุ่นจูเนียร์เกิดความรู้สึกแบบนั้น และวงจรแย่ ๆ ก็เลยเกิดซ้ำไปเรื่อย ๆ ช่างฝีมือย่อมไม่โทษเครื่องมือเด็ดขาด ขอเป็นกำลังใจให้นักพัฒนา PHP ทุกคนเสมอครับ
ในฐานะคนพัฒนา php.. ความหยิ่งผยองของคนที่ใช้ภาษาอื่นนี่ถึงขั้นทำเอาอยากด่าเลย
ไม่เข้าใจจริงๆ ว่าทำไมถึงต้องชอบเหยียดภาษาที่คนอื่นใช้นัก
ผมเองก็พัฒนา php แล้วก็เคยย้ายไปลอง Java, ลอง Python, แล้วก็ลอง nodejs เหมือนกัน..
แต่ละภาษาต่างก็มีแนวคิดหรือความไม่สะดวกที่ชวนไม่เข้าใจในแบบของมันเอง แล้วทำไมมีแต่ php ที่โดนด่าไม่เลิกก็ไม่เข้าใจ..
แม่งเป็นอะไรวะ—
สถานการณ์ที่ถูกเรียกว่าเป็นบั๊กของ php พอเอาเข้าจริงเวลาเขียนงานจริง
ต่อให้ไม่รู้ก็แทบไม่ค่อยได้ใช้ไวยากรณ์หรือโครงสร้างพวกนั้นอยู่แล้ว
แล้วพวก legacy แบบนั้น ภาษาอื่นก็มีอยู่ในระดับหนึ่งเหมือนกันหมด
เอือมระอาสุดๆ
ผมขออภัยที่ได้พูดถึงเทคโนโลยีที่คุณยึดเป็นอาชีพ ไม่ว่าเจตนาของผมจะเป็นอย่างไร แต่ผลลัพธ์คือทำให้คุณ koxel รู้สึกไม่ดี และนั่นเป็นความรับผิดชอบของผม
อย่างไรก็ตาม ผมแค่เขียนถึงสิ่งที่ผมรู้สึกหลังจากคลุกคลีในฐานะจูเนียร์ท่ามกลางนักพัฒนา PHP ที่คิดว่ามีแค่การเขียนโค้ดแบบลุย ๆ เท่านั้น นักพัฒนา PHP บางคนถึงขั้นไม่ยอมรับและปฏิเสธแม้กระทั่งการเปลี่ยนแปลงของ best practices ตรงนั้นทำให้ผมอึดอัดใจ ตอนนี้โดยสถานการณ์ผมทำงานในสายฟรอนต์เอนด์เป็นหลัก แต่ผมก็คิดว่าวิธีการพัฒนา JavaScript เองก็มีจุดให้วิจารณ์ได้มากมายเหมือนกัน ผมไม่ได้คิดว่าภาษาไหนมีความเหนือกว่าแบบสัมบูรณ์ และคิดว่าควรใช้เกณฑ์ที่ต่างกันไปตามสถานการณ์
พอมองดูแล้ว เหมือนว่าปัญหาคือโครงสร้างที่เปิดทางให้นักพัฒนามือใหม่เขียนโปรแกรมผิดๆ ได้
แต่เรื่องแบบนั้นภาษาอื่นก็เหมือนกันหมดไม่ใช่หรือ
ที่แต่ละภาษามีสิ่งที่เรียกว่า best practice ก็เพราะเหตุผลนั้นแหละ..
สำหรับ WordPress สัดส่วนการใช้งาน PHP เวอร์ชัน 5.6 หรือต่ำกว่านั้นอยู่ที่ไม่ถึง 5%
https://wordpress.org/about/stats/
ถึงอย่างนั้นในปี 2023 WordPress ก็ได้ยกระดับข้อกำหนดขั้นต่ำของการติดตั้ง PHP เป็น 7.0
โดยส่วนตัวแล้ว ระดับความไม่ชอบ PHP ของผมแทบจะพอๆ กับระดับความไม่ชอบ Javascript เลยนะครับ
ถ้าเทียบกับสองตัวนี้แล้ว Python ยังดูเหมือนนางฟ้าไปเลย
ผมเริ่มต้นเส้นทางอาชีพด้วย php และเหมือนจะพีคในสายอาชีพได้ก็เพราะ php เช่นกัน
ตอนนี้หาเลี้ยงชีพด้วยภาษาอื่นแล้ว แต่
โปรเจ็กต์ข้าง ๆ หรือทำเล่นเป็นงานอดิเรก บางทีก็ยังหยิบ php ออกมาใช้อยู่
มันก็ยังเป็นเพื่อนที่มีเสน่ห์เหมือนกัน
แน่นอนว่าช่วงนี้มีทางเลือกอื่น ๆ ออกมาเยอะ เลยแอบเสียดายนิดหน่อย แต่
laravel vapor ก็โอเคครับ
ตอนนี้ผมไม่ได้ทำเว็บดีเวลอปเมนต์อยู่แล้ว แต่ก็ทำให้นึกถึงความหลังขึ้นมาได้
ดูเหมือนหลายคนจะไม่ชอบ PHP กันนะครับ ผมเองก็เคยใช้ PHP อยู่ราว ๆ 3 ปี และคิดมาตลอดว่าในฐานะภาษาแล้วมันมีเสน่ห์น้อยมาก และพอได้รู้จัก RoR ก็เลยเข้าใจได้ว่าเหตุใดถึงหลงใหลในความสง่างามของภาษาอย่าง Ruby ได้มากขนาดนั้น ซึ่งจะมองว่า PHP เป็นตัวที่ทำให้เกิดความรู้สึกนั้นขึ้นมาก็คงได้
แต่ตอนที่ PHP ออกมาใหม่ ๆ มันยอดมากจริง ๆ! ตอนนั้นยังเป็นยุคที่เขียนบอร์ดด้วย CGI กันอยู่เลย ความคล่องตัวที่ PHP มอบให้ในเวลานั้นถือว่าเป็นอะไรที่สร้างความฮือฮามาก และคงเป็นเรื่องจริงที่ PHP ได้เปิดขอบฟ้าใหม่ครั้งใหญ่ให้กับการพัฒนาเว็บ :)
แต่เหล้าใหม่ก็ต้องใส่ขวดใหม่...
แม้ว่า PHP ในฐานะภาษายังคงเป็นภาษาที่แย่ที่สุดอยู่ดี
แต่ผมคิดว่า PHP ในฐานะแพลตฟอร์ม (หาคำที่เหมาะกว่านี้ยากเหมือนกัน) กลับโอเคกว่าที่คิดครับ
โดยเฉพาะสำหรับโปรเจกต์ช่วง MVP จนถึงช่วงเริ่มเติบโต ถ้ากำหนดกันไว้ตั้งแต่แรกแล้วว่าสุดท้ายจะย้ายไปภาษา/แพลตฟอร์ม/เฟรมเวิร์กอื่นในภายหลังอยู่แล้ว (โดยมากก็คือ Spring)
หลังจากนั้น ข้อบกพร่องของตัวภาษาก็ไม่ใช่ประเด็นสำคัญอีกต่อไป และสิ่งที่เห็นชัดก็จะเหลือแต่ข้อดีของ PHP
เพราะสามารถดีพลอยได้โดยแทบไม่ต้องหยุดระบบ แค่แก้ไฟล์ก็พอ จึงสะท้อนฟีดแบ็กจากผู้ใช้ได้เร็วกว่า
และการจัดการคิวคำขอแบบประหยัดทรัพยากรที่ PHP(-FPM) ทำได้โดดเด่นกว่าสิ่งอื่น ๆ ก็ช่วยให้รับมือกับทราฟฟิกจำนวนมากแบบไม่คาดคิด (การเติบโตอย่างรวดเร็วในช่วงสั้น ๆ) ได้ดี
ถึงจะมีบั๊ก แอปทั้งตัวก็ไม่ล่ม และค่อนข้างเป็นอิสระจากปัญหา memory leak ในระดับหนึ่ง ทำให้โฟกัสกับ business logic+a ได้
แม้แต่นักพัฒนาที่ไม่เคยใช้ PHP มาก่อนและใช้ภาษาอื่นเป็นหลัก ถ้าใช้เวลาดูสักอาทิตย์หนึ่งก็พอจะใช้งานได้ในระดับหนึ่ง เพราะเรียนรู้ได้ไม่ยาก...
ทั้งหมดนี้พอระบบใหญ่ขึ้นก็อาจย้อนกลับมาเป็นข้อเสียได้ (และอาจจะร้ายแรงด้วย)...
แต่อย่างน้อยในระดับ MVP ในสถานการณ์ที่ต้องรับฟีดแบ็กจากผู้ใช้แล้วรีบปรับใช้ และต้องโตให้เร็ว จะมีตัวเลือกไหนที่เหมาะเท่า PHP ไหม?
ยิ่งไปกว่านั้น ตอนตัดสินใจใช้ PHP ก็คิดไว้แล้วด้วยว่า "ถ้าระบบใหญ่ขึ้นจะย้ายไปภาษาอื่น" ดังนั้นถ้าจะพูดกันแบบจริงจัง... Why not?
ผมคิดต่างอยู่นิดหน่อยว่า ถ้าจะสร้าง MVP คนเดียวได้ จำเป็นต้องมีเครื่องมือที่ทำทั้ง DB schema, WAS และ UI ได้ด้วยการเขียนโค้ดให้น้อยที่สุด และผมคิดว่านอกจาก PHP แล้ว ก็ยังมีตัวเลือกที่ยอดเยี่ยมอย่าง Ruby on Rails และ Django
ในกรณีของ Django ถ้าแค่นิยาม model class ด้วย Active Record pattern (เป็นคำที่เก่ามากจริง ๆ นะครับ) ก็จะได้ทั้ง DB schema และ CRUD UI สำหรับ back office ที่พอใช้งานได้ออกมา มีเครื่องมือพื้นฐานสำหรับการพัฒนาเว็บเซอร์วิสให้ครบ ทั้งการยืนยันตัวตน, การควบคุมสิทธิ์การเข้าถึง, การตรวจสอบฟอร์ม, เครื่องมือ DB migration, เครื่องมือทดสอบ ฯลฯ สำหรับผมแล้ว ตั้งแต่เริ่มเขียนเว็บโปรแกรมมิงช่วงปลายยุค 2000 มาก็ยังไม่เคยเจออะไรที่ให้ผลิตภาพเท่า Django อีกเลย หลังจากแนวทางแบบ SPA ได้รับความนิยมและสายงานฝั่ง frontend กับ backend ถูกแยกออกจากกัน กลับรู้สึกด้วยซ้ำว่าผลิตภาพลดลง เพราะอย่างน้อยต้องมีคนทำงานสองคนที่เข้าใจ user flow และต้องทำงานโดยตกลงโปรโตคอลกันไว้ก่อน จึงจะทำงานแบบขนานกันได้
ถ้า PHP อยากวางตัวเป็นภาษาเทมเพลตสำหรับเว็บแอป ผมคิดว่าในระดับภาษามันก็ควรมีวิธีป้องกันช่องโหว่เว็บมาให้ด้วย และการที่สไตล์ PHP สมัยใหม่หันไปรับแนวทางการพัฒนาแบบเฟรมเวิร์ก ก็อาจมองได้ว่าเป็นหลักฐานของเรื่องนั้นครับ
และ PHP ก็ประกาศตัวว่าเป็นภาษาสคริปต์อเนกประสงค์มานานแล้ว
ผมไม่เข้าใจว่าทำไมถึงเอาภาษากับเฟรมเวิร์กมาเปรียบเทียบกัน
มี Laravel ที่มีคอนเซ็ปต์แบบ Ruby on Rails และ Django อยู่นี่ครับ
ผมคิดว่าเมื่อ modern PHP ไม่ได้เป็น "modern" อีกต่อไปแต่กลายเป็นแนวทางการพัฒนามาตรฐานของ PHP และเมื่อ CMS ต่างๆ รวมถึง WordPress นำ modern PHP มาใช้ ผู้คนก็จะมองว่า PHP เป็นภาษาทั่วไปที่ปลอดภัย การกู้คืนความเชื่อมั่นนั้นโดยทั่วไปต้องใช้ความพยายามมากกว่าการทำลายความเชื่อมั่น
เป็นเพราะภายใต้ข้ออ้างเรื่องการคงความเข้ากันได้แบบย้อนหลัง จึงปล่อยให้ผู้เริ่มต้นสามารถสร้างเว็บเซอร์วิสที่ไม่ปลอดภัยได้โดยอาศัยเพียงฟังก์ชันพื้นฐานของ PHP ในบรรดา 5 อันดับแรกของเว็บไซต์ที่ค้นหาด้วยคำว่า PHP tutorial นั้น นอกจาก เว็บไซต์ทางการของ PHP แล้ว ก็ไม่มีตัวอย่างไหนที่ระบุว่าเวลานำค่าจากตัวแปรซูเปอร์โกลบอล (superglobal) มาแสดงผล ต้องทำ HTML escape เพื่อป้องกัน XSS เลย เมื่อไกด์ที่พวกเขาจัดทำอย่างเป็นทางการมีเนื้อหาเกี่ยวกับการพัฒนาเว็บอยู่ด้วย แบบนี้จะมองว่า PHP ทำหน้าที่ทั้งสองอย่าง คือเป็นทั้งภาษาและเฟรมเวิร์ก ไม่ได้หรือ?
คุณคิดอย่างไรกับการที่ องค์ประกอบหลายอย่างของ HTTP ถูกเตรียมไว้ให้เป็นค่าพื้นฐาน ในนามของตัวแปรซูเปอร์โกลบอล? ผมคิดว่าขอบเขตของความเป็นภาษาทั่วไปและกรณีการใช้งานนั้นถูกกำหนดโดยเนื้อหาที่ภาษานั้นแสดงออกมา
ตัวอย่างที่ยกมาอย่าง
$_GET,$_POSTซึ่งเป็นตัวแปร superglobal นั้น เป็นค่าที่ถูกเปิดเผยเมื่อใช้งาน PHP ในโหมด CGI, SAPI ถ้าใช้ PHP แบบ CLI ค่าดังกล่าวจะไม่ถูกเปิดเผยตัวแปร superglobal เหล่านั้นเป็น API ชนิดหนึ่งที่เปิดเผยโดย PHP-CGI, PHP-FPM ฯลฯ ซึ่งเป็นรันไทม์ที่ใช้รัน PHP ไม่ใช่สเปกของ PHP ในฐานะภาษา
ส่วนที่กล่าวถึงก่อนหน้านี้ว่า "PHP ที่ชูตัวเองเป็น template language" ถ้าจะพูดกันอย่างเคร่งครัด ก็ไม่ใช่ PHP แต่เป็น CGI ซึ่งเป็นหนึ่งในรันไทม์ของ PHP ที่ต้องการให้ถูกใช้งานในลักษณะนั้น
เช่นเดียวกัน ฟังก์ชัน built-in ของ PHP จำนวนมากที่ถูกพูดถึงว่าเป็นช่องโหว่ ก็เป็นฟังก์ชันที่ถูกเปิดเผยโดย extension ของ PHP ไม่ใช่ความสามารถที่ตัว "ภาษา" PHP มีอยู่เอง
ถ้าตามที่คุณพูด
JavaScript ก็จะกลายเป็นทั้งภาษาและเฟรมเวิร์กที่ถูกออกแบบมาเพื่อใช้ API ที่เบราว์เซอร์เปิดเผยไว้สำหรับสื่อสารกับเบราว์เซอร์มาตั้งแต่แรก
Java เองแม้จะเป็นภาษา แต่ในทางปฏิบัติก็จะกลายเป็นเฟรมเวิร์กที่ถูกใช้เพื่ออาศัย API จำนวนมากของ JDK
และภาษาอื่น ๆ ทั้งหมดก็คงต้องถูกมองว่าเป็นเฟรมเวิร์กทั้งหมด เพียงเพราะมี standard library หรือ API ให้ใช้งาน โดยไม่เกี่ยวกับสเปกของภาษานั้นเอง
แน่นอนว่ามันเป็นความสัมพันธ์ที่แยกจากกันได้ยาก แต่จะหยิบประเด็นเหล่านี้มาบอกว่า PHP เป็นเฟรมเวิร์กนั้น ยังขาดน้ำหนักอย่างมากครับ
และเมื่อดูจากข้อเท็จจริงที่ว่าแม้กระทั่ง ณ เดือนพฤษภาคม 2024 ก็ยังมีการแพตช์ XSS ใน โปรเจ็กต์ WordPress Core อยู่ ดูเหมือนว่าการปรับปรุงในระดับไวยากรณ์ของ PHP เพียงอย่างเดียวจะไม่สามารถป้องกัน XSS ได้อย่างสมบูรณ์
เฟรมเวิร์กฝั่งฟรอนต์เอนด์และเทมเพลตเอนจินฝั่งเซิร์ฟเวอร์จะใช้การทำ HTML escape กับทุกเนื้อหาที่สามารถเรนเดอร์จากข้อมูลได้โดยอัตโนมัติ และจะสร้างเอาต์พุตแบบที่ไม่ปลอดภัยก็ต่อเมื่อมีการสั่งปิดการ escape อย่างชัดเจนเท่านั้น ใน PHP ไม่มีวิธีที่เป็นที่ยอมรับร่วมกันซึ่งสามารถบังคับใช้การจัดการลักษณะนี้ได้แบบครอบคลุมทั้งหมด หากคำสั่ง
echoหรือprintรองรับการ escape เป็นค่าเริ่มต้น แม้ในระยะสั้นจะมีโค้ดจำนวนมากที่ใช้งานไม่ได้ทันที แต่ในระยะยาวก็น่าจะช่วยลดความผิดพลาดจากการที่หลายคนลืมใส่ escape ได้มากขึ้นใช่ ผมไม่เห็นด้วยกับมุมมองที่แยกภาษาและสภาพแวดล้อมรันไทม์ออกจากกัน และคิดว่าไม่ว่าทางใดทางหนึ่ง สภาพแวดล้อมรันไทม์ย่อมส่งผลต่อภาษาด้วย สำหรับ JavaScript มีสภาพแวดล้อมรันไทม์อยู่สองแบบคือ Node.js และเบราว์เซอร์ ส่วน Python แม้จะมี implementation อยู่หลายตัว แต่เข้าใจได้ว่า CPython เป็นตัวที่มีอิทธิพลเหนือกว่า
ประเด็นของบทความต้นฉบับจำกัดอยู่ที่การปรับปรุงด้านไวยากรณ์ แต่ผมอยากพูดถึงเรื่องที่กว้างกว่ากรอบแบบนี้เล็กน้อย
> อีกทั้งผมคิดว่า Laravel เป็นสิ่งที่ควรจะออกมาเป็นฟีเจอร์อย่างเป็นทางการของภาษา ไม่ใช่เป็นโปรเจกต์แยกโดยผู้มีส่วนร่วมโอเพนซอร์ส แต่ควรเกิดขึ้นโดย Rasmus หรือบริษัทอย่าง Zend ตั้งแต่ราวปี 2007 ไม่ใช่ปี 2011 ด้วยซ้ำ แม้ Python 3 จะมีอุปสรรคในการนำไปใช้เพราะยอมทิ้งความเข้ากันได้ย้อนหลังบางส่วน แต่ผมก็คิดว่า PHP เองก็ควรจัดระเบียบความเข้ากันได้ย้อนหลังครั้งใหญ่ตั้งแต่ช่วงเวอร์ชัน 5 เหมือนกัน ดูเหมือนการเปลี่ยนแปลงของ PHP จะช้ากว่ากระแสของยุคสมัยอยู่เสมอ
ขอถือโอกาสตอบคอมเมนต์ข้างต้นไปด้วยครับ
ถ้ามองจากมุมที่คุณพูดมา ก็พอจะคิดได้ว่าอาจมอง PHP เป็นเว็บเฟรมเวิร์กชนิดหนึ่งได้เหมือนกัน
แต่ถึงอย่างนั้น ผมก็ไม่ได้คิดว่าฟีเจอร์ต่าง ๆ อย่างตัวกรอง XSS, escape และอื่น ๆ ที่ยกตัวอย่างมานั้น PHP จำเป็นต้องมีให้โดยพื้นฐาน
PHP-FPM ที่ใช้กันแพร่หลายที่สุด กับ Django และ RoR ไม่ได้อยู่ในตำแหน่งเดียวกันครับ
มันใกล้กับ Flask, Sinatra, Express มากกว่า
PHP-FPM ไม่ได้ทำหน้าที่เกินไปกว่าการทำ routing (อิงตามไดเรกทอรี), การตีความคำขอ (
$_GET,$_POST,$_FILE,$_COOKIE), การส่ง response (echo,print), และการจัดการ session ($_SESSION)แล้ว Flask ต่างออกไปไหม?
ถ้าจะให้ Flask ส่ง response ที่มีการ escape HTML แล้ว ก็ไม่ได้จบแค่
returnเฉย ๆhttps://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping
แล้ว Sinatra ต่างออกไปไหม?
ก็เหมือนกัน ต้องใช้ไลบรารีสำหรับ escape แยกต่างหาก
https://sinatrarb.com/faq.html#escape_html
แล้ว Express ต่างออกไปไหม?
อันนี้ก็เหมือนกัน ต้องใช้ไลบรารีสำหรับ escape แยกต่างหาก
https://expressjs.com/en/resources/middleware.html
ไลบรารีที่ยกมาเป็นตัวอย่างทั้งหมด ก็ไม่ใช่ไลบรารีที่เฟรมเวิร์กนั้น ๆ ให้มาอย่างเป็นทางการ
แล้วทำไม PHP ถึงจำเป็นต้องเป็น PHP ที่ต้องมีฟังก์ชันแบบนั้นให้อย่างเป็นทางการด้วยล่ะ?
ถ้าจะบอกว่า PHP ห่วยด้วยเหตุผลที่คนจำนวนมากพูดกันอยู่แล้ว เช่น
"มีเฟรมเวิร์กบ้าอะไรเอาข้อมูลคำขอมาเปิดเป็น superglobal กันตรง ๆ แบบนี้ ต่อให้ไม่มีปัญหาด้านความปลอดภัย นี่ก็ไม่ให้เกียรติผู้ใช้อยู่ดี!"
แบบนั้นผมยังพอเข้าใจได้
แต่เหตุผลที่คุณยกว่า "ฟังก์ชันพื้นฐานของ PHP ยังไม่เพียงพอเท่ากับที่ฟูลสแตกเฟรมเวิร์กมีให้" นั้น... อย่างน้อยสำหรับผมแล้วค่อนข้างเห็นด้วยได้ยาก
เหมือนกับที่มี Nestjs ถูกสร้างขึ้นมาเพื่อให้ใช้ Express ได้อย่างโมเดิร์นและเป็นระบบมากขึ้น ผมก็คิดว่า Laravel ถูกสร้างขึ้นมาเพื่อให้ใช้ PHP ได้อย่างโมเดิร์นและเป็นระบบมากขึ้นเหมือนกัน...
ถ้าอย่างนั้น เมื่อเทียบกับจุดด้อยที่มักถูกเปรียบเทียบกับเฟรมเวิร์ก(หรือภาษา) อื่น ๆ ข้อดีเฉพาะตัวของ PHP(-FPM) แบบที่ผมพูดไว้ในคอมเมนต์ต้นทาง มันไม่ได้ชัดเจนกว่าหรือครับ?
พอลองทบทวนความทรงจำดู อย่างน้อยถ้าชุดผสม
slimกับtwigถูกใช้อย่างแพร่หลายกว่านั้น ก็น่าจะช่วยลดความผิดพลาดเกี่ยวกับ PHP ที่เคยเจอในโปรเจกต์ได้บ้าง แน่นอนว่าในตอนนั้นนักพัฒนา PHP คนอื่น ๆ คุ้นเคยกับการเขียน PHP แบบดิบ ๆ อยู่แล้ว เลยไม่สามารถนำมาใช้ได้ โชคดีที่PDOอยู่ในไลบรารีมาตรฐาน จึงพอรับมือกับ SQL injection ได้สำหรับเรื่องการจำกัดผลกระทบของบั๊กหรือประสิทธิภาพการประมวลผลที่คุณพูดถึงในคอมเมนต์ต้นทาง ผมไม่ได้มีความเห็นชัดเจนว่าจะเห็นด้วยหรือคัดค้าน คิดว่าเป็นความสามารถที่มีก็ดี แต่ปัญหาอย่างปริมาณงานที่พุ่งสูงขึ้นหรือการใช้หน่วยความจำ ก็มักเป็นเรื่องที่ต้องคิดอย่างน้อยสักครั้งในช่วงที่ระบบกำลังเติบโตอยู่แล้ว เลยคิดว่าถ้าปัญหาแบบนั้นแสดงออกมาอย่างชัดเจนได้เร็วที่สุดเท่าที่จะเป็นไปได้ก็น่าจะดีกว่า
> แน่นอนว่าในตอนนั้นเอาเข้ามาใช้ไม่ได้ เพราะนักพัฒนา PHP คนอื่น ๆ คุ้นชินกับการเขียน PHP แบบดิบ ๆ อยู่แล้ว
> เพราะสิ่งที่กินเวลานานที่สุดและยากที่สุดคือการเปลี่ยนคนที่เขียนพัฒนาเป็นด้วย PHP
ส่วนตัวผมมองว่าตัว PHP เองไม่ได้มีปัญหา หรือมีวิธีรับมือได้เพียงพอ หรือไม่ก็เป็นเพียงความแตกต่างที่เกิดขึ้นจากเหตุผลที่พอเข้าใจได้เหมือนภาษาอื่น ๆ แต่ปัญหาเรื่องบุคลากรที่คุณพูดถึง... อันนี้น่าจะเป็นปัญหาใหญ่ที่สุดจริง ๆ ครับ
นักพัฒนาที่สามารถใช้ PHP ได้อย่างจริงจังนั้น ส่วนใหญ่คงเข็ดกับ PHP ยุคเก่าไปนานแล้ว และหนีออกจาก PHP กันไปตั้งนานแล้ว
ผู้ใช้ส่วนใหญ่ที่ยังเหลืออยู่ก็เป็นคนที่ไม่ว่าจะพัฒนา PHP ไปแค่ไหนก็ไม่ยอมมองมันอย่างจริงจัง หรือไม่ก็ไม่มีศักยภาพพอจะมองมันอย่างจริงจัง
ในโปรเจ็กต์แนว MVP+a ที่คิดว่า PHP เหมาะสม คนมีประสบการณ์แบบกลุ่มแรกก็ไม่มีเหตุผลให้เข้ามาร่วม
ต่อให้เข้าร่วมจริง ๆ ก็อาจไม่เลือก PHP หรือถึงเลือก PHP พอมีผู้ใช้แบบกลุ่มหลังปะปนมาสักหนึ่งสองคน ทุกอย่างก็คงเละเทะ... 555
อย่างน้อยในเกาหลีก็ไม่ง่ายเลยที่จะหาคนที่สามารถพัฒนา PHP ได้ในระดับน่าพอใจ
แล้ว PHP ก็ถูกตัดออกจากตัวเลือกอีก ทำให้ระดับเฉลี่ยของกำลังคนยิ่งต่ำลงไปอีก และวนซ้ำแบบไม่รู้จบจนกลายเป็นวงจรอุบาทว์
~~ต่อให้ต้องขายฝันแบบนี้ต่อไป อย่างน้อยในโปรเจ็กต์เล็ก ๆ ขนาด 1~3 คนก็ตาม~~ ผมคิดว่าต้องมีกรณีที่พยายามทำโปรเจ็กต์ PHP แบบจริงจังให้มากขึ้น วงจรอุบาทว์นี้ถึงจะถูกตัดได้
แม้แต่ตัวผมเองจริง ๆ แล้วรายได้ที่ PHP สร้างให้ก็ไม่ได้มากนัก เพราะการหาคนที่รับเข้ามาแล้วพอใจได้มันยากเกินไป จนในความเป็นจริงก็แทบจะเอา PHP ไปเป็นเมนสแตกไม่ได้...
นั่นเป็นเพราะมีความแตกต่างระหว่างภาษาอเนกประสงค์กับ PHP ในวิธีการสร้างหน้า HTML ขึ้นมา Flask อย่างน้อยก็ตั้งแต่เปิดตัวเวอร์ชัน 1.0 ก็ได้สนับสนุนให้ผู้คนใช้เทมเพลตเอนจิน และถูกออกแบบมาให้พึ่งพาเทมเพลตเอนจิน โดยตั้งใจแยกข้อมูลฝั่งเซิร์ฟเวอร์ออกจากหน้า HTML และรองรับการทำงานในระดับเทมเพลตมาโดยตลอด ผมคิดว่ามีการคำนึงถึงลักษณะของปัญหาที่ต้องการแก้และพฤติกรรมการใช้งานของผู้คน
ในทางกลับกัน สำหรับ PHP เอาต์พุตมาตรฐานก็คือส่วนหนึ่งของหน้าเพจทันที และเส้นแบ่งระหว่างข้อมูลฝั่งเซิร์ฟเวอร์กับหน้า HTML ก็ไม่ชัดเจน การ
printจะถูกใส่ลงในหน้าผลลัพธ์ตรงๆ และนักพัฒนาต้องทำการ escape เองอย่างชัดเจน แนวคิดที่ว่าต้องใส่ฟังก์ชันhtmlcharacterescapesให้กับข้อมูลภายนอกทั้งหมดนั้นไม่ได้รับการยอมรับจากผู้คนมากนัก ผู้คนต้องการเทมเพลตโดยสัญชาตญาณ แต่ PHP ดูเหมือนจะไม่ได้คำนึงถึงเป้าหมายของผู้ใช้ที่ต้องการสร้างหน้า HTMLเหตุผลที่ฟังก์ชันนั้นควรอยู่ในไลบรารีมาตรฐานหรือกระทั่งในตัวภาษาเอง ก็เพราะเมื่อพิจารณาสภาพแวดล้อมการตั้งค่าของ PHP และวิธีการดีพลอยโค้ดแล้ว นั่นเป็นวิธีที่มีประสิทธิภาพที่สุด สภาพแวดล้อมการพัฒนาถูกทำให้เป็นมาตรฐานด้วย LAMP stack และสภาพแวดล้อมการใช้งานจริงก็เป็นรูปแบบเว็บโฮสติ้ง ผู้คนคุ้นเคยกับการโยนไฟล์ขึ้นผ่าน FTP ดังนั้นความเป็นไปได้ในการจัดหาแพ็กเกจเพิ่มเติมจึงต่ำกว่าภาษาอเนกประสงค์ อีกทั้งก็ไม่สามารถคาดหวังให้ผู้เริ่มต้นต้องติดตั้งโมดูลได้ ทางเลือกที่เหลือจึงมีเพียงไลบรารีมาตรฐานและเอกสารมาตรฐานเท่านั้น
> ผู้คนต้องการเทมเพลตโดยไม่รู้ตัว แต่ดูเหมือนว่า PHP จะไม่ได้คำนึงถึงเป้าหมายของผู้ใช้ที่ต้องการสร้างหน้า HTML
ผมคิดว่าเนื้อหานี้ไม่น่าเห็นด้วยอย่างมากนัก
จะบอกได้ว่าในยุค PHP3 ซึ่งเป็นเพียงระดับที่เปิดเผย C API ผ่าน CGI ได้อย่างง่ายดายตามที่คุณพูดนั้น ถูกใช้ในฐานะเครื่องมือทำเทมเพลต...
ตั้งแต่ PHP 4.2 เป็นต้นมา สภาพแวดล้อมก็ถูกสร้างขึ้นมาในระดับที่สามารถใช้งานแบบ general-purpose ได้อย่างเพียงพอแล้ว
มันกลายเป็นสภาพแวดล้อมที่คาดหวังได้ว่าโค้ดจะถูกรันผ่าน CLI และอย่างที่คุณกล่าวไว้ในคอมเมนต์ก่อนหน้านี้ว่า "Laravel ควรจะออกมาตั้งแต่ราวปี 2007 ในฐานะฟีเจอร์ทางการของภาษา ไม่ใช่โปรเจกต์แยก" นั้น เป็นคำพูดที่ไม่สอดคล้องกับทิศทางของ PHP ในเวลานั้นเลย
การมีอยู่ของ Smarty ซึ่งเป็น template engine สำหรับ PHP ที่เปิดตัวในปี 2004 และ CodeIgniter ซึ่งเป็น MVC framework สำหรับ PHP ที่เปิดตัวในปี 2006 เป็นหลักฐานโต้แย้งว่า PHP เองไม่ใช่ภาษาเทมเพลต และยังพอจะมองได้ว่าในสังคม PHP ตอนนั้นได้ก่อตัวเป็นฉันทามติแล้วว่าจะไม่ใช้งานมันในลักษณะนั้น
> ทั้ง frontend framework และ server-side template engine จะใช้ HTML escaping กับทุกอย่างที่สามารถ render จากข้อมูลได้แบบครอบคลุม และจะสร้าง output ที่ไม่ปลอดภัยก็ต่อเมื่อมีการปิดการ escape อย่างชัดเจนเท่านั้น
ผมคิดว่าเนื้อหาส่วนนี้จากคอมเมนต์ก่อนหน้าก็ไม่ใช่เรื่องที่ถูกต้องนักเช่นกัน เมื่อเทียบกับไทม์ไลน์ของ PHP
ตั้งแต่ django เปิดตัวครั้งแรกในปี 2005 และต่อมาอีกหลายปี HTML escaping ไม่ได้เป็นค่าเริ่มต้น นักพัฒนาต้องตั้งค่า escape filter ด้วยตัวเองโดยตั้งใจ ส่วน jinja ที่ยังถูกใช้อยู่ใน Python จนถึงทุกวันนี้ ก็ยังไม่ได้จัดการ HTML escaping แบบอัตโนมัติ
ในช่วงที่การ escape อัตโนมัติเริ่มถูกมองว่าเป็นเรื่องปกติ PHP ก็หลุดพ้นจากอัตลักษณ์ความเป็นภาษาเทมเพลตไปนานแล้ว (แม้ว่าผู้ใช้ที่ใช้ PHP แบบไม่คิดอะไรมากในตอนนั้นอาจจะไม่ได้ต้องการสิ่งนั้นก็ตาม แต่ถ้ามองอีกแบบ ก็อาจพูดได้ว่า PHP ได้ตัดสินใจไปแล้วว่าจะค่อยๆ กันผู้ใช้ลักษณะนั้นออกไป)
เพราะ PHP ไม่ใช่ภาษาสำหรับจุดประสงค์แบบนั้นอีกต่อไปแล้ว จึงไม่มีเหตุผลเลยที่ PHP จะต้องใช้ฟังก์ชันลักษณะนั้นเป็นค่าเริ่มต้นใน standard library และตัวภาษาเอง และหากมองจากจุดยืนของ PHP ที่ต้องการทำงานในฐานะภาษา general-purpose ก็ถือว่าฟังก์ชัน htmlcharacterescapes ที่คุณกล่าวถึงได้ทำหน้าที่ของมันเพียงพอแล้ว
> สภาพแวดล้อมการรันถูกทำให้เป็นมาตรฐานในรูปแบบเว็บโฮสติ้ง และเพราะคุ้นชินกับวิธีโยนไฟล์ขึ้นไปผ่าน FTP จึงมีความเป็นไปได้น้อยกว่าภาษา general-purpose ในการจัดหาแพ็กเกจเพิ่มเติม
ผมก็เห็นด้วยกับข้อความข้างต้นได้ยากมากเช่นกัน ตั้งแต่ก่อนหน้านี้นานกว่าสิบปีแล้ว ก็มีการใช้ git และอื่นๆ ได้ดีมากอยู่แล้ว แม้แต่หลังจาก Docker เปิดตัวได้ไม่นาน ก็มีการลองใช้ Docker สำหรับ deployment กันมากพอสมควร และทุกวันนี้ก็ยังใช้อยู่แบบนั้น
ผมคิดว่าเนื้อหาส่วนใหญ่ที่คุณพูดถึง น่าจะมีความหมายก็ตอนเล่นอยู่บน CMS ที่พัฒนาด้วย PHP มากกว่าจะเกี่ยวกับ PHP เอง
ผมไม่ค่อยชอบสำนวนแบบนี้เท่าไร แต่ก็คงเป็นเคสประเภทที่แม้แต่คนทำ PHP ด้วยกันเองก็ยังไม่ค่อยนับว่าเป็นนักพัฒนา...
ฟังก์ชัน auto escaping ของ jinja ทำให้ข้อโต้แย้งของผมไม่ถูกต้อง และสิ่งที่คุณพูดมาก็ถูกต้องครับ
> ผมเองก็เห็นด้วยกับข้างต้นได้ยากมากเหมือนกัน ก่อนหน้านั้นตั้งแต่สิบกว่าปีก่อนก็มีการใช้งาน git ฯลฯ ได้ดีมากอยู่แล้ว แม้แต่ทันทีหลังจาก Docker ถูกเผยแพร่ ก็มีการลองใช้ Docker สำหรับการ deploy กันมากพอสมควร และตอนนี้ก็ยังใช้งานกันแบบนั้นอยู่
ประสบการณ์ PHP ของผมหยุดอยู่ที่ปี 2014 และตอนนั้นยังไม่มี Docker ครับ ส่วน git ก็ไม่สามารถนำมาใช้ได้ เพราะต้องเปลี่ยนวิธีการทำงานด้วย การจะนำของแบบนั้นมาใช้ในสภาพแวดล้อมการทำงานจริงต้องมีฉันทามติร่วมกัน แต่ในสถานการณ์ของผมตอนนั้นมันเป็นไปไม่ได้ครับ
> ถึงจะไม่ชอบสำนวนแบบนี้เท่าไร แต่ก็เป็นเคสประเภทที่แม้แต่นักพัฒนา PHP เองก็ยังไม่ได้รับการปฏิบัติในฐานะนักพัฒนา...
พอมองย้อนกลับไป เหมือนว่าผมจะทำงานอยู่ท่ามกลางคนที่ไม่ได้รับการปฏิบัติในฐานะนักพัฒนาครับ
ตัวอย่างที่คุณยกมาอย่างการยืนยันตัวตน การควบคุมสิทธิ์ การตรวจสอบฟอร์ม เครื่องมือ migration ฐานข้อมูล และเครื่องมือทดสอบของ Django นั้น Laravel ของ PHP ก็มีให้ทั้งหมดเช่นกัน
การยืนยันตัวตน: https://laravel.com/docs/11.x/authentication
การควบคุมสิทธิ์: https://laravel.com/docs/11.x/authorization
การตรวจสอบฟอร์ม: https://laravel.com/docs/11.x/validation
DB migration: https://laravel.com/docs/11.x/migrations
การทดสอบ: https://laravel.com/docs/11.x/testing
และยังมีไลบรารีภายนอกหรือไลบรารีแบบเสียเงิน
ที่สามารถ export DB schema เดิมออกมาเป็น model และโค้ด migration หรือทำย้อนกลับในทางกลับกันก็ได้ด้วย
รวมถึงยังมี https://nova.laravel.com/ ที่มอบ back office ที่เรียบร้อยพร้อม CRUD UI อีกด้วย
ฟีเจอร์แทบทั้งหมดที่ Django มีนั้น Laravel ก็มีเช่นกัน
(ตั้งแต่แรกทั้งคู่ก็สืบทอดแนวคิดมาจาก RoR อยู่แล้ว จึงมองว่าฟีเจอร์ที่มีให้ย่อมคล้ายกันเป็นธรรมดา)
ถึงอย่างนั้น Laravel-PHP ก็ยังมีข้อดีเพิ่มเติมจากที่ผมพูดถึงในคอมเมนต์ต้นฉบับ ต่างจาก Django-Python ด้วย
ปฏิเสธไม่ได้ว่า PHP เป็นภาษาที่ถูกออกแบบมาโดยชูจุดขายว่าเป็นภาษาเทมเพลตสำหรับเว็บแอป
แต่ในยุคที่สไตล์ PHP แบบโมเดิร์นได้ลงหลักปักฐานมาจวนจะครบสิบปีแล้ว ผมคิดว่าการมองมันเป็นแค่ภาษาเทมเพลตอย่างเดียวน่าจะใจร้ายเกินไปหน่อย
ผมลองดูเพราะมีการลิงก์ Nova ไว้ แต่ตัวนี้ก็เป็นไลเซนส์แบบเสียเงินเหมือนกันนะครับ ถึงฟังก์ชันอาจจะคล้ายกับ Django Admin ที่ระบุไว้ชัดเจนในโปรเจกต์ทิวทอเรียลและใช้งานได้ทันที แต่ในแง่การเข้าถึงดูเหมือนจะมีความแตกต่างกันอยู่
นอกจากนี้ ผมคิดว่าสิ่งนี้ใน Laravel ควรจะไม่ได้ออกมาโดยผู้มีส่วนร่วมโอเพนซอร์ส แต่ควรเป็นฟีเจอร์ทางการของภาษาที่ออกมาตั้งแต่ราวปี 2007 ไม่ใช่ปี 2011 โดยบริษัทอย่าง Rasmus หรือ Zend มากกว่า ไม่ใช่ในรูปแบบโปรเจกต์แยกต่างหาก ถึง Python 3 จะมีปัญหาในการนำมาใช้เพราะยอมทิ้งความเข้ากันได้ย้อนหลังบางส่วนไป แต่ผมก็คิดว่า PHP เองก็ควรจะจัดระเบียบความเข้ากันได้ย้อนหลังครั้งใหญ่ตั้งแต่ช่วงเวอร์ชัน 5 แล้ว การเปลี่ยนแปลงของ PHP ดูเหมือนจะช้ากว่ากระแสของยุคสมัยอยู่เสมอ
ตอนนี้โดยส่วนตัวแล้วผมไม่ได้อยู่ในจุดที่กำลังเริ่มต้นเรียนรู้การพัฒนาเว็บอีกต่อไป จึงคงไม่มีเหตุผลที่จะเลือก PHP
คุณกำลังสับสนระหว่างภาษาและเฟรมเวิร์กอยู่เรื่อยเลยนะ
ผมคิดว่าไม่จำเป็นต้องคอมเมนต์เนื้อหาเดียวกันไว้หลายที่นะครับ คุณอยากเรียกร้องความสนใจหรือเปล่า?
แน่นอนว่ามันก็ดีขึ้นกว่าเมื่อก่อน แต่ในตอนนี้ถ้าจะใช้ PHP ก็รู้สึกว่าการใช้ Node.js หรือ Python น่าจะมีที่ให้ใช้งานได้หลากหลายกว่ามาก
ยุคเฟื่องฟูของ PHP กำลังมา
ไม่มีการกล่าวถึงเลยว่าตลอด 10 ปีที่ผ่านมา ecosystem ของ PHP, วิธีการ deploy, execution model, และวิธีการ debug ดีขึ้นมากแค่ไหน และเพราะการเปลี่ยนคนที่พัฒนาเป็น PHP ให้รู้วิธีพัฒนาอย่างถูกต้องนั้นใช้เวลานานที่สุดและยากที่สุด ผมจึงแทบไม่คาดหวังเลยว่ามันจะดีขึ้น โดยเฉพาะโพสต์ที่ลิงก์ไว้นั้นเป็นบล็อกเพื่อการตลาดของฟรีแลนซ์ PHP จึงน่าจะต้องรับฟังอย่างคัดกรองเป็นพิเศษ
ในช่วง 10 ปีที่ผ่านมา หากดูจากสถิติการใช้งาน PHP บนฐานของแพ็กเกจ Composer (การแจกจ่ายแบบเดียวกับ npm ของ Node) จะเห็นว่า PHP 5 หรือต่ำกว่านั้นแทบสูญพันธุ์ไปหมดแล้ว และอีโคซิสเต็มของ PHP ก็ย้ายมาอยู่รอบ Composer มานานมากแล้ว
CMS บางตัวอย่าง WordPress, GnuBoard เป็นต้น แยกออกไปคนละทางโดยสิ้นเชิง
อีโคซิสเต็มที่ไม่นับรวม CMS ก็เป็นสถานการณ์ตามที่กล่าวไว้ข้างต้น
ในมุมของคนที่ใช้ PHP อยู่ PHP ก็ยังคงเป็นภาษาที่แย่ที่สุดอยู่ดี
เพราะภาษาอื่นพัฒนาขึ้นไปมากกว่านี้แล้ว
ความคิดเห็นจาก Hacker News
สรุป:
fopen()ได้PHP: ไม่ได้เป็นแฟรกทัลของการออกแบบที่ย่ำแย่อีกต่อไปแล้ว
เอกสารเมื่อ 12 ปีก่อน 555
ยังอ้างอิงเอกสารที่เขียนตั้งแต่ปี 2012 อยู่อีก....
คิดว่า php จะยังคงอยู่แบบเดิมจากยุคนั้นโดยไม่มีพัฒนาการเลยงั้นเหรอ..?
อ้อ แน่นอนว่า จะปฏิเสธไม่ได้เหมือนกันว่าเป็นภาษาที่เริ่มต้นมาแบบไร้รากฐานจริง ๆ ฮ่า
นี่คือลิงก์ฉบับแปลของเอกสารภาษาอังกฤษที่กล่าวถึง..
ต่อให้ PHP แย่แค่ไหน ก็คงไม่ถึงกับยังคงปัญหาแบบในยุคนั้นเอาไว้หรอกนะ
ต่อให้ยังคงดูแลรักษาอยู่ก็ยังเป็นปัญหาอยู่ดีครับ ตั้งแต่ระดับการออกแบบประมาณนี้ก็ผิดพลาดมาตั้งแต่ต้นแล้ว แต่จะบอกว่าอัปเกรดเวอร์ชันแล้วคุณภาพดีขึ้นงั้นเหรอ? นั่นก็เป็นปัญหาเพราะทำลายความเข้ากันได้ย้อนหลังอย่างรุนแรง แม้แต่ตัวดำเนินการเปรียบเทียบก็ยังประหลาด แล้วจะให้ทำยังไงล่ะครับ
ดูเหมือนว่าแค่นำฉบับแปลภาษาเกาหลีของลิงก์ที่ 4 ในสรุป Hacker News มาให้เฉยๆ ครับ ฮ่าๆ