Bergegas ke sisi klien dalam pengembangan web

10

Dalam beberapa bulan terakhir, saya mengenali kegembiraan besar tentang scripting sisi klien dalam pengembangan web. Tetapi sementara teknologi sisi server matang, stabil dan diterima dengan baik oleh pengembang backend, teknologi sisi klien tidak matang (yaitu dibandingkan dengan kerangka sisi server besar) dan tidak disukai oleh banyak pengembang lama. Namun demikian semua orang melakukan pengembangan sisi klien hari ini. Saya pribadi berharap kerangka besar sisi server menghilang dalam 2-5 tahun, melihat tren saat ini.

Kenapa begitu? Bagaimana mungkin sisi klien baru dan "menyebar" berkembang di HTML5 / JS mungkin lebih unggul daripada solusi sisi server yang besar dan dipikirkan dengan baik?

— Bruno Schäpper
sumber

4

Apakah Anda memiliki sumber untuk memverifikasi asumsi Anda? Javascript hampir setua internet itu sendiri, dan saya tidak melihat pemrograman sisi server terjadi di mana saja dalam waktu dekat.

— tdammers

1

Untuk memperjelas, asumsi saya terbatas pada front-end. Saya melihat pergeseran ke sisi klien, dalam logika UI, rendering dan hal-hal seperti itu. Tentu saja sisi server tidak akan pernah hilang, tetapi direduksi menjadi REST-api (atau SOAP dalam hal ini).

— Bruno Schäpper

3

Pergeseran ini datang dan pergi. Biasanya pengembangan front-end menjadi lebih populer begitu teknologi keren baru diperkenalkan (Shockwave, Flash, JavaFX, Flex) atau kerangka kerja js baru yang besar mencoba "mengambil alih dunia" (motool, jquery, dll.)

— Andrzej Bobak

1

@VainFellowman: Anda benar-benar tidak ingin menggunakan SOAP dalam skrip sisi klien. Ada terlalu banyak overhead, parsing itu menyakitkan, dan Anda tidak menang banyak karena Javascript dengan disiplin pengetikan dinamisnya tidak akan bisa menggunakan banyak informasi jenis SOAP.

— tdammers

1

@Dammers Saya tidak mau, sungguh saya tidak mau. Saya tidak melihat gunanya menggunakan SOAP melalui HTTP. REST cocok untuk hampir semuanya.

— Bruno Schäpper

7

Ini benar:

Bergegas ke sisi klien dalam pengembangan web

Tapi itu tidak terbatas pada sisi klien, itu adalah gerakan tumpukan penuh.

Saya tahu ini mungkin mengejutkan. Tolong, dengarkan aku.

Kenapa begitu? Bagaimana mungkin sisi klien baru dan "menyebar" berkembang di HTML5 / JS mungkin lebih unggul daripada solusi sisi server yang besar dan dipikirkan dengan baik?

Pertama-tama, keduanya dipikirkan dengan baik.

Kedua, Karena lebih baik.

Pertanyaan bagus.

Tetapi "lebih baik" bersifat subyektif, jadi jawaban untuk pertanyaan Anda adalah, apa yang lebih baik secara spesifik?

Kunjungi kembali pertanyaan:

Bagaimana "menyebar" sisi klien berkembang di HTML5 / JS mungkin lebih unggul daripada solusi sisi server besar?

Because small is nimble.
And big is clunky.

Itu adalah fleksibilitas.

Sepertinya bukan masalah besar. Melakukannya? Fleksibilitas.

Namun, fleksibilitas mendasari segalanya. Satu peningkatan dalam fleksibilitas - meningkatkan segalanya.

Maintabilitas. Kemungkinan diperpanjang. Skalabilitas. Modularitas. Kegunaan. UX.

Dan lebih cepat untuk diimplementasikan. Ini adalah kenyataannya. Lebih cepat dan lebih baik.

This is why Windows 8 made JS a first-class citizen.

HTML5 - JS, bukan iseng dan tidak akan hilang. Kami hanya melihat benih teknologi yang akan tumbuh untuk menyediakan konten komputasi dan perilaku interaksi ke tablet. Tablet.

Ponsel pintar adalah adopsi media massa tercepat sejak TV pada 1950-an. Sekarang, kita tidak hanya memiliki smartphone - kita juga memiliki Tablet.

Sudah dalam pengembangan di Mozilla dan Windows OS yang akan berjalan di perangkat masa depan di pasar mereka -> HTML / JS.

Masih banyak solusi dan inovasi.

Tumpukan penuh JS muncul, berdasarkan fleksibilitas.

Saya harap itu membantu.

— Jack Stone
sumber

1

Jawaban bagus! Tetapi kerangka kerja sisi server menjanjikan manfaat yang sama, bukan?

— Bruno Schäpper

1

Ya Pak, kerangka kerja sisi server menjanjikan manfaat yang sama, ya. Yang perlu diketahui adalah bahwa ada manfaat tambahan, yang ditemukan secara tak terduga, dalam teknologi yang muncul. Itu berada pada level terendah (c) di io. Utas menunggu. Di JS memiliki callback. Itu tidak menunggu. Jadi ada optimasi io di tingkat terendah. Realisasi ini sekarang, diam-diam, diadopsi secara besar-besaran oleh Microsoft. Itulah sebabnya OS mereka adalah JS. Poin terakhir, ini menghasilkan optimasi dan optimisasi meta - di semua tingkatan. Karena bahasanya fleksibel. Suatu hal sederhana yang tidak terlihat. Tidak diketahui. Semoga itu bisa membantu.

— Jack Stone

1

Saya memilih untuk menerima jawaban ini, karena ini adalah jawaban yang paling lengkap. Semua yang lain punya poin bagus, tapi ini yang paling konklusif. Terimakasih semuanya!

— Bruno Schäpper

9

Kisah ini selalu memiliki dua sisi; kode sisi-server dan sisi-klien memiliki pro dan kontra.

Keuntungan dari skrip sisi klien meliputi:

Dapat dibuat lebih responsif, perubahan luas dimungkinkan tanpa bolak-balik server.
Kode berjalan pada klien, mengurangi penggunaan sumber daya di server.
Pemisahan antara logika dan presentasi menjadi fisik.
Terkadang lebih mudah memuat-keseimbangan, terutama jika otentikasi per-permintaan digunakan.

Tetapi skrip sisi server memiliki banyak keuntungan juga:

Anda mengontrol mesin yang menjalankan kode.
Cukup banyak hal yang mungkin - jika server Anda dapat melakukannya, skrip Anda juga bisa.
Pengguna tidak dapat memodifikasi skrip Anda sebelum menjalankannya.
Pengguna tidak dapat menggunakan pemblokir skrip untuk mencegah skrip Anda berjalan.
Pengguna tidak dapat melihat apa yang dilakukan skrip Anda, mereka hanya dapat mengamati hasilnya.
Kode ini akan bekerja dengan andal pada setiap klien yang dapat Anda bayangkan, termasuk pembaca layar, browser web tekstual, spider mesin pencari, pencakar, akumulator, bot IRC, mesin super-low-end, browser yang diblok skrip, apa saja.
Plugin pengguna cenderung rusak.

Untuk aplikasi web yang sangat dinamis, pendekatan yang berpusat pada klien selalu menjadi pilihan populer, karena itu satu-satunya cara untuk memberikan pengalaman pengguna yang seperti desktop responsif yang layak: tanpa skrip sisi klien, setiap tindakan pengguna memerlukan putaran trip, yang berarti setidaknya setengah detik penundaan, biasanya lebih. Tetapi untuk situs informasi yang pada dasarnya hanya sekelompok halaman statis yang dilayani dari database (katakanlah, wikipedia), keuntungannya kecil, sedangkan manfaat skrip sisi server masih luar biasa.

Hype yang diamati berasal dari kombinasi dua perkembangan terakhir:

HTML5 dan korona teknologi terkait. Butuh waktu terlalu lama, tetapi sekarang kita akhirnya memiliki standar yang berisi semua yang Anda butuhkan untuk membuat aplikasi web yang dinamis seperti desktop tanpa menumpuk hack, dan browser mainstream yang mengimplementasikannya dengan benar.
Daya pemrosesan yang tersedia. PC desktop komoditas saat ini sama kuatnya dengan server web entry-level, ponsel kelas pelanggan praktis komputer desktop 2005, dan implementasi javascript modern cukup efisien untuk memiringkan keseimbangan kinerja: saat ini, sumber daya sisi klien lebih murah daripada server sumber daya.

Faktanya, tidak ada yang berubah dalam hal apa yang baik pada pendekatan server-centric dan client-centric; apa yang telah berubah adalah bahwa klien-sentris sekarang lebih mudah dan lebih murah untuk dilakukan dan berkinerja lebih baik daripada beberapa tahun yang lalu, menjadikannya pilihan yang layak untuk banyak aplikasi daripada sebelumnya.

— tammmer
sumber

kebenaran sulit ... +1.

— Jack Stone

8

Sisi server akan selalu ada. Anda tidak bisa duduk di sisi klien untuk semuanya. Misalnya, Anda tidak ingin menggunakan desain MVC Backbone.js untuk mikro-controller Anda mengirimkan parameter secara real time dari overhead overhead crane produksi.

Jangan percaya hype.

— lwm
sumber

Katakan padaku. Apakah JS di Windows 8, hype? -1. Saya setuju dengan poin pertama, tetapi poin kedua Anda tentang hype, perlu klarifikasi.

— Jack Stone

JS tidak eksklusif untuk sisi klien dan belum lama.

— Erik Reppen

@ClintNash ya, sebenarnya. Ms memungkinkan j's untuk membangun aplikasi win8 untuk meningkatkan jumlah pengembang potensial untuk platform mereka. Ini adalah tanggapan terhadap orang-orang yang memilih untuk mempelajari teknologi tersebut daripada teknologi desktop. Tapi sebagai rev yang sudah tahu c # / wpf, saya tidak melihat alasan untuk membangun aplikasi win8 dengan html / js.

— Andy

@ ErikReppen ini benar, tetapi js saja tidak memotongnya di server, Anda perlu kerangka kerja untuk membangun. Terus terang keinginan untuk menggunakan skrip di server membingungkan saya. Kami sudah melakukannya, itu ASP klasik, dan saya tidak benar-benar ingin mengulangi pengalaman itu.

— Andy

@Andy Pada ASP klasik (khususnya formulir web), Anda tidak akan menemukan akhir dari persetujuan dengan pengembang JS yang mengalami kemalangan untuk memiliki run-in dengan alat-alat yang kami pasti tidak ingin kembali ke sana lagi. Tapi itu adalah alat scripting sisi server tag paling tidak diingat yesterdecade dan mungkin solusi klien tipis paling dibenci yang pernah melihat tingkat popularitas. Membandingkannya dengan sesuatu seperti Python dan sekarang JS di sisi server berbatasan dengan memberitahu orang untuk mendapatkan kuda.

— Erik Reppen

6

Saya telah beralih pada tahun 2009 dari kerangka PHP sisi-server ke solusi ExtJS sisi-klien yang dikaitkan dengan layanan web sisi-server.

Alasan migrasi saya adalah:

Keamanan yang lebih baik dengan mengurangi jumlah titik akhir dan kode pada server.
Dengan pindah ke layanan web Anda memvalidasi input pada batas layanan web dan memiliki kontrol yang lebih tepat atas I / O server Anda. Tidak ada lapisan UI sisi server untuk mengacaukan arsitektur keamanan Anda.
Peningkatan kinerja karena lebih sedikit pulang
- pergi server Arsitektur berubah sehingga pengambilan data lebih jarang terjadi dan data dapat di-cache secara lokal dengan rendering UI yang tidak memerlukan bolak-balik sama sekali. Roundtrips adalah apa yang mematikan kinerja aplikasi web.
Peningkatan kinerja karena
UI yang dapat disimpan dalam cache . Lapisan UI dapat dihosting di CDN sepenuhnya. Saya bahkan membuat aplikasi web offline dengan memasukkan kode UI ke cache aplikasi HTML5.
Keakuratan UI yang lebih tinggi (kontrol sisi klien yang kaya)
Pengembang pihak ketiga dapat menggunakan API yang sama dengan yang digunakan front-end saya, dan saya dapat dengan mudah menggunakan kembali seluruh modul API jika mereka berbagi fitur.
Ini berarti lebih sedikit pengembangan, QA, dokumentasi, ...
Saya suka pemrograman dalam JavaScript lebih baik daripada PHP, Python atau Java

Tapi, jangan salah, yang terjadi sekarang adalah hype. Ini akan reda dan banyak aplikasi web akan menggunakan arsitektur UI sisi-server lagi.

— Joeri Sebrechts
sumber

Apa, hype? -1 Semoga beruntung dengan itu ketika Windows 8 menjadikan JS warga negara kelas satu. Ya, arsitektur UI sisi server yang ditulis dalam node.js mungkin. Kita perlu mempelajarinya karena itu bukan pemblokiran.

— Jack Stone

Saya tidak berpikir kami akan kembali ke solusi klien tebal dalam waktu dekat. Tetapi jika saya dibebani dengan ExtJS untuk masalah apa pun yang menjadi lebih rumit daripada membuang UI web pra-fab (yaitu semua masalah terlepas dari rencana semula), saya bisa melihat mengapa alternatif itu mungkin tampak kurang ideal.

— Erik Reppen

6

Faktor lain yang mendorong antusiasme untuk solusi sisi klien adalah pertumbuhan aplikasi seluler. Jika Anda membuat situs web berdasarkan pada JavaScript sisi klien dan AJAX, dan juga membangun aplikasi iOS dan Android asli, ada peluang bagus bahwa ketiganya dapat menggunakan layanan REST yang sama untuk melakukan semua data mereka ke sana-sini .

— Carson63000
sumber

Dikatakan dengan baik ... +1.

— Jack Stone

Poin yang sangat bagus.

— Bruno Schäpper

4

Pertama-tama, pengguna tidak melihat (dan kadang-kadang bahkan tidak peduli) apa yang bukan server. Tidak peduli seberapa baik kode sisi server ditulis, pengguna tidak akan menghargai aplikasi jika bagian klien tidak dilakukan dengan baik. Kadang-kadang bahkan UI yang bagus lebih penting daripada fungsi.

Server hosting yang besar dan kuat cukup mahal. Jauh lebih murah untuk mengimplementasikan beberapa logika (kecuali validasi) di sisi klien. Jadi Anda bisa menggunakan hosting server yang lebih kecil (karena itu, lebih murah), karena tidak akan dimuat sebanyak itu.

Ini adalah alasan bahwa, terlepas dari ketidakstabilan, teknologi dari sisi klien semakin populer. Selain itu, JS dan HTML / CSS didukung oleh (hampir) semua browser modern.

Dua bagian aplikasi ini tidak dapat ada secara terpisah. Dan Internet sepertinya tidak akan pergi ke mana pun dalam waktu dekat.
Saya juga tidak berpikir itu big server-side frameworksakan hilang. Akan selalu ada perusahaan yang mampu membelinya, dan akan menggunakan keuntungan signifikan mereka.

— superM
sumber

4

Pengembangan web sisi klien sangat digabungkan dengan browser web dan perubahan di dalamnya dari waktu ke waktu. Solusi yang Anda berikan sekarang mungkin tidak berfungsi dalam beberapa bulan karena perubahan signifikan pada mesin rendering halaman browser web. Beberapa browser tidak kompatibel dengan standar dan oleh karena itu diperlukan upaya lebih dari para pengembang hanya untuk mencapai hasil yang diharapkan.

Ada beberapa solusi yang mencoba untuk memperbaiki masalah ini. Misalnya, jika Anda menggunakan jquery, Anda yakin skrip Anda akan berfungsi pada browser yang didukung oleh pustaka jquery khusus ini. Tetapi hanya tergantung penulisnya untuk memberikan Anda kompatibilitas dengan sebagian / sebagian besar / semua browser. Pertanyaannya adalah tim mana yang akan mendukung Anda dengan lebih baik. Apakah itu tim motool, tim jquery, tim lain? Jika mereka tidak memberikan dukungan ke browser web tertentu, proyek Anda mungkin tidak berfungsi di browser itu.

Kegembiraan yang tampaknya sudah ada sejak lama. Saya melihatnya ketika Shockwave dan penggantinya Flash diperkenalkan, ada "comeback besar" dari antarmuka pengguna yang kaya begitu pustaka js kompleks dikirimkan, pertama dengan motool, kemudian dengan jquery (saya mulai menggunakannya dalam urutan ini). Ada Flex dan JavaFX. Tapi tidak ada satu pun dari mereka yang bisa mendapat bagian besar di pasar. Beberapa memerlukan plugin yang pada waktunya sering mengekspos pengguna akhir terhadap kerentanan keamanan, yang lain mungkin tidak berfungsi di sisi klien karena beberapa pengaturan khusus (misalnya JavaScript dinonaktifkan di browser klien).

Di sisi lain, solusi sisi server biasanya ditulis hanya sekali. Anda tidak perlu khawatir bahwa semuanya akan gagal dan harus ditulis ulang begitu Firefox / Chrome / IE / Opera baru dikirimkan. Anda juga tidak perlu khawatir bahwa klien akan mencoba merusak aplikasi Anda dan / atau merusak data.

— Andrzej Bobak
sumber

1

Bukankah itu imajinasi murni? Anda mungkin harus mengubah hal-hal sisi server Anda ketika klien berubah, karena Anda tidak mendapatkan putaran menghasilkan HTML / JS / CSS di beberapa titik.

— Bruno Schäpper

1

Satu hal lagi, 'Pengembangan web sisi klien sangat digabungkan dengan browser web' - Teknologi web adalah standar resmi, selama Anda tetap menggunakannya, Anda menerapkan standar, bukan menyambungkan aplikasi Anda ke browser. Walaupun belum terlalu lama ini tidak benar, sepertinya saat ini.

— Bruno Schäpper

Pertama-tama baca bagaimana beberapa browser tidak mengikuti standar (Internet Explorer misalnya). Beberapa hal telah berubah dari waktu ke waktu, tetapi bahkan dengan IE7 saya memiliki masalah mengerikan karena caranya sendiri dalam menafsirkan apa yang saya tulis. Baca juga beberapa artikel tentang kompatibilitas lintas-browser. Masalah ini tidak akan ada jika setiap vendor browser web akan mengikuti standar. Kedua, jika set data berubah, Anda harus mengubah logika bisnis Anda, itu jelas. Namun ketika IE baru dikirimkan dan Anda harus menulis ulang sekitar 30% kode hanya untuk membuat kode berfungsi di browser baru - ada yang salah

— Andrzej Bobak

Tentu saja saya tahu betapa menyakitkannya dan untuk membuat semuanya berfungsi di setiap browser. Tetapi pekerjaan ini harus dilakukan terlepas dari sisi server atau sisi klien (karena pada akhirnya Anda harus menggunakan browser). Saya tentu setuju dengan poin kedua Anda. Namun, saya tidak melihat 30% ditulis ulang. Beberapa perubahan mungkin diperlukan, tetapi saya ragu itu sama buruknya dengan di masa lalu. Di sisi lain Anda harus mengulang semuanya berdasarkan pada lapisan layanan, jika Anda ingin mengganti tumpukan sisi server Anda. Jadi Anda SANGAT erat dengan implementasi sisi server Anda. Mungkin dari bagian atas UI ke model.

— Bruno Schäpper

-1

Sepenuhnya setuju dengan sentimen Anda. Saya juga percaya bahwa di luar apa yang Anda katakan, kita akan melihat penurunan dramatis dalam REST dan kenaikan besar-besaran di soket web untuk cara utama kita melihat situs berkomunikasi kembali ke server mereka. Vert.x, Node.js dll. Seluruh sisi server, serta sisi klien, pindah ke pemrograman yang digerakkan oleh peristiwa. Java EE, PHP, Rails, dll. Mereka semua perlu beradaptasi atau mereka akan kehilangan dengan sangat cepat.

— coding
sumber

Tanpa penjelasan, jawaban ini mungkin menjadi tidak berguna jika ada orang lain yang memberikan pendapat berbeda. Misalnya, jika seseorang memposting klaim seperti "kita tidak akan melihat penurunan dramatis dalam REST dan kenaikan besar-besaran di websockets", bagaimana jawaban ini membantu pembaca untuk memilih pendapat yang berbeda ini? Pertimbangkan untuk mengeditnya menjadi bentuk yang lebih baik

— agas