Perché il web ha vinto lo spazio delle applicazioni remote e X no?

Il sistema X Window ha 25 anni, ieri è stato il suo compleanno (il 15).

Come probabilmente saprai, una delle sue caratteristiche più importanti è la separazione tra lato server e lato client in un modo che né i sistemi di finestre Microsoft, Apple o Wayland hanno.

Ai tempi (scusate per il fraseggio ambiguo) molti credevano che X avrebbe dominato su altri modi di creare finestre a causa di questa separazione tra server e client, consentendo all'applicazione di essere eseguita su un server altrove mentre l'utente fa clic e digita su di lei proprio computer a casa.

Questo uso ovviamente esiste ancora, ma nella migliore delle ipotesi è emarginato. Quando scriviamo e usiamo programmi che girano su un server, usiamo quasi sempre il web con il suo html / css / js.

Perché il web ha vinto e X no? Le tecnologie utilizzate per il web (detto html / css / js) sono un casino. Combinato con tutti i back-end-framework (Rails, Django e tutti) è davvero una giungla da percorrere. Tuttavia il Web prospera con creatività e progressi, mentre le app X remote non lo fanno.

Sembra assolutamente ovvio e fondamentale ora, ma l'innovazione killer del world wide web è stata il collegamento ipertestuale. Anche se X non fosse completamente inutilizzabile su un collegamento modem, la sua incapacità di avviare un processo completamente nuovo su un server completamente nuovo tramite un solo clic ne ostacolerebbe l'adozione per quel tipo di caso d'uso.

Perché X richiede di avere una laurea in CS per scrivere una domanda. Mentre Web richiede di avere la possibilità di digitare (nemmeno quello).

Soprattutto ai primi tempi quando il web era solo html. È possibile aprire un terminale e creare un display funzionante in 10 minuti e quindi migliorarlo in modo interattivo con feedback immediato. Questa barra di accesso bassa ha stimolato un massiccio assorbimento da parte dell'utente. La creazione di un'applicazione X-Server invece è un'attività non banale anche per i programmatori esperti.

Ci sono voluti 10 anni perché il Web fosse un concorrente diretto di X applicatoin in termini di funzionalità e fornisse la stessa interfaccia grafica delle abilità. Questa funzionalità è stata aggiunta allo stack di lingue nel tempo, consentendo agli sviluppatori di padroneggiare un set di funzionalità prima che fosse aggiunto il successivo; quindi questa graduale espansione della complessità tecnologica ha mantenuto un livello basso (per le persone che sono già sul campo e ce ne sono molte). Saltare sul campo ora è molto più difficile di quanto non fosse 10 anni fa, ma è ancora possibile e il feedback istantaneo della rete rende l'apprendimento più gratificante (gli umani hanno bisogno di una gratificazione rapida per rafforzare le loro pulsioni).

Il costo è un altro driver. Il costo effettivo dell'apprendimento di competenze di programmazione sufficienti per sviluppare un X-Server è significativo. Inoltre, la disponibilità di server su cui eseguire l'applicazione ha aumentato i costi. Imparare a scrivere HTML non era praticamente nulla per far funzionare la pagina "Hello World" e i provider di servizi Internet fornivano hosting gratuito per ispirarti a ottenere una connessione web. Quindi puoi esercitarti gratuitamente. Quando alla fine hai avuto bisogno di attività di hosting, la disponibilità delle società di hosting è cresciuta e il costo è sempre stato relativamente economico.

La risposta è che "molte tecnologie sono adottate per ragioni storiche o socio-politiche arbitrarie piuttosto che per ragioni tecniche". La migliore soluzione per un determinato problema non diventa sempre la tecnologia dominante. (In realtà, lo fa raramente.)

Nel 2012, dove i server HTTP vengono utilizzati per creare applicazioni interattive alla pari con le applicazioni desktop, il confronto tra HTTP e X è interessante. Con il senno di poi, X è probabilmente una tecnologia migliore per sviluppare ricche applicazioni interattive distribuite in rete. Le applicazioni interattive simili a desktop non si associano bene a una tecnologia senza stato e orientata ai documenti come HTTP, e questa discrepanza ha storicamente portato a tutti i tipi di soluzioni (hack) per creare stato, come cookie, sessioni, ecc.

Ma lo scopo originale di HTTP non era quello di sviluppare app simili a desktop. Si trattava di recuperare documenti e visualizzare informazioni , informazioni che potevano essere collegate ad altri documenti che potevano anche essere visualizzati istantaneamente. L'idea di una raccolta di documenti collegati risale agli anni '60 con il " Progetto Xanadu " di Theodore Nelson . Il Web doveva essere un'implementazione del concetto di ipertesto di Nelson , che era un tentativo di informatizzare la pagina stampata - come l'enciclopedia o il giornale - permettendo all'utente di "saltare" istantaneamente da un articolo all'altro con un solo clic.

Molte iterazioni di questa idea sono andate e sono andate, come l' hypercard di Apple , che ha implementato il concetto di ipertesto / hyperlink, ma non è mai stato distribuito su reti. Il World Wide Web era l'implementazione basata su rete del CERN del concetto di ipertesto e probabilmente decollò perché Tim Berners-Lee pubblicò gratuitamente la sua libreria di codici del browser, permettendo ad altri di sperimentarlo. Questo alla fine portò al browser Mosaic di Marc Andreesen, il predecessore di Netscape. E il resto è storia.

Ma ... come con così tante tecnologie, iniziarono ad emergere nuove possibilità che i progettisti originali di HTTP o ipertesto non pensavano davvero troppo. Il web è stato commercializzato e le persone hanno iniziato a sviluppare siti Web che presentavano interattività con stato, come carrelli della spesa e accessi. È diventato sempre più evidente che la natura senza stato e orientata ai documenti dell'HTTP non era molto adatta alle applicazioni desktop. Ma a quel punto era troppo tardi. Tutti stavano già utilizzando HTTP. Quindi, eccoci qui oggi, con varie applicazioni AJAX hacky che fanno del loro meglio per far finta di essere app desktop.

Le tecnologie potrebbero provare a risolvere problemi simili ora, ma sicuramente non lo hanno fatto in passato.

L'attuale stack HTML si è evoluto nel tempo dal semplice trasferimento di documenti di testo, attraverso documenti "visivi" con pochi script, in una piattaforma applicativa completa.

All'inizio dell'HTML, nessuno poteva mai sognare di collegarsi a un computer remoto e di eseguire applicazioni grafiche lì. Solo dopo che Internet ha migliorato la latenza e il throughput, questo è diventato possibile. Eppure a quel tempo, l'HTML era già sempre presente. Tutti sapevano che questo era un modo per dare a clienti e utenti l'accesso all'applicazione grafica, che viene eseguita sul computer remoto.

E come con ogni sistema "libero", è diventato impossibile "resettare" il tutto e ricominciare da capo per farlo meglio questa volta. Ecco perché dobbiamo tacere e usare HTML / CSS / JS e desiderare solo che le persone che lo supportano possano finalmente sottrarsi e seppellirlo insieme alla sua eredità lunga anni.

Questo risponde alla domanda "Perché ha vinto il web?". Non c'era competizione, il web ha vinto prima ancora che tutto iniziasse.

Concordo sul fatto che, in linea di principio, i due sono simili. Se poni la domanda "come possiamo eseguire il codice su un server ma fornire la visualizzazione su un client remoto?", È ragionevole pensare che i team indipendenti potrebbero trovare entrambe le soluzioni.

Sospetto che il motivo per cui uno è più popolare dell'altro in certi aspetti è perché i due affrontano lo stesso problema da prospettive completamente diverse. X è una soluzione tecnica a un problema tecnico, ma il Web si è evoluto come una necessità di risolvere un problema sociale : come posso prendere risorse da un server remoto e visualizzarlo sul mio computer locale, e farlo in modo facile e conveniente?

Il web "ha vinto" perché ha risolto un problema riscontrato da più persone. Pensa a un'analogia con l'auto: sia le berline di lusso che i camion risolvono apparentemente lo stesso problema: come trasportare qualcosa da un posto a un altro.

Il camion ha risolto il problema tecnico di letteralmente come trasportare qualcosa dal punto A al punto B, e per questo funziona abbastanza bene. L'autovettura si è evoluta come necessità per le persone di sentirsi a proprio agio mentre viaggiano e di trasportare più persone e meno letame. Divenne una necessità che richiedeva comodità. Quindi, nel tempo, il numero di autovetture lontano, di gran lunga superiore al numero di camioncini sulla strada (immagino, in base all'osservazione del traffico di Chicago, forse è diverso in Texas? :-)

Quindi, come l'analogia auto / camion, sia il web che l'X11 risolvono probabilmente lo stesso problema tecnico, ma servono a scopi completamente separati.

Stai confrontando le mele con le pere. X windows riguarda la separazione del rendering del contenuto dello schermo in un client locale, che potrebbe essere collegato con un filo sottile alla fonte del contenuto. È davvero un'estensione del modello computazionale dall'era del "vetro tty" al dominio della grafica di alta qualità. X ha avuto origine nell'era in cui i PC erano ancora piuttosto deboli e la maggior parte del calcolo reale era fatta su scatole unix o mainframe. L'idea era di sfruttare la potenza di "terminali X" relativamente economici e di reti relativamente lente per rendere graficamente disponibili queste serie risorse di calcolo.

Le ragioni per cui questo non ha vinto su Mac e PC è che il loro sviluppo è stato sempre guidato dal desiderio di supportare la grafica di fascia alta nelle applicazioni locali , inclusi giochi, editor e grafica aziendale. Il supporto di applicazioni residenti in rete è un ripensamento recente.