Sì, l’ho usato per testare altri plugin ultimamente. Puoi semplicemente guardare il video che ho realizzato se hai fretta o installarlo localmente e giocare con il codice. Non ho reso open source la versione tiptap su cui ho iniziato a lavorare. Ho anche lavorato per correggere il sistema di bozze. Penso che le regole su quante bozze si possono avere e dove sembrino arbitrarie. Quindi gli utenti possono avere tutte le bozze di nuovi argomenti che desiderano.
Ma come ho detto, probabilmente non lo finirò a meno che non sia davvero davvero annoiato haha
Se non c’è un incentivo finanziario, semplicemente non mi importerà abbastanza.
Ci ho pensato anch’io. Stavo lavorando a un’integrazione discourse-monero in modo da poter vendere l’accesso anticipato ai repository git (ho anche considerato l’integrazione di discourse e qualcosa come gitea o gitlab). Ma non sono sicuro se ci sia davvero una “folla” da mettere nel “crowdfunding”. Sembra che le uniche persone che pagano per discourse abbiano una relazione commerciale con l’azienda dietro discourse.
Tiptap in realtà non è un esempio comparabile perché utilizza solo scorciatoie markdown per convertire in HTML (per quanto ne so). Non è possibile modificare la formattazione già esistente utilizzando markdown (poiché la sintassi non viene visualizzata). Quindi puoi andare in una direzione ma non nell’altra. E per me qualsiasi soluzione di editor WYSIWYG per Discourse che non venga renderizzata in markdown nell’output è inaccettabile. Ciò interrompe fondamentalmente la compatibilità principale e ti blocca nel particolare plugin dell’editor che hai scelto. Immagino che se Tiptap potesse produrre markdown, l’approccio andrebbe bene.
Il punto di mostrare Typora come esempio è che armonizzano in modo abbastanza elegante WYSIWYG con markdown. Sembra che per alcuni, come @Jagster, sia desiderabile la capacità di mantenere il comportamento esistente e non “saltare” tra anteprima e sintassi. Ma penso che l’approccio di Typora sia preferibile e più intuitivo per molte altre persone.
È eccitante sentirlo! Sarei sicuramente interessato a questo.
D’accordo! Penso/spero che questo verrà migliorato nel core in futuro.
Mentre non penso che tu abbia del tutto ragione sul fatto che “solo” le persone che pagano per Discourse abbiano una relazione commerciale con CDCK (Communiteq probabilmente avrebbe qualcosa da dire a riguardo ), concordo sul fatto che per un progetto open source Discourse abbia una comunità che manca un po’ di “spirito comunitario” o “apertura” o qualcosa del genere. Non riesco a definirlo con precisione, ma le cose qui funzionano sicuramente in modo diverso rispetto a molti altri progetti open source, anche quelli gestiti da entità commerciali. Spero che veri sforzi di crowdfunding e plugin guidati dalla comunità (o anche modifiche al core) possano accadere un giorno. Mi piacerebbe particolarmente vederlo intorno allo sviluppo di temi per layout e modifiche più avanzate, come ho già menzionato: Relativa mancanza di temi - mi manca qualcosa?
Ho già spiegato la mia posizione a riguardo. Markdown è un ripiego e dobbiamo sbarazzarcene.
Non lo fa. Se qualcuno vuole davvero convertire html in markdown, può farlo e migrare indietro. Guarda gli script di migrazione e scrivine uno tuo. Non è un grosso problema.
Giusto.
Il problema principale è: tutto ciò che non è scritto in react è solo un costo sommerso a questo punto. Chiunque sia serio riguardo ad avere una carriera nello sviluppo frontend o anche chi vuole solo fare qualcosa che abbia un impatto eviterà qualsiasi cosa che non sia react.
Quindi deve esserci un incentivo finanziario che contrasti questo. Anche l’esperienza dello sviluppatore non è molto buona. Non è molto divertente lavorare con questa codebase. Quindi l’unica ragione per cui continuerei a lavorare su queste cose quando sono davvero annoiato è perché ci ho già speso così tanto tempo e mi ci sono abituato.
Il crowdfunding, secondo me, funzionerebbe più facilmente per le persone che non sono grandi aziende che gestiscono discussioni. Ci sono alcuni plugin e componenti tema/tema contribuiti dalla comunità.
Le piccole imprese spesso non dispongono di grandi fondi da investire individualmente. Ma organizzando l’interesse, un progetto finanziato dalla comunità può avere un pool uguale o addirittura più grande.
Si tratta solo di capire come fare domanda. Sia che si utilizzi qualcosa come Donate, Patreon, ecc.
E sì, penso che la tua visione di modernizzare e rendere l’editor molto facile da usare sia molto attraente per le masse.
Non sono d’accordo e uso markdown ovunque e sono contento che esista e sia ampiamente supportato.
È interessante sentirlo. Non sono uno sviluppatore, quindi non so com’è lavorare con la codebase di Discourse. Spero che la tua esperienza non sia la norma, anche se ne riconosco la validità e l’importanza.
Sarebbe meglio riformularlo come “Chiunque voglia le maggiori opportunità di lavoro nel frontend dovrebbe imparare React”?
Ho utilizzato framework non React in produzione per oltre un decennio, da piccoli a grandi progetti, da progetti greenfield a legacy. Ho utilizzato React in un paio di prototipi e progetti giocattolo per vedere come funziona. L’azienda con cui lavoro attualmente impiega buoni sviluppatori JavaScript indipendentemente dalla loro esperienza in un particolare framework.
Questo rischia di andare fuori tema, ma merita una discussione da qualche parte.
Penso che, indipendentemente dal valore di mercato immediatamente evidente, sia bene imparare una varietà di linguaggi e framework se si presenta l’opportunità, perché c’è sempre qualche approccio generalmente applicabile da imparare. Inoltre, può essere la porta d’accesso per imparare cose indirettamente. Recentemente ho imparato Go per consegnare un progetto su una piattaforma completamente diversa e mi ha ricordato i benefici della semplicità e della velocità. Ho anche imparato molto di più sulla creazione di una buona API. Se non mi fossi sforzato di imparare Golang, non avrei avuto quell’esperienza.
Ember è implacabile ma apparentemente ben progettato? La sfida di lavorare su Discourse è che ti trovi anche di fronte a una grande piattaforma personalizzata che devi imparare a navigare. Gli approcci di ingegneria inversa auto-sufficiente (in assenza di documentazione dettagliata) che sviluppi facendo ciò ti saranno utili in domini completamente diversi.
Sostengo che imparare una o due piattaforme principali sia più importante che imparare un framework specifico. Ad esempio, è più importante imparare Wordpress che concentrarsi sull’apprendimento di PHP?
Quindi non penso che imparare piattaforme diverse e i loro stack tecnologici individuali debba essere in alcun modo un problema. Poi arriva il networking professionale che ne deriva. La combinazione di tutta quell’esperienza ti metterà in buona posizione per la tua carriera.
Il problema principale che vedo qui è il conflitto tra open source e finanziamenti. La stessa CDCK ha dimostrato che è possibile costruire un business sostenibile attorno all’open source. Dobbiamo diventare piuttosto sofisticati per renderlo redditizio e fornire valore.
È responsabilità dell’intera comunità sostenere coloro che guidano l’ecosistema. Suggerirei che ciò inizi anche con la comunità che monetizza le proprie piattaforme in modo da potersi permettere di contribuire. E molti lo hanno fatto: sono molto grato per il lavoro che mi è stato finanziato dai più ambiziosi e laboriosi uomini d’affari che frequentano qui.
Il fatto è che se qualcuno sta iniziando ora o è ancora all’inizio della sua carriera, imparerà e si concentrerà su React. Concentrarsi su una tecnologia è come fare una scommessa e scommettere una carriera su qualsiasi cosa che non sia React in questo momento nel frontend è una cattiva scelta. L’unica alternativa legittima potrebbe essere Vue, ma non è assolutamente Ember.
Direi che il numero di persone con una carriera incentrata su Ember ha probabilmente raggiunto il picco tempo fa.
vedi un enorme afflusso di persone che vogliono imparare Ember e il codebase di Discourse?
Non lo vedo. È un segno che questo è software legacy. Che ha raggiunto il picco del suo potenziale. Non c’è un enorme afflusso di persone che vogliono usarlo o lavorarci. Anche dopo l’aumento del lavoro da casa e l’uso di software di collaborazione remota. Le persone preferiscono usare Zoom e Discord.
questo è quello che intendo per esperienza dello sviluppatore.
Questo è un buon punto. Discourse è principalmente un prodotto: un forum di community/supporto self-hosted per un pubblico un po’ nerd. Non sarà mai molto più di questo perché è da lì che provengono i suoi finanziamenti. Quindi la maggior parte delle decisioni sarà presa per accontentare questo pubblico.
Per tornare all’argomento. Sostituire il compositore markdown significa rendere questo software meno nerd. Quindi significa una divisione dal pubblico a cui è rivolto.
Non è facile uscire da questo minimo locale.
quindi una volta che un software ha trovato il suo pubblico, inizia un ciclo di feedback riflessivo che porta a più funzionalità che accontentano questo pubblico, mentre l’usabilità per altri gruppi viene sempre più trascurata.
Solo la mia opinione (2 centesimi):\n\nAbbiamo circa 1000 utenti attivi nel nostro forum e una buona parte di utenti nella fascia d’età 50+ che vanno tutti d’accordo con markdown e non abbiamo mai avuto lamentele.\n\nLa mia conclusione: se un gruppo di fumatori può imparare a usare markdown, chiunque può.
Ci sono 3,5 milioni di fumatori di cannabis in Germania. L’84% di tutti i tedeschi è a favore della legalizzazione. Quindi penso che ci sia molto spazio per la crescita del tuo forum. La base utenti attuale e la sua base utenti potenziale sono distanti ordini di grandezza. Non basta lavorare per questo obiettivo apportando piccoli miglioramenti o modifiche.
Le modifiche che placano la base utenti attuale potrebbero persino inibirne la crescita.
Le modifiche sono sempre compromessi. Qualcosa che potrebbe rendere la vita più comoda per un utente esperto allontanerà un nuovo utente. A un certo punto la barriera è così alta che le nuove registrazioni si esauriscono e il forum decade lentamente.
Hai ragione. Potremmo voler provare a sondare gli (ex) membri per identificare quali siano state le loro ragioni per lasciare il nostro forum. Forse alcuni di loro sono stati sopraffatti dall’editor markdown.
Sì, questo è assolutamente rappresentativo di alcuni punti che ho cercato di sollevare in precedenza sulla camera dell’eco sia di Meta stessa che dei clienti paganti di CDCK. Ovviamente vuoi rendere felici i tuoi clienti esistenti, ma è anche chiaro che c’è un mercato complessivo molto più ampio per le “piattaforme di community/discussione” che è servito da un gruppo di altri attori, alcuni dei quali stanno sicuramente facendo cose che li aiutano a ottenere una vendita invece di Discourse. Una di queste cose potrebbe benissimo essere il WYSIWYG, ma è solo parte di un problema più ampio, a mio avviso. Il design e il tema generali sono un altro, che ho già menzionato sopra, ma vale la pena ripeterlo in questo contesto separato: Mancanza relativa di temi - mi sfugge qualcosa?
punto molto buono. Questa è solo la punta dell’iceberg. Ci sono molte cose che potrebbero essere migliorate. Ad esempio, le regole idiosincratiche su quanti bozze si possono avere. All’inizio ho pensato che fosse solo un bug, ma in realtà è intenzionale così com’è.
Cerco anche di affrontare questo aspetto.
Quindi è completato? In caso contrario, ti preghiamo di essere così gentile da descrivere i problemi noti e cosa fare nel primo argomento, in modo che gli amministratori delle community personalizzate di Discourse possano facilmente decidere se utilizzarlo o meno.
Non arrenderti ancora! Penso di poter parlare per molti altri utenti qui quando dico che questo Plugin sarebbe una svolta assoluta per Discourse e cambierebbe tutto, specialmente in certi casi d’uso. Ti incoraggio vivamente a continuare e a percorrere l’ultimo miglio.
Potresti elaborare? Potrei averne bisogno, quindi sono molto interessato a quello che hai da dire. Hai tutta la mia attenzione ora…
Ci ho pensato ancora. Penso che non sia una buona idea sostituire il composer. Perché significa che ci sarà sempre una lotta per stare al passo con i cambiamenti attuali in discourse e non voglio passare così tanto tempo a mantenerlo.
Userò le conoscenze che ho raccolto da questo per costruire qualcosa che funzioni a fianco dell’interfaccia utente di discourse invece di sostituirla.
Sì, in realtà ho già dato un’occhiata e lo userò. Integrano persino Excalidraw nell’editor. È fantastico. Mi sono unito al loro canale Discord un po’ di tempo fa per discutere di un problema relativo all’upload di immagini. Attualmente il loro esempio per Excalidraw incorpora le immagini come SVG, il che rappresenta un problema di sicurezza e deve essere modificato. Ci sono quindi alcuni piccoli dettagli di cui occuparsi.
Ma rispetto a CKEditor o Tiptap sarà molto più facile da usare. Per dare anche un breve aggiornamento su questo argomento in generale:
Come detto in precedenza, modificare il frontend di Discourse quando si tratta di qualcosa di importante come questo non è una buona idea. Ecco perché è molto meglio implementare questa funzionalità come parte di un’aggiunta all’interfaccia tradizionale, invece di cercare di sostituirla. Le conoscenze acquisite dal lavoro svolto finora saranno utilizzate qui:
mentre è orientato a un caso d’uso web3 e conterrà alcune funzionalità web3, non c’è necessità di utilizzarle.
Quindi sarà possibile utilizzare questo plugin per creare categorie che hanno un editor lessicale. Ciò significa anche molto meno rischio nel provarlo. Perché l’esperimento sarà limitato solo a una parte del sito.
Attualmente sono ancora impegnato con il lavoro sulle sottoscrizioni di criptovalute per Discourse. Una volta terminato, mi concentrerò nuovamente sul portare avanti questo progetto.