Grazie! Questo aiuta sicuramente e riduce il panico.
Ma:
sono ancora entrambi punti molto validi.
Penso che molti di noi stiano sostenendo non se la “funzionalità X” debba o non debba essere supportata dalla “versione Y” per “tempo Z”, ma che Discourse dovrebbe offrire un degrado aggraziato, magari qualcosa come una modalità HTML semplice + POST HTTP come offrivano i primi forum. Idealmente, ciò dovrebbe essere prioritario rispetto alle nuove funzionalità, soprattutto rispetto alle modifiche estetiche, ma sostengo anche che dovrebbe essere prioritario rispetto alle ottimizzazioni delle prestazioni.
Gli utenti di Discourse non dovrebbero dover scegliere tra la community e le nuove funzionalità — e questa parte sembra una questione culturale. Sembra che gli sviluppatori vogliano “muoversi un po’ velocemente, non troppo velocemente, rompere alcune cose ma non troppe”. Questa potrebbe essere una posizione perfettamente ragionevole per un’azienda di software, ma NON è necessariamente la stessa posizione che vorrebbero le community di Discourse. Alcune community vorrebbero muoversi più velocemente, mentre altre preferirebbero un movimento molto più lento o nessuno.
Secondo me, Discourse oggi è già “abbastanza buono” e se ci fosse un’opzione per i clienti ospitati di scegliere un ramo di supporto a lungo termine senza nuove funzionalità aggiunte per i prossimi 10 anni, solo correzioni di sicurezza critiche, la sceglierei totalmente — anche se la nuova versione fosse 10 volte più veloce. Preferirei di gran lunga un forum lento che tutti possano usare piuttosto che uno che perde gradualmente utenti solo per offrire un’esperienza più veloce e brillante ai sopravvissuti.
Ma non tutti sarebbero d’accordo. Quel ritmo sarebbe troppo lento sia per gli sviluppatori (presumo) che per altre community di Discourse… dipende totalmente dai loro dati demografici di utenti e dispositivi. Un forum per anziani non inseguirà mai le stesse funzionalità di un forum sull’IA, per esempio.
Ma non dovrebbero aver BISOGNO di combattere l’uno contro l’altro in questo modo. Questi non sono obiettivi mutualmente esclusivi. Il degrado aggraziato è stato un principio fondamentale fin dai primi giorni del web, e Discourse è già abbastanza headless (con varie API, e anche dimostrato da implementazioni di terze parti come Discorkie) che dovrebbe essere possibile fornire una modalità “HTML semplice” con lettura + pubblicazione di base. Non ha bisogno di temi eleganti, non ha bisogno di paginazione infinita, non ha nemmeno necessariamente bisogno di modifica e notifiche e tutte le altre funzionalità desiderabili. Deve solo essere un’esperienza di base utilizzabile che permetta alle persone di continuare a utilizzare il forum per la sua funzione prevista, leggere e pubblicare. Non può offrire più di un’UX in stile Usenet degli anni ‘90 e sarebbe comunque meglio che tagliare completamente le persone. Con un po’ più di tempo di sviluppo, potrebbe offrire un’interfaccia utente in stile era PHP di vBulletin e sarebbe comunque un enorme miglioramento rispetto alla situazione “Spiacenti, non è più possibile pubblicare” (che vedremo ancora a luglio).
IMHO Discourse è (o dovrebbe essere) soprattutto community. Non è una demo tecnologica (più), e mentre la mia preferenza personale è che sia considerato un “software stabile e noioso” che raramente cambia… capisco che non è quello che gli sviluppatori e altre community di Discourse potrebbero volere. Va bene. Non è un mainframe bancario 
Ma d’altra parte, non ha nemmeno bisogno di inseguire continui miglioramenti dei browser (che non finiranno mai). Tra i due estremi, una modalità HTML di base permetterebbe agli utenti di continuare a pubblicare molto tempo dopo che i loro browser saranno obsoleti, consentendo anche uno sviluppo di funzionalità più rapido sul ramo principale perché gli utenti avranno qualcosa a cui tornare.
Come bonus, potrebbe effettivamente permetterti di gestire il tipo di sviluppo basato su finestre temporali che vuoi fare (ad esempio, “supporteremo browser fino a 2 anni fa, o al 95% del marchio caniuse”) piuttosto che scegliere singole funzionalità in ogni possibile permutazione di hardware + sistema operativo + browser + fork. Qualsiasi cosa più vecchia di quel target potrà comunque pubblicare tramite la modalità HTML di base, ma non potrà utilizzare i temi più recenti, _____, ______, _____ ecc. (il che va benissimo perché probabilmente non gli importa di tutto ciò). Ti libera dal dover ricontrollare ogni funzionalità con ogni browser… se un utente non può usare una funzionalità elegante, beh, sarebbe davvero compito suo aggiornare a un nuovo browser. Ma almeno non verrebbero cacciati dalle loro community.