Konsepnya sendiri sesekali pernah saya lihat, tetapi saya terkejut karena halaman webnya dibuat dengan sangat baik sehingga fitur-fiturnya bisa langsung dicoba dan dipahami dalam sekali lihat.
Di tengah rasa kantuk, ini jadi pengalaman yang menyenangkan dan bikin mata langsung melek.
Sejak awal, kalau situasinya hanya mempertimbangkan SPA karena alasan "kelancaran", saya justru akan memilih mengorbankan sedikit kelancaran dan menulisnya sebagai MPA, jadi saya pribadi tidak terlalu bisa berempati dengan argumen itu...
Sejujurnya ada juga beberapa orang yang sebenarnya tidak ada kerjaan, tapi tetap memaksa menjalankan banyak sesi sekaligus buat memaksimalkan langganannya...
Dari contoh yang Anda ajukan, satu-satunya yang tidak bisa digantikan dari SPA dengan view transition dan semacamnya hanyalah alat kolaborasi real-time, dan mayoritas situs web bukanlah alat kolaborasi real-time. Situs marketing, dashboard, dan aplikasi commerce semuanya bisa dibangun sambil menyingkirkan framework SPA serta tetap memenuhi syarat rendering di server, halaman penuh, animasi berbasis CSS, preloading yang disengaja, dan penggunaan JS seminimal mungkin. Ada juga Hotwire dari ekosistem Rails yang mengarah ke pendekatan ini, dan ini punya contoh produksi seperti Basecamp dan Hey. Manajemen state? Selama bukan sesuatu seperti alat kolaborasi real-time, itu cukup ditangani dengan metode sisi server seperti parameter URL dan sesi server, atau dengan local storage. Memang ada kasus yang mengadopsi SPA hanya karena perpindahan halaman (seperti situs resmi AGF, yang sebenarnya Astro pun sudah cukup tetapi tetap mengadopsi React), dan tidak bisa disangkal bahwa perpindahan halaman adalah hal yang sering disebut sebagai keunggulan representatif SPA.
Memang ada kasus di mana framework SPA diadopsi hanya demi satu interaksi yang mulus. Sebagian besar situs yang menerapkan SPA sebenarnya tidak memerlukan interaksi yang kompleks.
Tidak semuanya adalah endofunctor. Hal seperti Result<T, E> yang punya beberapa parameter tipe bukanlah 𝒞 → 𝒞, melainkan Result : 𝒞 × 𝒞 → 𝒞, jadi yang seperti ini adalah bifunctor.
Tepat sekali!
Sepertinya ada kesalahpahaman dalam proses menerapkan konten yang ditulis dalam bahasa lain dengan acuan Rust.
Karena sistem tipe Rust membentuk satu kategori tunggal, tampaknya pembedaan antara endofunctor dan functor umum menjadi tidak bermakna.
Sayangnya blog tersebut tidak memiliki fitur komentar, jadi saya rasa saya perlu menanyakan apakah memungkinkan untuk meminta revisi.
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."
Di sana juga yang banyak cuma jumlah orangnya, yang dikerjain ya sama aja kayak di sini wkwkwk
Mulai dengan "Han" dan berakhir dengan "guk"—terasa seperti keseharian di sebuah negara yang sudah sangat familiar.
Konsepnya sendiri sesekali pernah saya lihat, tetapi saya terkejut karena halaman webnya dibuat dengan sangat baik sehingga fitur-fiturnya bisa langsung dicoba dan dipahami dalam sekali lihat.
Di tengah rasa kantuk, ini jadi pengalaman yang menyenangkan dan bikin mata langsung melek.
Sejak awal, kalau situasinya hanya mempertimbangkan SPA karena alasan "kelancaran", saya justru akan memilih mengorbankan sedikit kelancaran dan menulisnya sebagai MPA, jadi saya pribadi tidak terlalu bisa berempati dengan argumen itu...
Sejujurnya ada juga beberapa orang yang sebenarnya tidak ada kerjaan, tapi tetap memaksa menjalankan banyak sesi sekaligus buat memaksimalkan langganannya...
Dari contoh yang Anda ajukan, satu-satunya yang tidak bisa digantikan dari SPA dengan view transition dan semacamnya hanyalah alat kolaborasi real-time, dan mayoritas situs web bukanlah alat kolaborasi real-time. Situs marketing, dashboard, dan aplikasi commerce semuanya bisa dibangun sambil menyingkirkan framework SPA serta tetap memenuhi syarat rendering di server, halaman penuh, animasi berbasis CSS, preloading yang disengaja, dan penggunaan JS seminimal mungkin. Ada juga Hotwire dari ekosistem Rails yang mengarah ke pendekatan ini, dan ini punya contoh produksi seperti Basecamp dan Hey. Manajemen state? Selama bukan sesuatu seperti alat kolaborasi real-time, itu cukup ditangani dengan metode sisi server seperti parameter URL dan sesi server, atau dengan local storage. Memang ada kasus yang mengadopsi SPA hanya karena perpindahan halaman (seperti situs resmi AGF, yang sebenarnya Astro pun sudah cukup tetapi tetap mengadopsi React), dan tidak bisa disangkal bahwa perpindahan halaman adalah hal yang sering disebut sebagai keunggulan representatif SPA.
Memang ada kasus di mana framework SPA diadopsi hanya demi satu interaksi yang mulus. Sebagian besar situs yang menerapkan SPA sebenarnya tidak memerlukan interaksi yang kompleks.
Tidak semuanya adalah endofunctor. Hal seperti
Result<T, E>yang punya beberapa parameter tipe bukanlah 𝒞 → 𝒞, melainkanResult : 𝒞 × 𝒞 → 𝒞, jadi yang seperti ini adalah bifunctor.Tepat sekali!
Sepertinya ada kesalahpahaman dalam proses menerapkan konten yang ditulis dalam bahasa lain dengan acuan Rust.
Karena sistem tipe Rust membentuk satu kategori tunggal, tampaknya pembedaan antara endofunctor dan functor umum menjadi tidak bermakna.
Sayangnya blog tersebut tidak memiliki fitur komentar, jadi saya rasa saya perlu menanyakan apakah memungkinkan untuk meminta revisi.
Artikel yang bagus! Namun, penjelasan terkait endofunctor tampaknya mengandung kesalahan, jadi akan lebih baik jika diperbaiki https://x.com/simnalamburt/status/1950074970647761168?s=46
king - man + woman = queenFitur-fitur yang rasanya bakal enak kalau ada, semuanya masuk. Ini sendirian sudah menjalankan semua fungsi NAS.
Bahkan hanya dengan melihat situs demonya saja sudah sangat mengesankan. Dengan kode yang benar-benar singkat, banyak fitur yang didukung.
Namu Wiki...
Saya kurang paham bagaimana verifikasi usia dan perlindungan privasi bisa dipakai bersamaan..
Bukankah pada saat melakukan verifikasi, setidaknya sekali saya meninggalkan tanda tangan saya di sana?
Kalau benar-benar ingin melindungi privasi, seharusnya bisa digunakan secara anonim
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."