Sim, tenho usado para testar outros plugins ultimamente. Você pode assistir ao vídeo que fiz se estiver com pressa ou instalá-lo localmente e brincar com o código. Não abri o código da versão tiptap que comecei a trabalhar. Também trabalhei em corrigir o sistema de rascunhos. Acho que as regras sobre quantos rascunhos uma pessoa pode ter e onde parecem arbitrárias. Portanto, os usuários podem ter quantos rascunhos de novos tópicos quiserem.
Mas, como eu disse, provavelmente não vou terminar, a menos que esteja realmente, realmente entediado haha
Se não houver incentivo financeiro, simplesmente não me importarei o suficiente.
Eu também pensei sobre isso. Estava trabalhando em uma integração discourse-monero para que eu pudesse vender acesso antecipado a repositórios git (também considerei integrar discourse e algo como gitea ou gitlab). Mas não tenho certeza se realmente existe uma “multidão” para colocar no “financiamento coletivo”. Parece que as únicas pessoas que pagam pelo discourse têm um relacionamento comercial com a empresa por trás do discourse.
Tiptap não é realmente um exemplo comparável, pois ele apenas usa atalhos de markdown para converter para HTML (pelo que sei). Você não pode editar a formatação que já existe usando markdown (porque a sintaxe não é exibida). Então, você pode ir em uma direção, mas não na outra. E, para mim, qualquer solução de editor WYSIWYG para Discourse que não renderize em markdown na saída é inaceitável. Isso quebra fundamentalmente a compatibilidade principal e te prende ao plugin de editor específico que você escolheu. Acho que se o Tiptap pudesse gerar markdown, a abordagem seria aceitável.
O ponto de mostrar o Typora como exemplo é que eles harmonizam WYSIWYG com markdown de forma bastante elegante. Parece que, para alguns, como @Jagster, a capacidade de manter o comportamento existente e não “pular” entre a visualização e a sintaxe seria desejável. Mas eu acho que a abordagem do Typora é preferível e mais intuitiva para muitas outras pessoas.
É animador ouvir isso! Eu definitivamente estaria interessado nisso.
Concordo! Acho/espero que isso seja melhorado no core no futuro.
Embora eu não ache que você esteja totalmente certo de que “as únicas” pessoas que pagam por Discourse têm um relacionamento comercial com a CDCK (a Communiteq provavelmente teria algo a dizer sobre isso ), concordo que, para um projeto de código aberto, o Discourse tem uma comunidade um tanto carente de “espírito comunitário” ou “abertura” ou algo assim. Não consigo identificar exatamente o quê, mas as coisas definitivamente funcionam de maneira diferente aqui do que em muitos outros projetos de código aberto, mesmo aqueles administrados por entidades comerciais. Tenho esperança de que verdadeiros esforços de financiamento coletivo e plugins de propriedade/direcionados pela comunidade (ou até mesmo mudanças no core) possam acontecer um dia. Eu gostaria especialmente de ver isso em torno do desenvolvimento de temas para layouts e alterações mais avançadas, como mencionei antes: Falta relativa de temas - estou perdendo algo?
Eu já expliquei minha posição sobre isso. Markdown é uma muleta e precisamos nos livrar dele.
Não quebra. Se alguém realmente quiser converter HTML de volta para markdown, pode fazer isso e migrar de volta. Olhe os scripts de migração e escreva o seu. Não é grande coisa.
Ponto válido.
O principal problema é: tudo que não é escrito em React é apenas um custo irrecuperável neste momento. Qualquer pessoa séria sobre ter uma carreira em desenvolvimento frontend ou mesmo alguém que queira fazer algo que tenha impacto evitará qualquer coisa que não seja React.
Então, precisa haver um incentivo financeiro que contrabalance isso. A experiência do desenvolvedor também não é muito boa. Não é muito divertido trabalhar com essa base de código. Então, a única razão pela qual eu continuaria trabalhando nisso quando estivesse realmente entediado é porque já gastei tanto tempo nisso e me acostumei com isso.
Financiamento coletivo, na minha opinião, funcionaria mais facilmente para pessoas que não são grandes empresas que executam o Discourse. Existem alguns plugins e componentes de tema contribuídos pela comunidade.
Grandes empresas geralmente não têm grandes reservas de fundos para investir individualmente. Mas, organizando o interesse, um projeto financiado pela comunidade pode ter uma reserva igual ou até maior.
É apenas uma questão de descobrir como aplicar. Se usando algo como Doar, Patreon, etc.
E sim, acho que sua visão de modernizar e tornar o editor muito fácil de usar é muito atraente para as massas.
Discordo e uso markdown em todos os lugares e fico feliz que ele exista e seja amplamente suportado.
Interessante ouvir isso. Eu mesmo não sou um desenvolvedor, então não sei como é trabalhar com a base de código do Discourse. Espero que sua experiência não seja a norma, embora eu também reconheça sua validade e importância.
Isso seria melhor formulado como “qualquer um que queira as maiores oportunidades de emprego em frontend deve aprender React”?
Tenho usado frameworks não-React em produção por mais de uma década, de projetos pequenos a grandes, de projetos do zero a legados. Usei React em alguns protótipos e projetos de teste para ver como funciona. A empresa em que estou atualmente emprega bons desenvolvedores JavaScript, independentemente da experiência em um framework específico.
Isso corre o risco de sair completamente do tópico, mas merece discussão em algum lugar.
Acho que, independentemente do valor de mercado imediatamente óbvio, é bom aprender uma variedade de linguagens e frameworks se a oportunidade surgir, porque sempre há alguma abordagem geralmente aplicável para aprender. Além disso, pode ser a porta de entrada para aprender coisas indiretamente. Recentemente, aprendi Go para entregar um projeto em uma plataforma completamente diferente e isso me lembrou dos benefícios da simplicidade e velocidade. Também aprendi muito mais sobre como construir uma boa API. Se eu não tivesse me esforçado para aprender Golang, não teria tido essa experiência.
Ember é implacável, mas aparentemente bem projetado? O desafio de trabalhar no Discourse é que você também se depara com uma grande plataforma personalizada que precisa aprender a navegar. As abordagens de engenharia reversa autossuficiente (na ausência de documentação detalhada) que você desenvolve ao fazer isso o beneficiarão em domínios completamente diferentes.
Eu argumentaria que aprender uma ou duas plataformas importantes é mais importante do que aprender um framework específico. Por exemplo, é mais importante aprender Wordpress do que focar em aprender PHP?
Portanto, não acho que aprender diferentes plataformas e seus pilhas de tecnologia individuais devam ser um problema de forma alguma. Em seguida, vem o networking profissional que vem com isso. A combinação de toda essa experiência o colocará em boa posição para sua carreira.
O principal problema que vejo aqui é o conflito entre código aberto e financiamento. A própria CDCK provou que construir um negócio sustentável em torno de código aberto é alcançável. Temos que nos tornar bastante sofisticados para que isso gere lucro e entregue valor.
É responsabilidade de toda a comunidade apoiar aqueles que estão impulsionando o ecossistema. Eu sugiro que isso também comece com a comunidade monetizando suas próprias plataformas para que possam pagar para contribuir. E muitas o fizeram: sou muito grato pelo trabalho que fui financiado para fazer pelas pessoas de negócios mais ambiciosas e trabalhadoras que frequentam aqui.
A questão é: se alguém está começando agora ou ainda está no início de sua carreira, aprenderá e se concentrará no React. Focar em uma tecnologia é como fazer uma aposta, e apostar a carreira em qualquer coisa que não seja React agora no frontend é uma má escolha. A única alternativa legítima pode ser o Vue, mas definitivamente não é o Ember.
Eu diria que o número de pessoas com carreira focada em Ember provavelmente atingiu o pico há algum tempo.
você vê um grande afluxo de pessoas querendo aprender Ember e o codebase do Discourse?
Eu não vejo. É um sinal de que este é um software legado. Que atingiu o pico de seu potencial. Não há um grande afluxo de pessoas querendo usá-lo ou trabalhar nele. Mesmo após o aumento do trabalho em casa e o uso de software de colaboração remota. As pessoas preferem usar Zoom e Discord.
é isso que eu quero dizer com experiência do desenvolvedor.
Este é um bom ponto. O Discourse é, em sua maioria, um produto: um fórum de comunidade/suporte auto-hospedado para um público um pouco nerd. Nunca será muito mais do que isso porque é de onde vem seu financiamento. Portanto, a maioria das decisões será tomada para agradar a esse público.
Para voltar ao tópico. Substituir o compositor markdown significa tornar este software menos nerd. Portanto, significa uma divisão do público para o qual ele é voltado.
Não é fácil sair deste mínimo local.
então, uma vez que um software encontrou seu público, um loop de feedback reflexivo começa, que leva a mais recursos que agradam a esse público, enquanto a usabilidade para outros grupos é cada vez mais negligenciada.
Só dando minha opinião:\n\nTemos cerca de 1.000 usuários ativos em nosso fórum e uma boa parte deles tem mais de 50 anos, que se dão bem com markdown e nunca tivemos reclamações.\n\nMinha conclusão: Se um bando de maconheiros consegue aprender a usar o markdown, qualquer um consegue.
Existem 3,5 milhões de fumantes de cannabis na Alemanha. 84% de todos os alemães são a favor da legalização. Então, acho que há muito espaço para crescimento em seu fórum. A base de usuários atual e sua base de usuários potencial estão a ordens de magnitude de distância. Não é suficiente trabalhar para atingir esse objetivo fazendo pequenas melhorias ou modificações.
Mudanças que acalmam a base de usuários atual podem até inibir seu crescimento.
Mudanças são sempre um compromisso. Algo que pode tornar a vida mais conveniente para um usuário avançado afastará um novo usuário. Em algum momento, a barreira é tão alta que novos registros diminuem e o fórum lentamente decai.
Você tem um ponto. Talvez devêssemos tentar pesquisar (ex) membros para identificar os motivos pelos quais eles deixaram nosso fórum. Talvez alguns deles tenham ficado sobrecarregados com o editor markdown.
Sim, isso é absolutamente representativo de alguns pontos que tentei levantar antes sobre a câmara de eco da própria Meta e dos clientes pagantes existentes da CDCK. Obviamente, você quer deixar seus clientes existentes felizes, mas também está claro que há um mercado geral muito maior para “plataformas de comunidade/discussão” que está sendo atendido por vários outros players, alguns dos quais estão definitivamente fazendo coisas que os ajudam a fechar uma venda em vez do Discourse. Uma dessas coisas pode muito bem ser WYSIWYG, mas é apenas parte de um problema mais amplo, na minha opinião. O design e a tematização em geral são outro, que já mencionei acima, mas vale a pena repetir neste contexto separado: Falta relativa de temas - estou perdendo alguma coisa?
ponto muito bom. Isso é apenas a ponta do iceberg. Há muitas coisas que poderiam ser melhoradas. Por exemplo, as regras idiossincráticas sobre quantos rascunhos você tem permissão para ter. Eu pensei que era apenas um bug, mas na verdade é intencional como é.
Eu também tento abordar isso.
Então, está concluído? Se não, por favor, seja tão gentil e descreva os problemas conhecidos e o que fazer no primeiro tópico, para que os administradores de comunidades personalizadas do Discourse possam facilmente decidir usá-lo ou não.
Não desista ainda! Acho que posso falar por muitos outros usuários aqui quando digo que este Plugin seria um avanço absoluto para o Discourse e mudaria tudo, especialmente em certos casos de uso. Eu o encorajo fortemente a continuar e terminar a última milha.
Você poderia elaborar sobre isso? Eu posso ter uma necessidade para isso, então estou muito interessado no que você tem a dizer. Você tem toda a minha atenção agora…
Pensei mais sobre isso. Acho que não é uma boa ideia substituir o composer. Porque isso significa que sempre haverá uma luta para acompanhar as mudanças atuais no discourse e eu não quero gastar tanto tempo mantendo-o.
Vou usar o conhecimento que coletei disso e construir algo que funcione ao lado da interface do usuário do discourse em vez de substituí-la.
Sim, na verdade, já dei uma olhada atenta e vou usá-lo. Eles até integram o Excalidraw ao editor. É incrível. Entrei no canal deles no Discord há um tempo para discutir um problema relacionado ao upload de imagens. Atualmente, o exemplo deles para o Excalidraw incorpora as imagens como SVG, o que é uma preocupação de segurança e precisa ser alterado. Portanto, há alguns pequenos detalhes que precisam ser cuidados.
Mas, em comparação com o CKEditor ou Tiptap, será muito mais fácil de usar. Para dar também uma breve atualização sobre este tópico em geral:
Como dito antes, modificar o frontend do Discourse quando se trata de algo importante como isso não é uma boa ideia. É por isso que é um caminho muito melhor implementar essa funcionalidade como parte de uma adição à interface tradicional, em vez de tentar substituí-la. O conhecimento adquirido com o trabalho aqui até agora será usado aqui:
enquanto é voltado para um caso de uso web3 e conterá alguns recursos web3, não há necessidade de usá-los.
Portanto, será possível usar este plugin para criar categorias que tenham um editor lexical. Isso também significa um risco muito menor ao tentar isso. Porque o experimento será limitado a apenas parte do site.
Atualmente, ainda estou ocupado com o trabalho em assinaturas de criptomoedas para o Discourse. Assim que isso for feito, voltarei a focar em avançar nisso.
), concordo que, para um projeto de código aberto, o Discourse tem uma comunidade um tanto carente de “espírito comunitário” ou “abertura” ou algo assim. Não consigo identificar exatamente o quê, mas as coisas definitivamente funcionam de maneira diferente aqui do que em muitos outros projetos de código aberto, mesmo aqueles administrados por entidades comerciais. Tenho esperança de que verdadeiros esforços de financiamento coletivo e plugins de propriedade/direcionados pela comunidade (ou até mesmo mudanças no core) possam acontecer um dia. Eu gostaria especialmente de ver isso em torno do desenvolvimento de temas para layouts e alterações mais avançadas, como mencionei antes: 
