Sepertinya orang ini sedang membicarakan biaya langganan IDE. FLCC memang tidak disediakan di versi gratis.
Tapi juga bukan berarti orang membayar hanya demi itu saja.
Menafsirkan tujuan sebenarnya dari SPA secara terlalu sempit
View Transitions API memang sangat keren, tetapi itu saja tidak berarti SPA menjadi tidak diperlukan.
Melihat semua situs web dengan tolok ukur yang sama
Situs pemasaran ≠ dasbor ≠ aplikasi komersial ≠ alat kolaborasi real-time
Semuanya memiliki kebutuhan struktural yang berbeda.
Dalam praktiknya, SPA + SSR + MPA masih hidup berdampingan
Framework hibrida seperti Next.js menunjukkan hal ini dengan baik.
Aset statis memakai SSG, dasbor setelah login memakai CSR/SPA, dan penyesuaian untuk mesin pencari memakai SSR; kombinasi yang fleksibel seperti ini diperlukan.
Saya rasa SPA bukan hanya soal pengalaman pengguna, tetapi lebih dekat pada hasil dari perbaikan struktur.
Untuk halaman yang tidak memerlukan SPA, MPA + CSS modern mungkin bisa menjadi pilihan yang baik, tetapi SPA tetap esensial dari sisi struktur, state, skalabilitas, dan maintainability. Menurut saya, CSS modern bisa “melengkapi” SPA, tetapi tidak bisa “menggantikan”-nya.
Sejujurnya, ini terlihat seperti berkata, tentang Rust atau Haskell yang bahkan belum pernah disentuh, "tanpa itu pun sekarang semuanya bisa dilakukan dengan C++ modern."
Memang benar bahwa framework SPA saat ini dan tren frontend yang berbasis padanya perlu terus mewaspadai ketidakstandaran, dan juga mudah memicu overengineering serta konsumsi sumber daya yang tidak perlu…
Pandangan terhadap konsep SPA sendiri juga terasa terlalu sempit, tetapi lebih dari itu, saya jadi ragu apakah benar dipahami dampak framework SPA terhadap keseluruhan proses pengembangan.
Mengatakan bahwa dengan satu View Transitions API dan CSS semuanya selesai, jika dibalik artinya semua fungsi yang tidak terkait dengannya, serta paradigma untuk mencapainya, sepenuhnya tidak bermakna; menurut saya itu sudut pandang yang terlalu arogan.
Itu juga persoalan yang berbeda dari overengineering ketika membuat situs setingkat pengganti brosur dengan React.
Saya setuju bahwa kebanyakan proyek kecil tidak benar-benar memerlukan framework SPA, tetapi untuk layanan yang menuntut interaksi kompleks, pengalaman pengguna yang berkelanjutan, serta pemeliharaan dan peningkatan terus-menerus sebagai requirement, menurut saya tetap tidak demikian meskipun CSS sudah berkembang.
Setahu saya, jika digunakan di Kotlin, ada potensi masalah performa karena primitive akan dibungkus sebagai wrapper sehingga disimpan di heap, bukan di stack. Tentu saja, dalam sebagian besar use case, maintainability lebih diprioritaskan. Selain itu, masalah performa dapat diminimalkan dengan menggunakan value class.
LLM memang bukannya tanpa kekurangan, tetapi saya rasa sulit untuk setuju bahwa semua layanan AI tidak menguntungkan. Saya pikir dalam 5 tahun ke depan, hampir semua layanan platform yang ada saat ini pada akhirnya akan digantikan oleh agen AI.
> Apakah ringkasan ini ingin saya dokumentasikan secara terpisah dalam format laporan ringkasan PDF (ikhtisar ringkasan-pendahuluan-isi-kesimpulan)?
Karena ini ditulis oleh orang yang memang sering mengunggah banyak tulisan, sepertinya bagian ini memang sengaja dimasukkan ya wkwkwk
Tulisan yang menarik. Sepertinya lebih baik mencoba berpikir sendiri dulu sebelum memakai llm
Luar biasa. Saya sangat suka pendekatan seperti ini.
Metodologi optimasi berbasis non-ML yang menyegarkan.
Sepertinya orang ini sedang membicarakan biaya langganan IDE. FLCC memang tidak disediakan di versi gratis.
Tapi juga bukan berarti orang membayar hanya demi itu saja.
Hal yang disayangkan dari tulisan tersebut
Menafsirkan tujuan sebenarnya dari SPA secara terlalu sempit
View Transitions API memang sangat keren, tetapi itu saja tidak berarti SPA menjadi tidak diperlukan.
Melihat semua situs web dengan tolok ukur yang sama
Situs pemasaran ≠ dasbor ≠ aplikasi komersial ≠ alat kolaborasi real-time
Semuanya memiliki kebutuhan struktural yang berbeda.
Dalam praktiknya, SPA + SSR + MPA masih hidup berdampingan
Framework hibrida seperti Next.js menunjukkan hal ini dengan baik.
Aset statis memakai SSG, dasbor setelah login memakai CSR/SPA, dan penyesuaian untuk mesin pencari memakai SSR; kombinasi yang fleksibel seperti ini diperlukan.
Saya rasa SPA bukan hanya soal pengalaman pengguna, tetapi lebih dekat pada hasil dari perbaikan struktur.
Untuk halaman yang tidak memerlukan SPA, MPA + CSS modern mungkin bisa menjadi pilihan yang baik, tetapi SPA tetap esensial dari sisi struktur, state, skalabilitas, dan maintainability. Menurut saya, CSS modern bisa “melengkapi” SPA, tetapi tidak bisa “menggantikan”-nya.
Sejujurnya, ini terlihat seperti berkata, tentang Rust atau Haskell yang bahkan belum pernah disentuh, "tanpa itu pun sekarang semuanya bisa dilakukan dengan C++ modern."
Memang benar bahwa framework SPA saat ini dan tren frontend yang berbasis padanya perlu terus mewaspadai ketidakstandaran, dan juga mudah memicu overengineering serta konsumsi sumber daya yang tidak perlu…
Pandangan terhadap konsep SPA sendiri juga terasa terlalu sempit, tetapi lebih dari itu, saya jadi ragu apakah benar dipahami dampak framework SPA terhadap keseluruhan proses pengembangan.
Mengatakan bahwa dengan satu View Transitions API dan CSS semuanya selesai, jika dibalik artinya semua fungsi yang tidak terkait dengannya, serta paradigma untuk mencapainya, sepenuhnya tidak bermakna; menurut saya itu sudut pandang yang terlalu arogan.
Itu juga persoalan yang berbeda dari overengineering ketika membuat situs setingkat pengganti brosur dengan React.
Saya setuju bahwa kebanyakan proyek kecil tidak benar-benar memerlukan framework SPA, tetapi untuk layanan yang menuntut interaksi kompleks, pengalaman pengguna yang berkelanjutan, serta pemeliharaan dan peningkatan terus-menerus sebagai requirement, menurut saya tetap tidak demikian meskipun CSS sudah berkembang.
Bagus karena ada banyak hal yang sempat dipikirkan saat menangani pencarian vektor.
Setahu saya, jika digunakan di Kotlin, ada potensi masalah performa karena
primitiveakan dibungkus sebagai wrapper sehingga disimpan di heap, bukan di stack. Tentu saja, dalam sebagian besar use case, maintainability lebih diprioritaskan. Selain itu, masalah performa dapat diminimalkan dengan menggunakan value class.Sebagai referensi, tiket dukungan rust: https://github.com/android/ndk/issues/1742
Semoga hal seperti ini juga ada di C++!
Hmm, entahlah. Bukankah tujuan penggunaan framework SPA lebih untuk interaksi yang kompleks dengan pengguna daripada sekadar transisi yang mulus?
Karena berjalan secara lokal, sepertinya tidak perlu biaya.
Menghabiskan $20 ~ $200 per bulan cuma untuk itu rasanya agak...
Sementara itu, Pass:
Hmm...^^;;; saya melakukan kesalahan.. lain kali saya akan meninjau sedikit lebih teliti sebelum mempostingnya..
LLM memang bukannya tanpa kekurangan, tetapi saya rasa sulit untuk setuju bahwa semua layanan AI tidak menguntungkan. Saya pikir dalam 5 tahun ke depan, hampir semua layanan platform yang ada saat ini pada akhirnya akan digantikan oleh agen AI.
> Apakah ringkasan ini ingin saya dokumentasikan secara terpisah dalam format laporan ringkasan PDF (ikhtisar ringkasan-pendahuluan-isi-kesimpulan)?
Karena ini ditulis oleh orang yang memang sering mengunggah banyak tulisan, sepertinya bagian ini memang sengaja dimasukkan ya wkwkwk
Tulisan yang menarik. Sepertinya lebih baik mencoba berpikir sendiri dulu sebelum memakai llm
Ternyata memang benar kalau akurasi dan rasa kepemilikannya rendah.
Bahkan ringkasannya pun pakai LLM..
Saya mengerti, terima kasih.