- Phần lớn những lời chỉ trích kiểu "PHP Sucks" là vì họ chưa nhìn vào PHP sau năm 2012
- Kể từ PHP 5.4 đã có rất nhiều thay đổi, và cần xem lại những thay đổi của ngôn ngữ kể từ đó
Những thay đổi chính kể từ PHP 5.4
- Traits (PHP 5.4)
- Giúp có thể dùng composition thay cho kế thừa
- Có thể có các trait được đưa vào mọi class
- Cú pháp mảng rút gọn
- Có thể dùng dấu ngoặc vuông mà không cần viết
array()
- Phân rã cấu trúc mảng
- Có thể gán trực tiếp vào biến mà không cần gán mảng vào biến tạm trước
- Hàm variadic hạng nhất
- Có thể truyền số lượng đối số tùy ý vào hàm bằng cú pháp
...
- Generator
- Cho phép xử lý các tác vụ ngốn bộ nhớ theo cách hiệu quả hơn về bộ nhớ
- Anonymous class
- Có thể tạo class mới mà không cần tạo file mới
- Cũng có thể triển khai interface như các class khác
Những thay đổi chính kể từ PHP 7
- Dấu phẩy cuối
- Không còn phải bận tâm về việc thêm dấu phẩy cuối trong lời gọi hàm hay phương thức
- Arrow function
- Dù hơi khác JavaScript một chút, đây vẫn là một bổ sung tốt cho ngôn ngữ
- Toán tử null coalescing
- Không cần kiểm tra null trước khi gán giá trị
- Toán tử gán null coalescing (PHP 7.4)
- Cũng có toán tử gán rút gọn cho null coalescing
- WeakMap (PHP 7.4)
- Tốt hơn nhiều về bộ nhớ so với mảng
- Có thể dùng object làm key
Những thay đổi từ PHP 8 trở đi
- Toán tử null-safe chain
- Không cần kiểm tra null trước khi gọi phương thức
- Named arguments
- Không cần dùng null để bỏ qua các đối số tùy chọn
- Attributes (annotation)
- Có thể dùng để thêm annotation vào class, method, đối số hoặc thuộc tính
- Cải thiện xử lý lỗi
- Không cần các biến ngoại lệ chỉ để trả về false
- Câu lệnh match
- Cách ngắn gọn và dễ đọc hơn để thay cho các câu lệnh switch dài dòng
- Enum (PHP 8.1)
- Có thể tạo enum class có giá trị và method
- Cũng có thể dùng làm type hint
- An toàn kiểu dữ liệu
- Có đối số được định kiểu, kiểu trả về, union type, intersection type, v.v.
- Cũng có thể dùng type hint cho enum
- Constructor property promotion (PHP 8.0)
- Chấm dứt các constructor dài dòng
- Giúp giảm mã boilerplate
- Readonly property (PHP 8.1)
- Có thể khai báo từ khóa để đánh dấu thuộc tính là chỉ đọc
Hiệu năng
- Tăng hiệu năng 400% khi chuyển từ PHP 5.6 lên 7
- Tăng hiệu năng 20% khi chuyển từ PHP 7 lên 8
- Cung cấp hiệu năng đủ dùng cho hầu hết nhu cầu phát triển web; nếu cần các trường hợp chuyên biệt hơn thì nên dùng ngôn ngữ chuyên dụng
Kết luận
- PHP chưa chết, và cũng không còn là thứ tệ nhất nữa. Kể từ sau năm 2012, ngôn ngữ này đã thay đổi đáng kể, và đã đến lúc cần cập nhật lại quan điểm về nó.
- Với việc đưa vào nhiều tính năng như traits, cú pháp mảng rút gọn, phân rã cấu trúc mảng, PHP đã trở thành một ngôn ngữ hiệu quả hơn, dễ đọc hơn và dễ bảo trì hơn.
- Cộng thêm các cải tiến về xử lý lỗi, việc đưa vào attributes, và sự xuất hiện đã được chờ đợi từ lâu của enum, có thể thấy rõ PHP đã phát triển thành một lựa chọn vững chắc và đáng tin cậy cho phát triển web.
- Vì vậy, nếu ai đó nói PHP là thứ tệ nhất, bạn hoàn toàn có thể tự tin nói rằng họ chỉ đang mắc kẹt trong quá khứ.
Ý kiến của GN⁺
- Nhìn vào những thay đổi về mặt ngôn ngữ của PHP, có thể thấy đây không còn là PHP của quá khứ nữa. Tuy vậy, dường như nhiều lập trình viên vẫn đang mắc kẹt trong nhận thức cũ.
- Nhiều tính năng giúp mã ngắn gọn và dễ đọc hơn như trait, cú pháp short array, phân rã cấu trúc cũng đã được bổ sung. Điều này có vẻ sẽ góp phần cải thiện khả năng bảo trì.
- Các tính năng cải thiện hiệu quả bộ nhớ như generator hay WeakMap cũng rất đáng chú ý. Chúng có vẻ sẽ hữu ích khi xử lý dữ liệu quy mô lớn.
- Những thay đổi như enum hay cải thiện an toàn kiểu dữ liệu cũng giúp tăng độ hoàn thiện của ngôn ngữ. Việc viết clean code được kỳ vọng sẽ dễ dàng hơn.
- Trên hết, cải thiện hiệu năng ở PHP 8 là rất ấn tượng. Theo đó, kết quả benchmark thực tế được cho là cho thấy hiệu năng sánh ngang NodeJS và Go.
- Tuy nhiên, hiện đại hóa các dự án PHP legacy vẫn không phải là việc dễ. Việc migrate code có thể tiêu tốn nhiều nguồn lực.
- PHP vẫn là ngôn ngữ nền tảng của rất nhiều hệ sinh thái mã nguồn mở như WordPress. Chỉ nhìn vào đặc tính ngôn ngữ để hạ thấp giá trị của PHP thì có lẽ là không hợp lý.
40 bình luận
Đúng là những bình luận cho thấy rất rõ vì sao php đến giờ vẫn còn tệ.
Xin chúc mừng vì nó đã trở thành một đống phân không còn bốc mùi.
Nếu có cơ hội, mong các bạn thử ăn thứ khác thay vì phân : )
Có rất nhiều ý kiến được đăng lên nhỉ. Tôi không phải là lập trình viên PHP. Có vẻ như khi thấy làn sóng ghét PHP do cộng đồng thổi bùng, các bạn junior cũng nảy sinh cảm xúc như vậy và vòng luẩn quẩn cứ lặp lại. Người thợ giỏi tuyệt đối không bao giờ đổ lỗi cho công cụ. Luôn cổ vũ các lập trình viên PHP!
Là một lập trình viên PHP... sự ngạo mạn của những người dùng ngôn ngữ khác thật sự khiến tôi muốn chửi thề.
Không hiểu nổi sao họ cứ nhất quyết phải dìm ngôn ngữ người khác đang dùng.
Tôi cũng từng làm PHP rồi chuyển sang Java, thử cả Python lẫn Node.js...
Mỗi ngôn ngữ đều có triết lý khó hiểu hoặc điểm bất tiện riêng, vậy mà không hiểu sao chỉ mỗi PHP là bị chửi không ngừng..
Địt mẹ, rốt cuộc sao lại thế chứ...
Những tình huống bị gọi là bug của PHP, khi thực sự phát triển thì
đa phần là những cú pháp hoặc cấu trúc hầu như chẳng ai dùng, kể cả không biết cũng gần như không đụng tới
mấy thứ legacy kiểu đó thì ngôn ngữ nào cũng có ở mức độ nào đó thôi.
Thật sự phát ngán rồi
Tôi xin lỗi vì đã bàn luận về công nghệ mà bạn đang theo đuổi như một nghề. Dù không phải chủ ý của tôi, nhưng kết quả là tôi đã làm koxel cảm thấy khó chịu, và đó là trách nhiệm của tôi.
Tuy vậy, tôi chỉ viết ra những điều mình cảm nhận được khi từng lăn lộn ở vị trí junior giữa những lập trình viên PHP nghĩ rằng viết code kiểu tay ngang là tất cả. Một số lập trình viên PHP thậm chí không thừa nhận, và còn từ chối, việc ngay cả best practice cũng thay đổi. Điều đó khiến tôi bức bối. Hiện tại, do hoàn cảnh, tôi chủ yếu làm việc trong ngành frontend, nhưng tôi cũng nghĩ rằng vẫn có không ít điểm có thể phê phán về cách phát triển JavaScript. Tôi không cho rằng có ngôn ngữ nào nắm ưu thế tuyệt đối, mà cho rằng tùy tình huống sẽ cần áp dụng những tiêu chí khác nhau.
Nghĩ kỹ thì vấn đề là cấu trúc cho phép lập trình viên mới vào nghề viết ra chương trình sai.
Nhưng chuyện đó chẳng phải ngôn ngữ nào khác cũng vậy sao.
Lý do mỗi ngôn ngữ đều có cái gọi là best practice cũng chính là vì thế mà..
Theo số liệu của WordPress, tỷ lệ sử dụng PHP 5.6 trở xuống là dưới 5%.
https://wordpress.org/about/stats/
Dù vậy, đến năm 2023 WordPress vẫn nâng mức yêu cầu tối thiểu cho bản cài đặt PHP lên 7.0.
Cá nhân tôi ghét PHP gần như ngang với mức ghét Javascript.
So với hai đứa này thì Python còn trông như thiên thần vậy.
Tôi bắt đầu sự nghiệp với php, và có lẽ cũng đạt đến đỉnh cao sự nghiệp nhờ php.
Hiện giờ tôi kiếm sống bằng ngôn ngữ khác, nhưng
thỉnh thoảng tôi vẫn lôi php ra dùng cho side project hay sở thích cá nhân.
Tương tự vậy, có vẻ đây vẫn là một người bạn đầy sức hút.
Dĩ nhiên dạo này có nhiều lựa chọn thay thế xuất hiện nên cũng hơi tiếc một chút, nhưng
laravel vapor ổn đấy
Hiện tại tôi không còn làm web nữa, nhưng điều này gợi lại khá nhiều ký ức xưa.
Có vẻ nhiều người không thích PHP. Tôi cũng đã dùng PHP khoảng 3 năm, và suốt thời gian đó luôn nghĩ rằng đây là một ngôn ngữ thật sự kém hấp dẫn; đến khi tiếp xúc với RoR, tôi lại càng chìm đắm trong sự thanh lịch của ngôn ngữ Ruby, nên cũng có thể nói chính PHP đã khiến tôi cảm nhận điều đó rõ hơn.
Nhưng mà, khi PHP mới xuất hiện thì nó thực sự rất ghê gớm! Hồi đó vẫn là thời người ta viết hay dựng forum bằng CGI. Sự nhanh nhạy mà PHP mang lại khi ấy quả thật là một cơn chấn động. Có lẽ đúng là PHP đã mở ra một chân trời lớn cho phát triển web. :)
Tuy nhiên, rượu mới thì phải đựng trong bình mới...
Dù xét như một ngôn ngữ thì PHP vẫn là ngôn ngữ tệ nhất,
nhưng xét như một nền tảng (khó tìm được cách diễn đạt thật chuẩn) thì tôi nghĩ PHP ổn hơn nhiều so với tưởng tượng.
Đặc biệt ở các dự án từ MVP đến giai đoạn đầu tăng trưởng, nếu ngay từ đầu đã chốt rằng sau này sẽ chuyển sang ngôn ngữ/nền tảng/framework khác (thường là Spring),
thì từ đó trở đi các khiếm khuyết của ngôn ngữ không còn quá quan trọng nữa, và chỉ còn những ưu điểm của PHP đập vào mắt.
Chỉ cần sửa file liên tục mà không cần dừng dịch vụ cũng có thể triển khai, nên có thể phản ánh phản hồi của người dùng nhanh hơn,
việc PHP(-FPM) xử lý hàng đợi request một cách tiết kiệm, hiệu quả hơn hẳn nhiều thứ khác giúp nó chống chịu tốt trước lượng truy cập lớn bất ngờ (tăng trưởng ngắn hạn),
dù có bug thì cũng không làm toàn bộ ứng dụng chết hẳn, lại tương đối ít bị ảnh hưởng bởi memory leak, nên có thể tập trung vào business logic+a,
và ngay cả các lập trình viên dùng ngôn ngữ khác làm ngôn ngữ chính nhưng chưa từng dùng PHP, chỉ cần nhìn vào khoảng một tuần là cũng có thể dùng được kha khá vì độ khó rất thấp...
Tất cả những điều này khi quy mô lớn lên sẽ quay lại thành nhược điểm (thậm chí có thể là nhược điểm nghiêm trọng)...
Nhưng ít nhất ở quy mô MVP, trong tình huống cần nhận phản hồi người dùng, cập nhật thật nhanh, và phải tăng trưởng thật nhanh, liệu có lựa chọn nào phù hợp hơn PHP không?
Thêm nữa, khi quyết định áp dụng PHP thì cũng đã xác định sẵn trong đầu rằng “nếu hệ thống lớn lên thì sẽ chuyển sang ngôn ngữ khác”, nên nghiêm túc mà nói... Why not?
Tôi thì có phần khác quan điểm: nếu muốn một mình tạo ra MVP, tôi nghĩ cần một công cụ có thể triển khai 3 phần là schema DB, WAS và UI với lượng code tối thiểu. Và tôi cho rằng có những lựa chọn rất tốt thay cho PHP là Ruby on Rails và Django.
Với Django, chỉ cần định nghĩa class model theo pattern Active Record (đúng là một thuật ngữ khá cũ nhỉ) thì sẽ có được schema DB và một CRUD UI kiểu back-office tạm ổn để sử dụng. Nó cung cấp các công cụ tối thiểu để phát triển web service như xác thực, kiểm soát truy cập, kiểm tra biểu mẫu, công cụ migration DB, công cụ test, v.v. Cá nhân tôi, kể từ khi bắt đầu lập trình web vào cuối những năm 2000, chưa từng trải nghiệm năng suất nào sánh được với Django. Từ sau khi mô hình SPA trở nên phổ biến và vai trò frontend/backend tách riêng, tôi thậm chí còn có cảm giác năng suất giảm đi. Bởi vì ít nhất phải có hai người cùng hiểu user flow, và chỉ khi đã thống nhất giao thức làm việc thì mới có thể thực hiện công việc song song.
Nếu PHP muốn tự định vị là một ngôn ngữ template cho web app, tôi nghĩ nó lẽ ra phải cung cấp các phương tiện ở cấp độ ngôn ngữ để phòng vệ trước các lỗ hổng web. Việc phong cách PHP hiện đại áp dụng cách phát triển dựa trên framework có lẽ có thể xem là bằng chứng cho điều đó.
Và từ lâu PHP đã không còn tự định vị mình là một ngôn ngữ kịch bản đa dụng nữa.
Tôi không hiểu vì sao bạn lại so sánh ngôn ngữ với framework.
Có Laravel với concept của Ruby on Rails và Django mà.
Khi modern PHP không còn là “modern” nữa mà được xác lập thành phương pháp phát triển tiêu chuẩn của PHP, và khi các CMS bao gồm WordPress áp dụng modern PHP, tôi nghĩ mọi người sẽ nhìn nhận PHP là một ngôn ngữ đa dụng an toàn. Việc khôi phục niềm tin nhìn chung luôn đòi hỏi nhiều nỗ lực hơn là phá vỡ niềm tin.
Lý do là dưới danh nghĩa duy trì khả năng tương thích ngược, nó cho phép người mới chỉ với các chức năng cơ bản của PHP cũng có thể tạo ra các dịch vụ web không an toàn. Trong 5 trang đứng đầu khi tìm kiếm
PHP tutorial, ngoài trang chính thức của PHP thì không có trường hợp nào đề cập rằng khi xuất nội dung của siêu biến toàn cục (superglobal), cần áp dụng HTML escape để phòng chống XSS. Nếu hướng dẫn mà họ chính thức cung cấp lại bao hàm nội dung phát triển web, chẳng phải PHP đang đồng thời đóng cả hai vai trò: ngôn ngữ và framework sao?Mọi người nghĩ sao về việc nhiều thành phần của HTTP được cung cấp sẵn dưới tên các siêu biến toàn cục? Tôi cho rằng phạm vi tính đa dụng và nơi sử dụng sẽ được quyết định bởi những gì mà ngôn ngữ đó biểu đạt.
Ví dụ, các siêu biến toàn cục như
$_GET,$_POSTmà bạn nêu ra là những giá trị được phơi bày khi PHP được sử dụng ở chế độ CGI, SAPI. Khi dùng PHP ở CLI thì các giá trị đó không được phơi bày.Những siêu biến toàn cục đó là một dạng API do PHP-CGI, PHP-FPM v.v. — tức runtime dùng để chạy PHP — phơi bày, chứ không phải là đặc tả của PHP với tư cách một ngôn ngữ.
Điều "PHP tự nhận là ngôn ngữ template" được nhắc đến trước đó cũng vậy; nói một cách chặt chẽ thì không phải PHP, mà là CGI — một trong các runtime của PHP — mong muốn được sử dụng theo cách đó.
Tương tự, rất nhiều hàm dựng sẵn của PHP từng bị xem là lỗ hổng cũng là các hàm do extension của PHP phơi bày, chứ không phải chức năng mà "ngôn ngữ" PHP tự thân có.
Nếu theo cách nói của bạn,
thì JavaScript sẽ trở thành một ngôn ngữ đồng thời là framework, được thiết kế ngay từ đầu để dùng các API mà trình duyệt phơi bày nhằm giao tiếp với trình duyệt,
Java thì là một ngôn ngữ nhưng trên thực tế lại thành framework dùng để tận dụng vô số API của JDK,
và mọi ngôn ngữ khác cũng vậy: bất kể đặc tả của bản thân ngôn ngữ ra sao, hễ cung cấp standard library hay API thì đều phải bị xem là framework cả.
Dĩ nhiên, đúng là chúng có mối quan hệ không thể tách rời, nhưng lấy những điểm này để khẳng định PHP là framework thì sức thuyết phục giảm đi rất nhiều.
Và ngay cả tính đến tháng 5 năm 2024, nhìn vào việc XSS vẫn đang được vá trong dự án WordPress Core, có vẻ như chỉ riêng các cải tiến ở cấp độ cú pháp của PHP là không thể ngăn chặn XSS một cách trọn vẹn.
Các frontend framework, server-side template engine, v.v. đều áp dụng HTML escape một cách đồng bộ cho mọi nội dung có thể được render từ dữ liệu, và chỉ khi chủ đích tắt escape thì mới tạo ra đầu ra theo cách không an toàn. Trong PHP không có một phương pháp đã được đồng thuận để áp dụng kiểu xử lý đó một cách nhất quán. Nếu các câu lệnh
echohoặcprinthỗ trợ escape theo mặc định, thì trước mắt có lẽ sẽ xuất hiện hàng loạt đoạn mã không còn hoạt động, nhưng về lâu dài điều đó có thể đã giúp nhiều người giảm bớt những sai sót do bỏ sót bước escape.Vâng, tôi không đồng ý với góc nhìn tách biệt ngôn ngữ và môi trường thực thi, và tôi cho rằng theo cách này hay cách khác thì môi trường thực thi cũng ảnh hưởng đến ngôn ngữ. Trong trường hợp của JavaScript, có hai môi trường thực thi là Node.js và trình duyệt; còn Python thì có nhiều implementation, nhưng có thể hiểu rằng CPython đang chiếm ưu thế.
Chủ đề của bài gốc chỉ giới hạn ở những cải tiến về mặt cú pháp, nhưng tôi muốn nói đến một phạm vi rộng hơn một chút thay vì khung đó.
> Ngoài ra, tôi nghĩ Laravel là thứ lẽ ra phải xuất hiện như một tính năng chính thức của ngôn ngữ vào khoảng năm 2007 chứ không phải 2011, và do Rasmus hay một công ty như Zend thúc đẩy chứ không phải bởi các cộng tác viên mã nguồn mở, thay vì là một dự án riêng lẻ. Vì Python 3 đã từ bỏ một phần tính tương thích ngược nên việc áp dụng bị chững lại, nhưng tôi cũng nghĩ PHP lẽ ra nên có một đợt dọn dẹp lớn về tương thích ngược vào khoảng phiên bản 5. Có cảm giác những thay đổi của PHP lúc nào cũng chậm hơn dòng chảy của thời đại một nhịp.
Đây cũng là câu trả lời cho bình luận ở trên.
Nhìn từ góc độ bạn nói, đúng là tôi cũng thấy có thể xem PHP như một dạng web framework.
Tuy vậy, tôi không nghĩ PHP bắt buộc phải mặc định cung cấp nhiều chức năng như bộ lọc XSS, escape v.v. mà bạn nêu làm ví dụ.
PHP-FPM phổ biến nhất và Django, RoR không ở cùng một vị trí. Nó gần với Flask, Sinatra, Express hơn.
PHP-FPM không đảm nhiệm nhiều hơn các chức năng như routing (dựa trên thư mục), phân tích request (
$_GET,$_POST,$_FILE,$_COOKIE), gửi response (echo,print), và quản lý session ($_SESSION).Flask thì khác sao?
Trong Flask, nếu muốn trả về response với HTML đã được escape thì không thể chỉ giải quyết bằng
returnđơn thuần.https://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping
Sinatra thì khác sao?
Tương tự, cũng phải dùng một thư viện escape riêng.
https://sinatrarb.com/faq.html#escape_html
Express thì khác sao?
Cái này cũng vậy, phải dùng một thư viện escape riêng.
https://expressjs.com/en/resources/middleware.html
Tất cả các thư viện nêu làm ví dụ đều không phải thư viện được framework đó cung cấp chính thức.
Vậy thì vì sao PHP lại nhất định phải chính thức cung cấp các chức năng như thế ngay trong PHP?
Nếu lập luận rằng PHP là đồ bỏ đi vì những lý do mà đã có rất nhiều người nói đến, kiểu như
"Cái framework quái quỷ nào lại phơi dữ liệu request ra bằng superglobal, cho dù không có vấn đề bảo mật thì đây cũng chẳng tôn trọng người dùng chút nào!"
thì còn hiểu được, nhưng
lý do bạn nêu là "các chức năng cơ bản của PHP không đủ đầy như những gì full-stack framework cung cấp" thì... ít nhất tôi rất khó đồng ý.
Cũng giống như Nestjs được tạo ra để dùng Express theo cách hiện đại và có hệ thống hơn, nếu nghĩ rằng Laravel được tạo ra để dùng PHP theo cách hiện đại và có hệ thống hơn thì...
so với những nhược điểm khi bị đem ra so với framework (ngôn ngữ) khác, chẳng phải các ưu điểm riêng của PHP(-FPM) như tôi nói trong bình luận gốc sẽ thấy rõ hơn sao?
Nhìn lại ký ức cũ, tôi nghĩ rằng ít nhất nếu tổ hợp slim + twig đã được phổ biến rộng rãi thì có lẽ đã có thể giảm bớt những sai lầm về PHP mà tôi từng mắc trong dự án. Tất nhiên, vì các lập trình viên PHP khác khi đó đã quen với kiểu code PHP thuần thủ công, nên lúc ấy không thể đưa nó vào. May mắn là PDO có trong thư viện chuẩn, nên vẫn có thể phòng bị trước SQL injection.
Về mức độ giới hạn ảnh hưởng của bug hay hiệu năng xử lý mà bạn nhắc đến trong bình luận gốc, tôi không có ý kiến rõ ràng là phản đối hay ủng hộ. Tôi nghĩ đó là những tính năng có thì tốt, nhưng các vấn đề như lưu lượng xử lý tăng đột biến hay mức sử dụng bộ nhớ là những điều ở giai đoạn tăng trưởng ít nhất cũng phải cân nhắc một lần, nên tôi cho rằng sẽ tốt hơn nếu các vấn đề đó xuất hiện dưới dạng rõ ràng càng sớm càng tốt.
> Tất nhiên, vì các lập trình viên PHP khác khi đó đã quen với kiểu code PHP chắp vá nên lúc ấy cũng không thể áp dụng được.
> Vì việc thay đổi những người biết phát triển bằng PHP là thứ tốn thời gian nhất và cũng khó nhất.
Cá nhân tôi thấy bản thân PHP không có vấn đề gì, hoặc có đủ cách để ứng phó, hoặc chỉ có những khác biệt phát sinh vì các lý do có thể chấp nhận được như ở các ngôn ngữ khác; nhưng vấn đề nhân lực mà bạn nói đến... có lẽ thực sự đây mới là vấn đề lớn nhất.
Những lập trình viên có thể dùng PHP một cách nghiêm túc thì từ lâu đã chán ngấy PHP của ngày xưa và rời khỏi PHP từ lâu rồi,
còn phần lớn người dùng còn lại thì dù PHP có phát triển đến đâu cũng không nhìn nhận nó một cách đúng đắn, hoặc không có đủ năng lực để nhìn nhận đúng.
Với các dự án MVP+a mà người ta cho là phù hợp với PHP, không có lý do gì để nhóm kỳ cựu ở vế trước tham gia,
mà dù có tham gia đi nữa thì hoặc là họ sẽ không chọn PHP, hoặc kể cả có chọn PHP thì chỉ cần một hai người dùng thuộc nhóm sau chen vào là mọi thứ sẽ thành mớ hỗn độn... haha
Ít nhất ở trong nước, ngay cả việc tìm được nhân lực có thể phát triển PHP ở mức khiến mình hài lòng cũng đã không dễ.
Rồi vì thế PHP lại bị loại khỏi danh sách lựa chọn, trình độ nhân lực trung bình lại càng thấp đi, và cứ lặp vô hạn như vậy để tạo ra một vòng luẩn quẩn.
~~Dù sao thì có lẽ phải tiếp tục "rao bán" như thế này để ít nhất trong các dự án nhỏ 1~3 người~~ số trường hợp thử làm các dự án PHP tử tế phải tăng lên thì vòng luẩn quẩn này mới bị cắt đứt.
Mà ngay cả tôi thì thực ra doanh thu mà PHP mang lại cũng không lớn đến thế. Vì việc tuyển được nhân lực như ý quá khó nên thực tế là dù muốn cũng không thể lấy PHP làm stack chính...
Sở dĩ có khác biệt giữa ngôn ngữ đa dụng và PHP là vì cách chúng tạo ra trang HTML khác nhau. Ít nhất từ khi phát hành phiên bản 1.0, Flask đã khuyến khích mọi người sử dụng template engine và được thiết kế để phụ thuộc vào template engine. Nó chủ ý tách biệt giữa trang HTML và dữ liệu phía máy chủ, đồng thời hỗ trợ làm việc theo đơn vị template. Tôi nghĩ rằng ở đây đã có sự cân nhắc đến đặc điểm của vấn đề cần giải quyết cũng như thói quen sử dụng của con người.
Ngược lại, trong PHP, đầu ra chuẩn tự nó trở thành một phần của trang, và ranh giới giữa dữ liệu phía máy chủ với trang HTML trở nên mơ hồ. Những gì được
printsẽ đi thẳng vào trang kết quả, và việc escape phải do lập trình viên thực hiện một cách tường minh. Một thiết kế đòi hỏi phải gắn hàmhtmlcharacterescapesvào mọi dữ liệu bên ngoài đã không được người dùng đón nhận tốt. Mọi người trong vô thức vẫn muốn có template, nhưng ở PHP dường như mục tiêu của người dùng là tạo ra trang HTML lại không được cân nhắc đến.Lý do chức năng đó cần nằm trong thư viện chuẩn hoặc ngay trong chính ngôn ngữ là vì, khi xét đến cách cấu hình môi trường và cách triển khai mã nguồn của PHP, đó là phương án hiệu quả nhất. Môi trường phát triển được chuẩn hóa quanh stack LAMP, môi trường vận hành được chuẩn hóa theo kiểu web hosting, và vì mọi người đã quen với cách ném file lên qua FTP nên khả năng cung cấp thêm package thấp hơn so với ngôn ngữ đa dụng. Cũng không thể bắt người mới bắt đầu phải cài module. Lựa chọn còn lại chỉ là thư viện chuẩn và tài liệu chuẩn.
> Mọi người vô thức muốn một template, nhưng có vẻ như ở PHP, mục đích của người dùng là tạo ra các trang HTML lại không được cân nhắc.
Tôi không thấy đây là quan điểm đáng đồng tình lắm.
Có thể nói thời kỳ PHP3, khi nó chỉ ở mức giúp phơi bày C API qua CGI một cách dễ dàng, đúng như bạn nói, đã được dùng cho mục đích template...
Nhưng từ PHP4.2 trở đi, môi trường đã được định hình ở mức hoàn toàn có thể dùng cho các mục đích tổng quát.
Đó là một môi trường mà người ta có thể kỳ vọng mã được thực thi qua CLI, và như bạn đã nói trong bình luận trước, nhận định kiểu như "Laravel lẽ ra phải xuất hiện vào khoảng năm 2007 không phải dưới dạng dự án riêng lẻ mà là tính năng chính thức của ngôn ngữ" hoàn toàn không phù hợp với định hướng của PHP khi đó.
Sự tồn tại của Smarty, một template engine cho PHP được công bố năm 2004, hay CodeIgniter, một framework MVC cho PHP được công bố năm 2006, là bằng chứng ngược lại rằng bản thân PHP không phải là ngôn ngữ template; đồng thời cũng có thể xem là lúc đó trong cộng đồng PHP đã hình thành đồng thuận xã hội rằng sẽ không dùng nó theo cách như vậy.
> Các frontend framework, server-side template engine, v.v. đều áp dụng HTML escaping một cách đồng loạt cho mọi nội dung có thể render từ dữ liệu, và chỉ khi bỏ escape một cách tường minh thì mới tạo ra đầu ra theo cách không an toàn.
Tôi cũng không nghĩ đoạn trên trong bình luận trước là nhận định đúng nếu so với bối cảnh thời gian của PHP.
Từ khi Django lần đầu được công bố năm 2005 và trong vài năm sau đó, HTML escaping không phải là thiết lập mặc định. Lập trình viên phải chủ động đặt escape filter. Ngay cả Jinja, hiện vẫn đang được dùng trong Python, cho tới giờ cũng vẫn không tự động xử lý HTML escaping.
Vào thời điểm việc tự động escape được xem là thông lệ phổ biến, PHP từ lâu đã rũ bỏ bản sắc là một ngôn ngữ template rồi. (Dĩ nhiên những người dùng PHP một cách vô thức vào thời đó có thể không mong muốn điều đó, nhưng nhìn theo cách khác thì cũng có thể nói PHP đã quyết định dần loại bỏ những người dùng như vậy.)
Vì PHP không còn là ngôn ngữ cho mục đích đó nữa, nên chẳng có lý do gì để áp dụng mặc định những tính năng như vậy vào thư viện chuẩn hay chính ngôn ngữ. Từ góc độ một PHP muốn vận hành như ngôn ngữ đa dụng, tôi cho rằng hàm
htmlcharacterescapesmà bạn nhắc tới đã làm tròn vai từ lâu rồi.> Môi trường vận hành được chuẩn hóa theo kiểu web hosting và mọi người đã quen với cách ném file lên bằng FTP, nên khả năng cung cấp thêm package thấp hơn so với ngôn ngữ đa dụng.
Tôi cũng khó mà đồng tình với đoạn trên. Từ hơn chục năm trước người ta đã tận dụng git rất tốt rồi. Thậm chí ngay sau khi Docker được công bố, việc triển khai bằng Docker cũng đã được thử nghiệm khá nhiều, và đến giờ vẫn đang được dùng như vậy.
Tôi nghĩ phần lớn những điều bạn nói sẽ chỉ có ý nghĩa khi làm việc trên các CMS được phát triển bằng PHP, hơn là với chính PHP.
Tôi không thích kiểu diễn đạt này lắm, nhưng đó có lẽ là những trường hợp mà ngay cả các lập trình viên PHP cũng không xem là lập trình viên...
Tính năng tự động escape của jinja cho thấy lập luận của tôi là sai và những gì bạn đề cập là đúng.
> Tôi cũng rất khó đồng cảm với nội dung trên. Từ hơn chục năm trước, người ta đã tận dụng git rất tốt rồi. Thậm chí ngay sau khi Docker được công bố, cũng đã có khá nhiều thử nghiệm triển khai bằng Docker, và đến giờ vẫn đang dùng như vậy.
Kinh nghiệm của tôi với PHP dừng lại ở năm 2014, và vào thời điểm đó chưa có Docker. Còn git thì vì phải thay đổi cách làm việc nên cũng không thể đưa vào. Trên thực tế, nếu muốn áp dụng những thứ đó trong môi trường làm việc thì phải có sự đồng thuận chung, nhưng trong hoàn cảnh của tôi khi đó thì điều đó là không thể.
> Tôi không thích kiểu diễn đạt này, nhưng đó là kiểu trường hợp mà ngay cả các lập trình viên PHP cũng không được coi là lập trình viên...
Nghĩ lại thì có lẽ tôi đã làm việc giữa những người không được đối xử như lập trình viên.
Ví dụ bạn nêu như xác thực, kiểm soát truy cập, kiểm tra biểu mẫu, công cụ migration DB và công cụ test đều đã được cung cấp đầy đủ trong Laravel của PHP.
Xác thực: https://laravel.com/docs/11.x/authentication
Kiểm soát truy cập: https://laravel.com/docs/11.x/authorization
Kiểm tra biểu mẫu: https://laravel.com/docs/11.x/validation
Migration DB: https://laravel.com/docs/11.x/migrations
Test: https://laravel.com/docs/11.x/testing
Ngoài ra, tuy là thư viện bên ngoài hoặc thư viện trả phí,
cũng có những công cụ có thể xuất schema DB hiện có thành model và mã migration, hoặc làm theo chiều ngược lại,
và cũng có cả https://nova.laravel.com/ cung cấp một back office gọn gàng kèm UI CRUD.
Gần như mọi tính năng mà Django có thì Laravel cũng đều có.
(Ngay từ đầu cả hai đều kế thừa concept của RoR, nên bản thân các tính năng được cung cấp vốn dĩ khó tránh khỏi việc tương tự nhau.)
Dù vậy, khác với Django-Python, Laravel-PHP còn có thêm những ưu điểm mà tôi đã nhắc tới trong bình luận gốc.
Không thể phủ nhận việc PHP là ngôn ngữ được thiết kế với định hướng là ngôn ngữ template cho web app,
nhưng đến thời điểm mà phong cách PHP hiện đại đã định hình gần mười năm như bây giờ, tôi nghĩ việc chỉ nhìn nó như một ngôn ngữ template đơn thuần thì có phần quá khắt khe.
Tôi đã xem vì có người dẫn link Nova, nhưng cái này cũng là giấy phép trả phí. Dù chức năng có thể tương tự Django Admin, vốn được nêu rõ trong tutorial dự án và có thể dùng ngay, thì xét về mức độ tiếp cận vẫn có vẻ có khác biệt.
Ngoài ra, tôi nghĩ Laravel lẽ ra không phải do các công ty như Rasmus hay Zend đưa ra như một dự án riêng lẻ vào khoảng năm 2007 chứ không phải 2011, thay vì dựa vào những người đóng góp mã nguồn mở, mà đáng ra phải xuất hiện dưới dạng tính năng chính thức của ngôn ngữ. Việc Python 3 từng gặp trở ngại trong quá trình áp dụng vì đã phần nào từ bỏ tính tương thích ngược, nhưng tôi cũng cho rằng PHP lẽ ra nên tiến hành một đợt dọn dẹp lớn về tương thích ngược vào khoảng thời phiên bản 5. Có vẻ như những thay đổi của PHP lúc nào cũng chậm hơn dòng chảy của thời đại một nhịp.
Giờ thì cá nhân tôi không còn ở vị thế mới bắt đầu học phát triển web nữa, nên sẽ không có chuyện chọn PHP.
Bạn cứ liên tục nhầm lẫn giữa ngôn ngữ và framework.
Tôi nghĩ không cần phải đăng cùng một nội dung bình luận ở nhiều nơi. Bạn đang muốn thu hút sự chú ý sao?
Tất nhiên là nó đã tốt hơn trước đây, nhưng ở thời điểm này nếu phải dùng PHP thì có vẻ dùng Node.js hoặc Python sẽ có nhiều chỗ để tận dụng đa mục đích hơn.
Làn sóng bùng nổ của PHP sẽ đến
Trong 10 năm qua hầu như không thấy nhắc gì đến việc hệ sinh thái PHP, cách triển khai, mô hình thực thi, phương pháp debug, v.v. đã cải thiện đến mức nào. Vì điều khó nhất và cũng mất nhiều thời gian nhất là thay đổi những người biết phát triển bằng PHP, nên tôi cũng không kỳ vọng gì mấy rằng nó sẽ khá hơn. Đặc biệt, bài viết được liên kết là blog mang tính marketing của một freelancer PHP, nên có lẽ cần tiếp nhận một cách chọn lọc hơn.
Trong 10 năm qua, xét theo thống kê sử dụng PHP dựa trên các gói Composer (phân phối kiểu như npm của Node), thì PHP 5 trở xuống gần như đã biến mất, và hệ sinh thái PHP từ lâu đã chuyển sang lấy Composer làm trung tâm.
Một số CMS như WordPress, GnuBoard thì hoàn toàn tách biệt.
Ngoài CMS ra, hệ sinh thái đang ở trong tình trạng như trên.
Từ góc nhìn của người dùng PHP, PHP vẫn là ngôn ngữ tệ nhất.
Vì các ngôn ngữ khác đã trở nên tốt hơn.
Ý kiến trên Hacker News
Tóm tắt:
fopen()PHP không còn tệ nữa
Tài liệu từ 12 năm trước haha
Vẫn còn lấy tài liệu viết từ năm 2012 ra nói....
Bạn nghĩ PHP không phát triển gì và vẫn giữ nguyên như thời năm 2012 đó sao..?
À tất nhiên, việc nó là một ngôn ngữ khởi đầu khá thiếu nền tảng thì đúng là cũng khó phủ nhận thật. Ha
Đây là liên kết tới bản dịch của tài liệu tiếng Anh được nhắc đến..
Dù PHP có tệ đến đâu thì chắc cũng không thể vẫn còn giữ nguyên những vấn đề từ thời đó chứ.
Ngay cả việc tiếp tục duy trì nó cũng đã là vấn đề. Ngay từ mức độ này mà thiết kế đã sai từ gốc, vậy mà chỉ vì nâng phiên bản rồi chất lượng tốt hơn ư? Đó là một vấn đề vì đã phá vỡ nghiêm trọng tính tương thích ngược. Ngay cả toán tử so sánh cũng kỳ quặc, thì còn biết làm sao nữa.
Có vẻ như đây chỉ đơn giản là bản dịch tiếng Hàn của liên kết thứ 4 trong phần tóm tắt Hacker News thôi haha