Mengapa web memenangkan ruang aplikasi jarak jauh dan X tidak?


19

Sistem X Window berusia 25 tahun, ulang tahun kemarin (tanggal 15).

Seperti yang mungkin Anda ketahui, salah satu fitur yang paling penting adalah pemisahan sisi server dan sisi klien dengan cara yang tidak dimiliki oleh sistem jendela Microsoft, Apples atau Wayland.

Kembali pada hari-hari (maaf untuk kalimat yang ambigu) banyak yang percaya X akan mendominasi cara lain untuk membuat windows karena pemisahan server dan klien ini, memungkinkan aplikasi untuk dijalankan pada server di tempat lain sementara pengguna mengklik dan mengetik pada dirinya komputer sendiri di rumah.

Penggunaan ini jelas masih ada, tetapi dipinggirkan. Ketika kita menulis dan menggunakan program yang berjalan di server, kita hampir selalu menggunakan web dengan html / css / js.

Mengapa web menang, dan X tidak? Teknologi yang digunakan untuk web (kata html / css / js) berantakan. Dikombinasikan dengan semua back-end-frameworks (Rails, Django dan semua) itu benar-benar hutan untuk menavigasi melalui. Web tetap berkembang dengan kreativitas dan kemajuan, sedangkan aplikasi jarak jauh X tidak.


6
Keduanya bahkan tidak sebanding. Koneksi X-server memungkinkan saya untuk menjalankan aplikasi jarak jauh, dan melihatnya GUI secara lokal, yang merupakan kasus penggunaan yang sama sekali berbeda dengan memungkinkan saya memuat sumber daya jarak jauh ke klien lokal.
Martijn Pieters

3
Saya tidak setuju bahwa ada perbedaan. Ketika saya menghubungkan klien web saya (browser) ke server (lokal atau jarak jauh) saya dapat melihat GUI aplikasi (web-) saya. Sama seperti saya dapat melihat GUI aplikasi saya dengan sesi X.
Martin Josefsson

4
Cobalah menulis program X11 dan membandingkannya dengan halaman HTML - juga membandingkan bandwidth yang dibutuhkan. Selain itu, WWW tidak menggantikan X11, itu menggantikan Gopher.

2
Pieters: Tentu saja, halaman diberikan pada klien, dan JS berjalan pada klien, tetapi itu hanyalah teknis. Lebih sering daripada tidak, kode berjalan di sisi server (php, java, .net, python, ruby, apa pun). Dalam praktiknya keduanya adalah antarmuka untuk menjalankan aplikasi pada server dan ditampilkan pada klien. X dan web melakukannya dengan cara yang berbeda, tetapi itulah intinya.
Martin Josefsson

14
Karena teknologi tidak lulus validasi oleh industri hiburan dewasa, langkah yang diperlukan dalam adopsi arus utama teknologi (itu cara yang bagus untuk mengatakan bahwa gambar wanita telanjang tidak tersedia dengan cepat pada sistem X).
dasblinkenlight

Jawaban:


22

Tampaknya sangat jelas dan mendasar sekarang, tetapi inovasi pembunuh dari world wide web adalah hyperlink. Bahkan jika X tidak sepenuhnya tidak dapat digunakan melalui tautan modem, ketidakmampuannya untuk meluncurkan proses yang sama sekali baru pada server yang sama sekali baru melalui satu klik akan menghambat penerapannya untuk jenis penggunaan seperti itu.


1
Ini mungkin jawaban yang benar. Juga bahwa klien web berjalan di Apple dan Microsoft OS juga.
Martin Josefsson

Tautan tersebut bukan inovasi dari World Wide Web. Itu diterapkan berkali-kali sebelumnya, seperti di Apple's Hypercard, sebuah program populer di tahun 80-an dan 90-an dengan banyak kesamaan luar biasa dengan Web Browser. Konsep hypertext dan hyperlink kembali ke tahun 60-an, dengan Project Xanadu, dan telah diimplementasikan berkali-kali dalam banyak format sebelum Tim Berners-Lee akhirnya menciptakan sendiri implementasi hypertext berbasis jaringan di CERN pada awal 90-an.
Charles Salvia

3
@CharlesSalvia: Terobosan hyperlink HTML disebabkan oleh URL. Secara khusus, aspek Universal: global, dengan otoritas pusat yang cukup untuk bekerja, dan tidak terikat pada satu jenis media atau teknologi tertentu. Teknologi Anda sebelumnya jauh, jauh kurang universal.
MSalters

17

Karena X mengharuskan Anda memiliki gelar CS untuk menulis aplikasi. Sementara Web mengharuskan Anda memiliki kemampuan untuk mengetik (bukan itu).

Terutama di hari-hari awal ketika web hanya html. Anda dapat membuka terminal dan membangun tampilan yang berfungsi dalam 10 menit dan kemudian secara interaktif meningkatkannya dengan umpan balik instan. Bilah entri yang rendah ini mendorong penyerapan besar-besaran pengguna. Membangun aplikasi X-Server di sisi lain adalah tugas yang tidak sepele bahkan untuk programmer yang berpengalaman.

Diperlukan waktu 10 tahun bagi Web untuk menjadi pesaing langsung untuk aplikasi X dalam hal fungsionalitas dan memberikan kemampuan seperti GUI yang sama. Fungsi ini telah ditambahkan ke tumpukan bahasa dari waktu ke waktu yang memungkinkan pengembang untuk menguasai satu set fitur sebelum berikutnya ditambahkan; jadi ekspansi bertahap dari kompleksitas teknologi ini telah mempertahankan standar yang rendah (untuk orang-orang yang sudah berada di lapangan dan ada banyak dari mereka). Melompat ke bidang sekarang jauh lebih sulit daripada 10 tahun yang lalu tetapi masih mungkin dan umpan balik instan dari web membuat belajar lebih memuaskan (manusia membutuhkan kepuasan cepat untuk memperkuat drive mereka).

Biaya adalah pengemudi lain. Biaya sebenarnya belajar keterampilan pemrograman yang cukup untuk mengembangkan X-Server adalah signifikan. Kemudian juga ketersediaan server untuk menjalankan aplikasi Anda telah mendorong biaya naik. Belajar menulis HTML praktis bukan apa-apa untuk mendapatkan halaman dan menjalankan "Hello World" dan penyedia layanan internet menyediakan hosting gratis untuk menginspirasi Anda untuk mendapatkan koneksi web. Jadi Anda bisa berlatih secara gratis. Ketika Anda akhirnya membutuhkan bisnis hosting, ketersediaan perusahaan hosting telah tumbuh dan biayanya selalu relatif murah.


1
Anda berasumsi bahwa untuk menulis aplikasi yang digunakan lebih dari X Anda harus memahami X api. Tetapi sama seperti Anda tidak perlu memahami HTTP untuk menulis aplikasi web, Anda tidak perlu memahami X untuk menulis aplikasi yang berjalan di bawah X. Anda bisa menulisnya dalam satu bahasa, bahasa yang Anda sukai, dan hanya memiliki perpustakaan GTK di atas. Jauh lebih mudah daripada belajar html dan css dan js dan bahasa serveride. Intinya: sama seperti Anda tidak perlu menulis server http untuk menerbitkan situs web, Anda tidak perlu menulis server X untuk melayani aplikasi X.
Martin Josefsson

Saya tidak setuju dengan analisis Anda di sana. Meskipun Anda ada gunanya menulis aplikasi web modern sekarang hampir sama rumitnya dengan menulis aplikasi X 10 tahun yang lalu. Untuk menulis Aplikasi-X masih bukan proses sepele. Ini seperti menulis aplikasi windows. Jauh melampaui kemampuan siapa pun yang belum melakukan pengalaman pemrograman yang signifikan. Di sisi lain, memasang halaman HTML itu sepele dan dapat dilakukan dalam 10 menit (bahkan oleh seorang pemula). Dengan demikian mengarah pada penegakan kembali yang cepat dan kemampuan untuk bereksperimen dengan cepat. Ini membuatnya menjadi bar yang jauh lebih rendah untuk masuk.
Martin York

GTK tidak tersedia sampai setelah web didirikan.
user16764

@ user16764: Itu tidak benar. Saya menggunakan GTK pada tahun 1997 (tidak yakin kapan mereka pertama kali memulai tetapi sebelum itu). Web (seperti dalam HTML / HTTP) mungkin sudah ada tetapi belum cukup mapan. Maksud saya browser web baru saja dibawa ke aliran utama di 92 (Pertama kali saya melihatnya). X memiliki beberapa window manager lain yang dapat digunakan sebelumnya. Saya ingat menggunakan twm (manajer jendela tom, saya percaya) dan satu tingkat yang sedikit lebih tinggi (yang saya lupa) tetapi ada banyak untuk memilih dari (terlalu banyak) di 90 (dan mereka tersedia sebelum itu (saya pikir)).
Martin York

@LokiAstari: Anda membingungkan Window Manager dan GUI libs. Meskipun ada tumpang tindih yang pasti (GNOME / Gtk, KDE / Qt) mereka pasti tidak identik. Bahkan dengan manajer jendela Anda masih memiliki dunia kesakitan.
MSalters

11

Jawabannya adalah "banyak teknologi diadopsi untuk alasan historis atau sosial-politik yang sewenang-wenang daripada alasan teknis." Solusi terbaik untuk masalah yang diberikan tidak selalu menjadi teknologi yang dominan. (Faktanya, itu jarang terjadi.)

Pada 2012, di mana server HTTP digunakan untuk membuat aplikasi interaktif yang setara dengan aplikasi Desktop, perbandingan antara HTTP dan X menarik. Jika dipikir-pikir, X mungkin merupakan teknologi yang lebih baik untuk mengembangkan aplikasi yang kaya dan interaktif yang digunakan jaringan. Aplikasi seperti Desktop interaktif tidak memetakan dengan baik ke teknologi tanpa kewarganegaraan, berorientasi pada dokumen seperti HTTP, dan ketidakcocokan ini secara historis menghasilkan segala macam penyelesaian (peretasan) untuk menciptakan keadaan, seperti cookie, sesi, dll.

Tetapi tujuan asli HTTP bukan untuk mengembangkan aplikasi seperti Desktop yang stateful. Itu untuk mengambil dokumen dan menampilkan informasi - informasi yang dapat menghubungkan ke dokumen lain yang juga dapat langsung ditampilkan. Gagasan kumpulan dokumen yang tertaut kembali ke tahun 1960-an dengan Theodore Nelson's " Project Xanadu ". Web seharusnya merupakan implementasi dari konsep hypertext Nelson , yang merupakan upaya untuk mengkomputerisasi halaman yang dicetak - seperti ensiklopedia atau surat kabar - yang memungkinkan pengguna untuk secara instan "melompat" dari satu artikel ke artikel lain dengan satu klik.

Banyak iterasi gagasan ini telah datang dan pergi, seperti Apple's Hypercard , yang menerapkan konsep hypertext / hyperlink, tetapi tidak pernah digunakan melalui jaringan. World Wide Web adalah implementasi Cext yang berbasis jaringan dari konsep hypertext, dan kemungkinan lepas landas karena Tim Berners-Lee merilis perpustakaan kode browsernya secara gratis, memungkinkan orang lain untuk bereksperimen dengannya. Ini akhirnya mengarah ke browser Mosaic Marc Andreesen, pendahulu Netscape. Dan sisanya adalah sejarah.


Tapi ... seperti halnya begitu banyak teknologi, kemungkinan baru mulai muncul sehingga para desainer asli HTTP atau hypertext tidak terlalu memikirkan terlalu banyak. Web menjadi dikomersialkan dan orang-orang mulai mengembangkan situs web yang menampilkan interaktivitas stateful, seperti keranjang belanja dan login. Semakin jelas bahwa sifat HTTP tanpa dokumen dan berorientasi dokumen tidak begitu cocok untuk aplikasi seperti Desktop. Tetapi pada saat itu, sudah terlambat. Semua orang sudah menggunakan HTTP. Jadi, di sinilah kita hari ini, dengan berbagai aplikasi AJAX yang meretas mencoba yang terbaik untuk berpura-pura mereka adalah aplikasi Desktop.


3

Teknologi mungkin mencoba untuk memecahkan masalah yang sama sekarang, tetapi mereka yakin tidak di masa lalu.

Tumpukan HTML saat ini berkembang dari waktu ke waktu dari transfer dokumen teks yang sangat sederhana, melalui dokumen "visual" dengan sedikit skrip, menjadi platform aplikasi berfitur lengkap.

Pada saat HTML dimulai, tidak ada yang bisa bermimpi tentang menghubungkan ke komputer jarak jauh dan menjalankan aplikasi grafis di sana. Hanya setelah internet mendapatkan latensi dan throughput yang lebih baik, ini menjadi mungkin. Namun pada waktu itu, HTML sudah pernah ada. Semua orang tahu bahwa ini adalah cara untuk memberi pelanggan dan pengguna akses ke aplikasi grafis, yang berjalan di mesin jarak jauh.

Dan seperti halnya setiap sistem "bebas", menjadi tidak mungkin untuk "mengatur ulang" semuanya dan mulai lagi untuk melakukannya dengan lebih baik saat ini. Itu sebabnya kita perlu tutup mulut dan menggunakan HTML / CSS / JS dan hanya berharap orang-orang yang mendukungnya akhirnya akan lebih bijak dan menguburnya bersama dengan warisan selama bertahun-tahun.

Ini menjawab pertanyaan "Mengapa web menang?". Tidak ada kompetisi, web menang sebelum semuanya dimulai.


1
Pada saat HTML dimulai, sudah ada komputasi sisi server, dengan server HTTP NSCA dan SGI-nya. Sebagian besar aplikasi mengirim teks tetapi saya ingat salah satu yang mampu membuat peta kustom B / W, leluhur peta google.
mouviciel

Peta gambar memang berasal dari tahun-tahun awal dekade terakhir abad sebelumnya.
MSalters

1

Saya setuju bahwa pada prinsipnya keduanya sama. Jika Anda mengajukan pertanyaan "bagaimana kami dapat menjalankan kode pada server tetapi memberikan visualisasi pada klien jarak jauh?", Masuk akal untuk berpikir bahwa tim independen dapat memberikan solusi.

Saya menduga alasan yang satu lebih populer daripada yang lain dalam aspek-aspek tertentu adalah karena keduanya mendekati masalah yang sama dari perspektif yang sama sekali berbeda. X adalah solusi teknis untuk masalah teknis, tetapi web berevolusi sebagai kebutuhan untuk menyelesaikan masalah sosial - bagaimana saya bisa mengambil sumber daya dari server jauh dan menampilkannya di mesin lokal saya, dan melakukannya dengan cara yang mudah dan nyaman?

Web "dimenangkan" karena memecahkan masalah yang dialami oleh lebih banyak orang. Pikirkan analogi mobil: sedan mewah dan truk seolah-olah memecahkan masalah yang sama: bagaimana mengangkut sesuatu dari satu tempat ke tempat lain.

Truk itu memecahkan masalah teknis tentang bagaimana cara mengangkut sesuatu dari titik A ke titik B, dan untuk itu ia bekerja dengan cukup baik. Mobil penumpang berkembang sebagai kebutuhan bagi orang-orang untuk merasa nyaman saat mereka bepergian, dan untuk membawa lebih banyak orang dan lebih sedikit pupuk kandang. Itu menjadi kebutuhan yang membutuhkan kemudahan. Jadi, seiring waktu, jumlah mobil penumpang jauh, jauh melebihi jumlah truk pickup di jalan (saya menduga, berdasarkan pengamatan lalu lintas Chicago, mungkin berbeda di Texas? :-)

Jadi, seperti analogi mobil / truk, web dan X11 keduanya bisa dibilang menyelesaikan masalah teknis yang sama, tetapi keduanya melayani tujuan yang sepenuhnya terpisah.


1

Anda membandingkan apel dengan pir. X windows adalah tentang memisahkan rendering konten layar menjadi klien lokal, yang dapat dihubungkan oleh kawat tipis ke sumber konten. Ini benar-benar perpanjangan dari model komputasi dari era "tty kaca" ke domain grafis berkualitas tinggi. X berasal dari era ketika PC masih sangat lemah, dan sebagian besar perhitungan yang sebenarnya dilakukan pada kotak unix atau mainframe. Idenya adalah untuk memanfaatkan kekuatan "terminal X" yang relatif murah dan jaringan yang relatif lambat untuk membuat sumber daya komputasi serius ini tersedia secara grafis.

Alasan ini tidak menang di Mac dan PC adalah bahwa pengembangan mereka selalu didorong oleh keinginan untuk mendukung grafis kelas atas di aplikasi lokal , termasuk game, editor, dan grafik bisnis. Aplikasi pendukung jaringan yang mendukung adalah renungan baru-baru ini.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.