Mengapa basis kode dalam pengembangan n-tier memiliki jumlah kode JavaScript yang sama, jika tidak lebih, sekarang?

Saya telah melakukan pemrograman web untuk waktu yang lama sekarang, dan di suatu tempat, saya kehilangan jejak mengapa kita melakukan apa yang kita lakukan hari ini (atau bagaimana kita melakukan hal-hal seperti ini)?

Saya mulai dengan pengembangan web ASP dasar, dan sangat awal, tampilan dan logika bisnis dicampur pada halaman. Pengembangan sisi klien sangat bervariasi (VBScript, berbagai rasa JavaScript), dan kami memiliki banyak peringatan tentang validasi sisi-server (dan jadi saya menjauh dari logika sisi klien).

Saya kemudian pindah ke ColdFusion untuk sementara waktu. ColdFusion mungkin merupakan kerangka pengembangan web pertama yang memisahkan tampilan dan logika bisnis menggunakan tag mereka. Tampaknya sangat jelas bagi saya, tetapi sangat bertele-tele, dan ColdFusion tidak dalam permintaan pasar yang tinggi, jadi saya pindah.

Saya kemudian melompat pada kereta band ASP.NET dan mulai menggunakan pendekatan MVC mereka. Saya juga menyadari bahwa Java tampaknya merupakan bahasa menara gading dari sistem perusahaan, dan juga mencoba pendekatan MVC mereka. Kemudian, ASP.NET mengembangkan pola desain MVVM ini, dan Java (tepatnya, J2EE atau JEE) juga berjuang dan keluar dengan pendekatan MVC2-nya.

Tetapi hari ini, apa yang saya temukan adalah bahwa pemrograman backend bukan lagi tempat yang menyenangkan dan maju. Juga, praktik MVC berbasis sisi server tampaknya sudah usang (apakah orang benar-benar menggunakan JSTL lagi?). Hari ini, di sebagian besar proyek yang saya jalani, saya menemukan bahwa kerangka kerja JavaScript dan pengembangan sisi klien adalah tempat semua kemajuan menarik dan inovatif sedang dibuat.

Mengapa perpindahan dari server ke pengembangan sisi klien ini terjadi? Saya melakukan penghitungan baris sederhana dari salah satu proyek JEE saya, dan ada lebih banyak baris kode dalam JavaScript daripada Java (tidak termasuk perpustakaan pihak ketiga). Saya menemukan bahwa sebagian besar pengembangan backend menggunakan bahasa pemrograman seperti Java atau C # hanya untuk menghasilkan antarmuka seperti REST, dan bahwa semua upaya keras tampilan, visualisasi, input / output data, interaksi pengguna, dll ... sedang ditangani melalui kerangka sisi klien seperti Angular, Backbone, Ember, Knockout, dll ...

Selama era pra-jQuery, saya melihat banyak diagram di mana ada garis konseptual yang jelas antara M, V, dan C dalam MVC dalam pengembangan n-tier. Post-jQuery, di mana garis-garis ini digambar? Tampaknya MVC dan MVVM semuanya ada di sana dalam kode JavaScript, sisi klien.

Yang ingin saya ketahui adalah, mengapa kita melakukan transisi semacam itu (dari penekanan pemrograman sisi server ke sisi klien, dari mendukung bahasa yang dikompilasi ke bahasa scripting, dari imperatif ke pemrograman fungsional, semua ini tampaknya telah terjadi secara bersamaan ) dan masalah apa yang dipecahkan oleh transisi / pergeseran ini?

Menggeser beban komputasi antara server dan klien adalah fenomena siklus, dan telah terjadi selama beberapa waktu.

Ketika saya masih di community college, Personal Computer baru saja mulai bersemangat. Tetapi Ethernet belum digunakan secara luas, dan tidak ada yang memiliki jaringan area lokal. Saat itu, perguruan tinggi memiliki mainframe yang menangani catatan siswa dan berfungsi sebagai platform untuk kelas pemrograman. Administrasi memiliki terminal yang terhubung ke mainframe berdasarkan pembagian waktu, tetapi siswa harus meninju kartu untuk menyelesaikan tugas pemrograman mereka, proses yang sulit. Akhirnya, mereka menempatkan di sebuah lab di mana para siswa dapat mendaftar untuk waktu di terminal, tetapi mungkin butuh setengah jam atau lebih untuk mendapatkan cetakan kesalahan setebal setengah inci Anda. Semua pekerjaan pemrosesan dilakukan pada mainframe (server).

Tetapi mainframe itu mahal, jadi perusahaan mulai memasang jaringan area lokal, dan beban pemrosesan bergeser dari server ke mesin klien individu, yang cukup kuat untuk menjalankan pengolah kata, spreadsheet, dan lini aplikasi bisnis, tetapi tidak cukup kuat untuk berbagi kekuatan pemrosesan mereka dengan orang lain. Server adalah mesin yang serupa dengan kemampuan yang sama (mungkin lebih banyak memori dan ruang hard drive), tetapi sebagian besar digunakan untuk berbagi file. Ini disebut Client / Server. Sebagian besar pemrosesan telah bergeser ke komputer klien.

Salah satu kelemahan dari melakukan semua pemrosesan pada mesin klien adalah Anda terkunci dalam siklus instalasi dan peningkatan perangkat lunak yang berkelanjutan ini, dan semua sakit kepala yang menyertainya. Model pemrograman mesin-mesin ini (berbasis-antarmuka, antarmuka pengguna di belakang kode) mendorong terciptanya program-program yang berantakan dan sulit dipelihara (bola-bola lumpur besar). Sebagian besar pengguna akhir tidak memiliki keterampilan untuk memelihara perangkat keras dan perangkat lunak mereka dengan benar, memerlukan pasukan personil pemeliharaan TI.

Ketika komputer menjadi semakin kuat, pembagian kerja menjadi mungkin. Sekarang Anda dapat memiliki server file, server database, server web, server cetak dan sebagainya. Setiap mesin dapat sedikit dioptimalkan untuk tugas yang disediakan, dan dikelola oleh seseorang dengan keahlian yang diperlukan. Program dapat ditulis yang berjalan di browser web, jadi instalasi klien tidak lagi diperlukan. Ini disebut Multi-Tier atau n-Tier. Browser pada dasarnya digunakan sebagai terminal bisu, seperti pada hari-hari mainframe, meskipun metode berkomunikasi dengan server lebih canggih, kurang eksklusif, dan didasarkan pada mekanisme interupsi daripada pembagian waktu dan pemungutan suara. Pemrosesan telah bergeser kembali ke server.

Namun, pengembangan web datang dengan set baru sakit kepala. Sebagian besar lini aplikasi bisnis yang ditulis untuk browser adalah formulir dan laporan statis. Ada sedikit interaktivitas yang tersedia di UI. Javascript belum menemukan angin kedua, dan ada masalah besar dengan inkompatibilitas peramban yang menghambat adopsi meluas. Namun, segalanya menjadi jauh lebih baik. HTML5 dan CSS3 memberikan kemampuan baru yang substansial untuk model pemrograman browser, jQuery keluar dan membantu seluruh generasi programmer menemukan betapa bermanfaatnya Javascript. Kerangka UI front-end baru muncul. Menjadi mungkin untuk menulis UI yang sangat interaktif di browser, bahkan game yang lengkap. Pemrosesan bergeser kembali ke klien lagi.

Hari ini, Anda dapat membeli kekuatan pemrosesan di cloud, sebanyak atau sesedikit yang Anda suka, dan menjalankan program di server. Saya akan mengatakan kita sekarang berada di tempat di mana, sebagai pengembang perangkat lunak, Anda memiliki banyak pilihan tentang di mana Anda dapat mengeksekusi kekuatan pemrosesan Anda, baik pada klien maupun di server.

Anda tampaknya mencampur dua konsep yang sangat berbeda:

1. Memisahkan presentasi dan logika bisnis (MVC) => meningkatkan pemeliharaan
2. Menetapkan eksekusi ke simpul => meningkatkan efisiensi

Kembali pada hari-hari komputasi Klien / Server sering bingung untuk menyiratkan yang pertama karena klien umumnya tidak menawarkan banyak daya komputasi, dibandingkan dengan server. Jadi sepertinya wajar untuk memindahkan komputasi logika bisnis (berat) "berat" ke server, sambil menjaga pemrosesan tampilan "ringan" (V) ke klien. Pada gilirannya Anda harus mengimplementasikan semacam arbitrator (C) untuk menerjemahkan keduanya.

Dengan klien sekarang dengan mudah menampilkan kecakapan proses yang pernah menyiratkan beberapa perangkat keras server mahal garis telah kabur ke mana untuk mengeksekusi logika bisnis - sisi klien atau sisi server. Sungguh, jawabannya tergantung pada kasus penggunaan khusus Anda dan pilihan trade-off Anda, misalnya:

• klien latensi vs kompleksitas: pemrosesan sisi server membuat sistem lebih sederhana karena tidak ada kode yang perlu digunakan / diunduh ke klien, namun hal itu harus dibayar dengan latensi sisi klien selama perhitungan.

• kompleksitas vs beban server: komputasi sisi klien dapat meningkatkan kompleksitas sistem tetapi juga dapat membantu mengurangi beban server.

• ketahanan aplikasi terdesentralisasi vs eksekusi terpusat: di dunia aplikasi seluler, mungkin penting untuk menjaga klien tetap bekerja meskipun jaringan terputus. Namun, ini terjadi dengan biaya mengelola beberapa versi logika bisnis yang digunakan.

Ini adalah daftar banyak trade-off yang tidak lengkap.

Karena pengguna selalu menginginkan fungsionalitas, lonceng, dan peluit yang sama dengan aplikasi web mereka (bukan hanya situs web) yang mereka miliki dengan aplikasi desktop. Membuat ini semua berjalan di browser (sebenarnya beberapa browser) tidak seperti masa lalu ketika Anda bisa menautkan formulir VB ke database dengan kode kecil. Ini lebih mudah dicapai ketika Anda tidak perlu melakukan perjalanan kembali ke server.

kebanyakan pengembangan backend menggunakan bahasa pemrograman seperti Java atau C # hanya untuk menghasilkan antarmuka seperti REST, dan bahwa semua usaha keras tampilan, visualisasi, input / output data, interaksi pengguna, dll ... sedang ditangani melalui client- kerangka samping seperti Angular, Backbone, Ember, Knockout, dll ...

Mungkin pemrograman / layanan backend tampak seperti hal lama yang sama, tetapi itu adalah jantung dari aplikasi. Praktik pengkodean mungkin lebih efisien di bidang ini. Alat, bahasa, browser, dan kerangka kerja masih terus berkembang, sehingga UI / UX sulit untuk dikembangkan. Mereka adalah hal-hal baru yang tidak dimiliki oleh ASP lama. Jika kita bisa lolos dengan antarmuka pengguna dengan formulir sederhana dan tabel html, tidak akan ada banyak minat / sensasi di area itu juga, tetapi pengguna ingin drag and drop, animasi, transisi, pop-up, dll.

Hari ini, di sebagian besar proyek yang saya jalani, saya menemukan bahwa kerangka kerja JavaScript dan pengembangan sisi klien adalah tempat semua kemajuan menarik dan inovatif sedang dibuat.

Mengapa perpindahan dari server ke pengembangan sisi klien ini terjadi?

Sebenarnya ada dua pertanyaan di sini:

1. Mengapa pemrograman sisi klien di mana kemajuan terjadi?
2. Mengapa aplikasi ditulis untuk dijalankan di klien daripada di server?

Keduanya sebenarnya berbeda.

Mengapa pemrograman sisi klien di mana kemajuan terjadi?

Karena runtime, lingkungan dan ekosistem telah matang secara substansial selama tiga tahun terakhir, dan ini telah membuka celah baru yang menunggu untuk dieksploitasi oleh inovator.

Pengembangan front-end dulu sulit . Anda harus memprogram untuk browser - selalu merupakan lingkungan yang tidak bersahabat - menggunakan fitur ECMAScript 3 yang dibatasi, dalam ekosistem yang tidak memiliki seni atau alat sebelumnya untuk membangun aplikasi klien yang tebal. Tidak ada pemuat modul. Anda tidak dapat menangani dependensi dengan benar. Ada kekurangan alat linting. Kerangka kerja yang belum matang dan reputasi front-end yang buruk menjauhkan inovator yang bisa menyelesaikan masalah ini.

Karena faktor-faktor ini telah berubah secara bertahap, mereka telah menciptakan massa kritis untuk mengembangkan aplikasi klien kaya dengan cepat dan menjalankannya secara konsisten.

Maka, sebagai jawaban atas pertanyaan Anda, tidak banyak teknologi front-end baru mendorong kemajuan ke depan, sebanyak mereka telah merilis kemacetan dan memungkinkan klien untuk mengejar ketinggalan dengan aspirasi pengguna.

Mengapa aplikasi ditulis untuk dijalankan di klien daripada di server?

Ada banyak penyebab langsung, tetapi yang paling menonjol beberapa tahun terakhir adalah munculnya smartphone.

Smartphone membuat komputasi yang cukup kuat menjadi murah, ada di mana-mana, dan bermanfaat. Mereka dimiliki oleh miliaran orang di seluruh planet ini, dan pada dasarnya telah membawa komputasi ke kelas menengah di negara berkembang. Tetapi jaringan seluler lamban, tambal sulam, dan terkendala oleh Masalah Geografis, Teknik, dan Politik. Dalam lingkungan ini, tidak dapat dihindari bagi aplikasi untuk menyimpan status secara lokal dan menambal data dengan enggan dan dalam operasi tanpa kewarganegaraan.

Bagaimana bisa berbeda? Bayangkan jika smartphone Anda hanya terminal bodoh. Setiap mutasi negara harus asinkron dan bisa salah. Setiap pemuatan konten akan berharga sen sen. Anda harus berinvestasi di server server besar dengan uptime lima sembilan. Biaya komputasi akan ditanggung oleh Anda secara langsung, sehingga lonjakan popularitas yang tiba-tiba dapat membuat bisnis Anda semakin macet.

Aplikasi sisi klien memungkinkan Anda untuk menangani keadaan yang berkaitan dengan masing-masing pengguna secara cepat dan sinkron. Mereka membiarkan Anda menurunkan biaya komputasi Anda ke pengguna Anda. Mereka membiarkan Anda pergi dengan downtime dan konektivitas jaringan yang buruk. Mereka membuat kode server begitu bodoh sehingga bisa di-cache di infrastruktur jaringan itu sendiri - file HTML dan JS statis, atau respons kalengan untuk aplikasi seluler.

Untuk memasukkannya ke dalam istilah yang sangat luas: Pengembangan sisi klien mengeksploitasi rendahnya biaya komputasi personal tingkat menengah dan menghindari biaya tinggi dari komputasi terpusat daya tinggi.

Anda mengajukan beberapa pertanyaan, beberapa di antaranya sudah memiliki jawaban yang baik. Beberapa orang belum memiliki jawaban:

Yang ingin saya ketahui adalah, mengapa kita melakukan transisi seperti itu (dari penekanan pemrograman sisi server ke sisi klien, ... semua ini tampaknya terjadi secara bersamaan) dan masalah apa yang dipecahkan oleh transisi / pergeseran ini?

Robert Harvey memberikan jawaban yang sangat baik.

... dari mendukung bahasa yang dikompilasi ke bahasa skrip,

Bahasa scripting menawarkan banyak keuntungan ( juga ) dibandingkan bahasa yang dikompilasi, misalnya:

• lebih mudah dipelajari dan digunakan
• menghilangkan waktu kompilasi (pengembangan lebih cepat)
• memberikan lebih banyak fitur (kontrol aplikasi kelas atas)
• izinkan perubahan cepat untuk menjalankan kode
• dll.

... dari keharusan ke pemrograman fungsional,

Ini perbandingan yang bagus, tetapi saya akan menyimpulkannya dengan mengatakan bahwa dalam perangkat lunak terdistribusi (pikirkan komputasi awan), mengelola perubahan status (sinkronisasi di banyak node) dapat menjadi masalah besar. Dalam pemrograman fungsional, kebutuhan untuk menghadapi perubahan status jauh lebih rendah.