Ini memang tepat seperti yang saya butuhkan dan sedang saya buat, ternyata mereka sudah membuatnya... Saya memakai Claude Code Max, dan saat mengembangkan beberapa proyek sekaligus, ini benar-benar software yang saya butuhkan.
Saya cukup banyak berempati dengan masalah pemborosan ruang disk ini...
Saya mengelola AKS, dan setiap kali melihat aplikasi Python dengan image container yang ukurannya melewati 1GB, kepala saya rasanya pusing.
Sekarang saya biasanya cuma mengambil Dockerfile lalu mengecilkan ukurannya sendiri sebelum diunggah lagi, dan kalau tidak bisa saya turunkan sampai di bawah 500MB, ya saya menyerah saja wkwk
Wow...! Saat pertama kali memakainya, itu proyek yang kupakai karena berbasis Python...
Waktu berlalu begitu lama ya!
Akan menyenangkan kalau bisa bekerja lagi di lingkungan tempat aku bisa memakainya :) hahaha
Apa coba iseng buat side project ya...
Sekitar pukul 7.00 waktu Korea sempat mengalami gangguan selama kurang lebih 50 menit, tetapi sekarang sudah berfungsi dengan baik.
CMD> nslookup news.hada.io 1.1.1.1
Mungkin cukup satu mesin yang sangat mantap dengan harga yang sangat mantap? Firma hukum yang sangat mantap bakal pilih beli saja, sih. Tapi ya seperti menjalankan mesin pabrik 24 jam terus wkwk
Maksud tulisan aslinya bukan sekadar mengkritik framework JS yang kian rumit.
Agar praktis, saya akan mengutip dari tautan terjemahan bahasa Korea di atas.
> Sekarang, bahkan untuk sekadar mengubah satu judul saja dibutuhkan 4 engineer, 3 framework, dan pipeline CI/CD. Menerbitkan halaman web telah menjadi sesuatu yang rumit secara tidak masuk akal.
> Sedikit demi sedikit, web telah berubah menjadi sesuatu yang harus dikompilasi sebelum dipublikasikan. Bukan karena pengguna membutuhkannya. Melainkan karena developer ingin merasa modern.
> Semua hal dioptimalkan untuk developer, dan menjadi tidak ramah bagi semua orang lainnya.
> Kita bukan lagi sekadar menoleransi kompleksitas, tetapi menganggapnya sebagai sesuatu yang wajar. Kita berasumsi bahwa setiap situs memerlukan tahap build, bundler, strategi hidrasi, lapisan routing, lapisan API, design system, serta logika invalidasi cache yang cerdik. Kita membangunnya sebagai microservices, meng-host-nya di edge network, dan menerapkan pipeline hanya untuk menyajikan konten yang sederhana.
> Kita sedang membangun ulang fungsi platform seperti WordPress, tetapi hasilnya 10 kali lebih berat dan jauh lebih buruk dalam hal kegunaan. Yang lebih buruk lagi, setiap lapisan baru menambahkan bug baru, masalah kompatibilitas baru, dan beban kognitif baru. Kini kita memelihara logika hidrasi, strategi cache, dan pipeline build hanya agar sebuah homepage sederhana bisa online.
> Kampanye marketing tertunda karena library komponen tidak cukup fleksibel. A/B test dibatalkan karena lapisan analitik tidak kompatibel dengan strategi hidrasi. Pembaruan konten harus menunggu build selama berhari-hari. Penyesuaian SEO dasar pun tenggelam di backlog.
> Marketer tidak bisa memperbarui copy atau menjalankan eksperimen tanpa membuat tiket. Mereka tidak bisa mem-pratinjau konten, menguji layout, atau memublikasikan halaman. Setiap perubahan harus melewati developer, pipeline, persetujuan, dan build ulang.
> Marketer, editor konten, penanggung jawab SEO, dan desainer semuanya tersingkir dari proses. Karena sekarang bahkan tugas sederhana pun membutuhkan kefasihan teknis. Jika Anda ingin mengganti title tag, Anda akan diminta berkonsultasi dengan engineer, dan jika ingin meluncurkan kampanye, Anda akan diminta membuat tiket lalu menunggu dua sprint.
> Semua hal mengalir melalui tim developer. Artinya, tim developer lah yang menentukan apa yang penting, apa yang dirilis, dan apa yang didorong ke belakang prioritas tanpa batas waktu. Dan semakin banyak kompleksitas yang mereka tambahkan, semakin tak tergantikan pula mereka.
Saya setuju dengan masalah 'kompleksitas web yang berlebihan' yang ditunjukkan tulisan aslinya. Namun, saya sulit setuju dengan diagnosis yang hanya menyalahkan budaya developer atau penyalahgunaan framework sebagai penyebabnya. Kompleksitas web saat ini sebagian besar juga merupakan bayang-bayang dari fungsi dan keamanan yang secara tak terelakkan dituntut oleh 'model bisnis'. Tanpa memasukkan poin ini, diagnosisnya mau tak mau hanya akan menjadi setengah matang.
Web bukan lagi sekadar ‘ruang pamer gratis’. Saat ini, selain situs publik, sebagian besar layanan web bertujuan menghasilkan pendapatan. Karena itu, pertanyaan inti dalam memilih teknologi seharusnya bukan “apakah kode ini murni?”, melainkan “apakah teknologi ini membuat bisnis kita berhasil?”.
Dilihat dari sudut pandang ini, ‘web konten ringan’ yang digambarkan secara ideal oleh tulisan asli akan berbenturan dengan tembok kebutuhan bisnis di dunia nyata. Misalnya, bisnis yang menjual konten tidak mungkin dijalankan hanya dengan halaman statis sederhana. Untuk menangani langganan berbayar dan pembayaran, diperlukan logika berbasis status seperti autentikasi pengguna, pemeriksaan status langganan, dan manajemen izin; untuk melindungi konten, lapisan keamanan seperti verifikasi token real-time guna mencegah pembajakan atau akses tanpa izin juga mutlak diperlukan. Lebih jauh lagi, untuk meningkatkan pengalaman pengguna dan conversion rate melalui personalisasi dan A/B test, pemrosesan data dinamis juga dibutuhkan.
Semua ini berada di ranah 'aplikasi yang canggih', dan framework adalah alat yang realistis untuk mewujudkannya.
Tentu saja, tidak semua kompleksitas bisa dibenarkan. Kita perlu membedakan kompleksitas menjadi dua jenis.
Kompleksitas yang tak terelakkan: kompleksitas dengan ROI yang jelas, yang muncul untuk mengimplementasikan fungsi bisnis (autentikasi, pembayaran, personalisasi, dan sebagainya). Ini adalah biaya yang harus ditanggung.
Kompleksitas insidental: kompleksitas yang tidak perlu, yang muncul karena kemudahan pengembangan atau abstraksi teknis yang berlebihan. Ini adalah utang teknis sekaligus pemborosan yang harus terus diukur dan dihilangkan.
Layanan yang sukses membedakan kedua hal ini dan membangun arsitektur yang realistis. Artinya, bagian terdepan yang penting untuk marketing dan SEO dibuat seringan mungkin, sementara area internal yang memerlukan transaksi inti atau fitur personalisasi dijaga kestabilannya dengan basis framework, melalui strategi hybrid yang memungkinkan mereka meraih dua hal sekaligus: kecepatan dan fungsionalitas.
Tulisan asli terlalu memusatkan penyebab memburuknya pengalaman pengguna pada budaya framework, sambil mengesampingkan ‘tuntutan yang tak terelakkan akibat model pendapatan’. Membahas pengembangan web tanpa poin ini tak ubahnya seperti hanya membicarakan menyajikan 'hidangan yang cepat dan lezat' ke meja pelanggan, sambil menganggap tidak ada dapur kompleks yang menyiapkannya dan kasir tempat pembayaran diterima.
Hanya karena web terasa berat, kita tidak bisa serta-merta membuang framework. Menurut saya, pokok persoalannya haruslah bagaimana mengimplementasikan fungsi yang dituntut bisnis seefisien mungkin, dengan biaya serendah mungkin, lalu menyampaikan nilainya kepada pengguna.
Untuk layanan seperti chatbot yang harus menyediakan fitur streaming, saat menangani permintaan secara bersamaan, proses prefill ikut terdampak hingga tahap decode, sehingga meskipun VRAM cukup lega, dari sudut pandang pengguna performanya terlihat sangat menurun.
Saya juga sudah mencoba opsi terkait chunk prefill dan fitur Disaggregated Prefilling yang disediakan secara eksperimental di vLLM, tetapi ketika permintaan baru masuk, jawaban yang sedang dihasilkan tetap terputus-putus. Jadi, sebagai pengembang pemula, saya penasaran apakah ada cara yang paling efisien selain menambah GPU atau node.
Ini memang tepat seperti yang saya butuhkan dan sedang saya buat, ternyata mereka sudah membuatnya... Saya memakai Claude Code Max, dan saat mengembangkan beberapa proyek sekaligus, ini benar-benar software yang saya butuhkan.
Selamat ulang tahun, Django!
Versi terjemahan bahasa Korea ada di bawah ini.
https://roy-jung.github.io/250701-history-of-js/
Akan lebih baik kalau peningkatan besar, keunggulan, dan akurasinya ditunjukkan dengan angka.
Saya penasaran bagaimana perbedaannya di Korea.
Saya cukup banyak berempati dengan masalah
pemborosan ruang diskini...Saya mengelola AKS, dan setiap kali melihat aplikasi Python dengan image container yang ukurannya melewati 1GB, kepala saya rasanya pusing.
Sekarang saya biasanya cuma mengambil Dockerfile lalu mengecilkan ukurannya sendiri sebelum diunggah lagi, dan kalau tidak bisa saya turunkan sampai di bawah 500MB, ya saya menyerah saja wkwk
Wow...! Saat pertama kali memakainya, itu proyek yang kupakai karena berbasis Python...
Waktu berlalu begitu lama ya!
Akan menyenangkan kalau bisa bekerja lagi di lingkungan tempat aku bisa memakainya :) hahaha
Apa coba iseng buat side project ya...
Bukankah membandingkannya dengan Claude 3 saat Claude 4 sudah keluar itu hampir seperti menipu...
Sekitar pukul 7.00 waktu Korea sempat mengalami gangguan selama kurang lebih 50 menit, tetapi sekarang sudah berfungsi dengan baik.
CMD> nslookup news.hada.io 1.1.1.1
Saya juga terus menerima notifikasi push Android yang mengatakan tidak dapat mengakses server DNS.
Untuk sementara saya beralih ke Google DNS.
https://developers.google.com/speed/public-dns/…
wow...
Betul, sepertinya semakin kita menggali secara mendalam apa tujuannya dan mengapa hal itu perlu dilakukan, semakin jelas solusi yang muncul.
Terima kasih sudah membaca dengan baik!
Terima kasih atas kata-kata baiknya!
Mungkin cukup satu mesin yang sangat mantap dengan harga yang sangat mantap? Firma hukum yang sangat mantap bakal pilih beli saja, sih. Tapi ya seperti menjalankan mesin pabrik 24 jam terus wkwk
Tipe orang yang cuma memikirkan harga Porsche, tanpa memikirkan sama sekali biaya perawatan, bensin, asuransi, dan sebagainya
Maksud tulisan aslinya bukan sekadar mengkritik framework JS yang kian rumit.
Agar praktis, saya akan mengutip dari tautan terjemahan bahasa Korea di atas.
> Sekarang, bahkan untuk sekadar mengubah satu judul saja dibutuhkan 4 engineer, 3 framework, dan pipeline CI/CD. Menerbitkan halaman web telah menjadi sesuatu yang rumit secara tidak masuk akal.
> Sedikit demi sedikit, web telah berubah menjadi sesuatu yang harus dikompilasi sebelum dipublikasikan. Bukan karena pengguna membutuhkannya. Melainkan karena developer ingin merasa modern.
> Semua hal dioptimalkan untuk developer, dan menjadi tidak ramah bagi semua orang lainnya.
> Kita bukan lagi sekadar menoleransi kompleksitas, tetapi menganggapnya sebagai sesuatu yang wajar. Kita berasumsi bahwa setiap situs memerlukan tahap build, bundler, strategi hidrasi, lapisan routing, lapisan API, design system, serta logika invalidasi cache yang cerdik. Kita membangunnya sebagai microservices, meng-host-nya di edge network, dan menerapkan pipeline hanya untuk menyajikan konten yang sederhana.
> Kita sedang membangun ulang fungsi platform seperti WordPress, tetapi hasilnya 10 kali lebih berat dan jauh lebih buruk dalam hal kegunaan. Yang lebih buruk lagi, setiap lapisan baru menambahkan bug baru, masalah kompatibilitas baru, dan beban kognitif baru. Kini kita memelihara logika hidrasi, strategi cache, dan pipeline build hanya agar sebuah homepage sederhana bisa online.
> Kampanye marketing tertunda karena library komponen tidak cukup fleksibel. A/B test dibatalkan karena lapisan analitik tidak kompatibel dengan strategi hidrasi. Pembaruan konten harus menunggu build selama berhari-hari. Penyesuaian SEO dasar pun tenggelam di backlog.
> Marketer tidak bisa memperbarui copy atau menjalankan eksperimen tanpa membuat tiket. Mereka tidak bisa mem-pratinjau konten, menguji layout, atau memublikasikan halaman. Setiap perubahan harus melewati developer, pipeline, persetujuan, dan build ulang.
> Marketer, editor konten, penanggung jawab SEO, dan desainer semuanya tersingkir dari proses. Karena sekarang bahkan tugas sederhana pun membutuhkan kefasihan teknis. Jika Anda ingin mengganti title tag, Anda akan diminta berkonsultasi dengan engineer, dan jika ingin meluncurkan kampanye, Anda akan diminta membuat tiket lalu menunggu dua sprint.
> Semua hal mengalir melalui tim developer. Artinya, tim developer lah yang menentukan apa yang penting, apa yang dirilis, dan apa yang didorong ke belakang prioritas tanpa batas waktu. Dan semakin banyak kompleksitas yang mereka tambahkan, semakin tak tergantikan pula mereka.
Sepertinya tidak akan berlaku untuk perusahaan Korea.
Saya setuju dengan masalah 'kompleksitas web yang berlebihan' yang ditunjukkan tulisan aslinya. Namun, saya sulit setuju dengan diagnosis yang hanya menyalahkan budaya developer atau penyalahgunaan framework sebagai penyebabnya. Kompleksitas web saat ini sebagian besar juga merupakan bayang-bayang dari fungsi dan keamanan yang secara tak terelakkan dituntut oleh 'model bisnis'. Tanpa memasukkan poin ini, diagnosisnya mau tak mau hanya akan menjadi setengah matang.
Web bukan lagi sekadar ‘ruang pamer gratis’. Saat ini, selain situs publik, sebagian besar layanan web bertujuan menghasilkan pendapatan. Karena itu, pertanyaan inti dalam memilih teknologi seharusnya bukan “apakah kode ini murni?”, melainkan “apakah teknologi ini membuat bisnis kita berhasil?”.
Dilihat dari sudut pandang ini, ‘web konten ringan’ yang digambarkan secara ideal oleh tulisan asli akan berbenturan dengan tembok kebutuhan bisnis di dunia nyata. Misalnya, bisnis yang menjual konten tidak mungkin dijalankan hanya dengan halaman statis sederhana. Untuk menangani langganan berbayar dan pembayaran, diperlukan logika berbasis status seperti autentikasi pengguna, pemeriksaan status langganan, dan manajemen izin; untuk melindungi konten, lapisan keamanan seperti verifikasi token real-time guna mencegah pembajakan atau akses tanpa izin juga mutlak diperlukan. Lebih jauh lagi, untuk meningkatkan pengalaman pengguna dan conversion rate melalui personalisasi dan A/B test, pemrosesan data dinamis juga dibutuhkan.
Semua ini berada di ranah 'aplikasi yang canggih', dan framework adalah alat yang realistis untuk mewujudkannya.
Tentu saja, tidak semua kompleksitas bisa dibenarkan. Kita perlu membedakan kompleksitas menjadi dua jenis.
Kompleksitas yang tak terelakkan: kompleksitas dengan ROI yang jelas, yang muncul untuk mengimplementasikan fungsi bisnis (autentikasi, pembayaran, personalisasi, dan sebagainya). Ini adalah biaya yang harus ditanggung.
Kompleksitas insidental: kompleksitas yang tidak perlu, yang muncul karena kemudahan pengembangan atau abstraksi teknis yang berlebihan. Ini adalah utang teknis sekaligus pemborosan yang harus terus diukur dan dihilangkan.
Layanan yang sukses membedakan kedua hal ini dan membangun arsitektur yang realistis. Artinya, bagian terdepan yang penting untuk marketing dan SEO dibuat seringan mungkin, sementara area internal yang memerlukan transaksi inti atau fitur personalisasi dijaga kestabilannya dengan basis framework, melalui strategi hybrid yang memungkinkan mereka meraih dua hal sekaligus: kecepatan dan fungsionalitas.
Tulisan asli terlalu memusatkan penyebab memburuknya pengalaman pengguna pada budaya framework, sambil mengesampingkan ‘tuntutan yang tak terelakkan akibat model pendapatan’. Membahas pengembangan web tanpa poin ini tak ubahnya seperti hanya membicarakan menyajikan 'hidangan yang cepat dan lezat' ke meja pelanggan, sambil menganggap tidak ada dapur kompleks yang menyiapkannya dan kasir tempat pembayaran diterima.
Hanya karena web terasa berat, kita tidak bisa serta-merta membuang framework. Menurut saya, pokok persoalannya haruslah bagaimana mengimplementasikan fungsi yang dituntut bisnis seefisien mungkin, dengan biaya serendah mungkin, lalu menyampaikan nilainya kepada pengguna.
Untuk layanan seperti chatbot yang harus menyediakan fitur streaming, saat menangani permintaan secara bersamaan, proses prefill ikut terdampak hingga tahap decode, sehingga meskipun VRAM cukup lega, dari sudut pandang pengguna performanya terlihat sangat menurun.
Saya juga sudah mencoba opsi terkait chunk prefill dan fitur Disaggregated Prefilling yang disediakan secara eksperimental di vLLM, tetapi ketika permintaan baru masuk, jawaban yang sedang dihasilkan tetap terputus-putus. Jadi, sebagai pengembang pemula, saya penasaran apakah ada cara yang paling efisien selain menambah GPU atau node.