- Sebagian besar kritik seperti "PHP itu jelek (PHP Sucks)" muncul karena mereka tidak melihat PHP setelah 2012
- Banyak perubahan terjadi sejak PHP 5.4, dan perubahan bahasa setelah itu layak diperhatikan
Perubahan utama sejak PHP 5.4
- Traits (PHP 5.4)
- Memungkinkan penggunaan composition alih-alih inheritance
- Dapat memiliki trait yang bisa disertakan ke semua class
- Sintaks array singkat
- Bisa memakai tanda kurung siku tanpa perlu menulis
array()
- Destrukturisasi array
- Bisa langsung mengalokasikan nilai ke variabel tanpa perlu menaruh array ke variabel sementara
- Fungsi variadic kelas satu
- Dengan sintaks
..., Anda dapat mengirimkan sebanyak mungkin argumen ke fungsi sesuai kebutuhan
- Generator
- Memungkinkan pekerjaan yang intensif memori dilakukan dengan lebih efisien
- Class anonim
- Bisa membuat class baru tanpa perlu membuat file baru
- Dapat mengimplementasikan interface seperti class lainnya
Perubahan utama sejak PHP 7
- Koma di akhir
- Tidak perlu khawatir menambahkan koma di akhir pada pemanggilan fungsi atau metode
- Arrow function
- Sedikit berbeda dari JavaScript, tetapi merupakan tambahan yang bagus untuk bahasa ini
- Operator null coalescing
- Tidak perlu melakukan pengecekan null sebelum menetapkan nilai
- Operator assignment null coalescing (PHP 7.4)
- Ada juga operator assignment singkat untuk null coalescing
- Weak map (PHP 7.4)
- Jauh lebih baik untuk memori dibanding array
- Bisa menggunakan object sebagai key
Perubahan sejak PHP 8
- Operator nullsafe chain
- Tidak perlu melakukan pengecekan null sebelum memanggil metode
- Named argument
- Tidak perlu memakai null untuk melewati argumen opsional
- Attribute (anotasi)
- Dapat digunakan untuk menambahkan anotasi pada class, metode, argumen, atau properti
- Penanganan error yang ditingkatkan
- Tidak perlu variabel exception hanya untuk mengembalikan false
- Pernyataan match
- Cara yang lebih ringkas dan mudah dibaca dibanding pernyataan switch yang panjang
- Enum (PHP 8.1)
- Bisa membuat class enum dengan nilai dan metode
- Juga bisa digunakan sebagai type hint
- Keamanan tipe
- Memiliki argumen bertipe, return type, union type, intersection type, dan lainnya
- Type hint untuk enum juga bisa digunakan
- Constructor property promotion (PHP 8.0)
- Tidak perlu lagi constructor yang bertele-tele
- Membantu mengurangi kode boilerplate
- Properti read-only (PHP 8.1)
- Bisa mendeklarasikan keyword untuk menandai properti sebagai hanya-baca
Performa
- Peningkatan performa 400% saat beralih dari PHP 5.6 ke 7
- Peningkatan performa 20% saat beralih dari PHP 7 ke 8
- Menyediakan performa yang cukup untuk sebagian besar kebutuhan pengembangan web; jika kebutuhannya lebih khusus, disarankan memakai bahasa yang lebih terspesialisasi
Kesimpulan
- PHP belum mati, dan tidak lagi menjadi yang terburuk. Bahasanya telah banyak berubah sejak 2012, dan sudah waktunya memperbarui pendapat tentangnya.
- Dengan hadirnya berbagai fitur seperti traits, sintaks array singkat, dan destrukturisasi array, PHP menjadi bahasa yang lebih efisien, mudah dibaca, dan mudah dipelihara.
- Ditambah lagi dengan peningkatan penanganan error, hadirnya attribute, dan akhirnya enum yang telah lama dinantikan, jelas bahwa PHP telah berkembang menjadi pilihan yang solid dan andal untuk pengembangan web.
- Jadi jika seseorang mengatakan PHP adalah yang terburuk, Anda bisa dengan yakin mengatakan bahwa mereka hanya hidup di masa lalu.
Opini GN⁺
- Melihat perubahan bahasa di PHP, terlihat jelas bahwa ini bukan lagi PHP masa lalu. Namun tampaknya masih banyak developer yang terjebak pada persepsi lama.
- Banyak fitur telah ditambahkan untuk membuat kode lebih ringkas dan mudah dibaca, seperti trait, sintaks short array, dan destructuring assignment. Ini juga tampaknya akan berkontribusi pada peningkatan maintainability.
- Fitur seperti generator dan weak map yang meningkatkan efisiensi memori juga menonjol. Tampaknya akan berguna saat memproses data dalam jumlah besar.
- Ada juga perubahan yang meningkatkan kematangan bahasa, seperti enum dan peningkatan type safety. Ini diharapkan membuat penulisan clean code menjadi lebih mudah.
- Yang paling mengesankan adalah peningkatan performa di PHP 8. Disebutkan bahwa hasil benchmark nyata menunjukkan performa yang sebanding dengan NodeJS dan Go.
- Namun memodernisasi proyek PHP legacy tetap merupakan tantangan yang tidak mudah. Migrasi kode bisa memakan banyak sumber daya.
- PHP masih menjadi bahasa dasar bagi banyak ekosistem open source seperti WordPress. Sulit meremehkan nilai PHP hanya dengan melihat karakteristik bahasanya saja.
40 komentar
Ini benar-benar komentar yang menunjukkan kenapa php sampai sekarang masih dianggap menyebalkan.
Selamat, sekarang itu jadi kotoran yang tidak berbau.
Kalau ada kesempatan, semoga Anda juga mencoba makan yang lain selain kotoran : )
Banyak sekali opini yang bermunculan. Saya bukan pengembang PHP. Melihat sentimen anti-PHP yang dipupuk komunitas, sepertinya para junior jadi ikut memiliki perasaan seperti itu dan lingkaran setannya terus berulang. Seorang ahli sejati tidak pernah menyalahkan alat. Semangat terus untuk para pengembang PHP.
Sebagai developer PHP.. arogansi orang-orang yang memakai bahasa lain itu benar-benar sampai bikin ingin memaki.
Saya benar-benar tidak paham kenapa mereka begitu ingin merendahkan bahasa yang dipakai orang lain.
Saya juga mulai sebagai developer PHP lalu pernah beralih ke Java, mencoba Python, dan juga Node.js, tapi..
setiap bahasa punya filosofi atau ketidaknyamanan masing-masing yang sulit dipahami, jadi saya tidak mengerti kenapa cuma PHP yang terus-terusan jadi sasaran hinaan..
Sialan, kenapa begitu—
Situasi-situasi yang disebut sebagai bug di PHP, kalau benar-benar dipakai untuk development,
sering kali adalah sintaks atau struktur yang nyaris tidak digunakan meski tidak mengetahuinya,
dan legacy seperti itu juga ada sampai tingkat tertentu di bahasa lain.
Benar-benar bikin muak.
Saya minta maaf karena membahas teknologi yang Anda geluti sebagai profesi. Terlepas dari niat saya, pada akhirnya saya membuat perasaan koxel terluka, dan itu adalah tanggung jawab saya.
Namun, saya hanya menulis apa yang saya rasakan saat bekerja keras sebagai junior di antara para pengembang PHP yang mengira coding serampangan adalah segalanya. Beberapa pengembang PHP bahkan tidak mengakui dan menolak kenyataan bahwa best practice pun berubah. Itulah yang membuat saya frustrasi. Saat ini, karena kondisi yang ada, saya lebih banyak bekerja di industri frontend, tetapi saya juga merasa ada banyak hal yang bisa dikritik dari cara pengembangan JavaScript. Saya tidak menganggap ada bahasa yang memiliki keunggulan mutlak, dan saya percaya bahwa standar yang berbeda perlu diterapkan sesuai situasi.
Kalau dilihat-lihat, katanya masalahnya ada pada struktur yang memungkinkan developer pemula menulis program yang buruk.
Bukankah bahasa lain juga sama saja.
Itulah alasan mengapa setiap bahasa punya yang namanya best practice..
Berdasarkan WordPress, tingkat penggunaan PHP versi 5.6 atau yang lebih rendah kurang dari 5%.
https://wordpress.org/about/stats/
Meski begitu, pada 2023 WordPress tetap menaikkan persyaratan minimum instalasi PHP menjadi 7.0.
Secara pribadi, tingkat ketidaksukaan saya terhadap PHP hampir sama dengan tingkat ketidaksukaan saya terhadap Javascript.
Dibandingkan keduanya, Python malah terlihat jauh lebih mending.
Saya memulai karier dengan PHP, dan rasanya puncak karier saya juga dicapai lewat PHP.
Sekarang saya mencari nafkah dengan bahasa lain, tapi
untuk side project atau hobi, saya masih kadang membuka PHP.
Sama saja, menurut saya ini bahasa yang punya daya tarik.
Tentu saja belakangan ini muncul banyak alternatif jadi agak disayangkan, tapi
laravel vaporlumayan bagus.Saya memang sedang tidak bekerja di pengembangan web sekarang... jadi teringat masa lalu.
Ternyata banyak yang tidak menyukai PHP. Saya juga sempat memakai PHP sekitar 3 tahun, dan terus merasa bahwa sebagai bahasa, daya tariknya memang sangat kurang. Bisa dibilang PHP juga yang membuat saya, saat mengenal RoR, jatuh begitu dalam pada keanggunan bahasa Ruby.
Tapi, ketika PHP pertama kali muncul, itu luar biasa! Waktu itu masih zamannya membuat board dengan CGI. Kelincahan yang diberikan PHP saat itu benar-benar sensasional. Rasanya memang benar bahwa PHP membuka cakrawala besar bagi pengembangan web. :)
Namun, anggur baru perlu wadah baru...
Sebagai bahasa, PHP memang masih terasa sebagai bahasa terburuk,
namun sebagai platform (sulit mencari istilah yang pas), menurut saya PHP lebih baik dari yang dibayangkan.
Terutama untuk proyek pada tahap MVP hingga awal pertumbuhan, jika sejak awal sudah ditegaskan bahwa nantinya akan pindah ke bahasa/platform/framework lain (biasanya Spring),
setelah itu kekurangan bahasanya jadi tidak terlalu penting, dan yang terlihat justru hanya kelebihan PHP.
Karena deployment bisa dilakukan hanya dengan mengubah file tanpa henti layanan, umpan balik pengguna bisa direfleksikan lebih cepat,
dan cara PHP(-FPM) menangani antrean request secara hemat dan efisien, yang sangat menonjol dibanding yang lain, membuatnya cukup tangguh menghadapi lonjakan trafik tak terduga (pertumbuhan dalam waktu singkat),
meskipun ada bug, seluruh aplikasi tidak langsung mati, dan karena relatif lebih bebas dari memory leak, kita bisa fokus pada business logic+a,
bahkan developer yang bahasa utamanya bahasa lain dan belum pernah memakai PHP pun, kalau mempelajarinya seminggu, biasanya sudah bisa memakainya sampai tingkat tertentu...
Semua ini memang akan berbalik menjadi kekurangan saat skalanya membesar (mungkin bahkan serius)...
Tetapi setidaknya pada skala MVP, dalam situasi di mana kita harus cepat menerima umpan balik pengguna, segera menerapkannya, dan tumbuh dengan cepat, adakah pilihan yang lebih cocok daripada PHP?
Ditambah lagi, saat memutuskan memakai PHP, kita sudah berada dalam kondisi mental "kalau ukurannya membesar, nanti kita migrasikan ke bahasa lain", jadi serius... Why not?
Saya agak punya pandangan berbeda: untuk membuat MVP sendirian, menurut saya dibutuhkan alat yang bisa mewujudkan tiga hal—skema DB, WAS, dan UI—dengan coding seminimal mungkin. Dan saya rasa ada pilihan yang sangat bagus selain PHP, yaitu Ruby on Rails dan Django.
Dalam kasus Django, jika Anda hanya mendefinisikan kelas model dengan pola Active Record (istilah yang benar-benar terasa kuno ya), maka skema DB dan UI CRUD back-office yang lumayan bisa dipakai akan ikut muncul. Tersedia juga alat-alat minimum untuk pengembangan layanan web seperti autentikasi, kontrol akses, validasi formulir, alat migrasi DB, alat pengujian, dan lain-lain. Secara pribadi, sejak mulai web programming pada akhir 2000-an, saya belum pernah merasakan produktivitas yang menandingi Django. Sejak pendekatan SPA menjadi tren dan peran frontend serta backend dipisahkan, malah terasa produktivitas menurun. Setidaknya harus ada dua orang yang sama-sama memahami user flow, dan pekerjaan baru bisa dilakukan secara paralel jika protokolnya sudah disepakati.
Kalau PHP ingin mengusung diri sebagai bahasa templating untuk web app, menurut saya seharusnya sejak level bahasa sudah menyediakan sarana untuk mencegah kerentanan web. Fakta bahwa gaya PHP modern mengadopsi pendekatan pengembangan berbasis framework tampaknya bisa dilihat sebagai buktinya.
Dan PHP sudah lama diposisikan sebagai bahasa skrip serbaguna.
Saya tidak mengerti kenapa Anda membandingkan bahasa dengan framework.
Ada Laravel, yang konsepnya seperti Ruby on Rails dan Django.
Saya rasa ketika modern PHP tidak lagi dianggap “modern” dan telah mapan sebagai metode pengembangan standar PHP, serta ketika CMS termasuk WordPress mengadopsi modern PHP, orang-orang akan memandang PHP sebagai bahasa serbaguna yang aman. Memulihkan kepercayaan umumnya membutuhkan usaha lebih besar daripada merusaknya.
Karena atas nama menjaga kompatibilitas ke belakang, pemula dibiarkan membuat layanan web yang tidak aman hanya dengan mengandalkan fungsi dasar PHP. Dari 5 situs teratas yang muncul saat mencari tutorial PHP, selain situs resmi PHP, tidak ada yang memasukkan penjelasan bahwa saat menampilkan isi superglobal untuk mencegah XSS, kita harus menerapkan HTML escape. Karena panduan yang mereka sediakan secara resmi juga memuat isi tentang pengembangan web, bukankah PHP pada akhirnya menjalankan dua peran sekaligus, yaitu sebagai bahasa dan framework?
Bagaimana pendapat Anda tentang fakta bahwa berbagai elemen HTTP disediakan secara bawaan melalui nama-nama superglobal? Saya pikir cakupan keumuman dan area penggunaannya ditentukan oleh apa yang diekspresikan oleh suatu bahasa.
Contoh seperti variabel superglobal
$_GET,$_POSTadalah nilai yang diekspos saat PHP digunakan dalam mode CGI atau SAPI. Jika PHP digunakan lewat CLI, nilai tersebut tidak diekspos.Variabel superglobal semacam itu adalah semacam API yang diekspos oleh runtime yang menjalankan PHP, seperti PHP-CGI dan PHP-FPM, bukan spesifikasi PHP sebagai bahasa.
Begitu juga dengan "PHP yang mengusung diri sebagai bahasa templat" yang disebutkan sebelumnya; kalau dibahas secara ketat, yang menginginkan penggunaan seperti itu bukan PHP, melainkan CGI, salah satu runtime PHP.
Demikian pula, banyak fungsi bawaan PHP yang disebut sebagai kerentanan juga merupakan fungsi yang diekspos oleh extension PHP, bukan fitur yang dimiliki "bahasa" PHP itu sendiri.
Kalau mengikuti penjelasan Anda,
JavaScript akan menjadi bahasa sekaligus framework yang sejak awal dirancang untuk menggunakan API yang diekspos browser demi berkomunikasi dengan browser,
Java adalah bahasa, tetapi pada praktiknya akan menjadi framework yang digunakan untuk memanfaatkan begitu banyak API dari JDK,
dan semua bahasa lain pun, terlepas dari spesifikasi bahasanya sendiri, jika menyediakan pustaka standar atau API maka semuanya harus dianggap sebagai framework.
Tentu benar bahwa hubungan keduanya tidak bisa dipisahkan, tetapi menggunakan hal-hal seperti ini untuk menyatakan bahwa PHP adalah framework jelas kurang meyakinkan.
Dan bahkan hingga Mei 2024, melihat XSS yang masih ditambal di proyek inti WordPress, tampaknya XSS tidak bisa dicegah hanya dengan perbaikan pada level sintaks PHP saja.
Framework frontend, template engine sisi server, dan sejenisnya menerapkan HTML escaping secara menyeluruh pada semua konten yang dapat dirender dari data, lalu hanya menghasilkan output dengan cara yang tidak aman ketika escaping dinonaktifkan secara eksplisit. Di PHP, tidak ada cara yang disepakati untuk menerapkan penanganan seperti itu secara menyeluruh. Jika pernyataan
echoatauprintmendukung escaping secara bawaan, mungkin akan langsung muncul banyak kode yang tidak berfungsi, tetapi dalam jangka panjang hal itu bisa mengurangi kesalahan banyak orang yang lupa menerapkan escaping.Ya, saya tidak setuju dengan sudut pandang yang memisahkan bahasa dan runtime, dan saya berpikir bahwa runtime bagaimanapun juga memengaruhi bahasa. Dalam kasus JavaScript, ada dua runtime yaitu nodejs dan browser, dan untuk Python ada banyak implementasi, tetapi bisa dipahami bahwa cpython yang dominan.
Topik tulisan asli terbatas pada perbaikan sintaksis, tetapi saya ingin membicarakan hal yang cakupannya sedikit lebih luas daripada kerangka seperti ini.
> Selain itu, saya juga berpikir Laravel seharusnya muncul bukan dari para kontributor open source atau oleh perusahaan seperti Rasmus atau Zend, bukan sekitar 2011, melainkan sekitar 2007, bukan sebagai proyek terpisah tetapi sebagai fitur resmi bahasa. Karena Python 3 sempat mengalami hambatan adopsi akibat sebagian mengorbankan kompatibilitas ke belakang, saya juga merasa PHP seharusnya melakukan pembersihan kompatibilitas ke belakang secara besar-besaran sekitar versi 5. Perubahan di PHP juga terasa selalu agak terlambat dibanding arus zaman.
Ini sekaligus menjadi jawaban untuk komentar di atas.
Dari sudut pandang yang Anda sampaikan, saya jadi berpikir PHP bisa diperlakukan sebagai semacam web framework.
Namun demikian, saya tidak berpikir berbagai fitur seperti filter XSS, escape, dan lain-lain dalam contoh tadi harus disediakan PHP secara bawaan.
PHP-FPM yang paling umum digunakan tidak berada pada posisi yang sama dengan Django atau RoR. Ia lebih dekat ke Flask, Sinatra, atau Express.
PHP-FPM tidak menangani lebih dari routing (berbasis direktori), penafsiran request (
$_GET,$_POST,$_FILE,$_COOKIE), pengiriman response (echo,print), dan manajemen sesi ($_SESSION).Apakah Flask berbeda?
Di Flask, untuk mengembalikan response dengan HTML yang sudah di-escape, itu tidak bisa diselesaikan hanya dengan
returnsaja.https://flask.palletsprojects.com/en/3.0.x/quickstart/#html-escaping
Apakah Sinatra berbeda?
Sama saja, Anda tetap harus memakai library escape terpisah.
https://sinatrarb.com/faq.html#escape_html
Apakah Express berbeda?
Ini juga sama, Anda perlu memakai library escape terpisah.
https://expressjs.com/en/resources/middleware.html
Semua library yang dijadikan contoh itu bukan library yang disediakan secara resmi oleh framework tersebut.
Kalau begitu, kenapa PHP harus wajib menyediakan fungsi-fungsi semacam itu secara resmi di PHP sendiri?
Kalau alasannya adalah hal-hal yang sudah banyak dibicarakan orang seperti,
"Framework gila macam apa yang mengekspos data request sebagai superglobal? Kalaupun tidak ada masalah keamanan, ini tetap tidak sopan terhadap pengguna!"
lalu dari situ menyimpulkan PHP itu sampah, saya masih bisa mengerti,
tetapi alasan yang Anda sampaikan, yaitu "fitur bawaan PHP tidak cukup memadai seperti yang disediakan full-stack framework"... setidaknya saya sulit untuk setuju.
Seperti halnya Nestjs dibuat agar Express bisa digunakan dengan cara yang lebih modern dan lebih terstruktur, kalau Laravel dibuat agar PHP bisa digunakan dengan cara yang lebih modern dan lebih terstruktur...
bukankah, dibanding kekurangan yang muncul saat dibandingkan dengan framework (atau bahasa) lain, kelebihan khas PHP(-FPM) seperti yang saya sebut di komentar awal justru terasa lebih menonjol?
Kalau saya mengingat-ingat lagi, rasanya setidaknya jika kombinasi slim + twig sudah lebih umum dipakai, kesalahan-kesalahan PHP yang saya buat di proyek bisa berkurang. Tentu saja, karena pengembang PHP lain saat itu sudah terbiasa dengan ngoding PHP secara mentah, pada masa itu hal tersebut juga tidak bisa diperkenalkan. Untungnya, PDO ada di pustaka standar, jadi setidaknya kami bisa mengantisipasi SQL injection.
Soal pembatasan dampak bug atau performa pemrosesan yang disebutkan di komentar asli, saya tidak punya pendapat yang secara khusus negatif maupun positif. Menurut saya itu fitur yang bagus kalau ada, tetapi karena lonjakan throughput atau masalah penggunaan memori adalah hal yang minimal sekali perlu dipikirkan pada tahap pertumbuhan, saya rasa akan lebih baik jika masalah seperti itu muncul dalam bentuk yang eksplisit sedini mungkin.
> Tentu saja saat itu hal tersebut tidak bisa diadopsi karena developer PHP lain sudah terbiasa dengan ngoding ala koboi di PHP.
> Karena yang paling memakan waktu dan paling sulit adalah mengubah orang-orang yang bisa mengembangkan dengan PHP
Secara pribadi saya melihat PHP itu sendiri tidak bermasalah, atau ada cara yang cukup memadai untuk mengatasinya, atau perbedaannya hanya sebatas sesuatu yang muncul dengan alasan yang bisa diterima seperti di bahasa lain; tetapi masalah SDM yang Anda sebutkan... saya rasa inilah sebenarnya masalah terbesar.
Developer yang bisa memakai PHP secara serius sudah sejak lama muak dengan PHP versi lama dan sudah lama kabur dari ekosistem PHP,
sementara sebagian besar pengguna yang tersisa adalah orang-orang yang, seberapa pun PHP berkembang, tidak akan melihatnya dengan semestinya, atau memang tidak punya kapasitas untuk menilainya dengan semestinya...
Untuk proyek MVP+a yang menurut saya cocok memakai PHP, tidak ada alasan bagi para profesional berpengalaman dari kelompok pertama untuk ikut terlibat,
dan bahkan kalaupun mereka ikut, kemungkinan mereka tidak akan memilih PHP, atau kalau memilih PHP pun, begitu ada satu-dua user dari kelompok kedua yang ikut masuk, semuanya akan jadi berantakan... haha
Setidaknya di dalam negeri, mencari talenta yang mampu melakukan pengembangan PHP yang memuaskan memang tidak mudah.
Akhirnya PHP kembali tersingkir dari daftar pilihan, level rata-rata talenta pun makin turun, dan itu terus berulang tanpa henti membentuk lingkaran setan.
~~Mungkin lingkaran setan ini baru bisa diputus kalau, meski cuma dengan terus jualan omongan begini,~~ makin banyak kasus yang mencoba menjalankan proyek PHP yang benar setidaknya di proyek kecil 1~3 orang.
Bahkan saya sendiri juga sebenarnya tidak mendapatkan pendapatan sebesar itu dari PHP. Karena sangat sulit mendapatkan suplai talenta yang memuaskan, realitanya saya tidak bisa menjadikan PHP sebagai stack utama meskipun ingin.
Itu karena ada perbedaan cara menghasilkan halaman HTML antara bahasa serbaguna dan PHP. Flask, setidaknya sejak merilis versi 1.0, mendorong orang untuk menggunakan template engine dan dirancang untuk bergantung padanya. HTML page dan data sisi server sengaja dipisahkan, dan pekerjaan berbasis unit template terus didukung. Menurut saya, karakteristik masalah yang ingin diselesaikan dan kebiasaan penggunaan orang telah dipertimbangkan.
Sebaliknya, di PHP, standard output langsung menjadi bagian dari halaman, dan batas antara data sisi server dan HTML page menjadi kabur. Apa yang di-
printakan masuk begitu saja ke halaman hasil, dan escaping harus dilakukan secara eksplisit oleh developer. Desain yang mengharuskan fungsihtmlcharacterescapesditempelkan ke semua data eksternal tidak diterima dengan baik oleh orang-orang. Orang-orang secara tidak sadar menginginkan template, tetapi di PHP tampaknya tujuan pengguna untuk menghasilkan halaman HTML tidak dipertimbangkan.Alasan fungsi itu perlu masuk ke standard library atau bahkan ke bahasa itu sendiri adalah karena, jika mempertimbangkan konfigurasi lingkungan dan cara deployment kode di PHP, itulah metode yang paling efektif. Lingkungan pengembangan dibakukan dengan stack LAMP, lingkungan operasional dibakukan dengan pola web hosting, dan karena orang sudah terbiasa dengan cara melempar file lewat FTP, kemungkinan untuk menyediakan paket tambahan lebih rendah dibanding bahasa serbaguna. Kita juga tidak bisa menuntut pemula untuk memasang modul. Pilihan yang tersisa hanyalah standard library dan dokumentasi standar.
> Orang-orang secara tidak sadar menginginkan template, tetapi pada PHP tampaknya tujuan pengguna untuk membuat halaman HTML tidak benar-benar dipertimbangkan.
Saya rasa saya tidak terlalu sependapat dengan pernyataan itu.
Pada masa PHP3, ketika fungsinya hanya sebatas mempermudah mengekspos C API ke CGI, memang bisa dibilang digunakan untuk keperluan template seperti yang Anda katakan, tetapi...
Sejak PHP4.2, lingkungannya sudah dibentuk pada tingkat yang cukup memungkinkan penggunaan umum.
Sudah menjadi lingkungan di mana kode bisa diharapkan dijalankan melalui CLI, dan seperti yang Anda sebutkan di komentar sebelumnya, pernyataan bahwa "Laravel seharusnya muncul sekitar 2007 bukan sebagai proyek terpisah, melainkan sebagai fitur resmi bahasa" sama sekali tidak sesuai dengan arah PHP pada masa itu.
Keberadaan Smarty, template engine untuk PHP yang dirilis pada 2004, dan CodeIgniter, framework MVC untuk PHP yang dirilis pada 2006, menjadi bukti sebaliknya bahwa PHP itu sendiri bukan bahasa template, dan juga bisa dinilai bahwa konsensus sosial di komunitas PHP untuk tidak menggunakannya seperti itu sudah terbentuk saat itu.
> Frontend framework, server-side template engine, dan sebagainya secara seragam menerapkan HTML escaping pada semua konten yang dapat dirender dari data, dan hanya ketika escaping dinonaktifkan secara eksplisit barulah output dihasilkan dengan cara yang tidak aman.
Menurut saya, pernyataan di komentar sebelumnya itu juga tidak terlalu tepat jika dibandingkan dengan garis waktu PHP.
Sejak django pertama kali dirilis pada 2005, dan selama beberapa tahun setelahnya, HTML escaping bukan pengaturan default. Pengembang harus secara sengaja menetapkan filter escape. Bahkan untuk jinja yang sampai sekarang masih digunakan di Python, HTML escaping pun masih belum ditangani secara otomatis.
Pada saat auto-escaping mulai dianggap sebagai hal yang umum, PHP sendiri sudah lama melepaskan identitasnya sebagai bahasa template. (Memang, para pengguna yang memakai PHP secara serampangan saat itu mungkin tidak menginginkannya, tetapi di sisi lain bisa juga dilihat bahwa PHP sudah memutuskan untuk perlahan menyingkirkan pengguna seperti itu.)
Karena PHP bukan lagi bahasa untuk tujuan seperti itu, sama sekali tidak ada alasan untuk menerapkan fungsi semacam itu sebagai nilai default di standard library dan bahasa PHP. Dari sudut pandang PHP yang ingin berfungsi sebagai bahasa umum, saya rasa fungsi
htmlcharacterescapesyang Anda sebutkan sudah lebih dari cukup menjalankan perannya.> Karena lingkungan operasionalnya dibakukan dalam bentuk web hosting dan orang terbiasa dengan cara melempar file lewat FTP, kemungkinan untuk menyediakan paket tambahan lebih rendah dibanding bahasa umum.
Untuk pernyataan di atas juga saya sulit merasa sangat setuju. Sejak jauh lebih dari belasan tahun lalu, git dan semacamnya sudah dimanfaatkan dengan sangat baik. Bahkan sejak tak lama setelah Docker dirilis, deployment menggunakan Docker juga sudah cukup banyak dicoba, dan sampai sekarang pun masih digunakan seperti itu.
Sebagian besar hal yang Anda sebutkan tampaknya lebih relevan saat bermain di atas CMS yang dibangun dengan PHP daripada pada PHP itu sendiri.
Saya sebenarnya tidak suka ungkapan seperti ini, tetapi ini terasa seperti kasus yang bahkan oleh developer PHP pun tidak dianggap sebagai sesama developer...
Fitur auto-escaping di jinja berarti klaim saya salah dan yang Anda sebutkan memang benar.
> Saya juga cukup sulit sepakat dengan poin di atas. Sejak lebih dari belasan tahun lalu, kami sudah memanfaatkan git dengan sangat baik. Bahkan tak lama setelah Docker dirilis, sudah cukup banyak upaya deployment menggunakan Docker, dan sampai sekarang pun masih digunakan seperti itu.
Pengalaman PHP saya berhenti di 2014, dan saat itu belum ada Docker. Git juga tidak bisa diadopsi karena itu mengharuskan perubahan cara kerja. Untuk benar-benar menerapkan hal-hal seperti itu di lingkungan kerja nyata, harus ada kesepahaman bersama, dan dalam situasi saya saat itu hal tersebut tidak memungkinkan.
> Saya sebenarnya tidak suka ungkapan seperti ini, tetapi ada juga kasus di mana bahkan developer PHP tidak diperlakukan sebagai developer...
Kalau dipikir-pikir lagi, sepertinya saya memang bekerja di antara orang-orang yang tidak diperlakukan sebagai developer.
Contoh yang Anda sebutkan—autentikasi, kontrol akses, validasi formulir, alat migrasi DB, dan alat pengujian di Django—semuanya juga tersedia di Laravel untuk PHP.
Autentikasi: https://laravel.com/docs/11.x/authentication
Kontrol akses: https://laravel.com/docs/11.x/authorization
Validasi formulir: https://laravel.com/docs/11.x/validation
Migrasi DB: https://laravel.com/docs/11.x/migrations
Pengujian: https://laravel.com/docs/11.x/testing
Selain itu, meskipun berupa library eksternal atau library berbayar,
ada juga alat yang bisa mengekspor skema DB yang sudah ada menjadi model dan kode migrasi, atau bekerja sebaliknya,
dan juga ada https://nova.laravel.com/ yang menyediakan back office yang rapi lengkap dengan UI CRUD.
Hampir semua fitur yang dimiliki Django juga ada di Laravel.
(Sejak awal, keduanya sama-sama mewarisi konsep RoR, jadi menurut saya wajar jika fitur yang disediakan memang mirip.)
Meski begitu, berbeda dari Django-Python, Laravel-PHP juga punya kelebihan tambahan yang saya sebutkan di komentar asli saya.
Memang tidak bisa disangkal bahwa PHP adalah bahasa yang dirancang dengan mengusung konsep bahasa templating untuk web app,
namun di masa sekarang, ketika gaya PHP modern sudah mapan hampir sepuluh tahun, rasanya terlalu keras jika masih melihatnya hanya sebagai bahasa templating semata.
Saya melihatnya karena Nova ditautkan, dan ini juga berlisensi berbayar. Meski mungkin fiturnya mirip dengan Django Admin yang dinyatakan secara jelas dalam tutorial proyek dan bisa langsung digunakan, tampaknya ada perbedaan dari sisi aksesibilitas.
Selain itu, saya merasa Laravel seharusnya bukan sesuatu yang lahir karena para kontributor open source, melainkan sesuatu yang semestinya sudah hadir sebagai fitur resmi bahasa sekitar 2007, bukan 2011, oleh perusahaan seperti Rasmus atau Zend, bukan sebagai proyek terpisah. Python 3 memang sempat mengalami hambatan adopsi karena sebagian mengorbankan kompatibilitas ke belakang, tetapi menurut saya PHP juga seharusnya melakukan pembersihan besar-besaran kompatibilitas ke belakang di sekitar versi 5. Perubahan pada PHP juga terasa selalu tertinggal dari arus zaman.
Sekarang, karena secara pribadi saya sudah bukan lagi berada pada posisi baru masuk ke pengembangan web, saya tidak akan memilih PHP.
Anda terus mencampuradukkan bahasa dan framework.
Saya rasa tidak perlu menulis komentar yang sama di banyak tempat. Apakah Anda ingin menarik perhatian?
Tentu saja PHP membaik dibanding dulu, tetapi kalau sekarang harus memilih memakai PHP, rasanya Node.js atau Python terlihat punya lebih banyak kegunaan untuk berbagai keperluan.
Boom PHP akan datang
Selama 10 tahun terakhir, tidak ada pembahasan tentang seberapa banyak ekosistem PHP, cara deployment, model eksekusi, metode debugging, dan lain-lain telah membaik. Karena yang paling memakan waktu dan paling sulit adalah mengubah orang-orang yang bisa mengembangkan dengan PHP, saya bahkan tidak terlalu berharap situasinya akan membaik. Terutama karena tulisan yang ditautkan adalah blog pemasaran milik seorang freelancer PHP, rasanya tulisan itu perlu diterima dengan sangat selektif.
Selama 10 tahun terakhir, berdasarkan statistik penggunaan PHP dari paket Composer (distribusi seperti npm di Node), PHP 5 ke bawah praktis sudah punah, dan ekosistem PHP sudah lama beralih dengan Composer sebagai pusatnya.
Sebagian CMS seperti WordPress, Gnuboard, dan sejenisnya benar-benar terpisah.
Ekosistem di luar CMS berada dalam situasi seperti di atas.
Dari sudut pandang pengguna PHP, PHP tetap merupakan bahasa terburuk.
Karena bahasa lain sudah menjadi lebih baik.
Komentar Hacker News
Ringkasan:
fopen()PHP: Fraktal dari desain yang buruk (bahasa Korea)
Dokumen dari 12 tahun lalu wkwk
Masih memakai dokumen yang ditulis pada 2012....
Apa Anda pikir PHP tanpa perkembangan akan tetap persis seperti masa itu di 2012..?
Ah, tentu saja sulit dibantah bahwa ini memang bahasa yang awalnya dimulai tanpa fondasi yang jelas. haha
Ini tautan ke versi terjemahan dari dokumen bahasa Inggris yang disebutkan..
Sejelek apa pun PHP, masa iya masalah-masalah dari zaman itu masih dipertahankan sampai sekarang.
Bahkan mempertahankannya pun sudah jadi masalah. Dari level desain seperti ini saja sudah salah sejak awal, lalu katanya kualitas membaik setelah upgrade versi? Itu justru masalah karena kompatibilitas mundurnya dirusak secara serius. Bahkan operator perbandingannya saja sudah aneh, mau bagaimana lagi.
Sepertinya ini hanya menyediakan terjemahan bahasa Korea dari tautan ke-4 pada ringkasan Hacker News, haha.