Awalnya ketika sumber daya komputer langka, disarankan untuk bekerja sedekat mungkin dengan level mesin. Tetapi karena sumber daya perangkat keras menjadi mudah tersedia dan waktu pengembangan menjadi sangat penting, bahasa tingkat yang lebih tinggi mulai muncul. Pengembangan pindah dari C ke C ++ dan kemudian Java dan C #. Seiring dengan tren ini, pemrograman server didominasi oleh bahasa scripting seperti PHP, Python, Perl, dan Ruby. Java dan C # jatuh di suatu tempat antara apa yang disebut “bahasa pemrograman nyata” dan “bahasa scripting”. C # dapat disebut lebih sebagai pengganti Microsoft untuk Java. Begitu banyak fakta yang berlaku untuk Java juga cocok untuk C #.
Karena Jawa datang dengan janji kemerdekaan platform, ia dengan cepat memperoleh popularitas. Ini bukan bahasa scripting atau bahasa yang dikompilasi dan mengembalikan kode byte yang dapat berjalan di “Java Virtual Machine”. Jadi JRE berfungsi sebagai mesin untuk Java seperti bahasa scripting lainnya membutuhkan mesin untuk interpretasi. Java jelas mengubah cara kami memandang bahasa pemrograman nyata. Java semakin cepat setiap tahun dan memberikan tantangan berat bagi C ++ dalam hal kinerja. Dan platform independensi dari kode byte memberi orang jenis kebebasan yang mereka miliki dengan bahasa scripting. Java dirancang untuk menjadi salah satu solusi untuk setiap platform yaitu desktop, browser, server, dan sistem embedded.
Tetapi karena dengan setiap teknologi yang baik tentu ada beberapa masalah dengan Java juga. Java gagal membuat tanda ketika datang ke browser. Meskipun applet dan java web start dirancang untuk membuatnya menjadi pilihan yang baik untuk menyebarkan aplikasi web tetapi entah bagaimana itu tidak berfungsi dengan baik. Applet segera menjadi teknologi yang sudah ketinggalan zaman. Tetapi kemalangan Jawa tidak berakhir dengan applet, itu diteruskan dan pengembang menghadapi masalah dengan perpustakaan GUI Jawa. Tidak peduli seberapa keras Sun bekerja dalam membuat toolkit GUI untuk Java, pengembang tampaknya tidak pernah puas dengan hal itu. Meskipun, sebagian besar komponen Java Swing Toolkit masih berfungsi dengan baik, membangun antarmuka ujung depan yang indah tetap menjadi impian yang jauh bagi pengembang Java.
Gelombang internet membawa serangkaian bahasa scripting untuk kedua sisi server dan klien. Sebagai aplikasi web mulai mendapatkan popularitas bahasa scripting ini mulai mendominasi dunia pemrograman. Meskipun skrip server menawarkan rasa PHP, Python, Perl, ASP dll, sisi klien tetap didominasi oleh JavaScript. Baru-baru ini popularitas AJAX telah menempatkan JavaScript di garis depan ketika datang untuk mengembangkan aplikasi web.
Komunitas web telah mendapatkan begitu banyak didorong oleh potensi aplikasi web sehingga Flash, Action Script, HTML5, JavaScript, Silverlight, AJAX adalah satu-satunya teknologi yang mereka pikir akan bertahan di sisi klien. Semua ini karena teknologi lain tidak dapat memberikan GUI sisi klien yang cantik tanpa sistem operasi. Jadi menurut mereka satu-satunya pilihan yang tersisa adalah menciptakan semua antarmuka yang indah dan kaya fitur dalam browser dan menjaga seluruh pemrosesan dan data di sisi server. Kecenderungan seluruh dunia menuju komputasi awan hanya membuktikan pola pikir ini.
Tidak diragukan lagi komputasi sisi server dan manajemen data (cloud computing) memiliki manfaat luar biasa. Tetapi merencanakannya sebagai solusi akhir untuk komputasi masa depan tampaknya bukan tindakan yang bijaksana. Jika kita mengatakan komputasi awan adalah komputasi generasi berikutnya, maka kita langsung mengatakan bahwa proses komputasi kita akan dipecah menjadi proses sisi klien dan server. Dan kami berharap semuanya menjadi lebih efisien, yaitu jumlah waktu pemrosesan server dan waktu pemrosesan browser menjadi kurang dari waktu memproses semuanya di sisi klien. Sekarang asumsi ini secara logis salah.
Selain itu, memberikan sisi klien di tangan bahasa skrip kami memastikan bahwa kami tidak akan pernah lebih cepat dari bahasa skrip sisi klien tercepat. Jadi, dengan melakukan ini, apakah kita tidak akan membuang tahun-tahun upaya pengoptimalan kinerja yang dilakukan untuk bahasa seperti Java menjadi sia-sia? Tentu saja, Java dapat dan akan bertahan dalam banyak bentuk lagi, tetapi dengan menyematkan hampir setiap aplikasi dari pemrosesan teks hingga gaming ke browser, kami pasti akan memperlambat pengalaman komputasi kami. Kami akan bergantung pada bandwidth internet, bahasa scripting, dan kapabilitas browser kami.
Tren ini dapat dibenarkan jika kita benar-benar kekurangan teknologi untuk membuat aplikasi sisi klien yang efisien dan interaktif. Tetapi menghambat aliran komputasi cepat hanya karena API dan toolkit bahasa kami agak gagal mengembangkan platform independen GUI yang kaya fitur, tampaknya tidak perlu dilakukan. Kami ingin mengembangkan browser sebagai mesin untuk menjalankan semua aplikasi kami. Tetapi tidak seperti mesin yang ada, itu hanya akan membuat GUI dan melakukan perhitungan dasar untuk kita dan mendelegasikan pekerjaan yang tersisa ke mesin server lain. Tidak seperti mesin sebenarnya, JRE yang sanggup melakukan setiap operasi. Jelas, peramban sebagai mesin untuk menjalankan aplikasi menguntungkan ketika aplikasi perlu menangani data yang disimpan di server atau informasi dibagikan dan dimodifikasi oleh sekelompok orang seperti di situs jejaring sosial, forum, dll. Tetapi memasukkan setiap aplikasi lain ke dalam peramban sama seperti menempatkan gajah ke dalam sangkar burung. Setiap aplikasi memiliki persyaratan sendiri sumber daya perangkat keras dan daya komputasi, yang diperlukan untuk pengalaman pengguna yang baik. Dan hanya karena beberapa orang memiliki akses ke bandwidth besar kami tidak dapat menghilangkan orang lain dari pengalaman komputasi yang sebenarnya.
Karena kemudahan pengembangan, kemandirian platform, sejumlah besar API dan kinerja tinggi Java masih berpotensi menciptakan aplikasi desktop yang mewah. Itu hanya perlu perhatian terus menerus dari pengembang. Bukan hanya aplikasi desktop, tetapi juga dapat digunakan untuk membuat aplikasi klien besar yang melakukan komputasi paling banyak di sisi klien dan bertukar data dengan server sesuai persyaratan seperti klien obrolan, game multi pemain, dll.